Le email del sito finiscono in spam: SPF, DKIM e DMARC spiegati a chi ha un sito

Il modulo contatti del sito dice “messaggio inviato”. Tu non ricevi niente. Oppure lo ricevi,
ma in spam, tre giorni dopo. Oppure lo ricevono tutti tranne il cliente che usa Gmail.

Non è il modulo. Nel 99% dei casi è il DNS del dominio, e sono tre record. Si chiamano SPF, DKIM
e DMARC, fanno tre lavori diversi e servono tutti e tre. Qui c’è cosa fanno davvero, e cosa
chiedere a chi ti gestisce il dominio — perché quasi sempre la correzione la fa lui in cinque
minuti, non il tuo sviluppatore.

Il problema di fondo: chiunque può scrivere il tuo nome

La posta elettronica è nata senza alcun controllo su chi dice di essere il mittente. Scrivere
Da: info@tuodominio.it dentro un messaggio costa esattamente zero, da qualunque computer del
mondo. I server che ricevono, quindi, hanno dovuto inventarsi un modo per capire se chi scrive
col tuo nome ha il permesso di farlo.

I tre record sono quel modo. Sono informazioni pubbliche che metti nel DNS del tuo dominio, e
dicono al server di Gmail o di Outlook: ecco da dove parte la mia posta, ecco come riconoscere
la mia firma, ecco cosa fare se non torna.

Se non ci sono, il tuo messaggio non è “bocciato”: è semplicemente non verificabile. E nel 2026
non verificabile vuol dire spam.

SPF: chi ha il permesso di spedire al posto tuo

SPF è un record di testo (TXT) nel DNS che elenca gli indirizzi IP autorizzati a spedire posta
per il tuo dominio. Comincia sempre con v=spf1 e lo specifica
RFC 7208: «SPF records MUST be published as a DNS
TXT (type 16) Resource Record».

Un record tipico somiglia a questo:

v=spf1 include:_spf.google.com include:spf.ilmiohosting.it ~all

Tradotto: può spedire per me chi spedisce per Google (perché la casella è su Gmail) e chi spedisce
per il mio hosting (perché il modulo contatti parte da lì). Tutti gli altri, no.

Tre cose sulle quali si sbaglia regolarmente:

• Un solo record SPF per dominio. Non due. L’RFC è esplicito: «A domain name MUST NOT have
  multiple records that would cause an authorization check to select more than one record».
  Se aggiungi un servizio nuovo, il suo include: va dentro il record che hai già. Due record
  SPF non si sommano: si rompono a vicenda.
• Massimo 10 interrogazioni DNS. Ogni include:, a, mx, exists costa una query, e
  «SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation».
  Superato il limite il controllo va in errore permanente. È il motivo per cui un dominio che ha
  collezionato newsletter, CRM e gestionale negli anni smette di funzionare all’improvviso.
• Il meccanismo ptr non va usato. Si trova ancora in record vecchi copiati da guide del 2010.
  L’RFC dice «This mechanism SHOULD NOT be published» perché «it is unnecessary and more reliable
  alternatives should be used instead».

E un limite che è bene conoscere subito: SPF non controlla il mittente che vedi tu. Verifica
l’indirizzo della busta SMTP (MAIL FROM) e il nome dato nel saluto HELO, non il campo Da:
che compare nel client di posta. Sono due cose diverse, e normalmente coincidono — ma non sempre.
Da qui nasce il bisogno del terzo record.

DKIM: la firma che resta attaccata al messaggio

DKIM aggiunge al messaggio una firma crittografica. La chiave privata sta sul server che spedisce,
la chiave pubblica la pubblichi nel DNS, e il destinatario verifica che il messaggio sia partito
da chi dice e non sia stato alterato per strada.

La chiave pubblica vive in un sottodominio con una forma precisa: selettore._domainkey.tuodominio.it.
Il selettore lo decide il servizio che spedisce (Gmail usa google, altri usano s1, mail,
dkim), quindi un dominio può avere più chiavi DKIM contemporaneamente, una per servizio. Nessun
conflitto, a differenza di SPF.

RFC 6376 — che è uno standard Internet pieno, STD 76 —
richiede che il campo From sia sempre firmato: «The From header field MUST be signed (that is,
included in the ‘h=’ tag)». Sulla lunghezza delle chiavi il riferimento aggiornato è
RFC 8301, del gennaio 2018: i firmatari «SHOULD use
RSA keys of at least 2048 bits», e SHA-1 è fuori — «rsa-sha1 MUST NOT be used for signing or
verifying». Se il tuo provider firma ancora con una chiave da 1024 bit e SHA-1, è un record da
rigenerare.

Il vantaggio pratico di DKIM è che sopravvive agli inoltri. Quando qualcuno gira la tua email
a un collega, l’IP che spedisce cambia e SPF cade; la firma DKIM invece resta valida. La
specifica DMARC lo dice senza giri di parole: «DKIM signatures will generally remain valid in
these relay situations».

DMARC: lega le due cose al mittente che il cliente legge

DMARC è il record che chiude il cerchio. Sta in _dmarc.tuodominio.it, comincia con v=DMARC1 e
fa due cose: verifica che SPF o DKIM corrispondano al dominio del campo From — quello che il tuo
cliente vede davvero — e dice al destinatario cosa fare quando non corrispondono.

