Skip to content
inboxprobe

Checkers

Generators

Guides

Checkers

Email header analyzer

Paste a message's headers to see whether it passed SPF, DKIM and DMARC, which server sent it, and where it spent time on the way. It all runs on this page; nothing is uploaded.

Gmail: ⋮ → Show original. Outlook on the web: … → View message source. Apple Mail: View → Message → All Headers. Copy from the top down to the first empty line.

Nothing leaves your browser. The headers are read on this page and never uploaded.

Where to find the headers

Mail appWhere
Gmail (web)Open the message → ⋮ (More) → Show original → Copy to clipboard
Outlook on the web / Outlook.comOpen the message → … (More actions) → View message source (in some versions it's under View)
Outlook for Windows (classic)Open the message in its own window → File → Properties → the Internet headers box
Apple MailOpen the message → View → Message → All Headers
Yahoo MailOpen the message → … (More) → View raw message

Take the headers from the recipient's copy. Your Sent folder has the message before any receiving server checked it, so it has no SPF, DKIM or DMARC results. If you're testing your own setup, send a message to a Gmail or Outlook.com address you own and look there.

Reading SPF, DKIM and DMARC results

The receiving server writes what it decided into an Authentication-Results header (RFC 8601). We read the top one: it was added by the last server, the one that delivered the message to the mailbox. Lower ones came from earlier servers and anyone can fake them, so we don't trust them.

ResultWhat it means
spf=passThe server that sent the message is allowed by the SPF record of the bounce (Return-Path) domain.
dkim=pass header.d=…The message carries a valid signature from that domain and wasn't changed on the way.
dmarc=pass header.from=…SPF or DKIM passed for a domain that matches the From address. This is the one Gmail, Yahoo and Outlook care about.
softfail / failNot authorised by SPF (softfail is the gentle version from ~all).
noneNothing to check: no SPF record, no signature, or no DMARC record.
temperror / permerrorA DNS problem or a broken record, not a judgement about the message.

Why SPF passes but doesn't match

Newsletter and CRM services send with their own bounce address (Mailchimp's look like bounce-mc…@…mcdlv.net), so SPF passes for their domain, not yours. That's normal. DMARC then depends on DKIM: the service has to sign with your domain, which is what “authenticate your domain” in their settings sets up. Our setup guides for Mailchimp, SendGrid, Brevo and Shopify Email walk through it.

The delivery path and delays

Every server that handles a message adds a Received header at the top, with a timestamp. Reading them bottom-up gives the path from the sender to the mailbox. We show them in that order, oldest first, with the time between each step.

  • Seconds between steps is normal.
  • Minutes usually means queueing: a busy server, a rate limit, or greylisting (the receiver asks the sender to retry later).
  • Hours usually means the sender retried after temporary errors. Check the sending server's logs for 4xx replies.
  • A negative delay means one server's clock is wrong, and the delays around it aren't reliable.

Privacy

Headers contain email addresses and sometimes internal server names. This page parses them with JavaScript in your browser; there is no upload and no server call. You can check by turning off your network after the page loads: the analyzer still works.

Questions

The verdict says DMARC passed. Why did my message go to spam?

Authentication only proves who sent a message. Spam filtering also looks at your domain's and IP's reputation, complaint rates, content, and whether recipients engage. DMARC passing is required, but it isn't enough on its own.

There's no Authentication-Results header in what I pasted.

You probably copied the message from your Sent folder, or from a mail server that doesn't add one. Copy the headers from the recipient's mailbox instead. Some servers only write a Received-SPF header; we read that too.

Can someone fake these headers?

Anything below the top Authentication-Results header could have been written by the sender. The top one and the Received headers added by the receiving organisation's own servers are the ones to trust.

Is my pasted data sent to inboxprobe?

No. The analyzer is plain JavaScript on this page. Nothing is uploaded or stored.

How do you decide if a domain “matches” the From address?

We compare the organisational domains, so news.example.com matches example.com. We use a simplified version of the public suffix rules, so treat it as a hint; the receiver's own dmarc= result is what counts.

Sources

Last reviewed: