SPF, DKIM e DMARC non sono tre plugin. Sono tre record DNS. Gmail, dal 2024, li pretende. Un form che «non arriva» di solito non è il form: è un TXT mancante, o due TXT di troppo.
Un form del sito che manda «grazie per l’ordine» in spam non è un problema di copy. È un problema di DNS. Il destinatario — Gmail in testa, dal 1° febbraio 2024 con regole scritte — chiede di sapere se quel messaggio è uscito davvero dal dominio che sta nel From. SPF, DKIM e DMARC sono tre risposte diverse. Non sono tre plugin. Non si «installano nel CMS». Si pubblicano come record, si allineano al From, si verificano.
In breve: SPF autorizza gli IP che possono spedire per il dominio. DKIM firma il messaggio con una chiave nel DNS. DMARC dice al ricevente cosa fare se i due controlli falliscono, e chiede che il dominio del From sia allineato a uno dei due. Google, per la posta verso account @gmail.com / @googlemail.com, pretende SPF o DKIM da tutti; sopra le 5.000 mail al giorno verso Gmail pretende SPF e DKIM e DMARC (la policy può restare a none). Senza, i messaggi finiscono in spam o non arrivano. Questo pezzo distingue i tre record, l’allineamento, e cosa non risolvono.
Cosa trovi in questo articolo
Tre record, tre mestieri
Il DNS del dominio non serve solo a far risolvere il sito. Serve anche a dire ai server di posta chi è autorizzato a parlare in nome tuo. La mappa DNS/hosting/CDN sta in un altro pezzo, DNS, hosting, CDN; qui conta solo la zona che pubblica i record di posta.
| SPF (RFC 7208) | DKIM (RFC 6376) | DMARC (RFC 9989, obsoleta RFC 7489) | |
|---|---|---|---|
| Cosa fa | Elenca gli IP / include i mittenti autorizzati a usare il dominio nell’envelope | Firma testata e corpo con una chiave pubblica nel DNS | Pubblica una policy su cosa fare se SPF/DKIM falliscono, e chiede report |
| Dove vive | Record TXT su dominio.tld (un solo SPF) | Record TXT su selettore._domainkey.dominio.tld | Record TXT su _dmarc.dominio.tld |
| Cosa non fa | Non sopravvive al forwarding (l’IP cambia). Non autentica il From visibile da solo | Non basta se si firma un dominio diverso da quello del From | Non spedisce. Non sostituisce i due controlli: li usa |
| Fallisce se | Mancano gli include (ESP, CRM, ticket, fatture), o ci sono due record SPF | Il corpo viene riscritto in transito, o la chiave non è pubblicata | From e dominio autenticato non sono allineati, anche con SPF/DKIM «verdi» |
SPF risponde alla domanda: questo IP poteva usare il dominio come mittente di envelope? DKIM risponde: questo messaggio è uscito con una chiave che il dominio dichiara? DMARC risponde: se la risposta è no, cosa deve fare il ricevente, e il From visibile è dello stesso dominio (o di un suo organizzativo) di uno dei due?
Tre domande. Tre record. Un plugin «anti-spam» nel sito non ne pubblica nessuno. Li pubblica chi gestisce la zona DNS: registrar, hosting, o il DNS del certificato e del transito, che è un altro strato. Il TLS cifra il salto (Gmail lo pretende in transito). L’autenticazione dice chi sei. Non sono sinonimi.
Cosa chiede Gmail (e perché conta anche se non sei Google)
Le Email sender guidelines di Google, in vigore dal 1° febbraio 2024 verso gli account personali Gmail, non sono un RFC. Sono la soglia pratica del destinatario più usato. Vale la pena leggerle come vincolo di consegna, non come legge.
Per tutti i mittenti verso @gmail.com / @googlemail.com:
SPF oppure DKIM sul dominio che spedisce;
DNS diretto e inverso (PTR) validi sugli IP;
transito su TLS;
tasso di spam in Postmaster Tools sotto lo 0,3%;
messaggi conformi a RFC 5322; niente From che impersonano Gmail.
Sopra le 5.000 mail al giorno verso Gmail, la lista si allunga: SPF e DKIM, più DMARC (la policy può essere p=none), allineamento del From con SPF o DKIM, unsubscribe a un clic sulle mail di marketing. Chi non c’è, scrive Google, rischia rate limit, spam o mancata consegna.
Non serve essere un ESP da 5.000 messaggi. Un e-commerce che manda ordine, spedizione e reset password accumula volume. Un form «contattaci» che esce da un IP di condiviso, senza SPF, è già fuori dalla prima riga. Il monitoring del sito misura i 5xx; la posta ha un altro cruscotto. I log applicativi dicono se il form ha accettato il messaggio. Non dicono se Gmail l’ha messo in Promozioni, o in Spam, o in /dev/null.
Allineamento: il From deve coincidere
Il punto che si salta più spesso: SPF e DKIM possono essere «pass» e DMARC comunque fallire. DMARC chiede identifier alignment: il dominio nel From (RFC 5322) deve allinearsi al dominio autenticato da SPF o da DKIM, in modalità relaxed (stesso dominio organizzativo) o strict (stesso dominio esatto), secondo quanto pubblicato nel record.
Esempi, tutti visti in produzione:
Il sito spedisce da
noreply@negozio.it, ma l’ESP firma DKIM consendgrid.nete lo SPF è su un altro hostname. Gmail vede un From non allineato. DMARC: fail.Due record SPF sullo stesso nome. Molti ricevitori trattano la situazione come permerror. Non è «più autorizzati»: è rotto.
Il modulo del CMS usa l’IP del webserver, che non è nell’SPF. Il messaggio parte. Arriva in spam, o non arriva.
Si inoltra la posta del form a una casella Gmail personale. SPF sul salto successivo fallisce (l’IP è quello dell’inoltro). Senza DKIM integro, DMARC non ha un’àncora.
La mossa corretta è una sola catena: un From del proprio dominio, SPF che include tutti i mittenti veri (transazionale, newsletter, ticket, fatture elettroniche se escono da quel From), DKIM con selettore proprio, DMARC che parte da p=none con un indirizzo rua dove arrivano i report. Si leggono i report. Poi si stringe. Non il contrario.
p=none, quarantine, reject
DMARC, nel record _dmarc, pubblica una policy. RFC 9989 (che sostituisce RFC 7489) resta il testo di riferimento; in pratica le tre parole che si vedono in zona sono queste:
| Policy | Cosa chiede al ricevente | Quando ha senso |
|---|---|---|
p=none | Nessuna azione speciale; manda i report | All’inizio. Gmail la accetta anche sopra le 5.000/giorno |
p=quarantine | Tratta i fail come sospetti (di solito spam) | Quando i report dicono che i mittenti legittimi passano |
p=reject | Rifiuta i fail | Quando si è sicuri di aver mappato ESP, CRM, fatture, ticket |
reject il primo giorno è un modo elegante per perdere le fatture. none per sempre è un modo elegante per far firmare altri a nome tuo: il ricevente non ha istruzioni. Si parte da none, si tengono i report (e i monitoraggi a parte: la posta non è l’uptime HTTP), si sale.
Un CMS, un SaaS o un hosting «gestito» che non espone SPF/DKIM/DMARC sul dominio del cliente sta spostando il problema. Si sceglie chi pubblica i record, o si cambia prodotto. Non si compra un plugin anti-spam. Keidea costruisce siti: se il perimetro include form, transazionali e un dominio proprio, questi tre record stanno nel go-live, non in coda. La relazione è dichiarata. Il pezzo resta in piedi senza quel nome: Gmail non chiede il fornitore, chiede i TXT.
Errori da evitare
Due record SPF sullo stesso hostname. Se ne pubblica uno, con tutti gli
include.Firmare DKIM sul dominio dell’ESP e lasciare il From sul dominio del sito, senza allineamento.
Mettere
p=rejectprima di aver letto una settimana di report.Credere che un plugin WordPress «SMTP» pubblichi i TXT. Pubblica, al massimo, la coda in uscita.
Usare un From @gmail.com dal sito. Google lo tratta come impersonazione.
Confondere TLS del transito e autenticazione del dominio. Servono entrambi.
In sintesi
SPF elenca chi può spedire. DKIM firma. DMARC allinea il From e dice cosa fare se i controlli falliscono. Gmail, dal 2024, li pretende in forma minima da tutti e in forma completa dai mittenti grandi. Si pubblicano nel DNS, si include ogni ESP vero, si parte da p=none, si leggono i report, si stringe. Il form del sito che «non arriva» di solito non è il form. È un TXT mancante, o due TXT di troppo.
Fonti
RFC Editor, RFC 7208 — SPF.
RFC Editor, RFC 6376 — DKIM.
RFC Editor, RFC 9989 — DMARC (obsoleta RFC 7489).
Google, Email sender guidelines (requisiti dal 1° febbraio 2024 verso Gmail personale).
Immagine di copertina: portatile su una scrivania. Foto Unsplash via Wikimedia Commons, licenza CC0.
Relazione: Keidea s.r.l. è parte correlata di questa testata. Il riferimento nel testo è un esempio di perimetro di lavoro (siti e transazionali), non un servizio di deliverability.
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
