Why use MailTap?
Raw email headers stay in your browser — paste message headers containing your address, subject line, or server infrastructure without transmitting them anywhere.
Delay analysis, not just hop listing
Most header analyzers list the Received chain. MailTap calculates the elapsed time between each hop and flags slow ones — so you can see in one glance whether a 45-minute delivery was caused by a spam hold at hop 3 or a misconfigured relay at hop 5, rather than doing the timestamp arithmetic yourself.
Security anomaly detection built in
Reply-to domain mismatches, envelope sender divergence, auth failures, and missing required headers are checked automatically and surfaced as warnings with plain-English explanations. You don't need to know RFC 2822 to understand what the flag means.
No server, no account, no data retention
Email headers contain your address, the subject of the message, your mail server's IP, and routing information about your organisation's infrastructure. Tools that process headers server-side receive all of that. MailTap parses entirely in your browser — the text never leaves the page.
Works on messy real-world headers
RFC 2822 header folding, non-standard date formats, IPv6 addresses in brackets, multiple Authentication-Results from different gateways — MailTap handles the formats that real mail infrastructure actually produces, not just clean textbook examples.
How email routing works and what Received headers tell you
Every mail server that handles a message adds a Received header before passing it on. Reading them in order — oldest at the bottom, newest at the top — traces the full path from the sender's mail client through every relay to your inbox. Each Received header records the originating server, the receiving server, the protocol used (SMTP, ESMTP, HTTPS), and a timestamp. MailTap parses and reverses this chain into a readable hop-by-hop timeline, calculates the delay between each relay, and flags slow hops that might indicate a spam filter hold, a misconfigured relay, or deliberate delay injection.
SPF, DKIM, and DMARC: what each one actually checks
SPF (Sender Policy Framework) checks whether the IP address that sent the message is listed as an authorised sender for the From domain in that domain's DNS records. A FAIL means the sending server was explicitly rejected; a SOFTFAIL means it was not listed but the domain owner hasn't set a hard policy. DKIM (DomainKeys Identified Mail) checks a cryptographic signature attached to the message — if the signature verifies, the message body and key headers have not been altered since the sending server signed them. DMARC ties both together: it requires at least one of SPF or DKIM to pass and for the domain used to align with the visible From address. A DMARC FAIL means neither check aligned — strong evidence of spoofing or a misconfigured sending infrastructure.
Security anomalies: reply-to mismatch and envelope sender divergence
Several header combinations are reliable phishing signals. A Reply-To address on a different domain than the From address is one of the most common: the message appears to come from a legitimate organisation, but any reply goes to an attacker-controlled inbox. The Return-Path (envelope sender) is where bounces go — a mismatch with the From domain suggests the message was sent through a third-party relay that didn't properly authenticate for the visible From domain. MailTap checks both mismatches automatically and flags missing required headers like Message-ID and Date, which legitimate mail servers always include.
Reading delay data to diagnose delivery problems
The timestamp in each Received header is provided by the receiving server, not the sender — a server can't forge the timestamp on its own inbound Received entry. Comparing consecutive timestamps gives the time each relay held the message. Delays under a few seconds are normal handoff time. Delays of 30 seconds to several minutes typically indicate the message was held in a queue — usually at an anti-spam gateway running content analysis. Delays over 5 minutes warrant investigation: they may indicate a misconfigured relay, greylisting (where the receiving server temporarily rejects new senders to filter spam), or a network problem. MailTap highlights slow and very slow hops visually so you can see at a glance where time was lost.
What raw email headers are and how to get them
Every email has two parts: the body you read, and a block of technical metadata at the top called headers. Your email client hides these by default because they’re dense and meant for mail servers, not humans. But they contain the full story of how your email got to you. In Gmail, open the message, click the three-dot menu in the top right, and choose “Show original.” In Outlook, open the message, click File, then Properties — the headers are in the Internet headers box. Copy everything from that box and paste it into MailTap.
The routing chain: how your email bounced through the internet
An email doesn’t go directly from sender to recipient. It hops through a series of mail servers, like a relay race. Every server it passes through adds a record of itself at the top of the headers — a “Received” line. Reading these bottom-to-top gives you the path the message took. MailTap reverses them into chronological order and shows you each hop: which server handed the message off, which server received it, what protocol they used, and when. The timing between hops tells you where the message was delayed — often a spam filter holding it for analysis.
SPF, DKIM, and DMARC: the three checks that prove an email is real
Email is old technology — it was designed before spam and phishing existed, and anyone can put any address in the From field. Three authentication systems were added later to fix this. SPF checks whether the server that sent your email was actually allowed to send on behalf of that domain — the domain owner publishes a list of authorised servers in their DNS. DKIM is a cryptographic signature: the sending server signs the message with a private key, and your mail server verifies the signature using the public key in DNS — if it matches, nothing was tampered with in transit. DMARC ties both together and tells receiving servers what to do when they fail. MailTap shows you whether all three passed.
When to be suspicious: the warning signs MailTap flags
A few header patterns are classic phishing signals. A Reply-To address on a different domain than the From address means replies go somewhere the sender controls but the From address doesn’t. It’s how attackers make an email look like it came from your bank but have your reply go to a lookalike domain. Authentication failures (SPF fail, DKIM fail, DMARC fail) mean the message didn’t pass the checks designed to prove it’s genuine. Missing a Message-ID or Date header is unusual for legitimate mail servers — they always add them. MailTap flags all of these automatically.