Quando le mail finiscono nello spam del destinatario o vengono rifiutate, spesso non c'è un'impostazione “rotta” ma un malinteso: SPF, DKIM e DMARC verificano mittenti diversi. Una volta chiarito questo, i quadri di errore più comuni si inquadrano facilmente.
La differenza in 30 secondi
| Verifica | Nel DNS come | Se manca | |
|---|---|---|---|
| SPF | Questo server può inviare per il dominio? | TXT sul dominio: v=spf1 … | Altri possono falsificare il tuo dominio più facilmente; più mail nello spam. |
| DKIM | La mail è integra e firmata dal dominio? | TXT su selector._domainkey | L'inoltro rompe SPF — senza DKIM la mail non supera più nulla. |
| DMARC | SPF o DKIM coincidono col dominio From visibile — e se no, cosa fare? | TXT su _dmarc: v=DMARC1; p=… | Nessuna policy, nessun report; Gmail e Microsoft richiedono DMARC a chi invia in massa. |
Verificalo da solo: controllo DNS della posta (MX, PTR, SPF, DMARC), limite di lookup SPF e il generatore DMARC per il record giusto.
Cosa verificano davvero SPF, DKIM e DMARC
SPF risponde a una sola domanda: l'indirizzo IP che invia può spedire mail per il dominio indicato nell'envelope sender (anche MAIL FROM o Return-Path)? Il destinatario di solito non vede mai quell'indirizzo. Il mittente visibile (From:) per SPF non conta.
DKIM verifica se un dominio ha firmato crittograficamente il messaggio (il campo d= della firma) e se non è stato modificato lungo il percorso. La chiave pubblica viene presa dal DNS (selector._domainkey.dominio).
DMARC collega entrambi a ciò che il destinatario vede davvero: il dominio del From. DMARC richiede che SPF oppure DKIM sia superato e che il dominio verificato corrisponda al dominio del From (“allineamento”). La policy (none, quarantine, reject) dice al destinatario cosa fare in caso di fallimento.
Il problema dell'allineamento
Un caso tipico: un servizio di newsletter invia mail con mittente visibile info@esempio.it ma usa come return path un dominio proprio, ad esempio bounce.servizio-newsletter.com.
Risultato: SPF è superato – per servizio-newsletter.com. Anche una firma DKIM con d=servizio-newsletter.com è valida. Nessuno dei due domini corrisponde a esempio.it, quindi DMARC fallisce anche se nell'header c'è “spf=pass”.
L'allineamento ha due modalità: relaxed (predefinita, aspf=r/adkim=r) accetta sottodomini dello stesso dominio organizzativo, ad es. mail.esempio.it per esempio.it. Strict richiede esattamente lo stesso dominio.
Soluzione: configurare DKIM con il proprio dominio presso il servizio di invio (di solito uno o due record CNAME o TXT) e, se possibile, un dominio return-path personalizzato. DMARC viene allora superato tramite DKIM anche se SPF non è allineato.
Leggere gli header
Aprire il sorgente del messaggio nel client di posta (in Gmail: “Mostra originale”) e cercare Authentication-Results:
Authentication-Results: mx.example.net;
spf=pass smtp.mailfrom=bounce.servizio-newsletter.com;
dkim=pass header.d=servizio-newsletter.com;
dmarc=fail (p=QUARANTINE) header.from=esempio.itLo schema è evidente: SPF e DKIM sono validi, ma per servizio-newsletter.com invece di esempio.it. Confrontare smtp.mailfrom e header.d con header.from è il passo più importante dell'analisi.
Comandi di verifica
dig +short TXT esempio.it | grep -i spf
dig +short TXT _dmarc.esempio.it
dig +short TXT selector1._domainkey.esempio.itErrori tipici che emergono:
Più record SPF: un dominio può avere un solo record TXT che inizia con v=spf1. Due record causano un permerror – tutti i mittenti vanno in un solo record.
Troppe query DNS: SPF consente al massimo 10 query (include, a, mx, redirect …). Con molti servizi inclusi con include si supera facilmente il limite – di nuovo permerror.
Selector sbagliato: il selector si trova nell'header (s= nella firma DKIM), non si indovina.
In quale ordine introdurre tutto
1. Ripulire SPF. Un solo record, tutti i mittenti legittimi inclusi, inizialmente con ~all in fondo.
2. Attivare DKIM presso ogni servizio di invio – ogni volta con il proprio dominio (webmail, strumento newsletter, sistema di ticket, CRM, software di fatturazione …).
3. Avviare DMARC in modalità di osservazione:
_dmarc.esempio.it. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@esempio.it"Per due-quattro settimane si leggono i report aggregati (rua): chi invia davvero mail a nome vostro? Spesso salta fuori un servizio dimenticato da tempo.
4. Inasprire gradualmente: p=quarantine (iniziando con pct=10 e aumentando), solo dopo p=reject.
Altre cause di classificazione come spam
Record PTR mancante o errato (reverse DNS) sul proprio mail server: l'IP deve puntare a un hostname che risolve di nuovo allo stesso IP.
Indirizzo IP in una blocklist – purtroppo frequente dopo una migrazione o con IP condiviso (sulla migrazione vedi Migrazione DNS senza downtime).
Un picco improvviso di invii da un dominio prima silenzioso.
Mail di massa senza link di disiscrizione: dal 2024 Google e Yahoo richiedono ai mittenti di grandi volumi SPF, DKIM, DMARC, disiscrizione con un clic tramite List-Unsubscribe e bassi tassi di spam.
Checklist
- Esattamente un record SPF, al massimo 10 query?
- DKIM attivo con il proprio dominio presso ogni servizio di invio?
- Record DMARC presente e report letti?
- Nell'header:
header.fromcorrisponde asmtp.mailfromoheader.d? - Record PTR corretto, IP non in lista?
La maggior parte dei “problemi di spam” non è un problema di consegna ma di identità: il destinatario non riesce a verificare che la mail provenga davvero dal dominio indicato nel mittente. Dimostrarlo con un allineamento pulito risolve la gran parte dei casi.
Traduzione dall'originale tedesco.