Email Header Analyzer

An email header analyzer turns the block of technical text behind every email into something you can read. Paste the full headers into our tool and it shows the From, Return-Path, Subject and Date, lists every Received hop in the order the message travelled with the delay between each one, and pulls out the SPF, DKIM and DMARC results recorded in the Authentication-Results header. Everything runs in your browser, so the headers you paste stay on your device.

How to use the Header analyzer

1. 1 Copy the full headersOpen the message in your email client and choose the option to show the original or view the message source. Copy everything above the message body.
2. 2 Paste them into the analyzerPaste the text into the box. The analysis runs in your browser straight away and nothing is uploaded.
3. 3 Check the authentication resultsLook at the SPF, DKIM and DMARC lines first. A fail on DMARC is the most common reason a genuine message ends up in spam.
4. 4 Read the hops for delaysScan the list of Received hops and the time between each one to find where a slow message was held up.

What email headers contain

Every email has two parts: the headers and the body. Your email client shows a few headers, such as From, To, Subject and Date, but hides dozens more. Those hidden lines are added by the sending software and by every server that handles the message on the way to the inbox, which makes them a record of where the message came from and what happened to it.

The format of email headers is defined in RFC 5322. Each header is a name, a colon and a value, and long values continue on the next line with leading spaces or tabs. That folding, plus the sheer number of lines, is what makes raw headers hard to read by eye and why an email header analyzer helps.

Headers are useful in three situations: working out why a genuine message was delayed, finding out why it went to spam or was rejected, and checking whether a suspicious message really came from the organisation it claims to be from.

What our email header analyzer shows

The analyzer focuses on the parts of the headers that answer most delivery questions. It does not judge the content of the message or give a spam score; it shows you the evidence in a clear order.

• Summary: the From address the recipient saw, the Return-Path used for bounces, the Subject and the Date the sender's software stamped on the message.
• Received hops: every Received header, put in the order the message travelled, from the first server to the last, with the time each server recorded.
• Delays: the time between consecutive hops, so you can see which step took seconds and which took hours.
• Authentication: the SPF, DKIM and DMARC results from the Authentication-Results header added by the receiving server.

Reading the Received hops

Each server that accepts the message adds a Received header at the top of the existing headers. That means the raw headers list hops in reverse: the most recent server is at the top and the first one is at the bottom. The analyzer turns them back into the order the message actually travelled, which is far easier to follow.

A typical Received line records which server the message came from, which server received it, the protocol used, such as ESMTP or ESMTPS where the S indicates an encrypted connection, and a timestamp. The first hops usually belong to the sender's own mail system or sending service, and the last ones belong to the recipient's provider and its filtering.

Only the hops added by the receiving organisation can be fully trusted. Anything below the point where the message entered the recipient's systems was written by servers outside their control, and spammers sometimes add fake Received lines to muddy the trail.

Finding where a message was delayed

The delay figures are worked out from the timestamps on consecutive hops. A gap of a few seconds between servers is normal. A gap of minutes or hours shows where a message was held, perhaps because a server was busy, a receiving server used greylisting and asked the sender to retry later, or a security gateway was scanning attachments.

Treat small negative delays with care. Each timestamp comes from a different server's clock, with its own time zone offset, and a server whose clock is a few seconds or minutes out can make a hop appear to happen before the previous one. No tool can correct a server clock that is simply wrong.

If the big delay is at the very start, between the Date header and the first hop, the message may have sat in the sender's outbox or been queued by their sending platform before it was handed over.

Understanding SPF, DKIM and DMARC results

The Authentication-Results header, defined in RFC 8601, is where the receiving server records the checks it ran. It starts with the name of the server that did the checking, followed by each method and its result, such as spf=pass or dkim=fail, usually with details in brackets and properties such as smtp.mailfrom or header.d.

SPF checks whether the sending server's IP address is authorised by the domain in the envelope sender, which appears as the Return-Path. DKIM checks a cryptographic signature added by the sender and shows the signing domain in header.d or header.i. DMARC passes when SPF or DKIM passes for a domain that aligns with the visible From address, and it records the policy the receiver applied.

Results other than pass and fail are common too. Neutral and none mean no definite answer, softfail means the domain suggests the server is probably not authorised, temperror points to a temporary DNS problem, and permerror means a broken record, such as an SPF record with too many lookups.

Privacy and what to share

Headers contain email addresses, server names, internal IP addresses and sometimes the IP address of the sender's computer. Because the analyzer runs entirely in your browser, nothing you paste is sent to our servers. If you share headers with your IT provider or email platform support, consider removing personal addresses first, but keep the Received and Authentication-Results lines intact, as they are what support needs to diagnose a problem.

Common patterns and what they usually mean

Some combinations of results come up again and again, and recognising them saves time. If SPF passes for a marketing or helpdesk platform's own domain, DKIM passes for that platform's domain too, and DMARC fails, the platform is sending as you without being set up to authenticate your domain. The fix is usually to switch on custom DKIM signing in that platform and add any include it needs to your SPF record.

If SPF fails but DKIM and DMARC pass, and the hops show the message went through a forwarding address or a mailing list, that is normal: forwarding breaks SPF but leaves the DKIM signature intact. If DKIM fails on a message that was clearly sent by you, look for a footer, disclaimer or link-tracking service that alters the message after it was signed.

If every result passes but the message still landed in spam, authentication is not the problem. Look instead at the sender's reputation, the content and links in the message, and whether recipients have engaged with earlier emails.

Examples you can copy

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.co.uk header.s=s1 header.b=AbC123;
       spf=pass (google.com: domain of bounce@example.co.uk designates 203.0.113.25 as permitted sender) smtp.mailfrom=bounce@example.co.uk;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.co.uk

Authentication-Results: mx.example.net;
       spf=pass smtp.mailfrom=mailer.example-esp.com;
       dkim=pass header.d=example-esp.com;
       dmarc=fail (p=reject) header.from=example.co.uk

Received: from mail.example.co.uk (mail.example.co.uk [203.0.113.25])
        by mx.example.net with ESMTPS id a1b2c3
        for <jo@example.net>; Tue, 20 Oct 2026 09:14:07 +0100

Common mistakes to avoid

Frequently asked questions