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

URL: https://iblockspam.com/blog/check-if-email-passed-spf-dkim-dmarc
Last updated: 2026-10-10
Published: 2026-10-10
Topic: SPF, DKIM & DMARC
Author: iBlockSpam Team

> Check SPF, DKIM and DMARC results for any email in Gmail, Outlook and Apple Mail, then read the Authentication-Results header to see why it passed or failed.

## Short answer

Open the message's full headers: Show original in Gmail, View message details in Outlook, or View > Message > All Headers in Apple Mail. Find the Authentication-Results header added by your own mail provider and read spf=, dkim= and dmarc=. A pass only counts for DMARC when the SPF or DKIM domain aligns with the From domain.

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](https://iblockspam.com/blog/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](https://www.rfc-editor.org/rfc/rfc8601.html). 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](https://support.google.com/mail/answer/180707?hl=en) 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](https://support.google.com/mail/answer/29436?hl=en)).
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](https://support.microsoft.com/en-us/office/view-internet-message-headers-in-outlook-cd039382-dc6e-4264-ac74-c048563d212c) gives these steps:

| Outlook version | Steps |
|---|---|
| New Outlook for Windows | Open the message, select **More actions** at the top of the message, then **View** > **View message details** |
| Outlook on the web and Outlook.com | Same as new Outlook: **More actions** > **View** > **View message details** |
| Classic Outlook for Windows | Double-click to open the message in its own window, then **File** > **Properties**. Headers are in the **Internet headers** box |

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](https://learn.microsoft.com/en-us/defender-office-365/message-headers-eop-mdo) documents. Our guide to [Microsoft 365 spam headers](https://iblockspam.com/blog/microsoft-365-spam-headers-explained) explains them.

## How do you check in Apple Mail?

On a Mac, [Apple's Mail guide](https://support.apple.com/guide/mail/show-detailed-email-headers-mlhlp1089/16.0/mac/15.0) (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

| Method | Possible results | What to check next |
|---|---|---|
| `spf=` | pass, fail, softfail, neutral, none, temperror, permerror, policy | `smtp.mailfrom=`: the envelope domain SPF checked |
| `dkim=` | pass, fail, none, neutral, policy, temperror, permerror | `header.d=` or `header.i=`: the signing domain. `header.s=` is the selector |
| `dmarc=` | pass, fail, none, temperror, permerror | `header.from=`: the From domain DMARC evaluated |

The meanings come from RFC 8601 for SPF and DKIM and from [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) 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"](https://iblockspam.com/blog/dkim-fail-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](https://iblockspam.com/blog/why-dmarc-fails) covers the causes and fixes.

## What do common result combinations mean?

| What you see | What it means | What to do |
|---|---|---|
| spf=pass, dkim=pass, dmarc=pass | Fully authenticated and aligned | Nothing |
| spf=fail, dkim=pass, dmarc=pass | Typical of forwarded mail; aligned DKIM carried it | Usually nothing |
| spf=pass, dkim=pass, dmarc=fail | Neither passing domain aligns with From | Set up custom-domain DKIM or a custom bounce domain at the sender |
| spf=pass, dkim=none, dmarc=pass | Relies on SPF alone | Add DKIM; SPF breaks on forwarding |
| dkim=fail (body hash did not verify) | The body changed after signing | Look for footers, gateways or mailing lists |
| dmarc=none | No DMARC record for the From domain | Publish one if it's your domain |
| dmarc=bestguesspass (Microsoft 365) | No record exists; Microsoft inferred a pass | Publish an explicit record, as Microsoft advises |

Forwarding and mailing lists explain many of the odd rows. See [why forwarding breaks SPF and DMARC](https://iblockspam.com/blog/email-forwarding-breaks-spf-dmarc-arc) and [DMARC and mailing lists](https://iblockspam.com/blog/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](https://iblockspam.com/blog/microsoft-365-third-party-spam-filter-enhanced-filtering) fixes this, and [Microsoft's DMARC guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure) 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](https://support.google.com/a/answer/174124?hl=en) 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](https://iblockspam.com/tools/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](https://iblockspam.com/tools/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](https://iblockspam.com/tools/dmarc-checker) and your selector with the [DKIM Checker](https://iblockspam.com/tools/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](https://iblockspam.com/blog/how-to-read-dmarc-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](https://iblockspam.com/blog/dkim-signature-header-explained).
- Keep your records from drifting. iBlockSpam's [domain monitoring](https://iblockspam.com/features/domain-monitoring) alerts you when your MX, SPF or DMARC records change.

Browse our other [SPF, DKIM and DMARC guides](https://iblockspam.com/blog/topic/authentication).

## Frequently asked questions

### How do I check DKIM in Gmail?

On a computer, open the message and select the Down arrow below the sender's name. Google says a 'Signed by' line with the sending domain means the message is DKIM authenticated. For the full result, select More, then Show original, and look for dkim=pass in the Authentication-Results header, with header.d showing the signing domain.

### Where is Authentication-Results in Outlook?

In new Outlook for Windows and Outlook on the web, open the message, select More actions, then View, then View message details. In classic Outlook for Windows, open the message in its own window and select File, then Properties; the headers are in the Internet headers box. Search the text for Authentication-Results.

### Why does DMARC fail when SPF and DKIM both pass?

Because DMARC needs alignment. SPF must pass for a domain that matches the From domain, or DKIM must pass with a d= domain that matches it. If SPF passed for your email service's bounce domain and DKIM passed for the service's own domain, neither aligns, so DMARC fails. Set up custom-domain DKIM at the service.

### Can I test my own domain by emailing myself?

Not reliably. Mail between mailboxes on the same system may never leave it, so outside checks don't run. Google's DKIM setup guide says you can't verify DKIM by sending yourself a test message. Send to a mailbox at a different provider, or use a test address from a deliverability testing tool.

### What does dmarc=none mean?

In RFC 9989's result names, none means no DMARC policy record exists for the From domain. It isn't a failure; there's simply nothing to evaluate. If it's your own domain, publish a DMARC record. Microsoft 365 may show dmarc=bestguesspass instead, meaning no record exists but Microsoft inferred a pass.

## Sources

- [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html)
- [RFC 9989: DMARC, section 9.2 (result names)](https://www.rfc-editor.org/rfc/rfc9989.html)
- [Gmail Help: Check if your Gmail message is authenticated](https://support.google.com/mail/answer/180707?hl=en)
- [Gmail Help: Trace an email with its full headers](https://support.google.com/mail/answer/29436?hl=en)
- [Microsoft Support: View internet message headers in Outlook](https://support.microsoft.com/en-us/office/view-internet-message-headers-in-outlook-cd039382-dc6e-4264-ac74-c048563d212c)
- [Apple Mail User Guide (macOS Sequoia): Show detailed headers in Mail on Mac](https://support.apple.com/guide/mail/show-detailed-email-headers-mlhlp1089/16.0/mac/15.0)
- [Microsoft Learn: Anti-spam message headers in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/message-headers-eop-mdo)
- [Google Workspace Admin Help: Set up DKIM](https://support.google.com/a/answer/174124?hl=en)

## Free tools for this guide

- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [Email Deliverability Test](https://iblockspam.com/tools/deliverability-test): Send one email and see its SPF, DKIM and DMARC results, reverse DNS, blocklists, TLS and spam verdict.
- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.
- [DKIM Checker](https://iblockspam.com/tools/dkim-checker): Validate DKIM keys by selector, including key type and strength.

---

Source: iBlockSpam, https://iblockspam.com/blog/check-if-email-passed-spf-dkim-dmarc (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt