Email Header Analyzer

Email headers are metadata fields attached to every email message, containing the complete routing information, authentication results, and technical details about the email's journey from sender to recipient. Headers are hidden from normal view but reveal critical forensic data. Key header information: Received headers show every mail server that handled the message, with timestamps and IP addresses, creating a complete trail. From/To/Subject are basic visible fields. Return-Path indicates where bounces should go (often reveals actual sender). Message-ID is a unique identifier for the email. Received-SPF, DKIM-Signature, ARC-Authentication-Results show email authentication status. X-Originating-IP reveals the sender's IP address. X-Mailer or User-Agent identifies the email client software used. Content-Type specifies message format (plain text, HTML, multipart). X-Spam-Status and X-Spam-Score show spam filtering results. Headers help identify: spam sources, phishing attempts, spoofed emails, delivery delays, server misconfigurations, and the true origin of suspicious messages. They're essential for email forensics, troubleshooting delivery issues, and verifying email authenticity.

To view headers: In Gmail, open the email, click three dots menu, select 'Show original'. In Outlook, open the message, go to File > Properties > Internet headers. In Apple Mail, select message, choose View > Message > All Headers. Copy the entire header text and paste it into the Email Header Analyzer. Red flags for spam/phishing: Mismatched From addresses - display name says 'PayPal' but actual address is randomstring@suspicious-domain.ru. Failed authentication - SPF, DKIM, or DMARC failures indicate the sender isn't authorized. Suspicious originating IPs - trace 'Received' headers to find the first server; residential IPs or foreign countries may indicate compromise. Missing or forged headers - legitimate mail servers add consistent headers; minimal headers suggest manipulation. Mismatched Return-Path - if Return-Path domain differs from From domain, it may be spoofed. Recent timestamps - but message claims to be urgent notification about old activity. Generic Message-IDs - legitimate services have consistent ID patterns. The analyzer highlights these issues automatically, showing authentication failures, suspicious server chains, and potential spoofing indicators. Check if domains in From, Return-Path, and DKIM signatures all match the claimed sender.

Received headers document each mail server hop in reverse chronological order (newest first, oldest last). Each 'Received:' line contains: the server name/IP that received the message, the server it was received from, and a timestamp. To trace the path: Start from the bottom Received header (original sender) and work upward to your mailbox. The Email Header Analyzer automatically parses and orders these chronologically. Example chain: (1) Sender's mail client → (2) Sender's outbound SMTP server (smtp.example.com) → (3) Recipient's MX server (mx.gmail.com) → (4) Recipient's mailbox. Identifying delays: Compare timestamps between consecutive Received headers. Normal processing is seconds to minutes. Hours-long gaps indicate: server queues due to high volume, greylisting (temporary rejection to deter spam), DNS problems causing delivery retries, network connectivity issues, or aggressive spam filtering. For example: if an email left the sender at 10:00 AM but didn't reach the first recipient server until 2:00 PM, the delay is in sender's infrastructure or network path. If it reached the recipient's server at 10:05 AM but wasn't delivered to the inbox until 3:00 PM, the delay is in recipient-side filtering or processing. The analyzer calculates total transit time and highlights unusual delays exceeding normal thresholds (typically >30 minutes for most routes).

Email headers contain authentication results that verify sender legitimacy. SPF (Sender Policy Framework) results appear as Received-SPF: pass or Authentication-Results: spf=pass. Pass means the sending IP is authorized in the domain's SPF record. Fail indicates unauthorized sending (potential spoofing). Softfail (~all) suggests possible unauthorized sender but not definitive. Neutral means SPF doesn't assert authorization. None indicates no SPF record exists. DKIM (DomainKeys Identified Mail) shows as dkim=pass header.d=example.com. Pass means the cryptographic signature is valid and message wasn't altered. Fail indicates signature verification failed (message tampered or misconfigured DKIM). None means no DKIM signature present. The header.d= shows which domain signed it. DMARC results: dmarc=pass means both SPF/DKIM passed AND the domain aligns (From domain matches authenticated domain). Fail means authentication or alignment failed. Check the action= field: none (monitoring only), quarantine (moved to spam), or reject (blocked entirely). Best practice: Trust emails with SPF=pass, DKIM=pass, DMARC=pass. Investigate if any authentication fails, especially for sensitive requests like password resets or financial transactions.

Display name spoofing: Check if the visible name matches the actual email address. 'CEO John Smith ' is obviously spoofed. Look at the From: header's actual address, not just the display name. Domain spoofing: Examine closely for typosquatting: paypa1.com (number 1 instead of L), micr0soft.com (zero instead of O), or subdomain tricks like paypal.com.suspicious-domain.com. Return-Path mismatch: If Return-Path: bounces@spam-domain.net but From: support@legitimate-bank.com, it's spoofed. Replies go to the From address, but technical bounce addresses reveal true sender. Authentication failures: Failed SPF/DKIM/DMARC strongly suggest spoofing. Legitimate companies have proper authentication. Originating IP analysis: Find the first 'Received:' header (bottom of the list) showing from [IP.address]. Perform reverse DNS or geolocation lookup. If the IP is residential, foreign, or belongs to a hosting provider rather than the claimed company's network, it's suspicious. Message-ID format: Legitimate services have consistent patterns like <uniqueid@mail.example.com>. Random or mismatched domain suggests forgery. Received header count: Too few headers (1-2) might indicate header stripping. Too many unusual relays suggest bot networks. The analyzer flags these discrepancies automatically, but understanding the underlying indicators helps you make informed trust decisions.

First, do not click any links or download attachments in the suspicious email. Do not reply or follow any instructions it contains. Document the evidence: Save the full email headers and the message itself. Take screenshots. Note the timestamp, sender details, and any suspicious URLs. Verify through official channels: If the email claims to be from your bank, a service provider, or colleague, contact them directly using known-good contact information (not information from the suspicious email). For example, call the bank's official customer service number from their website or your card. Report the phishing: Forward the entire email with headers to the legitimate organization being impersonated (most banks have abuse@bankname.com or phishing@servicename.com). Report to your email provider: Gmail (click Report Spam/Phishing), Outlook (Report phishing), etc. Report to Anti-Phishing Working Group at reportphishing@apwg.org. Report to FTC at ftc.gov/complaint if you're in the US. Internal threats: If in a corporate environment, report immediately to your IT security team. They may need to block the sender, warn other employees, or investigate if systems were compromised. If you clicked or provided information: Change passwords immediately for affected accounts, enable two-factor authentication, monitor financial accounts for unauthorized activity, run antivirus/malware scans, and consider credit monitoring if personal/financial information was exposed. Delete the phishing email after documentation to prevent accidental future interaction.