Smetti di indovinare il tuo DNS: un tour per sviluppatori di MX, SPF, DKIM e DMARC

Perché i record DNS per l'email contano oggi

L'autenticazione email un tempo era opzionale. Nel 2026, è un requisito di base. Gmail e Outlook applicano entrambi SPF e DKIM per i mittenti massivi, e DMARC sta rapidamente diventando obbligatorio per qualsiasi dominio che invii email transazionali. Se i tuoi record DNS sono sbagliati, le tue email non arrivano: nessun bounce, nessun avviso, solo silenzio.

Il problema è che questi record sono documentati come RFC, non come strumenti. La maggior parte degli sviluppatori copia e incolla esempi dalla guida di configurazione del proprio provider email e spera che funzioni. Va bene finché non devi fare troubleshooting, aggiungere un secondo servizio di invio o spiegare a un cliente perché le email del suo modulo di contatto finiscono nello spam.

Questa guida passa in rassegna MX, SPF, DKIM e DMARC nell'ordine in cui li incontrerai davvero, con abbastanza dettagli per configurarli correttamente e abbastanza contesto per diagnosticarli quando si rompono.

Record MX: dove arriva l'email in ingresso

I record MX dicono a internet quali server di posta accettano email per il tuo dominio. Sono i più semplici dei quattro, ma anche i più facili da configurare male.

Un record MX ha due parti: un numero di priorità e un hostname. I numeri di priorità più bassi vengono provati per primi. Se usi Google Workspace, i tuoi record MX potrebbero apparire così:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

I punti finali contano: indicano che l'hostname è pienamente qualificato. La maggior parte dei provider DNS li aggiunge automaticamente, ma non tutti.

Errori comuni: puntare i record MX a un record A invece che a un hostname, impostare tutte le priorità sullo stesso numero (annullando lo scopo dei backup) o dimenticare di rimuovere i vecchi record MX quando cambi provider. I record MX obsoleti non restano lì innocui: possono causare loop di posta o dividere la consegna tra due caselle.

Se gestisci un tuo modulo di contatto e vuoi evitare lo spam senza dipendere da servizi di terze parti, capire come i moduli diventano vettori di spam è un buon punto di partenza.

SPF: quali server sono autorizzati a inviare a tuo nome

SPF (Sender Policy Framework) è un record TXT che elenca gli indirizzi IP e i domini autorizzati a inviare email per conto del tuo dominio. È il primo controllo che la maggior parte dei server di posta esegue quando riceve un messaggio che dichiara di provenire da te.

Un record SPF di base appare così:

v=spf1 include:_spf.google.com ~all

Scomponiamolo:

• v=spf1 dichiara la versione SPF
• include:_spf.google.com delega al record SPF di Google
• ~all è un soft fail: rifiuta la posta da fonti non elencate, ma senza essere troppo rigido

Puoi anche usare ip4: o ip6: per consentire indirizzi specifici, oppure a e mx per fare riferimento ai record A e MX del tuo dominio. Il meccanismo all alla fine controlla cosa succede alla posta proveniente da fonti che non hai elencato: -all è un hard fail (rifiuta), ~all è un soft fail (segna come sospetta), ?all è neutrale (nessuna opinione) e +all è un via libera totale (non usarlo).

SPF ha due spigoli vivi. Primo, si rompe quando l'email viene inoltrata, perché il server di inoltro non è nel tuo record SPF. Secondo, i record SPF hanno un limite di dieci query DNS. Se includi troppi servizi di terze parti, supererai il limite e SPF smetterà di funzionare. La soluzione è appiattire il tuo record SPF: sostituire le direttive include: con gli intervalli IP effettivi, ma questo richiede manutenzione quando i provider cambiano i loro IP.

DKIM: prova crittografica dell'identità del mittente

DKIM (DomainKeys Identified Mail) aggiunge una firma digitale alla tua email in uscita. Il server ricevente verifica la firma rispetto a una chiave pubblica pubblicata nel tuo DNS. Se la firma è valida e il messaggio non è stato manomesso, DKIM passa.

A differenza di SPF, DKIM sopravvive all'inoltro, perché la firma viaggia con il messaggio. È anche più flessibile: puoi avere più chiavi DKIM per diversi servizi di invio, ciascuna con il proprio selector.

Un record DNS DKIM appare così:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Il selector (default in questo esempio) è arbitrario: lo sceglie il tuo provider email. Il valore p= è la chiave pubblica, di solito una lunga stringa codificata in base64. Il tuo provider email genera la chiave privata e la usa per firmare i messaggi in uscita.

