Email Header Analyzer

The email platform that sent the message, like Mailchimp, Klaviyo or HubSpot. Underneath, one line tells you what that's based on: the receiving server's own checks, or only the platform's traces in the headers. The "Why we say" section at the bottom shows the evidence from the headers. If you paste the whole email and only its links point to a platform, it says "Probably sent with" instead, so you know it's a guess.

This is the question SPF, DKIM and DMARC answer. Here's what each one does:

• DMARC is the final verdict. It passes when SPF or DKIM passes for the same domain as the From address. The sender's DMARC policy also tells inboxes what to do with fakes: nothing, spam folder, or reject.
• DKIM is a digital signature. If it passes, the email wasn't changed on the way and really comes from the domain that signed it. We also show the size of the key that signed it, and that key as it is published today. Anything under 2048 bits counts as weak. If the key has since been removed or revoked, you'll see that too.
• SPF checks that the server that delivered the email is allowed to send for the sender's domain.
• ARC matters for forwarded emails. The forwarding server records the original results and signs them, so the inbox at the end can still trust them.

We show the results the receiving server actually recorded when the email arrived. Where we look up the sender's DNS records today (for example their DMARC record), we mark it "checked today", because records can change after an email was sent.

If an email was forwarded, SPF usually fails at the end. That's normal: SPF checks the last server that handed the email over, and that's the forwarding server, not the original sender. DKIM normally survives a forward, which is why DMARC can still pass. The analyzer spots forwards and tells you when a failed check is expected.

Every server the email passed through, in order, with the time it spent at each stop, drawn to scale. If an email arrived late, this shows you where it was held up.

Since February 2024, Gmail and Yahoo require bulk senders to meet a set of rules. We check everything the headers can show: SPF or DKIM passes, the From address lines up with a passing check, the domain has a DMARC record, there's one-click unsubscribe, and the email was sent over an encrypted connection.

One rule can't be checked from headers: a spam complaint rate below 0.3%. Senders can see theirs in Google Postmaster Tools.

Checked today, straight from the sender's DNS:

• DMARC: their policy (including a parent domain's policy for subdomains), where their reports go and, for the report services we know, which company receives them, plus the raw record.
• SPF: how their record ends, like -all (refuse email from servers it doesn't list) or ~all (treat it as suspicious), and how many of the 10 DNS lookups SPF allows it uses. Go over 10 and SPF can fail. If this email's SPF check was for a different domain, its bounce address, we point that out.
• BIMI: their logo record.
• MTA-STS and TLS reporting: these are about email sent to the sender's domain, not from it. MTA-STS asks other servers to use encryption they can verify when delivering to the domain, and TLS reporting says where reports about failed encrypted deliveries go.

If you paste the whole email, not just the headers, you also see what's inside it: the template builder it was made with, tracking tools, traces of AI tools or editors like ChatGPT and Google Docs, AMP, dark mode support, and warnings like an unsubscribe link that doesn't work.

For emails received in Outlook or Microsoft 365, we decode Microsoft's own filter headers: the spam score (Microsoft says it no longer decides the verdict), the bulk complaint level, and Microsoft's combined sender check. If the sender also uses Microsoft 365, their own filter's notes are kept apart from the receiver's, so you know whose verdict you're reading.