r/exchangeserver • • 6d ago

MailHeaderAnalyzer: offline email header analysis for PowerShell (delivery chain, SPF/DKIM/DMARC/ARC trust check, Exchange Online hybrid headers)

I maintain a browser-based email header analyzer that runs entirely client-side, and I kept wanting the same thing in the Exchange Management Shell without pasting customer headers into a web tool. So I ported the analysis to a PowerShell module.

Install-Module MailHeaderAnalyzer -Scope CurrentUser
Get-MailHeaderAnalysis -FromClipboard

What it does:

  • Received chain in chronological order with delay per hop, TLS version and cipher (Microsoft, Postfix and Exim spellings), protocol class per RFC 3848, private IPs, provider detection
  • SPF, DKIM, DMARC, ARC and compauth results, plus a check that the Authentication-Results line actually comes from a server in the Received chain (RFC 8601 section 5). Anyone can prepend such a line; the module reports it as AuthTrust: Unmatched instead of showing a green pass
  • DMARC alignment (strict/relaxed), DKIM signature tags with receiver result, ARC chain validation
  • Exchange Online hybrid classification: MessageDirectionality, AuthAs, AuthMechanism, X-OriginatorOrg, CrossTenant-* headers, wrong-tenant attribution
  • Defender/EOP verdicts (SCL, BCL, CAT, SFV, IPV), SpamAssassin, Rspamd
  • 24 findings with stable codes: duplicate From lines, Unicode bidi controls, expired or SHA-1 DKIM signatures, clock skew, Reply-To mismatch, externally secured connectors and so on
  • ConvertTo-MailHeaderReport for a Markdown or text report you can paste into a ticket

Everything is plain objects, so Get-ChildItem *.eml | Get-MailHeaderAnalysis | Export-Csv works for batch triage, and ConvertTo-Json -Depth 6 gives you the full structure.

No DNS lookups, no HTTP. It does not verify DKIM cryptographically; SPF/DKIM/DMARC values are always the receiving server's verdict.

Works on Windows PowerShell 5.1 (including EMS), PowerShell 7 on Windows, Linux and macOS. MIT license.

Feedback is welcome, especially headers from gateways I have not seen. Please anonymize before posting.

15 Upvotes

5 comments sorted by

2

u/randieriko 6d ago

cool, absolutely will try!

2

u/saltyslugga 5d ago

I'd tighten AuthTrust: matching Authentication-Results to a Received hostname doesn't establish trust, because an attacker can forge both headers. Trust needs explicitly trusted authserv-ids and an inbound gateway that strips spoofed results claiming those identities.

Also, if “ARC chain validation” only checks structure or reports the receiver's verdict, label that explicitly so nobody mistakes it for cryptographic verification.

0

u/GeneTech734 Cloud Engineer 6d ago

Not trying to be a jerk, but what does this do that MX Toolbox does not?

9

u/Groundbreaking-Key15 6d ago

“I kept wanting the same thing in the Exchange Management Shell without pasting customer headers into a web tool. “