Qui va segnalata una cosa che cambia le carte in tavola: la specifica DMARC è stata riscritta nel
2026. Il vecchio RFC 7489 del 2015 è ufficialmente obsoleto, sostituito da
RFC 9989, 9990 e 9991. Non è un dettaglio da
collezionisti: DMARC è passata da documento informativo a Proposed Standard sulla via degli
standard IETF, e qualche tag è cambiato. Se stai leggendo una guida che cita il 7489, stai
leggendo una guida vecchia.

Un record di partenza:

v=DMARC1; p=none; rua=mailto:dmarc@tuodominio.it

• p= è la richiesta al destinatario. none significa «non esprimo preferenze»,
  quarantine «considero questa posta sospetta», reject «è un’indicazione chiara che l’uso del
  mio nome non è valido». Si parte sempre da none, come raccomanda l’RFC: «For best results,
  Domain Owners usually start with ‘p=none’», usando i rapporti per capire chi spedisce a tuo
  nome prima di bloccare qualcosa.
• rua= è l’indirizzo dove ricevere i rapporti aggregati. Sono il pezzo che vale di più:
  danno «insight into all mail streams using Author Domains under the Domain Owner’s control».
  Scoprirai servizi che spediscono col tuo dominio e che avevi dimenticato.
• Basta un controllo su due. Un messaggio passa DMARC se almeno uno fra SPF e DKIM è
  allineato: «If one or more of the Authenticated Identifiers align with the Author Domain, the
  message is considered to pass the DMARC mechanism check». Non servono entrambi ogni volta.
• Il tag pct, che molte guide spiegano ancora, è stato rimosso dalla nuova specifica. Al
  suo posto c’è t=y, un vero “modo test” che chiede di non applicare la policy dichiarata.

L’allineamento, in modalità predefinita, è “relaxed”: basta che il dominio organizzativo sia lo
stesso, quindi newsletter.tuodominio.it va bene per tuodominio.it. La modalità “strict”
pretende che siano identici.

L’errore che ferma il modulo contatti

Adesso il caso concreto, perché è sempre lo stesso. Il modulo contatti del sito è configurato per
spedire mettendo nel campo Da: l’indirizzo del visitatore, così tu puoi rispondere
direttamente. Sembra comodo. Ma in quel momento il tuo server sta spedendo una email che dice di
venire da @gmail.com, e nessun record di Google autorizza il tuo hosting a farlo. DMARC di
Gmail è su p=reject: il messaggio muore prima di arrivarti.

La correzione è banale, e non sta nel DNS: il modulo deve spedire dal tuo dominio, mettendo
l’indirizzo del visitatore nel campo Rispondi a: (Reply-To). Tu rispondi come prima, e la
posta passa i controlli.

Secondo errore, in ordine di frequenza: p=reject messo con entusiasmo senza avere DKIM. RFC 9989
è categorico — i domini che pubblicano p=reject «MUST NOT rely solely on SPF to secure a DMARC
pass and MUST apply valid DKIM signatures to their messages». Senza firma, basta un inoltro
qualsiasi e la tua email legittima viene rifiutata. Vale lo stesso per le mailing list, che l’RFC
elenca tra i casi che p=reject rompe: «role-based email aliases, and mailing lists across the
Internet».

Perché non è più opzionale

Dal 1° febbraio 2024 Google richiede a tutti i mittenti di configurare «SPF or DKIM email
authentication for your sending domains». Chi supera i 5.000 messaggi al giorno deve avere
SPF, DKIM e DMARC, con l’allineamento del From. Microsoft e gli altri grandi provider si sono
mossi nella stessa direzione.

Tradotto per chi ha un sito: tre record DNS sono il prezzo d’ingresso perché le email del tuo sito
vengano consegnate. Non un’ottimizzazione da fare più avanti.

Cosa chiedere a chi ti gestisce il dominio

Copia e incolla queste domande. Se le risposte non arrivano in giornata, il problema non è il DNS.

1. Il dominio ha un solo record SPF? Quanti include: contiene, e siamo sotto le 10 query?
2. C’è un record DKIM per ogni servizio che spedisce — casella di posta, modulo del sito,
   newsletter, gestionale? Con che lunghezza di chiave?
3. Esiste un record _dmarc? Con che p=, e a quale indirizzo arrivano i rapporti rua=?
4. Da quale indirizzo spedisce il modulo contatti del sito, e il Reply-To è impostato?

Le prime tre si verificano in un minuto, dall’esterno, senza accessi: sono record DNS pubblici.
La quarta è la più importante e non si vede dal DNS — va guardata nella configurazione del sito.

Se vuoi che la guardi io, i tuoi moduli e la tua posta li controllo volentieri:
scrivimi e dimmi solo il dominio.

Fonti. Tutte le citazioni di questo articolo vengono dalle specifiche originali:
RFC 7208 per SPF,
RFC 6376 e
RFC 8301 per DKIM,
RFC 9989 per DMARC (che rende obsoleto RFC 7489), e la
documentazione di Google per i requisiti dei mittenti.