Reading Email Headers to Troubleshoot Delivery

Do not automatically trust every line. A sending client can insert fabricated fields before the first server under your control receives the message. Establish a trust boundary: begin with a Received line added by a server you operate or a provider you can verify, then follow later hops toward the recipient.

Compare adjacent timestamps after converting them to the same time zone. A gap of seconds is routine. A much longer gap points to queueing between those two systems. Check sender logs for the queue ID and time window to determine whether the cause was a temporary 4xx SMTP response, connection failure, rate limit, or local backlog. If the recipient server accepted the message promptly, later inbox appearance is more likely a filtering, mailbox-rule, or client-sync issue than a transport delay.

Interpret authentication results in context

Look for Authentication-Results, usually added by the recipient's mail infrastructure. It may report SPF, DKIM, and DMARC outcomes, but first confirm that the evaluating server is one you trust.

• SPF: Check the evaluated envelope-from or return-path domain, not only the visible From address. A pass means the connecting IP was authorized for that envelope domain.
• DKIM: Note the signing domain in d=, the selector in s=, and whether the signature passed. A failure can result from a bad key, DNS problem, or message modification after signing.
• DMARC: Verify whether a passing SPF or DKIM identity aligns with the visible From domain. SPF can pass while DMARC fails if the domains are not aligned.

Forwarding commonly breaks SPF because the forwarder's IP may not be authorized by the original sender. DKIM may survive if the content remains unchanged. ARC results can provide additional forwarding context, but they do not turn an untrusted route into proof by themselves.

Use the SPF, DKIM, and DMARC guide when a result needs configuration-level investigation. If authentication passes but placement remains inconsistent, compare controlled results with inbox placement testing.

Correlate message IDs, timestamps, and routing fields

The Message-ID is useful for matching a recipient's copy to sender logs, support records, or duplicate reports. It is usually created by the sending application, so it identifies a message but does not prove delivery. A missing or malformed ID can also be a filtering signal.

Do not confuse the Message-ID with provider-specific queue IDs found in Received lines or diagnostic headers. Record both. Queue IDs are often the best keys for tracing a handoff inside a mail platform.

Also compare:

• Date, which is normally set by the sender and may reflect an incorrect device clock.
• Return-Path, which shows the envelope return address recorded at final delivery.
• From, which is the identity displayed to the recipient.
• Reply-To, which directs replies but does not control authentication.
• Recipient or routing fields showing aliases, forwarding, or list processing.

If the visible Date differs from the first trusted Received timestamp, trust the server timestamp when building the delivery timeline.

Turn header clues into a specific next action

Use the evidence to classify the incident before changing infrastructure:

• No recipient-side header exists: Confirm submission and inspect the SMTP response or bounce. Review your configuration or evaluate an external SMTP service if the sending path is unreliable.
• A long gap appears before recipient acceptance: Trace the queue ID on the server responsible for that interval and inspect temporary responses.
• Recipient acceptance was prompt: Investigate spam placement, quarantine, mailbox rules, aliases, and client synchronization.
• SPF, DKIM, or DMARC failed: Correct the failing identity, authorization, signature, or alignment issue before assuming reputation is the cause.
• Authentication passed but routing looks unfamiliar: Check forwarding, gateways, mailing-list modifications, and security relays.
• Only one recipient is affected: Compare that message with a successful message from the same send. Differences in route, content modification, domain, or recipient policy may isolate the cause.

Preserve a small evidence package rather than sending screenshots alone:

• [ ] Original .eml file or complete header
• [ ] Sender, recipient, and approximate send time with time zone
• [ ] Message-ID and relevant queue IDs
• [ ] SMTP response or bounce, if one exists
• [ ] Expected outcome and observed outcome

If you cannot reconcile the route with available logs, provide this package to Email Friend support.

Protect recipient data during investigation

Delivery troubleshooting does not override privacy or outreach obligations. If the message was outreach, document consent or the applicable legitimate-interest basis, honor opt-outs, and keep opted-out or invalid addresses on suppression lists so troubleshooting does not trigger another send.

Apply data minimization when sharing evidence. Remove unrelated recipients, subject content, tracking parameters, and internal details unless they are necessary to diagnose the route. Restrict access to raw headers, use an approved analysis tool, and delete temporary copies when the investigation is complete. Do not redact the specific domains, timestamps, authentication fields, or IDs needed to reproduce the finding.

Reach a defensible conclusion

A useful header investigation ends with a timeline and a bounded conclusion: where the message was accepted, where it waited, how it authenticated, and what evidence supports the next action. Read trusted Received lines bottom-up, correlate IDs with logs, normalize timestamps, and separate transport acceptance from inbox placement. That method is more reliable than treating any single header field—or analyzer score—as the final answer.