La configurazione DKIM è quasi sempre gestita dal tuo provider email. Il tuo compito è copiare il record TXT che ti fornisce e incollarlo nel tuo DNS. La parte delicata è che alcuni provider DNS non gestiscono bene i record TXT lunghi: li troncano oppure richiedono di dividere il valore in più stringhe tra virgolette.

Per verificare che DKIM funzioni, invia un'email di test a un indirizzo Gmail e controlla gli header. Cerca dkim=pass nell'header Authentication-Results.

DMARC: applicazione delle policy e reporting

DMARC (Domain-based Message Authentication, Reporting and Conformance) collega SPF e DKIM e dice ai server riceventi cosa fare quando l'autenticazione fallisce. Abilita anche il reporting, così puoi vedere chi invia email come il tuo dominio, sia in modo legittimo sia tramite spoofing.

Un record DMARC minimale appare così:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none significa solo monitoraggio: non rifiutare né mettere in quarantena i messaggi non riusciti
• rua=mailto:[email protected] specifica dove inviare i report aggregati

Quando sei sicuro che SPF e DKIM funzionino, puoi irrigidire la policy a p=quarantine (manda i fallimenti nello spam) o p=reject (rimbalzali direttamente). Puoi anche impostare una policy per i sottodomini con sp= e specificare con pct= la percentuale di messaggi a cui applicare la policy.

I report DMARC sono file XML inviati quotidianamente dai principali receiver. Sono prolissi e difficili da leggere grezzi, ma ti dicono esattamente quali messaggi hanno passato o fallito l'autenticazione e perché. Se vedi posta legittima rifiutata, i report ti mostreranno quale controllo SPF o DKIM sta fallendo.

Un'insidia: DMARC richiede l'allineamento. Per SPF, il dominio nell'header Return-Path deve corrispondere al dominio nell'header From (o essere un sottodominio). Per DKIM, il dominio d= nella firma DKIM deve corrispondere al dominio From. Se usi un servizio di invio di terze parti, deve supportare return path personalizzati o la firma DKIM con il tuo dominio, non con il suo.

Come auditare la configurazione attuale

La maggior parte dei problemi DNS è invisibile finché non causa un guasto. Ecco come controllare i tuoi record prima che qualcosa si rompa:

1. Interroga i tuoi record MX: dig MX example.com dovrebbe restituire gli hostname e le priorità dei tuoi server di posta. Verifica che corrispondano alla documentazione del tuo provider email.

1. Controlla la sintassi SPF: dig TXT example.com e cerca il record v=spf1. Passalo in un validatore SPF per individuare errori di sintassi e violazioni del limite di lookup.

1. Verifica le chiavi DKIM: invia un'email di test e ispeziona l'header DKIM-Signature. Estrai selector e dominio, poi interroga dig TXT selector._domainkey.example.com per confermare che la chiave pubblica esista.

1. Valida la policy DMARC: dig TXT _dmarc.example.com dovrebbe restituire il tuo record DMARC. Assicurati che rua= punti a un indirizzo che monitori davvero.

1. Test end-to-end: usa un servizio come mail-tester.com oppure invia a un indirizzo Gmail e controlla gli header completi. Cerca spf=pass, dkim=pass e dmarc=pass nell'header Authentication-Results.

Se stai diagnosticando perché le email non arrivano, gli header sono il tuo strumento migliore. La maggior parte dei client email permette di visualizzare gli header grezzi: in Gmail, apri il messaggio, clicca sui tre puntini e seleziona 'Mostra originale'. L'header Authentication-Results ti dirà esattamente quale controllo è fallito e perché.

Quando usare policy per sottodomini

Se invii email da più sottodomini, ad esempio newsletter.example.com per il marketing e app.example.com per la posta transazionale, puoi impostare policy DMARC per singolo sottodominio. Questo ti consente di applicare policy rigorose sui sottodomini che controlli mantenendo una policy più permissiva sul dominio principale.

Il compromesso è la complessità. Ogni sottodominio ha bisogno dei propri record SPF, DKIM e DMARC, e devi tracciare quali servizi di invio sono autorizzati per quali sottodomini. Per la maggior parte dei team piccoli, un singolo dominio ben configurato è più semplice e altrettanto sicuro.

Cosa fare quando l'autenticazione si rompe

La modalità di errore più comune è aggiungere un nuovo servizio di invio senza aggiornare il DNS. Se inizi a usare un nuovo provider di email transazionali, devi aggiungere il suo include SPF o intervallo IP, configurare la firma DKIM con il tuo dominio e verificare l'allineamento DMARC.

