Find out why that email went to spam
Every message carries a record of how it travelled and what each server thought of it. Paste those headers here and we will read them back in plain language.
Paste the headers
In Gmail this is Show original. In Outlook it is File → Properties → Internet headers, or View → Message details on a phone. In most other clients it is called “view source” or “show original”.
The text stays in your browser. Nothing is uploaded, which matters more here than on our other tools: headers carry real addresses and server names.
The three verdicts that decide where mail lands
SPF
Was the sending server one the domain authorises? A fail here is the single most common reason a legitimate message is treated as suspicious.
DKIM
Did the message’s signature still match when it arrived? A fail means something altered the message in transit, or the signing key does not match what is published.
DMARC
Did the From address a person actually reads line up with what passed? This is the one that gets mail rejected outright, because it is the check a forger cannot satisfy.
Where it went
The servers it passed through, oldest first, with the gap at each step. A long gap is a queue, and it is usually the answer when someone says mail is slow rather than missing.
Where this stops
Headers record what the receiving servers decided. They do not record why a filter made a judgement call on top of that.
So a message can pass SPF, DKIM and DMARC and still land in spam — because of the words in it, because the sending address is new, because the sending server’s reputation is poor, or because that recipient’s provider is simply cautious. Authentication is the part you can fix and the part that is usually wrong; it is not the whole of it.
Headers also only describe the one message you pasted. If mail from your domain is going astray generally, the DNS and email records check looks at the domain rather than a single message, and is the better place to start.
What this normally turns out to be
SPF fails because a new sender was never added
A billing system, a CRM or a newsletter tool starts sending on your behalf and nobody adds it to the SPF record.
Two SPF records
Adding a second one instead of editing the first. The specification treats that as a permanent error, so the effect is not two rules — it is no working SPF.
DKIM was never set up
Common on mail that works fine internally and fails as soon as it leaves.
DMARC missing entirely
Nothing tells receivers what to do when the other two disagree, and nobody sees the reports that would have shown the problem months earlier.
Frequently asked questions
Is it safe to paste my headers here?
They are read in your browser and never sent anywhere. That said, headers do contain addresses and internal server names, so treat them the way you would any other internal detail.
It says “the receiving server did not record a result”.
Usually the headers were pasted partially, or the receiving server does not publish its authentication checks. Copy the whole block from the first line.
Everything passed but the message still went to spam.
Then it is not authentication. See Section 3 — content, reputation and recipient settings all sit on top of it.
Can you fix our email so this stops happening?
Yes, and it is usually a day’s work rather than a project. Start with the DNS and email records check so you know what is actually missing.
Send us what it said
If the result was a fail and you are not sure what to do with it, tell us what came back and who hosts your mail. We will tell you what needs changing — whether or not you move anything to us.