Email header analyzer
Extract public relay addresses and reported SPF, DKIM, and DMARC outcomes from raw headers.
Quick answer
The email header reader extracts Received lines, public relay addresses, and reported SPF, DKIM, and DMARC outcomes from raw message headers. Received entries are normally read from the oldest trusted hop upward. The parser summarizes text already present; it does not independently authenticate the message.
Read a redacted mail route without claiming sender identity
Use the header reader to summarize Received hops, public relay addresses, and authentication-result text already present in a message. Headers can contain personal and internal details, so preserve the original privately and submit only the redacted lines needed for this diagnostic view.
Trace delivery order
Read Received lines from the bottom upward while recognizing that untrusted systems can add misleading text before a trusted relay accepts the message.
Review authentication results
Treat SPF, DKIM, and DMARC text as reported outcomes and verify signatures or policy through a capable mail system when the decision matters.
Investigate a suspicious message
Preserve the original in the mail platform, avoid clicking content, and send the relevant evidence to the provider or security team rather than confronting an address owner.
Follow the result into the next relevant page
Read reverse DNS lookup because it checks an optional PTR name for a relay address; Read DNS record lookup because it shows published mail and policy records; Read IP exposure guide because it sets the boundary between network clues and identity.
How to interpret the output
Each mail system adds information from its own viewpoint, while untrusted senders can forge earlier-looking lines. Authentication-Results is meaningful when it was added by a receiver you trust. A public relay address may belong to a shared mail service and does not necessarily locate or identify the author.
A reliable checking workflow
Obtain full headers from the receiving mailbox, redact names, addresses, message identifiers, internal hosts, and content not needed for analysis, then submit the remaining text. Start with the receiving system’s trusted authentication result and follow hops backward only as far as the trust boundary supports.
Key ideas behind email header analyzer
Mail headers record how systems handled a message. They can show relay hops and reported authentication results, but they do not provide a trustworthy identity by themselves.
Received chain
Each trusted mail server adds a line describing the handoff it observed.
Authentication results
SPF, DKIM, and DMARC fields report different checks and must be read from a receiver you trust.
Personal data
Headers can contain names, addresses, internal hosts, message IDs, and routing details that should be redacted.
Example: tracing from the trusted receiver backward
Start with the top Received line added by your mailbox provider, then move toward older hops only while you trust the adding server. A forged sender can insert convincing-looking early lines. Preserve the original message privately if the issue may need a provider or security-team investigation.
The boundary that matters
The reader does not validate DKIM cryptography, query current DNS policy, identify a person, or prove that a displayed address originated the message. Forwarding and mailing lists can legitimately alter authentication outcomes. Preserve the original message when reporting abuse because a pasted summary omits evidence.
How the main entities relate
| Subject | Relationship | Object |
|---|---|---|
| Receiving mail server | adds | a Received header |
| DKIM signature | binds | selected message fields to a domain |
| DMARC policy | evaluates | aligned authentication results |