📧 Email Auth Check
Enter a domain to fetch MX, SPF, DMARC, MTA-STS, TLS-RPT records and validate them.
📚 Email Auth Basics
• SPF: Declares which IPs/hosts may send mail for this domain (TXT)
• DKIM: Adds a digital signature to messages — selector required so cannot be auto-detected
• DMARC: Policy on top of SPF/DKIM (none / quarantine / reject)
• MTA-STS: Tells senders TLS is required for delivery
• TLS-RPT: Where to send reports about TLS delivery failures
📖 What this check tells you
This check reads DNS only, reporting on MX, SPF, DMARC and MTA-STS / TLS-RPT. DKIM is not included: its public key cannot be fetched without knowing the selector name, and selectors are not enumerable from DNS. Note also that all green here does not mean your mail reaches the inbox. Deliverability is driven mainly by the reputation of your sending IP and domain; authentication records are only the precondition.
| Item | What it means | How to fix it |
|---|---|---|
| SPF can pass on forged mail | SPF validates the envelope sender, the Return-Path, and never looks at the From: header the recipient actually sees. An attacker can configure SPF perfectly for a domain they control and still put your company in From:. SPF alone does not stop impersonation. |
DMARC closes this with alignment, requiring the From: domain to match the domain that passed SPF or DKIM. When you send through a SaaS, the default Return-Path is the vendor domain, so alignment fails. Use the custom Return-Path or sending-domain-authentication setting in that service to move it to a subdomain of yours, such as bounce.example.com. |
| DMARC left at p=none | p=none says: do nothing when authentication fails. The record exists, and not one forged message is being blocked. Because a record is present, checkers show green — which is exactly why this state gets mistaken for done. |
Collect aggregate reports with rua=mailto:… and spend two to four weeks identifying every legitimate sender — a marketing tool, a billing system, an old internal script you had forgotten. Once they all authenticate, start at p=quarantine; pct=10, raise the percentage gradually to 100, and finish at p=reject. |
| Forwarding always breaks SPF | When mail passes through a mailing list or an auto-forward, the sending IP becomes the forwarder, so SPF fails every time. That is inherent to the mechanism, not a misconfiguration. DKIM signs the body and headers, so it survives as long as the forwarder does not rewrite them. | Always configure DKIM. DMARC passes if either SPF or DKIM aligns, so DKIM keeps authentication intact through a forward. Raising to p=reject with SPF alone gets every forwarded message rejected. Mailing lists that prepend a subject tag break DKIM too, and there you have to rely on receivers that support ARC. |
A send-only domain that never receives mail still needs configuration. Rather than leaving MX empty, publish a null MX (0 ., RFC 7505) and declare v=spf1 -all with p=reject, so spam claiming to be from that domain is refused outright. The other trap worth knowing is that sender verification at an email provider is matched on the exact domain: verifying example.com does not necessarily authorise mail from mail.example.com. That is what stopped our own outbound mail until we standardised on a sender at the parent domain.