How do you check if an email passed SPF, DKIM and DMARC?

You don't need special software to see whether a message passed SPF, DKIM and DMARC. Every major mail client can show the verdicts its provider recorded. This guide gives the exact clicks for Gmail, Outlook and Apple Mail, then explains how to read the Authentication-Results header so you know why a check passed or failed. For a full tour of every header, see how to read email headers.

What are you looking for?

When a receiving mail system checks a message, it records the results in a header called Authentication-Results, defined in RFC 8601. A typical one looks like this:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s202610 header.b=Kq3vT1Zb;
       spf=pass (google.com: domain of bounce@mail.example.com designates 203.0.113.40 as permitted sender) smtp.mailfrom=bounce@mail.example.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

You need three things from it: the result for each method, the domain each method checked, and the From domain DMARC compared them against. The rest of this guide shows how to find the header, then how to read it.

How do you check in Gmail?

The quick check

Google's Gmail Help describes it:

1. On your computer, open Gmail and open the email.
2. Below the sender's name, click the Down arrow.
3. "The message is authenticated if you see" a Mailed by line with a domain name and a Signed by line with the sending domain.

Signed by names the domain that signed the message with DKIM. A question mark next to the sender's name means the message isn't authenticated. On Android, Google's steps are View details > View security details.

The full check

1. Open the message, select More (three dots) next to Reply, then Show original (Gmail Help).
2. The full header opens in a new window. At the top, Gmail usually shows a short summary that includes SPF, DKIM and DMARC lines.
3. Below the summary, find the Authentication-Results: mx.google.com header and read the details.
4. Select Copy to clipboard if you want to paste the headers into a tool.

How do you check in Outlook?

Microsoft Support gives these steps:

The header view isn't searchable in every version, so copy the text into an editor and search for Authentication-Results. Microsoft 365 adds its own fields, such as compauth= and reason=, which Microsoft Learn documents. Our guide to Microsoft 365 spam headers explains them.

How do you check in Apple Mail?

On a Mac, Apple's Mail guide (written for macOS Sequoia; menus may differ slightly in later versions) says to choose View > Message > All Headers to show more header fields, and View > Message > Default Headers to go back. Many versions of Mail also offer a Raw Source option in the same menu, which shows the whole message, headers and body, as plain text. Apple's guide doesn't document it, but where it's available it's the easiest view to copy.

Apple Mail doesn't show its own authentication verdict. You're reading the Authentication-Results header written by your mail provider, such as iCloud, Microsoft 365 or Google.

How do you read Authentication-Results?

RFC 8601 says the header contains "an authentication service identifier, an optional version, and then a series of statements" of the form method=result, each followed by properties showing what was checked. Text in parentheses is a comment for humans.

Step 1: Make sure it's your provider's header

The first value, before the semicolon, is the authserv-id: the name of the system that did the checks, such as mx.google.com. A message can carry several Authentication-Results headers, added by different systems along the way. Anyone can forge one, so trust only the header written by your own provider. RFC 8601 tells agents to use this identifier "to determine whether or not the data contained in an Authentication-Results header field ought to be used or ignored."

Step 2: Read each method and result

The meanings come from RFC 8601 for SPF and DKIM and from RFC 9989 for DMARC. A few are worth spelling out:

• dkim=none means the message wasn't signed. dkim=neutral means it was signed but the signature had syntax errors or couldn't be processed.
• dmarc=none means no DMARC record exists for the From domain.
• temperror is a temporary problem, such as a DNS timeout; a later check may pass. permerror is a lasting problem, such as a malformed record.
• dkim=fail often comes with a reason in parentheses, such as body hash did not verify. See DKIM "body hash did not verify".

Step 3: Check alignment

DMARC passes only when SPF or DKIM passes for a domain that aligns with header.from. In the Gmail example above:

• SPF passed for mail.example.com. Under relaxed alignment, that shares the organizational domain example.com, so it aligns.
• DKIM passed with header.i=@example.com, which aligns too.
• So dmarc=pass.

If both passing domains belong to someone else, such as your email platform, DMARC fails even though SPF and DKIM say pass. That's the most common surprise. Why DMARC fails covers the causes and fixes.

What do common result combinations mean?

Forwarding and mailing lists explain many of the odd rows. See why forwarding breaks SPF and DMARC and DMARC and mailing lists.

Why might the same message show different results?

Each receiving system runs its own checks, at its own time, on the copy it received. Results can legitimately differ:

• Forwarding and lists. A copy that went through a forwarder or mailing list arrives from a different server and may have been edited. SPF often fails, and DKIM fails if the body changed.
• DNS timing. If you've just changed a record, one receiver may see the old value from its cache and another the new one. A temperror usually means a lookup failed at that moment.
• Gateways in front of the mailbox. When your MX points to a filtering service, the mailbox provider behind it sees mail arriving from the service, not the original sender. Unless it's configured to look past that hop, its SPF check is against the wrong IP. In Microsoft 365, Enhanced Filtering for Connectors fixes this, and Microsoft's DMARC guidance says it "correctly identifies the source of internet messages for SPF, DKIM (if the service modifies messages), and DMARC validation."
• Local policy. RFC 8601 lets a receiver return policy when a check passed technically but the receiver's own rules didn't accept it, such as a signature from a domain it won't trust.

What about ARC results?

Some messages also carry arc=pass or arc=fail in Authentication-Results, plus ARC-Seal and related headers. These record what an earlier hop, such as a mailing list or forwarder, saw before it passed the message on. They don't change the SPF, DKIM or DMARC results; they give the receiver extra evidence when deciding what to do with a failure. Google says that if a forwarded message passes SPF or DKIM but ARC shows it previously failed, Gmail treats it as unauthenticated.

How do you test your own domain?

To check mail you send, don't email yourself. Google's DKIM setup guide says "You can't verify DKIM is on by sending yourself a test message." Mail between your own mailboxes may never leave your provider.

1. Send a test to an outside mailbox, ideally one at Gmail and one at Outlook.com, from each system that sends as your domain: your mail platform, CRM, invoicing tool and website.
2. Or use the Email Deliverability Test. Send one message to the address it gives you and it reports SPF, DKIM and DMARC, reverse DNS, blocklists and TLS.
3. Paste the headers into the Email Header Analyzer. It picks out each Authentication-Results header and the hops, and it runs in your browser, so nothing is uploaded.
4. Fix what fails. Check your record with the DMARC Checker and your selector with the DKIM Checker.

One test message shows one path on one day. For the full picture of every system sending as your domain, read your DMARC aggregate reports.

Next steps

• Send a test from every service that uses your domain, and confirm each shows aligned DKIM.
• Learn to read the signature itself with our DKIM-Signature header guide.
• Keep your records from drifting. iBlockSpam's domain monitoring alerts you when your MX, SPF or DMARC records change.

Browse our other SPF, DKIM and DMARC guides.