# Audit deliverability email: trova problemi DNS in 5 minuti

> Validatore online di SPF, DKIM, DMARC + MX lookup via DoH + confronto multi-resolver a 6 vie (Cloudflare, Google, AliDNS, dns.sb) per email deliverability.

Strumento gratuito nel browser (nessun upload): https://www.mauriziofonte.it/strumenti/validatore-email-dns

Toolkit per audit di **deliverability email**: parser e validatore di record **SPF**, **DKIM**, **DMARC**; **MX lookup** via DNS over HTTPS; **multi-resolver compare** a 6 vie per identificare propagazione asimmetrica, cache stale o 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). Estende il [DoH query tester](/strumenti/test-dns-https-online) con focus specifico su email security. Pensato per audit pre-deploy e troubleshooting di email che non arrivano.

## Come fare audit email deliverability

1. **Estrai i record DNS** - Da terminale: `dig TXT esempio.com` per SPF, `dig TXT _dmarc.esempio.com` per DMARC, `dig TXT selettore._domainkey.esempio.com` per DKIM (selettore = es. `google`, `k1`, `default`). Copia il contenuto della risposta TXT (fra le virgolette).
2. **Incolla nel tab corrispondente** - Tab SPF: incolla la stringa `v=spf1...`. Tab DKIM: incolla `v=DKIM1; k=rsa; p=...`. Tab DMARC: incolla `v=DMARC1; p=...;...`. Bottone 'Parsa': il tool mostra le findings.
3. **Leggi le findings** - Il parser identifica problemi comuni: SPF +all (troppo permissivo), troppi DNS lookups (>10), DMARC p=none (monitoring senza enforcement), DKIM p= vuoto (chiave revocata). Severity color-coded: rosso = critical, giallo = warning, verde = OK.
4. **MX lookup e multi-resolver** - Tab 'MX lookup' fa fetch via DoH e mostra i mail server con priorità. Tab 'Multi-resolver' fa la stessa query su 6 resolver pubblici diversi (4 unfiltered: Cloudflare/Google/AliDNS/dns.sb + 2 filtered Cloudflare Security/Family) e confronta le risposte. Differenze fra unfiltered = propagazione asimmetrica o cache stale. Differenza fra filtered e unfiltered = dominio bloccato dal DNS filter (malware/adult).

## Perché un toolkit dedicato

**Email deliverability è una catena di standard.** SPF, DKIM e DMARC sono i tre RFC che governano l'autenticazione email moderna. Ognuno ha sintassi specifica e errori sottili che causano mail rifiutate o classificate come spam: SPF con `+all` invece di `-all` equivale a dichiarare 'anyone can send', DMARC con `p=none` mai promosso a `p=reject` resta in modalità monitoring senza enforcement, DKIM con chiavi RSA a 1024 bit è deprecato dal 2018 (M3AAWG e Microsoft impongono 2048 bit minimum). Identificare questi problemi richiede leggere RFC, calcolare lookups, decodificare chiavi: il tool automatizza la catena.

**Multi-resolver compare a 6 vie.** La maggior parte dei tool di lookup interroga un singolo resolver. Qui le query partono in parallelo verso **6 resolver pubblici**, divisi in due gruppi: **4 unfiltered** (Cloudflare 1.1.1.1, Google 8.8.8.8, AliDNS 223.5.5.5, dns.sb) per verificare propagazione e cache, e **2 content-filtering** (Cloudflare Security 1.1.1.2 blocca malware, Cloudflare Family 1.1.1.3 blocca malware + adult) per block detection. Differenze fra unfiltered indicano cache stale o propagazione asimmetrica; differenza fra unfiltered e filtered indica un dominio classificato come malicious dai DNS filter di Cloudflare. Diagnostica utile in pre-deploy verification e nel detection di domini compromessi.

**Audit operabile su domini sensibili.** I parser SPF, DKIM e DMARC analizzano il testo che incolli in modo autonomo dal DNS effettivo del dominio: utile per validare un record prima di pubblicarlo, o per audit dove l'interrogazione stessa al DNS deve restare invisibile. Le interrogazioni MX e multi-resolver, quando servono, escono direttamente verso i resolver pubblici via DNS over HTTPS, senza intermediari commerciali che logghino il dominio analizzato. Scenari tipici: M&A, due diligence, pre-launch.

 Dopo aver pubblicato o corretto un record SPF, DKIM o DMARC, la domanda successiva è quando sarà visibile ovunque: la [verifica della propagazione DNS](/strumenti/verifica-propagazione-dns) legge il TTL residuo di ogni cache e risponde con un numero.

## Glossario

