Want to learn more?
Learn how to read email headers to trace message routing and detect phishing or spoofing attempts.
Read the guidePaste the raw email headers to analyze for security indicators
Investigating Phishing Attacks?
Our SOC team analyzes email threats, traces attack origins, and implements protections.
What Is Email Header Analysis
Email headers are metadata lines embedded in every email message that trace the message's path from sender to recipient. Headers contain critical information including the originating server, authentication results, routing hops, timestamps, and security verification outcomes. Analyzing email headers is a fundamental skill for investigating phishing attacks, diagnosing delivery issues, and verifying email authenticity.
While the visible "From" address can be easily spoofed, the headers reveal the true origin of a message. Security teams, IT administrators, and forensic analysts rely on header analysis to distinguish legitimate emails from malicious ones.
How Email Headers Work
Email headers are added by each mail server that processes the message. They are read from bottom to top — the oldest headers appear at the bottom, and each server that handles the message prepends new headers at the top.
Key Header Fields
| Header | Purpose | Security Relevance |
|---|---|---|
| Received | Records each server hop | Trace the actual delivery path; detect forged routing |
| From | Display sender address | Easily spoofed — do not trust without authentication |
| Return-Path | Bounce address (envelope sender) | Should match the From domain; mismatches suggest spoofing |
| Authentication-Results | SPF, DKIM, DMARC verdicts | Definitive authentication status from the receiving server |
| DKIM-Signature | Cryptographic signature | Proves the message was not altered in transit |
| Received-SPF | SPF check result | Confirms the sending IP is authorized for the domain |
| X-Mailer / User-Agent | Sending software | Can reveal phishing tools or unusual sending software |
| Message-ID | Unique message identifier | Should contain the sender's domain; mismatches are suspicious |
| X-Originating-IP | Original sender IP | Reveals the actual source, even behind forwarding services |
Common Use Cases
- Phishing investigation: Determine whether a suspicious email actually originated from the claimed sender by examining Received headers and authentication results
- Delivery troubleshooting: Trace why emails are being delayed, rejected, or sent to spam by following the routing path and reading server responses
- SPF/DKIM/DMARC verification: Confirm that email authentication is working correctly by checking Authentication-Results headers
- Forensic analysis: During incident response, extract IP addresses, timestamps, and server identities from headers to build an attack timeline
- Spam source identification: Identify the originating server and network for spam campaigns to feed into blocklists and abuse reports
Best Practices
- Read headers bottom-to-top — The first Received header (at the bottom) is the most trustworthy because it was added by the first server to handle the message. Upper headers can be forged by the sender.
- Verify authentication results — Look for the Authentication-Results header added by your receiving mail server. SPF=pass, DKIM=pass, and DMARC=pass together provide strong assurance of legitimacy.
- Check for header inconsistencies — Mismatches between the From domain, Return-Path, DKIM signing domain, and originating IP are strong indicators of spoofing.
- Extract IOCs for threat intelligence — IP addresses, domains, and Message-IDs from malicious email headers are valuable indicators of compromise (IOCs) for blocklists and SIEM correlation.
- Use automated tools for bulk analysis — Manual header analysis is valuable for individual investigations, but use automated tools and mail gateway logs for analyzing patterns across many messages.
References & Citations
- IETF. (2014). RFC 7208: Sender Policy Framework (SPF). Retrieved from https://datatracker.ietf.org/doc/html/rfc7208 (accessed January 2025)
- IETF. (2011). RFC 6376: DomainKeys Identified Mail (DKIM). Retrieved from https://datatracker.ietf.org/doc/html/rfc6376 (accessed January 2025)
- IETF. (2015). RFC 7489: Domain-based Message Authentication (DMARC). Retrieved from https://datatracker.ietf.org/doc/html/rfc7489 (accessed January 2025)
- FBI IC3. (2023). Business Email Compromise: The $50 Billion Scam. Retrieved from https://www.ic3.gov/PSA/2023/psa230609 (accessed January 2025)
Note: These citations are provided for informational and educational purposes. Always verify information with the original sources and consult with qualified professionals for specific advice related to your situation.
Key Security Terms
Understand the essential concepts behind this tool
SPF (Sender Policy Framework)
Email authentication method that specifies which mail servers are authorized to send email on behalf of your domain.
DKIM (DomainKeys Identified Mail)
Email authentication method that uses cryptographic signatures to verify that email content has not been tampered with in transit.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
Email validation system that builds on SPF and DKIM to prevent email spoofing and provide reporting on email authentication failures.
Phishing
A social engineering attack that uses fraudulent communications to trick recipients into revealing sensitive information or installing malware.
Frequently Asked Questions
Common questions about the Email Header Analyzer
Email headers contain metadata about email's journey from sender to recipient: Key header fields: (1) From: Display name and address (easily spoofed!), what user sees in mail client, not authenticated by default. (2) Return-Path: Where bounces go, indicates sending server, often different from "From" in phishing. (3) Received: Chain of mail servers that handled message, timestamped hops from sender to recipient, most reliable for tracing origin. (4) Authentication-Results: SPF/DKIM/DMARC check results, pass/fail for each mechanism, critical for detecting spoofing. (5) Message-ID: Unique identifier for email, format reveals sending system. (6) X-Originating-IP: Original sender's IP address, useful for geolocation and reputation checks. Security value: (1) Detect spoofing - "From" says CEO but Return-Path is suspicious external domain, authentication failures indicate forged sender. (2) Trace origin - Follow "Received" headers backwards to source, identify compromised mail servers, geolocate attacker infrastructure. (3) Identify phishing patterns - Free email services for business emails, mismatched domains, suspicious routing through unexpected countries. (4) Forensic analysis - Incident response investigations, evidence collection, attribution. (5) Validate legitimacy - Verify email came from claimed sender, check authentication pass rates. What attackers manipulate: Display name in "From" (easy), actual "From" address (harder, caught by DMARC), can't manipulate "Received" chain (added by infrastructure), can't forge DKIM signatures without private key. Use cases: Investigate suspicious emails before clicking links, verify wire transfer requests (CEO fraud), analyze phishing campaigns, compliance audits (email retention), troubleshoot delivery issues.
Received headers trace email's path through mail servers: Format: Received: from sendingserver.com (IP [192.0.2.1]) by receivingserver.com with ESMTP; timestamp. Reading order: Headers added in reverse order (newest first), read from BOTTOM to TOP to trace email path, bottom = originating server, top = final delivery to your inbox. Example path: (1) Bottom: Received: from client.home.net [203.0.113.45] (user's computer sent to their mail server). (2) Middle: Received: from mail.sender.com [198.51.100.10] (sender's mail server to internet). (3) Middle: Received: from mx.recipient.com [192.0.2.50] (recipient's mail server received from internet). (4) Top: Received: from mx.recipient.com by mailbox.recipient.com (internal delivery to user mailbox). Red flags: (1) Unexpected countries - Email from "US company" but originated from Eastern Europe, check geolocation of IPs. (2) Free email services - Business email routed through gmail/yahoo/hotmail, suspicious for corporate communications. (3) Too many hops - Normal: 3-6 hops, suspicious: 10+ hops (routing through multiple relays to obscure origin). (4) Time inconsistencies - Timestamps out of order, impossible time zones, future dates. (5) Spoofed Received headers - Attacker can add fake Received headers above theirs, but can't modify headers added by YOUR infrastructure. Trust boundary: Only trust "Received" headers added by YOUR mail servers (your domain), everything before that could be forged. Useful tools: MXToolbox Email Header Analyzer, Google Admin Toolbox, this email header analyzer. Analysis tips: Extract all IP addresses, do reverse DNS lookups, check IPs against reputation databases (Spamhaus, Barracuda), verify SPF records for claimed sender domain, cross-reference with Authentication-Results. Real-world example: BEC attack showed "From: [email protected]" but bottom Received showed origin from gmail.com with Nigerian IP.
Three complementary email authentication standards: SPF (Sender Policy Framework) - Published as DNS TXT record, lists IP addresses/servers authorized to send email for domain, receiving server checks if sending IP is in SPF record. SPF record example: v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all. Mechanisms: +all (allow all - insecure!), -all (hard fail - reject unauthorized), ~all (soft fail - mark as spam), ?all (neutral - no policy). DKIM (DomainKeys Identified Mail) - Cryptographic signature in email header, sending server signs email with private key, receiving server verifies with public key in DNS, ensures email not modified in transit. DKIM header: DKIM-Signature: v=1; a=rsa-sha256; d=sender.com; s=selector; h=from:to:subject:date; bh=
; b=BEC attacks show specific patterns in email headers: BEC attack types: (1) Display name spoofing - From: "CEO Name" [email protected], looks like CEO but different email address, catches victims who only read display name. (2) Lookalike domains - From: [email protected] (legitimate is company.com), From: [email protected] (rn looks like m). (3) Compromised accounts - Legitimate account stolen via phishing, all authentication passes (it's a real account!), behavioral analysis needed. Header indicators of BEC: (1) Mismatched domains - Display name: "CFO Name [email protected]", From header shows different domain (gmail.com, yahoo.com), Return-Path doesn't match From. (2) Authentication failures - SPF: fail (sent from unauthorized server), DKIM: fail or missing (no signature), DMARC: fail (domain alignment broken). (3) Suspicious origin - X-Originating-IP from unexpected country, free email service for business communication, unusual sending time (3 AM from "executive"). (4) Reply-To manipulation - From: [email protected], Reply-To: [email protected] (responses go to attacker). (5) User-Agent anomalies - Executive uses Outlook, but User-Agent shows Gmail web interface, unusual email client for that user. (6) Message-ID patterns - Format inconsistent with company's mail server, generated by free email service. Analysis workflow: (1) Check Authentication-Results first (any failures = red flag), (2) Compare From/Return-Path/Reply-To (all should match for legitimate email), (3) Trace Received headers to origin (verify comes from company infrastructure), (4) Check X-Originating-IP geolocation (matches sender's expected location?), (5) Verify urgency/requests (BEC often uses urgent wire transfer requests). Real-world BEC example: From: "John Smith CEO" [email protected], Return-Path: [email protected], Authentication-Results: spf=fail, dkim=fail, dmarc=fail, Received: from mail-sor-f41.google.com (free Gmail), Message-ID: [email protected] (Gmail format). Prevention: (1) Deploy DMARC with p=reject policy, (2) Train users to check full email address, (3) Implement "external email" warnings, (4) Flag emails with Reply-To different from From, (5) Require out-of-band verification for financial requests (call known number, not reply to email). FBI estimates $43B+ lost to BEC since 2016.
Authentication-Results header shows SPF, DKIM, DMARC verification status: SPF results: (1) pass - Sending IP authorized in SPF record, legitimate sender or properly configured relay. (2) fail - Sending IP NOT in SPF record, likely spoofed or misconfigured, DMARC policy determines handling. (3) softfail - SPF record uses ~all (ambiguous), treated as suspicious but not rejected. (4) neutral - SPF record uses ?all (no policy), provides no protection. (5) none - No SPF record published, legacy systems or misconfiguration. (6) temperror - DNS lookup failed temporarily, retry later. (7) permerror - SPF record syntax error, needs fixing by domain owner. DKIM results: (1) pass - Signature verified successfully, email integrity confirmed, signing domain authentic. (2) fail - Signature verification failed, email modified after signing, wrong public key used, replay attack. (3) policy - Signature doesn't meet policy requirements. (4) neutral - Signature couldn't be verified (missing key). (5) temperror - Temporary DNS failure. (6) permerror - Signature syntax error. (7) none - No DKIM signature present. DMARC results: (1) pass - SPF or DKIM aligned with From domain, domain authentication successful, safe to trust sender domain. (2) fail - Neither SPF nor DKIM aligned, spoofing attempt or misconfiguration, apply DMARC policy (reject/quarantine/none). Example interpretations: (1) Legitimate email: spf=pass, dkim=pass, dmarc=pass → All checks passed, strong confidence in sender. (2) Suspicious email: spf=fail, dkim=fail, dmarc=fail → Multiple failures, likely spoofing attempt. (3) Forwarded email: spf=fail (forwarding server not in SPF), dkim=pass (signature preserved), dmarc=fail (SPF broken, DKIM might not align) → Legitimate but forwarding breaks SPF. (4) Mailing list: spf=fail (list server sends), dkim=fail (list modified content), dmarc=fail → Mailing lists often break authentication. (5) Misconfigured but legitimate: spf=none, dkim=none, dmarc=none → Domain owner hasn't deployed authentication (risky!). What to trust: DMARC pass = highest confidence (requires alignment), DKIM pass alone = medium confidence (email integrity good, but domain might not align), SPF pass alone = low confidence (IP authorized but doesn't prove "From" address), All fail = high suspicion (investigate before trusting). Edge cases: Forwarding, mailing lists, and some cloud services break authentication - analyze full context.
Multiple methods to determine email's geographic source: Method 1: X-Originating-IP - Header added by webmail services (Gmail, Yahoo, Outlook.com), shows IP address of device that sent email, most reliable indicator of true origin. Example: X-Originating-IP: [203.0.113.45]. Lookup: Use IP geolocation services (MaxMind, IPinfo.io, ip2location), shows country, city, ISP, VPN/proxy detection. Method 2: Received Headers - Extract IPs from all Received headers, start with bottom-most (first) Received header, geolocate each IP in the chain. Example: Received: from client.isp.com [203.0.113.45] → geolocate 203.0.113.45. Method 3: Sending Mail Server - Identify sending domain's mail server, look up MX records for domain, geolocate mail server IPs. Example: nslookup -type=MX sender.com → mail.sender.com → 192.0.2.10 → geolocate. Method 4: SMTP Banner - Some Received headers include hostname, reverse DNS lookup on IP, identify ISP or hosting provider. Example: Received: from mail-lf1-f42.google.com → Google datacenter (multiple countries). Red flags: (1) Geographic mismatch - Email claims to be from "US company" but X-Originating-IP is in Nigeria, unlikely for legitimate business email. (2) VPN/Proxy indicators - IP belongs to known VPN provider (NordVPN, ExpressVPN), cloud hosting (AWS, Azure, DigitalOcean) for individual email (not corporate), Tor exit nodes. (3) High-risk countries - Not all emails from certain countries are malicious, but statistically more phishing originates from certain regions. (4) Impossible timeline - Email timestamp says 9 AM in New York, but IP geolocates to China with local time 9 PM. Tools: (1) MaxMind GeoIP2 - Commercial geolocation database, accuracy: ~90% country-level, ~80% city-level. (2) IPinfo.io - Free API for IP geolocation, includes privacy detection (VPN/proxy). (3) AbuseIPDB - Check IP reputation, see reports of malicious activity. (4) WHOIS - Find IP allocation info, identify ISP or organization. Limitations: (1) VPNs/proxies hide true location, (2) Compromised servers relay email (shows server location, not attacker), (3) Residential proxies use legitimate IPs, (4) Corporate VPNs may show unexpected locations. Investigation tip: Cross-reference multiple indicators (IP location, time zones in headers, language/spelling in email, domain registration location, claimed sender's known location). Don't rely solely on geolocation - context matters.
Step-by-step header extraction and analysis: Extract headers (by email client): (1) Gmail - Open email → three-dot menu → "Show original" → shows full headers + original message. (2) Outlook Desktop - Open email → File → Properties → look in "Internet headers" box, copy all text. (3) Outlook Web - Open email → three-dot menu → "View message details" → header displayed. (4) Apple Mail - Open email → View → Message → Raw Source, or View → Message → Long Headers. (5) Thunderbird - Open email → More → View Source → Ctrl+U. (6) Yahoo Mail - Open email → More → View Raw Message. Automated analysis tools: (1) MXToolbox Email Header Analyzer - Paste headers → get formatted output, shows SPF/DKIM/DMARC results, IP geolocation, spam score, hop-by-hop timeline. (2) Google Admin Toolbox - messageheader.google.com, similar to MXToolbox, good for Gmail analysis. (3) This Email Header Analyzer - Parse and visualize headers, extract authentication results, identify suspicious patterns. (4) Email Header Analyzer (Chrome Extension) - Right-click email → analyze headers, no copy-paste needed. Manual analysis workflow: (1) Identify sender - Check From, Return-Path, Reply-To (all match?). (2) Authentication - Find Authentication-Results header, check SPF/DKIM/DMARC (all pass?). (3) Trace path - Read Received headers bottom-to-top, extract and geolocate IPs. (4) Check timing - Verify timestamps make sense, consistent time zones. (5) Sender reputation - Lookup X-Originating-IP in AbuseIPDB, check domain in VirusTotal, query Spamhaus blocklists. Advanced analysis: (1) DKIM verification - Extract DKIM-Signature, extract public key: dig selector._domainkey.domain.com TXT, manually verify signature (use DKIM validator tool). (2) SPF lookup - Extract Return-Path domain, query SPF: dig domain.com TXT, check if sending IP in SPF record. (3) DMARC policy - Query: dig _dmarc.domain.com TXT, check policy (p=reject/quarantine/none). Automation for SOC teams: (1) Use SIEM to ingest email logs, (2) Create parsing rules for headers, (3) Enrich with threat intel (IP reputation, domain age), (4) Alert on patterns (authentication failures, unexpected geolocation, known bad IPs). Preservation for evidence: Save original email (.eml file format), screenshot full headers, document hash of email file (SHA-256), maintain chain of custody, use forensic email tools (FTK, EnCase). This tool helps automate header parsing and highlight security indicators.
Header-based phishing detection checklist: Indicator 1: Authentication Failures - ❌ spf=fail, dkim=fail, dmarc=fail → High confidence phishing, legitimate companies have working authentication, exception: legitimate but misconfigured senders (check other indicators). Indicator 2: Domain Mismatches - From: "CEO Name" [email protected], Return-Path: [email protected], domains don't match → spoofed sender. Indicator 3: Free Email Services for Business - From: [email protected], [email protected], [email protected], legitimate businesses use their own domains. Indicator 4: Reply-To Different from From - From: [email protected], Reply-To: [email protected], responses intercepted by attacker, legitimate mail rarely does this. Indicator 5: Suspicious Origin IPs - X-Originating-IP from unexpected country, IP belongs to VPN/hosting provider, IP has poor reputation (AbuseIPDB). Indicator 6: Unusual Received Path - Too many hops (10+), routing through unexpected countries, multiple free email services in chain. Indicator 7: Time Zone Inconsistencies - Email sent "from US office" at 3 AM local time, timestamps out of order or impossible. Indicator 8: Message-ID Patterns - Message-ID doesn't match From domain, generated by free email service, format inconsistent with claimed sender. Indicator 9: User-Agent Anomalies - Executive typically uses Outlook, but User-Agent: Gmail web interface, mobile app from user who always uses desktop. Indicator 10: Missing or Invalid DKIM - No DKIM signature (most businesses sign emails), DKIM d= domain doesn't match From domain, signature verification fails. Scoring system example: Authentication fail (all 3): +40 points, Domain mismatch: +30 points, Free email service: +25 points, Suspicious IP: +20 points, Reply-To mismatch: +15 points, Other anomalies: +10 points each. Total score: 0-30: Likely legitimate, 31-60: Suspicious (investigate), 61-90: High probability phishing, 91+: Almost certainly phishing. Real phishing example analysis: From: "Apple Support" <support@applé.com> (é is special char), Return-Path: [email protected] (Punycode for applé), Authentication-Results: spf=none, dkim=none, dmarc=none (no authentication at all), X-Originating-IP: 185.220.101.45 (Romania, VPN exit node), Received: from mail.cheaphosting.com (budget hosting), Message-ID: [email protected] (doesn't match "Apple"), User-Agent: PHPMailer 6.5.0 (bulk mail script). Result: Multiple red flags = phishing. Best practice: Combine header analysis with content analysis (urgent language, requests for credentials, grammatical errors, suspicious links).
⚠️ Security Notice
This tool is provided for educational and authorized security testing purposes only. Always ensure you have proper authorization before testing any systems or networks you do not own. Unauthorized access or security testing may be illegal in your jurisdiction. All processing happens client-side in your browser - no data is sent to our servers.