Cosa fanno davvero SPF, DKIM e DMARC
Pensa ai tre come a una catena di tre anelli. SPF autorizza i server che possono inviare per il tuo dominio. DKIM aggiunge una firma crittografica, così il destinatario può capire se il messaggio è stato alterato lungo la strada. DMARC riporta entrambi al dominio che chi legge vede davvero nella riga From: e pubblica una policy su cosa fare quando il controllo fallisce. In parole semplici: SPF controlla la busta, DKIM controlla il contenuto e DMARC controlla che almeno uno dei due corrisponda al nome che legge il destinatario.
SPF: quali server possono inviare per il tuo dominio
Un record SPF è una singola voce DNS di tipo TXT che inizia con v=spf1, elenca gli host e gli include autorizzati a inviare per il dominio e termina con un meccanismo all. Due regole colgono molti di sorpresa. Primo, un dominio può pubblicare un solo record v=spf1; un secondo record fa restituire permerror alla valutazione e l’autenticazione di fatto fallisce (RFC 7208, sezione 4.5). Secondo, durante la valutazione SPF può eseguire al massimo dieci meccanismi che richiedono una query DNS (include, a, mx, ptr, exists e il modificatore redirect); oltre dieci, il risultato è di nuovo permerror (sezione 4.6.4). Il qualificatore finale è la policy: ~all è un softfail (accetta ma segnala), -all è un hardfail (rifiuta i mittenti non elencati) e +all farebbe passare tutto, ed è per questo che non va mai pubblicato. Un limite strutturale da conoscere: SPF autentica il dominio nascosto del Return-Path, non il From: visibile, e si rompe con l’inoltro, perché l’IP del server che inoltra non è nel tuo record. È esattamente il motivo per cui DMARC non si affida al solo SPF.
DKIM: una firma che nessuno può cambiare di nascosto
DKIM firma ogni messaggio in uscita con una chiave privata custodita dal tuo sistema di invio e pubblica nel DNS la chiave pubblica corrispondente. La firma copre alcuni header scelti e il corpo, quindi se qualcosa viene alterato durante il transito la firma non è più valida. I destinatari trovano la chiave tramite un selettore: un header DKIM-Signature contiene s= (il selettore) e d= (il tuo dominio), e chi verifica interroga selector._domainkey.yourdomain per ottenere la chiave pubblica (RFC 6376, sezione 3.6.2.1). I selettori permettono anche di usare più chiavi in parallelo, ed è questo che rende pulita la rotazione: pubblichi un nuovo selettore, sposti la firma su quello, poi ritiri il vecchio (un valore di chiave vuoto lo segna come revocato). Sulla lunghezza della chiave, la RFC 6376 richiede chiavi RSA di almeno 1024 bit per un uso prolungato e chi verifica deve gestire chiavi fino a 2048 bit; 2048 bit è la scelta predefinita sensata oggi, e ruotare le chiavi periodicamente limita il danno se una dovesse mai trapelare.
DMARC: la policy che tiene tutto insieme
DMARC è il record che dà a SPF e DKIM un significato per il dominio che legge il destinatario. La sua idea centrale è l’allineamento. Un messaggio supera DMARC solo quando SPF o DKIM producono un pass e quel pass si basa su un identificatore allineato con il dominio From: visibile (RFC 7489, sezione 4.2). Ecco perché un messaggio può superare SPF e fallire comunque DMARC: se il tuo ESP invia con il proprio dominio di Return-Path, SPF passa per l’ESP, ma quel dominio non è allineato con il tuo From:, quindi la parte SPF di DMARC fallisce. L’allineamento ha due modalità: relaxed, che accetta un dominio organizzativo corrispondente (mail.yourco.com è allineato con yourco.com), e strict, che pretende una corrispondenza esatta. Poiché basta uno dei due meccanismi allineati, di solito è l’allineamento DKIM a far passare la posta che SPF non può coprire, come i messaggi inoltrati. Il record si presenta così: v=DMARC1; p=none; rua=mailto:reports@yourco.com; il tag p imposta la policy (none, quarantine o reject), rua indica dove inviare i report aggregati e sp imposta una policy separata per i sottodomini, che se lo ometti assume il valore di p.
Perché dal 2024 è diventato obbligatorio
L’autenticazione era una buona pratica facoltativa. A febbraio 2024 è diventata un requisito d’accesso. Gmail e Yahoo ora chiedono a chi invia grandi volumi (Google conta chiunque invii più di 5.000 messaggi al giorno ad account Gmail) di autenticarsi con SPF e DKIM e di pubblicare un record DMARC, che può partire da p=none. La posta di marketing e quella a cui ci si è iscritti devono anche offrire la disiscrizione con un clic: l’header List-Unsubscribe (RFC 2369) più List-Unsubscribe-Post: List-Unsubscribe=One-Click, il meccanismo a un clic della RFC 8058, così il client del destinatario può disiscriversi con un’unica POST HTTPS. Trovi le regole complete di Gmail e Yahoo nella panoramica sulla deliverability. Due cose da notare: dal 2024 l’applicazione delle regole si è fatta più severa, quindi rispettale anche sotto i 5.000 messaggi al giorno; e tenere basse le segnalazioni di spam è un requisito al pari dell’autenticazione, non un optional.
Errori comuni che rompono l’autenticazione senza avvisare
- Pubblicare +all nel record SPF, che autorizza tutto internet a inviare a tuo nome: l’esatto contrario dello scopo.
- Avere più di un record v=spf1 sullo stesso dominio, che restituisce permerror e annulla SPF.
- Superare il limite di dieci query DNS man mano che aggiungi gli include dei fornitori, che restituisce anch’esso permerror.
- Una chiave DKIM troppo corta o mai ruotata, così una chiave trapelata o forzata continua a firmare a tempo indeterminato.
- Passare subito a p=reject senza aver letto un solo report aggregato, bloccando posta legittima che avevi perso di vista.
- Dimenticare sp= per i sottodomini, così una policy permissiva lascia marketing.yourco.com esposto allo spoofing.
- Un mittente di terze parti (un ESP, uno strumento di fatturazione, un help desk) che non hai mai portato in allineamento SPF e DKIM, così la sua posta fallisce DMARC.
Dove si colloca l’autenticazione nel tuo stack
L’autenticazione è la base su cui poggia tutto il resto. In self-hosting il DNS e le chiavi di firma sono interamente tuoi: è la forma più forte di controllo sulla tua identità di mittente. Una piattaforma di customer engagement dovrebbe mostrare lo stato di autenticazione e di allineamento di ogni dominio di invio invece di nasconderlo, così vedi a colpo d’occhio quali sorgenti passano. Separa la posta transazionale e quella di marketing su flussi distinti e, idealmente, su sottodomini distinti, così un picco di segnalazioni sul marketing non mette mai a rischio il recapito delle email di reimpostazione della password. E rispetta l’ordine giusto: autenticazione e allineamento vengono prima del riscaldamento del dominio. Un warm-up su un dominio non autenticato insegna solo ai provider a diffidare di te più in fretta.