A complete guide to reading, understanding, and using email headers for diagnostics.
Every email you send or receive carries two distinct layers of information. The first is the message body — the text, images, and attachments that you actually read. The second is the header block — a section of plain-text metadata that your email client normally hides from view. Email headers contain the full routing history of a message: every server that touched it, every authentication check it passed, and a precise timestamp for each handoff. For most users, most of the time, headers are invisible background plumbing. But when an email is delayed, bounced, or flagged as spam, headers become the most valuable diagnostic tool available.
Email headers are written by the mail transfer agents (MTAs) and mail user agents (MUAs) that handle a message as it travels from sender to recipient. When you compose and send an email, your mail client (Gmail, Outlook, Apple Mail, or any other) writes the initial headers: From, To, Subject, Date, and a unique Message-ID. From that point forward, every server that receives and forwards the message prepends a new Received: header at the very top of the header block. This means that by the time a message reaches its destination, the full routing chain is recorded in reverse chronological order — the most recent server entry is at the top, and the original sending server is at the bottom.
This reverse ordering is a common source of confusion for first-time header readers. Tools like WhyIsMyEmailLate automatically reverse this order so you can read the journey chronologically, from the first hop to the last, which makes identifying delay points far more intuitive.
Every major email client provides a way to view the full raw headers of a message, though the method varies by platform:
Once you have the raw header text, copy everything from the first line (usually starting with "Received:" or "DKIM-Signature:") all the way to the blank line that separates the headers from the message body, and paste it into WhyIsMyEmailLate.
The most important header for delay analysis is the Received: header. Each one records a single server handoff and follows a structured format defined by RFC 5321:
Breaking this down: from identifies the sending server's hostname and IP address. by identifies the receiving server. with specifies the protocol used (SMTP, ESMTP, ESMTPS — more on this in the SMTP Routing guide). The timestamp at the end records when the receiving server accepted the message. By calculating the difference between consecutive Received: timestamps, you get the exact latency contributed by each hop in the chain.
Beyond routing, headers carry the results of three critical authentication mechanisms that modern email infrastructure uses to combat spoofing and spam:
DKIM (DomainKeys Identified Mail) — The sending domain uses a private key to generate a cryptographic signature over parts of the message. The receiving server retrieves the corresponding public key from DNS and verifies the signature. A valid DKIM signature proves that the message was authorized by the domain it claims to be from and that the signed headers and body were not modified in transit. You'll see this as a DKIM-Signature: header added by the sender and an Authentication-Results: header added by the receiver.
SPF (Sender Policy Framework) — The recipient's server checks the sending IP address against a list of authorized IPs published in the sender domain's DNS SPF record. A pass means the message originated from an IP the domain owner authorized. The result appears as a Received-SPF: header.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) — Builds on SPF and DKIM to give domain owners a policy framework: if both SPF and DKIM fail, DMARC tells receiving servers what to do (none, quarantine, or reject). The result appears within the Authentication-Results: header.
Failing authentication checks does not necessarily cause a delay, but it dramatically increases the probability that a message is flagged as spam or rejected outright, which then causes the sender's mail server to retry delivery — creating delays that appear in the Received: chain as gaps of 15 minutes to several hours.
Several common mistakes trip up new header readers. First: the Date: header records when the message was composed by the sender's client, not when it was delivered. A message can show a Date: of Monday 9:00 AM even if it wasn't delivered until Monday 11:30 AM because of queue delays. Always use the Received: timestamps for delivery timing analysis.
Second: the X-Originating-IP or X-Forwarded-For headers record the client IP that submitted the message to the outbound server — this is often the actual sender's IP address. However, these headers can be forged by malicious senders since they are not standardized and are written by the client, not the receiving infrastructure.
Third: a negative timestamp delta between two Received: headers does not mean time ran backwards. It means one of the two servers involved had a misconfigured or unsynchronized system clock. This tool detects negative deltas, clamps them to zero, and flags the affected hop with a Clock Skew indicator.
The most practical application of email headers is diagnosing why a message was delayed, bounced, or delivered to spam. The key is to find the largest time delta between consecutive Received: timestamps — that gap is your bottleneck. WhyIsMyEmailLate automates this calculation and highlights the bottleneck hop visually, but the underlying method is straightforward: read the timestamps in chronological order (bottom-up in raw headers, top-down in this tool) and find where the largest jump occurs. The hostname in the "by" field of that hop's Received: header identifies the server responsible for the delay, and that server's domain usually tells you whether the hold was at the sender's infrastructure, a third-party gateway, or the recipient's mail system.