Email Headers are the roadmap of an email’s journey—revealing who sent it, how it traveled, when it arrived, and whether it can be trusted. When someone (like support teams, IT, or compliance) asks you to share them, they’re not being nosy; they’re asking for the only reliable evidence that explains what actually happened to a message. Understanding what headers are, what they contain, and why they’re requested can save time, prevent scams, and resolve issues faster.
What are email headers?
Every email has two parts: the header and the body. The body is what you read. The header is the behind-the-scenes metadata that email servers add and pass along during delivery. You don’t usually see headers in your inbox view because they’re technical, but they’re always there.
Key things headers tell you:
- The path: Each server that handled the message
- The timing: When it left and arrived at each hop
- The sender identity: Who claims to have sent it and who actually did
- Authentication: Whether SPF, DKIM, and DMARC checks passed
- Delivery outcome: If messages were delayed, filtered, or rewritten
Why we ask for headers When a company or IT team asks for full headers, it’s typically for one of the following reasons:
- To investigate phishing or spoofing: Headers expose misspellings in domains, forged paths, and failed authentication checks that aren’t visible in the UI.
- To diagnose delivery delays: Received timestamps show where a message got stuck and for how long.
- To verify sender authenticity: Matching the “From” domain to SPF, DKIM, and DMARC results confirms the message is legitimate.
- To analyze routing or filtering: Headers reveal whether a gateway, security filter, or forwarding rule rerouted the email.
- To troubleshoot bounces and rejections: SMTP status codes and Received lines point to misconfigurations or blocklists.
Common header fields explained
- From: The human-friendly sender address. Can be spoofed; don’t rely on it alone.
- To/Cc/Bcc: Recipients. Bcc won’t appear for other recipients.
- Subject: The subject line users see.
- Date: The time the message claims to have been sent (may differ from actual server times).
- Message-ID: A unique identifier that helps with threading and tracking.
- Return-Path: Where non-delivery reports (bounces) go; often set by sending servers.
- Received: Added by each server that handles the message; shows the hop-by-hop path in reverse order (top is latest).
- SPF results (Authentication-Results, Received-SPF): Shows whether the sending IP was authorized by the sender’s domain.
- DKIM-Signature and results: Cryptographic signature confirming the message wasn’t altered and was authorized by the domain.
- DMARC results: Aligns From with SPF/DKIM to determine if the message should be trusted.
- X- headers: Custom or vendor-specific fields; useful for security tools and routing policies.
How to view headers in popular email clients
- Gmail (web): Open the message > three dots (More) > Show original. Copy the full header text from that page.
- Outlook for Windows: Open the message > File > Properties > Internet headers.
- New Outlook/Outlook for Mac: Open the message > three dots > View > View source (or Message options).
- Apple Mail (Mac): View > Message > All Headers, or View > Message > Raw Source.
- Thunderbird: View > Headers > All, or More > View Source.
- iPhone/iPad Mail: Tap the message > More > Forward > then use a desktop client to view full headers; iOS has limited header visibility.
- Microsoft 365 admin: Message Trace and headers appear in security/compliance portals.
Tip: Always copy the entire raw header block—partial copies can hide the crucial hop or authentication line.
How to read a header, step by step
1) Start with Authentication-Results: Check SPF, DKIM, DMARC. If any fail, look for alignment issues (e.g., From domain differs from the signing or envelope domain).
2) Review Received lines from bottom to top: The bottom is where the message originated; look for suspicious private IPs, foreign relays you don’t expect, or big time gaps.
3) Compare From to the domains in SPF/DKIM/Return-Path: Legitimate mail aligns domains; fakes often don’t.
4) Note Message-ID and Date: If the date looks wrong (far in the future/past), it might indicate a misconfigured sender.
5) Check X- headers from security tools: They often include verdicts like spam scores, policy actions, or malware flags.
Security and privacy considerations
- Sharing safely: Headers rarely include the email body, but they can reveal IP addresses, internal hostnames, and routing info. Share only with trusted support channels.
- Redaction: If you must protect internal server names or addresses, coordinate with support—over-redacting can remove the clues they need.
- Phishing detection: Poor alignment (SPF/DKIM/DMARC failures), lookalike domains, and odd Received paths are red flags.
- Forwarding pitfalls: Forwarding can break alignment and cause false failures. Use “forward as attachment” when reporting suspicious emails so original headers are preserved.
Best practices for senders
- Publish correct SPF records: Authorize all legitimate sending IPs and keep the record under DNS size limits.
- Sign with DKIM: Use at least 1024-bit keys (2048 recommended) and rotate keys periodically.
- Enforce DMARC: Start with p=none for monitoring, then move to quarantine/reject as alignment stabilizes.
- Use consistent domains: Align From, Return-Path, and DKIM d= domain to improve deliverability and trust.
- Monitor bounces and feedback loops: Use Message-ID correlation and headers to spot systemic issues.
Best practices for recipients and teams
- Verify suspicious mail via headers before clicking links.
- Train staff to capture and forward full headers when reporting incidents.
- Keep a quick-reference for how to retrieve headers in your primary email clients.
- Use automated header analysis tools to accelerate triage, but validate critical findings manually.
When to escalate with headers
- Repeated delivery delays from a specific domain or provider
- Patterns of spoofed messages targeting your users
- Inconsistent DKIM signatures or sudden SPF failures
- Unexplained bounces with cryptic SMTP codes
Email Headers in action: a quick example
- Symptom: A customer says an invoice didn’t arrive.
- Findings: Received lines show a 45-minute delay at an intermediate security gateway. Authentication-Results show SPF and DKIM passed. The message eventually delivered and was filtered into Promotions.
- Resolution: Adjust filtering rules for transactional mail; communicate the delay and ensure future messages are tagged properly.
The bottom line
Headers turn guesswork into evidence. Whether you’re confirming a sender, diagnosing a delay, or investigating a phishing attempt, full headers provide the truth of an email’s origin, path, and authenticity. Knowing how to access, read, and share them equips you to solve problems quickly and keep your inbox—and your organization—safer.