Il secondo problema più comune è l'inoltro. Se gli utenti inoltrano la tua email a un altro indirizzo, SPF fallirà perché il server di inoltro non è nel tuo record SPF. DKIM di solito sopravvive all'inoltro, quindi finché DKIM passa e la tua policy DMARC consente l'allineamento parziale, il messaggio dovrebbe comunque essere consegnato. Se vedi posta inoltrata rifiutata, controlla la tua policy DMARC: p=reject con allineamento rigoroso romperà l'inoltro.

Il terzo problema è la propagazione DNS. Le modifiche ai record DNS possono richiedere ore per propagarsi, e server di posta diversi mettono in cache i record per durate diverse. Se hai appena aggiornato un record e non funziona, aspetta qualche ora e riprova. Puoi controllare la propagazione con uno strumento come whatsmydns.net.

Punti chiave

• I record MX instradano la posta in ingresso; SPF, DKIM e DMARC autenticano la posta in uscita. Risolvono problemi diversi e ti servono tutti e quattro.
• SPF si rompe con l'inoltro e ha un limite di dieci lookup. DKIM sopravvive all'inoltro ma richiede configurazione per ogni servizio. DMARC li collega e abilita il reporting.
• Inizia con p=none in DMARC, monitora i report per qualche settimana, poi passa a p=quarantine o p=reject quando sei sicuro che la posta legittima passi.
• Gli errori DNS sono silenziosi. Testa la tua configurazione con email reali e ispeziona gli header per confermare che SPF, DKIM e DMARC passino.
• Se l'autenticazione si rompe dopo aver aggiunto un nuovo servizio di invio, controlla gli include SPF, i selector DKIM e l'allineamento DMARC. Gli header ti diranno quale controllo è fallito.

FAQ

Q: Posso avere più record SPF?

A: No. Più record SPF faranno sì che vengano tutti ignorati. Se devi autorizzare più servizi, usa direttive include: all'interno di un singolo record SPF, oppure elenca direttamente gli intervalli IP. Tieni d'occhio il limite di dieci lookup.

Q: Ho bisogno di DMARC se invio solo poche email al giorno?

A: Sì. DMARC non riguarda il volume: riguarda il dimostrare che sei chi dici di essere. Anche i domini piccoli beneficiano di DMARC, perché previene lo spoofing e ti dà visibilità sui problemi di consegna. Inizia con p=none e un indirizzo per i report.

Q: Cosa succede se DKIM e SPF falliscono entrambi ma l'email sembra legittima?

A: Dipende dalla tua policy DMARC. Se p=none, la posta viene consegnata con un avviso. Se p=quarantine, finisce nello spam. Se p=reject, viene rimbalzata. Ecco perché dovresti monitorare i report DMARC prima di applicare una policy rigida: potresti avere mittenti legittimi di cui non eri a conoscenza.

Q: Posso usare la stessa chiave DKIM per più domini?

A: Tecnicamente sì, ma non farlo. Ogni dominio dovrebbe avere la propria coppia di chiavi DKIM. Condividere le chiavi rende più difficile la rotazione e aumenta il raggio d'impatto se una chiave privata viene compromessa.

Q: Ogni quanto dovrei ruotare le chiavi DKIM?

A: Non esiste una regola universale, ma una volta all'anno è ragionevole per la maggior parte dei domini. Se sospetti che una chiave sia stata compromessa, ruotala immediatamente. Assicurati di pubblicare la nuova chiave pubblica nel DNS prima di iniziare a firmare con la nuova chiave privata, e lascia la vecchia chiave nel DNS per qualche giorno dopo la rotazione per gestire la posta ritardata.

<!-- tool-cta:start -->

💡 Prova questo: Ispeziona la policy pubblicata di qualsiasi dominio con DMARC Lookup per vedere come i record MX, SPF e DMARC si integrano nella pratica.

<!-- tool-cta:end -->

Fonti

• RFC 7208: Sender Policy Framework (SPF) — La specifica SPF, incluse le regole di sintassi e il limite di dieci lookup.
• RFC 6376: DomainKeys Identified Mail (DKIM) — La specifica DKIM, che copre generazione e verifica delle firme.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — La specifica DMARC, incluse la sintassi delle policy e il formato dei report aggregati.
• Google Workspace: Prevent spoofing and spam — Indicazioni pratiche sulla configurazione di SPF, DKIM e DMARC per domini Google Workspace.