Not sure about what’s going on in your email headers? We’ve got you covered.
Emails look pretty simple at first glance. You have a To, From, Subject, and the message body. There’s not much else to see, right?
Not quite. If you look below the waterline, there is actually a lot going on. Locked up in the headers is a lot of data—and if you want to find out whether a sender really is who they claim to be, this is where you want to look.
If you look at the raw email (sometimes called “source” or “original”), you can see more information about the email and how it got to you. Specifically, you want to look for headers that indicate the authentication status of the email message.
Email authentication consists of:
These three standards work together to help establish the identity of a sender. You can see the results of these evaluations in every email you get.
What you see in the email headers depends on your email service provider. They all show authentication results for SPF, DKIM, and DMARC checks in standard headers, but each has subtle variations in how they display the information.
Below we will show how you can see the authentication results for SPF, DKIM, and DMARC. For an email to pass DMARC, it must pass either SPF or DKIM with an aligned identifier. What this typically means is that the domain used for the SPF or DKIM check and the domain publishing the DMARC policy must at least be part of the same DNS namespace.
For example, marketing.company.com and mail.company.com are both part of the company.com namespace, and are therefore aligned. Some services require that you set up both if the sending service supports it.
Email authentication-results headers
Each of the three major mailbox providers includes a header labeled “Authentication-Results” in every message they deliver to a mailbox on their systems. This header contains not only the results (pass/fail) of any SPF, DKIM, and DMARC checks that were performed, but also find other information that contributed to this check.
Here is how some large email providers represent this information.
Authentication-Results: mx.google.com; dkim=pass email@example.com header.s=google2048 header.b=Z8L6tjHb; spf=pass (google.com: domain of [redacted]@valimail.com designates 220.127.116.11 as permitted sender) smtp.mailfrom=[redacted]@valimail.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=valimail.com
Authentication-Results: atlas321.free.mail.ne1.yahoo.com; dkim=pass firstname.lastname@example.org header.s=google2048; spf=pass smtp.mailfrom=valimail.com; dmarc=pass(p=REJECT) header.from=valimail.com;
Authentication-Results: spf=pass (sender IP is 18.104.22.168) smtp.mailfrom=valimail.com; dkim=pass (signature was verified) header.d=valimail.com;dmarc=pass action=none header.from=valimail.com;compauth=pass reason=100
However, they each have their own differences.
All three provide the SPF verdict (spf=pass in all three examples). Google shows the SPF domain in the “domain of [redacted]@valimail.com” part and the IP that was checked against the SPF record in the “designates 22.214.171.124” phrase.
Yahoo! only shows the SPF domain in the smtp.mailfrom= tag without showing the client IP. It would have to be located by parsing the Received headers. Microsoft uses the smtp.mailfrom= tag for the SPF domain and shows the IP in the “(sender IP is 126.96.36.199)” phrase.
The results of the DKIM evaluation will show the domain that was evaluated. To ensure you are looking at the proper result, look for the one that matches the domain in the From address for the email.
All three provide the DKIM verdict (dkim=pass). Google essentially shows the signing domain in the header.i= tag, the DKIM selector in the header.s= tag, and the first few characters of the DKIM hash in the header.b= tag.
Yahoo does the same, except for the header.b= tag, which it doesn’t include.
Microsoft shows the signing domain in the header.d= tag, but no selector information.
The DMARC results are relatively easy to read. The results will show whether or not the email passed DMARC. All three provide the DMARC verdict (dmarc=pass) and the DMARC policy domain (header.from=valimail.com).
Google additionally provides the prevailing policy statement for the domain (p=REJECT) and any subdomain (sp=REJECT) and the disposition of the message (dis=NONE).
Yahoo only adds the prevailing policy (p=REJECT), while Microsoft only adds the disposition in this case (action=none).
Get started with DMARC
Want DMARC enforcement without the hassle? There’s where we come in. Valimail helps accelerate and automate your DMARC enforcement across all your domains.
See for yourself. Schedule a demo with one of our DMARC experts.