Email headers are the delivery record attached to a message. They show the path mail took, the systems that handled it, and the authentication results the receiving mailbox evaluated. You do not need to understand every line. For most business-email problems, a few fields are enough to identify the sender, check SPF/DKIM/DMARC, and give a provider useful evidence.
Get the full original message
Use your mailbox’s “show original,” “view source,” or “view message details” option. Copy the full header before forwarding or editing the message. The visible From address and message body are not enough for diagnosis. Header access is especially useful when one message went to spam, bounced, or appears to have been spoofed.
Find the authentication summary
Many providers include an Authentication-Results line. Look for results such as spf=pass, dkim=pass, and dmarc=pass or failure reasons. This line is the receiving provider’s evaluation, which makes it more useful than a sending platform’s setup dashboard. Save it with the date, recipient domain, and message ID.
Understand the From address
The visible From address is what recipients see. It is the identity DMARC tries to protect. It may differ from the return-path, signing domain, and technical sender. When a message looks suspicious, compare the visible From domain with the other identities in the header rather than relying on the display name.
Find the return-path and SPF identity
The Return-Path usually identifies the envelope-from address that SPF evaluated. Look for it near the top of the headers, then compare it with the SPF result. A provider may use its own return-path domain, which can be normal, but it affects whether SPF aligns with the visible From domain for DMARC. See how to check SPF for the public-record side.
Find the DKIM signature
Look for a line starting with DKIM-Signature. Two important tags are d=, the signing domain, and s=, the selector. The selector points to a DNS record under _domainkey. Combine the selector and signing domain to check whether the public key exists. Review how to check DKIM and the DKIM record example.
Understand DMARC alignment
DMARC passes when SPF or DKIM passes with a domain aligned to the visible From domain. A header can show SPF pass and DKIM pass while DMARC fails if neither identity aligns. Note the exact DMARC result and the domains involved before changing policy. The DMARC implementation checklist explains the full rollout.
Read Received lines carefully
Received lines show the sequence of servers that handled a message. Read them from the bottom upward to see the earliest recorded hop first. They can help identify the sending platform or an unexpected relay, but they are technical evidence, not a reason to draw conclusions from one IP alone. Use them together with authentication results and known provider infrastructure.
Look for delivery clues
Headers can include timestamps, message IDs, list-unsubscribe fields, spam-filtering notes, and error information. These details help a provider trace a specific event. If a message arrived late, compare timestamps. If it went to spam, preserve the authentication results, sender identities, and recent sending changes. If it bounced, save the exact error text.
Protect sensitive information
Headers may contain email addresses, IPs, internal routing information, and message IDs. Share them only with trusted administrators or provider support when needed, and remove unrelated personal information where practical. Do not post customer headers publicly to troubleshoot a problem.
Use headers in a controlled process
Gather one fresh example, identify the sender stream, compare public DNS, and make one evidence-based change. Then send a new test. For the overall decision sequence, use the deliverability troubleshooting flowchart. Run Beacon’s free domain check to review the public SPF, DKIM, and DMARC records that correspond to header evidence.