Free diagnostic
Paste up to 64 KB of message headers to inspect required fields, dates, Message-ID, reply-path consistency, unsubscribe support, MIME, and common risk signals.
The analyzer keeps only the header block in memory for the request, discards any pasted body, and redacts addresses, Message-IDs, and IP addresses before returning evidence.
A clean header block cannot guarantee inbox placement. Sender reputation, authentication alignment, recipient history, content, links, and provider behavior remain separate inputs.
Fundamentals
The header block is the routing label of an email message. RFC 5322 strictly requires only two fields: the origination date (Date) and the originator (From). To, Subject, and Message-ID are formally optional, though receivers treat the common fields as effectively mandatory. A missing Date or malformed From is both non-compliant and a strong spam signal, which is why required-field checks come first. The Received fields are the travel log. Every server that handles the message prepends its own Received line, so the topmost one came from the last hop, usually your own provider, and the bottom one claims the origin. Read the chain bottom-up to follow the actual path. The catch: only lines written by servers you trust can be believed; anything lower is text the sender's side could have written, and forgers add fake hops routinely. The receiving server also records what it verified. Authentication-Results (RFC 8601) summarizes the spf, dkim, and dmarc verdicts computed on arrival, and it is the most useful line in the block because your own provider wrote it. Received-SPF and DKIM-Signature carry the raw material for those verdicts; the SPF, DKIM, and DMARC explainer covers what each means. Headers can prove what a server observed, not who the human sender was: every line below your provider's additions is forgeable, so authentication alignment matters more than the display name next to From.
Reading the output
Paste up to 64 KB of headers. Only the header block is parsed; anything after the blank line is discarded, and addresses, Message-IDs, IPs, and routing data are redacted before evidence is shown. The tool is anonymous, rate limited, and retains nothing you submit. The overall status is the worst individual outcome: pass, warning, or fail.
Troubleshooting
Most header failures trace back to a few causes, and nearly all are fixed at the sender: in your mail library, your ESP's settings, or your mailing software's defaults.
Providers
The standards are shared, but large providers write authentication evidence in different dialects and enforce different requirements. Knowing whose format you are reading prevents misdiagnosis.
Comparison
All three names come up for header work, but they are built around different jobs. MXToolbox offers free, ad-supported one-off tools, with paid monitoring from $129 per month. dmarcian is a paid, DMARC-focused suite for deployment and reporting. WillItInbox runs this analyzer free with no login, redacts addresses, Message-IDs, and IPs automatically, discards any pasted body, and retains nothing; for verdicts on a message you sent, the full deliverability test verifies DKIM, DNS, content, and links.
| Capability | WillItInbox | MXToolbox | dmarcian |
|---|---|---|---|
| Header analysis | Free, one-off, no login | Free, ad-supported tools | Not the product's focus |
| Automatic PII redaction | Addresses, Message-IDs, IPs redacted | Varies by product | Varies by product |
| Submitted-data retention | None; bodies discarded | Varies by product | Varies by product |
| DMARC deployment and reporting | Checker plus adjacent tools | Broad DNS diagnostic toolkit | Core paid offering |
| Ongoing monitoring | Full sent-message testing | Paid plans from $129/mo | Core paid offering |
Live diagnostic
This anonymous tool is rate limited and does not retain submitted input. It reports observable evidence without promising delivery, authentication alignment, or inbox placement.
No SMTP mailbox probing, account lookup, or tenant data is used.
Related
Implement one-click handling correctly.
Understand MIME alternatives.
Analyze the complete sent message.
Read the supporting guide for practical context around email deliverability testing.
Inspect the evidence format customers use to prioritize authentication, DNS, content, and placement fixes.
See how test inboxes turn authentication, DNS, headers, content, and link evidence into a launch-ready report.
Use the REST API reference when validation, bulk jobs, webhooks, reports, or usage need to run from your own systems.
Compare validation volume, monitoring, API access, reporting, and workspace limits by plan.
FAQ
No. The tool is anonymous, rate limited, and retains nothing you paste. Only the header block is parsed, anything after the blank line is discarded, and addresses, Message-IDs, and IPs are redacted before evidence is displayed. Do not paste full message bodies; they are not needed.
RFC 5322 recommends Message-ID rather than requiring it, so a missing one is not a standards violation on its own. In practice, filters treat absent or malformed IDs as a risk signal because legitimate mail software generates them automatically. The fix is at the sender: configure your application, library, or ESP to emit a unique, fully qualified ID per message.
One-click unsubscribe requires two fields together: a List-Unsubscribe header containing an HTTPS URL, and the RFC 8058 List-Unsubscribe-Post: List-Unsubscribe=One-Click field. The endpoint must accept the POST and process it without login or confirmation. Any missing piece fails; Gmail and Yahoo require the full setup from bulk senders of marketing mail.
No. Any header line below the ones your provider added can be forged, including From, Reply-To, and the lower Received hops. What headers establish is what a server observed: Authentication-Results says whether the stated domains passed SPF, DKIM, and DMARC on arrival. That is evidence about domains, not proof about a person.
Reply-To is a message header telling recipients where replies should go, honored by mail clients when someone hits reply. Return-Path is the envelope bounce address, copied from the SMTP MAIL FROM command by the final receiving server, and it receives failure notices. SPF alignment is evaluated against the Return-Path domain, never Reply-To.
They are not; each server prepends its own Received line, so the newest entry is at the top. Read the chain bottom-up to trace the path from origin to destination. Forwarding adds hops and typically breaks SPF on the forwarded copy, since the forwarder's IP is not authorized by the original domain.
No. Header structure is one input among many. Sender reputation, SPF, DKIM, and DMARC alignment, content, links, and engagement history all feed placement, and none of that is visible in a pasted header block. A pass means the structure is clean, not a delivery promise. Verifying authentication and content requires sending a real message to a test inbox.
