Email DNS toolbox

MX, SPF, DKIM & DMARC checker — free

Run a full email health scan on any domain: MX records with provider detection, SPF with the complete include-tree and the RFC 7208 ten-lookup counter, DKIM key probing across common selectors, DMARC policy analysis, MTA-STS, TLS-RPT and BIMI — graded A–F with a plain-English explanation for every finding, and builders to generate correct SPF and DMARC records. Lookups go over encrypted DNS-over-HTTPS straight from your browser to Cloudflare or Google.

Where your query goes: DNS lookups travel from your browser directly to Cloudflare (1.1.1.1) over encrypted DNS-over-HTTPS. BRev has no server in this flow and never sees the domain you check — but the resolver you pick does, like it would for any DNS lookup. Nothing here can honestly claim “nothing leaves your device”: a DNS check is a network request by definition.

Email health scorecard

Enter a domain above and run the scan — MX, SPF (with the full include-tree and lookup count), DKIM, DMARC, MTA-STS, TLS-RPT and BIMI, all at once.

How SPF, DKIM and DMARC actually interlock

SPF answers “is this server allowed to send for the bounce address?” — a TXT record listing permitted senders. DKIM answers “was this exact message cryptographically signed by the domain?” — a signature in the header, verified against a public key in DNS. Each alone has a hole: SPF breaks on forwarding, DKIM says nothing about the visible From: line. DMARC closes the loop: it requires that at least one of them passes and aligns with the From: domain the human actually sees, and — crucially — tells receivers what to do when neither does (p=none / quarantine / reject) and where to send reports (rua=).

The 10-lookup rule

Evaluating SPF may cost at most 10 DNS queries (RFC 7208 §4.6.4): every include:, redirect=, a, mx, exists: and ptr counts, and includes count recursively. Cross the limit and receivers return PERMERROR — your SPF silently stops working everywhere, usually after someone adds “just one more” marketing tool. The SPF tab walks the whole tree and shows the exact count; ip4:/ip6: terms are free, which is why flattening heavy includes into IP ranges is the standard fix.

Why p=none is only a start

p=none enforces nothing — spoofed mail is still delivered; you just get reports about it. It exists so you can discover every legitimate sender (the payroll tool, the CRM, that one newsletter service) before turning enforcement on. Sitting at p=none forever is the most common DMARC failure mode: you have the camera footage but the door is still unlocked. Ratchet: none → fix what the reports surface → quarantine (optionally with pct=) → reject.

And the rest

MTA-STS + TLS-RPT protect mail to you: they let senders refuse to deliver over an unencrypted connection and report when TLS fails. BIMI is the reward at the end: once DMARC is at quarantine/reject, your logo can appear beside messages in Gmail, Yahoo and Apple Mail (with a Verified Mark Certificate). Null MX (0 .) is the correct way to say a domain never receives mail — and parked domains should also publish v=spf1 -all plus p=reject so nobody can send as them.

Free MX lookup, SPF checker with include-tree and lookup counter, DKIM selector probe, DMARC checker and generator, MTA-STS, TLS-RPT and BIMI validation — running as DNS-over-HTTPS from your own browser.