- **SPF**: Sender Policy Framework, RFC 7208. Record TXT pubblicato dal dominio mittente che dichiara quali server IP sono autorizzati a inviare email a nome del dominio. Il receiver verifica l'IP del mittente contro la SPF policy per accettare/rifiutare.
- **DKIM**: DomainKeys Identified Mail, RFC 6376. Firma crittografica delle email via chiave privata del mittente. Receiver verifica con la chiave pubblica pubblicata nel DNS (TXT record sotto `selettore._domainkey.dominio`).
- **DMARC**: Domain-based Message Authentication, Reporting and Conformance, RFC 9989 (maggio 2026, sostituisce l'RFC 7489), con i report aggregati nell'RFC 9990 e quelli di errore nell'RFC 9991. Policy che dice al receiver cosa fare se SPF e/o DKIM falliscono: `none` (passa, monitoring), `quarantine` (spam folder), `reject` (rifiuto). Include reporting via `rua`.
- **MX record**: Mail Exchanger record DNS che dichiara i mail server del dominio (priorità + hostname). Senza MX, il dominio non può ricevere email. Tipico setup: 2-4 MX con priorità diverse per failover.
- **DNS lookup limit (SPF)**: RFC 7208 sez. 4.6.4 limita SPF a max 10 lookup DNS (include, a, mx, ptr, exists). Eccedere il limite causa **permerror**: il record viene trattato come invalido. Consolidare include in IP4/IP6 ranges per ridurre lookup.
- **DNS over HTTPS (DoH)**: Protocollo DNS che incapsula le query in HTTPS sulla porta 443, RFC 8484. Sostituisce il DNS tradizionale (UDP/TCP 53) con un canale cifrato che impedisce l'ispezione passiva delle query da parte di intermediari di rete. Il tool usa il formato JSON DoH (Accept: application/dns-json) supportato dai principali resolver pubblici: Cloudflare, Google, AliDNS e dns.sb.

## Domande frequenti

### Posso incollare il record con virgolette intorno?

Sì, il parser rimuove automaticamente virgolette ai bordi e whitespace. SPF e DMARC sono spesso pubblicati con doppie virgolette in `dig` output (RFC 7208 segmentazione TXT). Anche concatenazione di stringhe TXT split (es. `"v=spf1..." " include:..."`) viene gestita.

### Il tool fa fetch del record dal DNS?

I parser SPF, DKIM e DMARC analizzano direttamente il testo che incolli; non interrogano il DNS del dominio. MX lookup e multi-resolver invece escono verso i 6 resolver pubblici 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). Ogni interrogazione ha timeout di 8 secondi per evitare di bloccarsi su resolver lenti.

### Perché DKIM key size 1024 bit è deprecato?

M3AAWG (Messaging Anti-Abuse Working Group) raccomanda 2048+ bit dal 2018. Microsoft impone 2048 minimum dal 2024 per Outlook deliverability. RSA 1024 è considerato breakable con ~ $10K-100K compute (factoring), quindi non sicuro contro attaccanti motivati. Migration: genera nuova chiave 2048+, pubblica nuovo selettore, attendi 30 giorni, dismetti vecchia chiave.

### DMARC p=none è sicuro?

**No**, è solo monitoring. Non blocca spoofing del tuo dominio. È la fase iniziale di un rollout DMARC: pubblica `p=none` con `rua`, raccogli aggregate reports per 30-60 giorni, identifica i tuoi mail server legittimi che falliscono SPF/DKIM, fix la configurazione, poi promuovi a `p=quarantine` (3 mesi) e poi `p=reject` (target finale).

### Multi-resolver: cosa indica una differenza?

Tipicamente: (1) **cache stale**: un resolver ha ancora cachato il record vecchio (TTL non scaduto). Aspetta TTL e ri-controlla. (2) **propagazione asimmetrica**: dopo un cambio recente, alcuni resolver hanno il nuovo, altri il vecchio. (3) **regional answer**: per CDN/Anycast, i resolver geograficamente diversi vedono IP diversi (è normale, non è un bug). (4) raro: **DNS poisoning** di uno specifico resolver (improbabile su 1.1.1.1/8.8.8.8/9.9.9.9 ma teoricamente possibile).

### Il tool supporta record DKIM ed25519?

Sì, il parser riconosce `k=ed25519` e `k=rsa`. Ed25519 è molto più compatto (la chiave pubblica è ~80 char base64 vs ~390 per RSA 2048), supportato da Gmail, Microsoft 365, Sendgrid, Mailgun. Fix per la lunghezza max TXT (255 char): ed25519 non richiede splitting.

### Posso testare anche record BIMI?

BIMI (Brand Indicators for Message Identification) è un'estensione moderna di DMARC che pubblica logo via SVG nel DNS (record `default._bimi.dominio`). Il tool potrebbe essere esteso con un tab BIMI dedicato. Per ora, parsa BIMI manualmente come record TXT generico.

---
Uno strumento di Maurizio Fonte, senior backend engineer. Tutti gli strumenti: https://www.mauriziofonte.it/strumenti/