# Email deliverability audit: find DNS issues in 5 minutes

> Online SPF, DKIM, DMARC validator free + MX lookup via DoH + 6-way multi-resolver compare (Cloudflare, Google, AliDNS, dns.sb) for email deliverability.

Free in-browser tool (no upload): https://www.mauriziofonte.it/tools/email-dns-validator

Toolkit for **email deliverability** audits: parser and validator for **SPF**, **DKIM**, **DMARC** records; **MX lookup** via DNS over HTTPS; **6-way multi-resolver compare** to spot asymmetric propagation, stale cache or DNS poisoning (Cloudflare 1.1.1.1, Cloudflare Security 1.1.1.2, Cloudflare Family 1.1.1.3, Google 8.8.8.8, AliDNS 223.5.5.5, dns.sb). Extends the [DoH query tester](/tools/dns-over-https-tester) with email-security focus. Built for pre-deploy audits and troubleshooting of email that doesn't reach the inbox.

## How to audit email deliverability

1. **Extract DNS records** - From terminal: `dig TXT example.com` for SPF, `dig TXT _dmarc.example.com` for DMARC, `dig TXT selector._domainkey.example.com` for DKIM (selector = e.g. `google`, `k1`, `default`). Copy the TXT response content (between quotes).
2. **Paste into the matching tab** - SPF tab: paste `v=spf1...` string. DKIM tab: paste `v=DKIM1; k=rsa; p=...`. DMARC tab: paste `v=DMARC1; p=...;...`. 'Parse' button: the tool shows findings.
3. **Read the findings** - The parser identifies common issues: SPF +all (too permissive), too many DNS lookups (>10), DMARC p=none (monitoring without enforcement), DKIM empty p= (revoked key). Severity color-coded: red = critical, yellow = warning, green = OK.
4. **MX lookup and multi-resolver** - 'MX lookup' tab fetches via DoH and shows mail servers with priorities. 'Multi-resolver' tab runs the same query against 6 different public resolvers (4 unfiltered: Cloudflare/Google/AliDNS/dns.sb + 2 filtered Cloudflare Security/Family) and compares answers. Differences between unfiltered = asymmetric propagation or stale cache. Difference between filtered and unfiltered = domain blocked by DNS filter (malware/adult).

## Why a dedicated toolkit

**Email deliverability is a chain of standards.** SPF, DKIM and DMARC are the three RFCs that govern modern email authentication. Each has specific syntax and subtle errors that lead to rejected or spam-flagged mail: SPF with `+all` instead of `-all` is equivalent to declaring 'anyone can send', DMARC with `p=none` never promoted to `p=reject` stays in monitoring mode without enforcement, DKIM with 1024-bit RSA keys is deprecated since 2018 (M3AAWG and Microsoft enforce 2048-bit minimum). Identifying these issues requires reading RFCs, counting lookups, decoding keys: the tool automates the chain.

**6-way multi-resolver compare.** Most lookup tools query a single resolver. Here queries fan out in parallel to **6 public resolvers**, split into two groups: **4 unfiltered** (Cloudflare 1.1.1.1, Google 8.8.8.8, AliDNS 223.5.5.5, dns.sb) to verify propagation and cache, and **2 content-filtering** (Cloudflare Security 1.1.1.2 blocks malware, Cloudflare Family 1.1.1.3 blocks malware + adult) for block detection. Differences between unfiltered indicate stale cache or asymmetric propagation; differences between unfiltered and filtered indicate a domain classified as malicious by the Cloudflare DNS filter. Useful in pre-deploy verification and in detecting compromised domains.

**Audit suitable for sensitive domains.** The SPF, DKIM and DMARC parsers analyze the text you paste autonomously from the actual DNS of the domain: useful to validate a record before publishing it, or to audit scenarios where the lookup itself must remain invisible. MX and multi-resolver queries, when needed, go directly to public resolvers via DNS over HTTPS, with an 8-second per-fetch timeout. The audited domain does not transit through a commercial backend that would log it: typical scenarios M&A, due diligence, pre-launch.

 Once an SPF, DKIM or DMARC record is published or fixed, the next question is when it will be visible everywhere: the [DNS propagation checker](/tools/dns-propagation-checker) reads each cache's remaining TTL and answers with a number.

## Glossary

