Email Authentication — SPF, DKIM, DMARC & MTA-STS in practice

Email is still where most intrusions start, and for a supervised financial entity a spoofed domain is both an incident and a reputational problem. Email authentication is the layered answer — but the layers only help when they are configured, monitored, and actually enforced. This is the map, and the tool to reach for at each step.

The stack, in one paragraph

SPF declares which servers may send for your domain. DKIM cryptographically signs each message so tampering and forgery are detectable. DMARC ties the two to the visible From: address, tells receivers what to do when a message fails (none → quarantine → reject), and — crucially — asks them to report back. MTA-STS forces TLS on the delivery path so the mail can't be quietly downgraded, and BIMI rewards a domain that reaches p=reject with a verified logo. The order you deploy them in matters as much as the records themselves.

The workflow

These tools are built to be used in sequence — the output of one is the input of the next.

1. Email Header Analyzer — Start here when a message looks off. Paste the raw headers to reconstruct the delivery path, read the SPF/DKIM/DMARC results the receiver recorded, and find the true originating IP.
2. Phishing Checker — When the header trail smells wrong, run the message and its links through the phishing indicators to defang URLs and score the intent before anyone clicks.
3. Email Security Checker — Flip to the outbound side: check whether a domain actually publishes SPF, DKIM, DMARC and MTA-STS — and whether they are configured strictly enough to matter.
4. Email Auth Builder — Fix what the check found. Generate correct SPF, DMARC and MTA-STS records to publish for your own domain, without the copy-paste mistakes that silently break delivery.
5. Dmarc Report Analyzer — Once DMARC is live, turn the daily aggregate (RUA) XML into a readable pass/fail-by-source view so you can move the policy from p=none to p=reject with evidence.

Where teams get it wrong

• DMARC left at p=none forever. Monitoring mode protects no one. The aggregate reports exist precisely so you can reach enforcement safely — read them.
• SPF over-stuffed past 10 DNS lookups. It silently returns permerror and the whole record stops being evaluated. The builder keeps you under the limit.
• DKIM signing, but not the From: domain. Alignment is what DMARC checks — a valid signature on the wrong domain still fails DMARC.
• MTA-STS in testing mode indefinitely. Like DMARC, it does nothing until you enforce it.

FAQ

Do I need all of SPF, DKIM and DMARC?

Yes. SPF and DKIM are the mechanisms; DMARC is the policy and the feedback loop that makes them enforceable and observable. Any one alone leaves a gap an attacker can drive through.

Is a session cookie or my IP sent anywhere by these tools?

The lookups that need live DNS/SMTP data run server-side and never forward your IP; the analysis tools run in your browser. See the privacy notice.

What's the safe order to reach p=reject?

Publish SPF and DKIM, deploy DMARC at p=none with a reporting address, read the aggregate reports until every legitimate source aligns, then step to quarantine and finally reject. The report analyzer is what turns that from guesswork into a checklist.