How to Check If SPF, DKIM and DMARC Passed in Email Headers

The fastest way to check whether SPF, DKIM and DMARC passed is to read one line in the email's headers: Authentication-Results. It records which check ran, which domain it was measured against, and whether each one passed or failed. For a single message you do not need a separate tool — the answer is already written into the mail your provider delivered.

This is a focused authentication read, narrower than a general headers walkthrough. The goal is to see in seconds whether your mail is actually authenticating, and — the part most guides skip — whether the domain that passed lines up with the address the reader sees.

The short answer#

Open the full, raw headers of the message and search for the text Authentication-Results. That header, added by the receiving server, holds a short list such as spf=pass, dkim=pass and dmarc=pass. The word after each equals sign is the result. pass is the only value that means the check succeeded; everything else — fail, none, softfail, neutral, temperror, permerror — means it did not, for different reasons.

The three checks answer different questions. SPF asks whether the sending server was allowed to send for the envelope domain. DKIM asks whether a cryptographic signature verifies. DMARC asks whether SPF or DKIM passed and whether the domain that passed matches the From address the reader sees. A message can show spf=pass and dkim=pass and still fail DMARC — which is why dmarc=pass is the value that matters most.

What the Authentication-Results header looks like#

Each check appears as a method=result pair, followed by a ptype.property that names exactly what was checked. Reading left to right tells you the whole story: who ran the checks, then each verdict and the domain behind it.

Before you start#

You need two things: the message's full headers, and a clear idea of which From address you are checking against. Every mail client can show raw headers; only the menu name differs, and the platform table below lists them.

• The full, original headers — not the short summary a client shows by default. In Gmail this is Show original; elsewhere it is a View source or View message details option.
• The visible From address, because DMARC alignment is judged against that domain, not the envelope sender.
• A note of which server delivered the mail, so you can confirm the Authentication-Results line you read was added by your provider and not by the sender.
• Optionally, a second reference — a header-analysis service or a test message to a mailbox you control — if you are verifying your own domain rather than judging a single received email.

How to check the headers, step by step#

The procedure is the same on every platform once the raw headers are open. The menu that reveals them is the only part that changes.

1. 1

   Open the message's full headers

   Open the email, then use your client's raw-headers command — Show original in Gmail, View message source in Outlook on the web, or View, Message, All Headers in Apple Mail. This opens the complete message source, including every header the normal view hides.

2. 2

   Find the Authentication-Results line

   Search the source for Authentication-Results (Ctrl+F or Cmd+F). There may be more than one. The one you want was added by your receiving provider, named by its authserv-id at the start of the line. Read that one and ignore any lower down that came from another server.

3. 3

   Read the result after each method

   Look for spf=, dkim= and dmarc=. The word immediately after each equals sign is the verdict. pass means that check succeeded; fail, none, softfail, neutral, temperror or permerror each mean it did not. Note all three.

4. 4

   Check the domain each result was measured against

   After each result comes a ptype.property. smtp.mailfrom is the envelope domain SPF checked; header.d is the domain that signed DKIM; header.from is the visible From domain DMARC aligns against. These are the values you compare in the alignment section below.

5. 5

   Confirm DMARC, not just SPF or DKIM

   dmarc=pass is the summary verdict: it means at least one of SPF or DKIM passed and its domain aligned with the From address. If SPF and DKIM both say pass but DMARC says fail, the mail is authenticating for the wrong domain — the most common surprise in a header read.

What each pass, fail and none value means#

RFC 8601 defines the result words. SPF and DKIM share most of them; DMARC uses a shorter set. This table covers what you will actually see in a header.

The alignment trap: smtp.mailfrom, header.d and header.from#

Alignment is the part of a header read that catches people out, and it is the whole reason DMARC exists. SPF authenticates the envelope domain in smtp.mailfrom, which the reader never sees. DKIM authenticates the signing domain in header.d. DMARC then asks a further question: does either of those domains match the From address in header.from — the one shown in the email app?

If it does not, DMARC fails even when SPF and DKIM both pass. A marketing platform sending as your brand is the classic case: spf=pass smtp.mailfrom=mailer.vendor.com and dkim=pass header.d=vendor.com, but header.from=yourbrand.com. Two vendor domains authenticated, neither aligned to the brand, so dmarc=fail. Microsoft's own troubleshooting docs use exactly this pattern.

Alignment comes in two modes. Relaxed alignment accepts a match on the organisational domain (mail.acme.com aligns with acme.com); strict alignment demands an exact match. Which one applies is set in the sender's DMARC record, not in the header — the header only shows the outcome.

Where each email app shows it#

The header name is identical everywhere; only the menu that reveals it changes. As of August 2026, here is where to find the raw headers and any built-in summary in the major clients. Vendors move menus, so if a label has changed, look for any option named source, original, or details.

What to do when a check fails#

A failing check is a message about configuration, not a dead end. Match your result to the cause, then fix at the source — the DNS records or the sending service, not the header itself.

A faster way — and where AI Emaily fits#

Reading one header is quick. Reading it on every message that lands — to judge whether a sender is really who the From line claims — does not scale, and that is the recurring version of this task. If that is your situation, an email client that reads the Authentication-Results for you is the faster way.

AI Emaily does exactly that on inbound mail. It reads the SPF, DKIM and DMARC results your provider stamped and factors them into spam and phishing protection, and it treats every message body as untrusted input — so a message whose From domain failed alignment does not get a pass just because the display name looks familiar. It approves before it acts, keeps an undo, and logs an audit trail. We build AI Emaily, and it comes with a 7-day free trial on the Pro and Autopilot plans.

One honest limit: if you are checking your own sending domain rather than judging received mail, that is a sender-side job. AI Emaily is not a DMARC monitor or a deliverability tester — for continuous reporting on your outbound authentication, use a DMARC aggregate-report service and read your own headers with a test send.