- **SPF**: Sender Policy Framework, RFC 7208. TXT record published by the sending domain declaring which IP servers are authorized to send mail on its behalf. The receiver checks the sender IP against the SPF policy to accept/reject.
- **DKIM**: DomainKeys Identified Mail, RFC 6376. Cryptographic email signature using the sender's private key. The receiver verifies with the public key published in DNS (TXT record under `selector._domainkey.domain`).
- **DMARC**: Domain-based Message Authentication, Reporting and Conformance, RFC 9989 (May 2026, obsoletes RFC 7489), with aggregate reports in RFC 9990 and failure reports in RFC 9991. Policy that tells the receiver what to do if SPF and/or DKIM fails: `none` (pass, monitoring), `quarantine` (spam folder), `reject` (reject). Includes reporting via `rua`.
- **MX record**: Mail Exchanger DNS record declaring the domain's mail servers (priority + hostname). Without MX, the domain cannot receive email. Typical setup: 2-4 MX with different priorities for failover.
- **DNS lookup limit (SPF)**: RFC 7208 sec. 4.6.4 limits SPF to max 10 DNS lookups (include, a, mx, ptr, exists). Exceeding the limit causes **permerror**: the record is treated as invalid. Consolidate includes into IP4/IP6 ranges to reduce lookups.
- **DNS over HTTPS (DoH)**: Protocol that wraps DNS queries inside HTTPS on port 443, RFC 8484. Replaces traditional DNS (UDP/TCP 53) with an encrypted channel that prevents passive inspection of queries by network intermediaries. The tool uses DoH JSON format (Accept: application/dns-json) supported by all major public resolvers: Cloudflare, Google, AliDNS, dns.sb.

## Frequently asked questions

### Can I paste the record with surrounding quotes?

Yes, the parser automatically strips edge quotes and whitespace. SPF and DMARC are often published with double quotes in `dig` output (RFC 7208 TXT segmentation). String concatenation of split TXT records (e.g. `"v=spf1..." " include:..."`) is also handled.

### Does the tool fetch the record from DNS?

The SPF, DKIM and DMARC parsers analyze the text you paste directly; they do not query the domain's DNS. MX lookup and multi-resolver instead reach out to the 6 public resolvers via DNS over HTTPS (Cloudflare 1.1.1.1, Cloudflare Security 1.1.1.2, Cloudflare Family 1.1.1.3, Google 8.8.8.8, AliDNS 223.5.5.5, dns.sb). Each query has an 8-second timeout to avoid hanging on slow resolvers.

### Why is DKIM 1024-bit key size deprecated?

M3AAWG (Messaging Anti-Abuse Working Group) recommends 2048+ bits since 2018. Microsoft enforces 2048 minimum since 2024 for Outlook deliverability. RSA 1024 is considered breakable with ~$10K-100K compute (factoring), so not safe against motivated attackers. Migration: generate new 2048+ key, publish new selector, wait 30 days, retire old key.

### Is DMARC p=none safe?

**No**, it's monitoring only. It does not block spoofing of your domain. It's the initial phase of a DMARC rollout: publish `p=none` with `rua`, collect aggregate reports for 30-60 days, identify your legitimate mail servers failing SPF/DKIM, fix the configuration, then promote to `p=quarantine` (3 months) and finally `p=reject` (final target).

### Multi-resolver: what does a difference mean?

Typically: (1) **stale cache**: one resolver still has the old record cached (TTL not yet expired). Wait for TTL and re-check. (2) **asymmetric propagation**: after a recent change, some resolvers have the new value, others the old. (3) **regional answer**: for CDN/Anycast, geographically different resolvers see different IPs (this is normal, not a bug). (4) rare: **DNS poisoning** of a specific resolver (unlikely on 1.1.1.1/8.8.8.8/9.9.9.9 but theoretically possible).

### Does the tool support DKIM ed25519 records?

Yes, the parser recognizes `k=ed25519` and `k=rsa`. Ed25519 is much more compact (public key ~80 base64 chars vs ~390 for RSA 2048), supported by Gmail, Microsoft 365, Sendgrid, Mailgun. Fix for the 255-char TXT max: ed25519 doesn't require splitting.

### Can I also test BIMI records?

BIMI (Brand Indicators for Message Identification) is a modern DMARC extension that publishes logos via SVG in DNS (`default._bimi.domain` record). The tool could be extended with a BIMI tab. For now, parse BIMI manually as a generic TXT record.

---
Tool by Maurizio Fonte, senior backend engineer. All tools: https://www.mauriziofonte.it/tools/