What this analysis does
Paste a header to evaluate visible sender identity, return path, authentication results, route consistency and obvious identity anomalies. The receipt is designed for human review, not as a guarantee that content is safe.
Deciding whether a message is what it claims to be is a question about identity and authentication evidence, not about tone or urgency. This analysis compiles the identities a message asserted and the authentication results a receiver recorded into a compact, evidence-bounded assessment.
What the assessment is built from
The receipt records the visible From domain, the envelope sender, the DKIM signing domain and any Reply-To, then places the receiver-stamped SPF, DKIM and DMARC results alongside them. The relationship between those identities is what carries meaning, rather than any single field.
The strongest positive signal is an aligned DKIM signature over a domain that plausibly owns the message. The strongest negative signal is a DMARC failure for a domain that publishes an enforcing policy, because that combination indicates the message would have been rejected had policy been applied.
- Identity relationships matter more than any individual field.
- Aligned DKIM is the most durable positive signal.
- A DMARC failure against an enforcing policy is a strong negative signal.
Authentication is not a safety verdict
A message can authenticate perfectly and still be harmful. When an attacker compromises a legitimate account, everything the receipt examines passes, because the mail genuinely originates from the authorized infrastructure. Authentication establishes provenance, not intent.
The inverse is also common. Mailing lists and forwarding services routinely break SPF alignment and sometimes invalidate DKIM signatures through content modification, producing authentication failures on entirely legitimate mail. Both directions argue against reading a single score as a verdict.
Where a receipt is genuinely useful
The clearest application is a disputed message. When a recipient asserts that a request came from a known party and the sender denies it, the receipt records what the receiving system observed, in a form that can be attached to a ticket or an incident record.
It is also a fast triage step before a payment or credential action. If a message requesting a change fails alignment for a domain that normally aligns, that discrepancy is worth an out-of-band check regardless of how ordinary the message reads.
Verify an emailed payment changeProduce a portable evidence manifest
Example: an unsigned message from an enforcing domain
Evidence supplied
A message whose From domain publishes an enforcing DMARC policy, with no DKIM signature and an unaligned envelope sender.
How to read the result
The receipt reports that no aligned authentication path exists and that the domain publishes enforcement. That combination indicates the message did not originate from the domain’s authorized infrastructure, and the assessment reflects that directly.
Known limits
- The assessment is bounded by supplied evidence; headers added outside your trust boundary can be forged.
- A passing result does not establish that the content or any attachment is safe.
- Forwarding and mailing lists frequently break authentication on legitimate messages.
Common questions
Can this confirm a message is a phishing attempt?
It can show that identity and authentication evidence is inconsistent with the domain the message claims. Intent is a separate judgement that requires context beyond the header.
Why does a message from a known contact fail?
Forwarding, mailing lists and some security gateways modify messages in ways that break SPF alignment or invalidate a DKIM signature. Check the route before treating the failure as impersonation.
Is a passing result sufficient to act on a payment request?
No. Verify any payment or credential change through an independently known channel, regardless of how the authentication evidence reads.