In sintesi
- SPF (RFC 7208): pubblica l'elenco degli indirizzi IP e dei servizi di invio autorizzati a inviare email usando il tuo dominio come mittente della busta (Return-Path).
- DKIM (RFC 6376): usa una coppia di chiavi asimmetriche per aggiungere a ogni messaggio una firma crittografica, che dimostra che il messaggio è stato autorizzato dal dominio firmatario e non è stato alterato durante il transito.
- DMARC (RFC 7489): indica ai server riceventi come gestire le email che non superano l'allineamento SPF e DKIM (none, quarantine o reject) e dove inviare i report aggregati.
- Da febbraio 2024 Gmail e Yahoo richiedono ai bulk sender (Gmail li definisce come chi invia oltre 5.000 messaggi al giorno verso account Gmail personali) di autenticarsi sia con SPF sia con DKIM, pubblicare un record DMARC (almeno
p=none) e allineare il dominio del From con SPF o DKIM.
Quando un server di posta ricevente come Google Workspace, Microsoft 365 o Yahoo Mail accetta un messaggio da contact@yourcompany.com, il suo sistema di filtraggio esegue una serie di controlli tecnici per stabilire se il messaggio proviene davvero dal legittimo proprietario di quel dominio o se si tratta di un tentativo di spoofing o phishing.
Se nel DNS (Domain Name System) del tuo dominio mancano i record di autenticazione richiesti, il messaggio viene considerato ad alto rischio. Con ogni probabilità finirà nella cartella spam o verrà rifiutato direttamente a livello SMTP, e la tua piattaforma di invio lo registrerà come bounce.
1. I tre meccanismi fondamentali di autenticazione email
Per capire come i sistemi di sicurezza email lavorano insieme, conviene guardare al ruolo distinto ma complementare di ciascun protocollo:
SPF (Sender Policy Framework)
SPF funziona come una allowlist pubblica pubblicata nel tuo DNS. Il record dichiara quali server, identificati tramite indirizzo IP o tramite un meccanismo include che rimanda a un provider come Amazon SES, SendGrid o Mailgun, sono autorizzati a inviare email per conto del tuo dominio. I server riceventi verificano SPF sul dominio del mittente della busta (MAIL FROM / Return-Path), non sull'indirizzo From visibile.
DKIM (DomainKeys Identified Mail)
DKIM verifica l'integrità del messaggio. Quando un messaggio lascia il server di invio, viene generata una firma digitale con una chiave privata, aggiunta al messaggio come header DKIM-Signature. Il server ricevente recupera dal tuo DNS la chiave pubblica corrispondente e la usa per verificare la firma, confermando che gli header firmati e il corpo del messaggio non sono stati falsificati né modificati lungo il percorso.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC è il livello che unisce SPF e DKIM. Richiede al server ricevente di verificare che il dominio dell'indirizzo mittente visibile (l'Header From) corrisponda al dominio autenticato da SPF o DKIM: questo controllo si chiama allineamento. Un messaggio supera DMARC se almeno uno dei due controlli è superato ed è allineato. DMARC definisce inoltre cosa deve fare il server ricevente quando l'autenticazione fallisce e fornisce un canale per i report aggregati (RUA).
2. Struttura e sintassi del record SPF
Un record SPF viene pubblicato come record TXT sul dominio usato come mittente della busta. Per le email inviate dai tuoi server o da Google Workspace, di solito si tratta del dominio principale:
Host / Name: @ (or yourcompany.com)
Value / Content: v=spf1 include:amazonses.com ~all
Il significato di ogni parte del record:
v=spf1: dichiara la versione di SPF utilizzata. Deve essere il primo termine del record.include:amazonses.com: autorizza gli intervalli IP di invio di Amazon Simple Email Service (SES) a inviare email per il dominio. Se usi anche SendGrid, l'equivalente èinclude:sendgrid.net. Tieni presente che con Amazon SES l'SPF risulta allineato ai fini DMARC solo se configuri un sottodominio MAIL FROM personalizzato (ad esempiobounce.yourcompany.com) e pubblichi questo record su quel sottodominio, insieme al record MX fornito da SES. Con la domain authentication di SendGrid e l'opzione automated security attiva, SendGrid gestisce l'SPF del proprio sottodominio di return-path tramite un CNAME, quindi non serve un include sul dominio principale.~all(SoftFail): indica che le email provenienti da server non presenti nell'elenco vanno considerate sospette, ma in genere comunque accettate. È la scelta più diffusa, soprattutto mentre stai ancora censendo le tue fonti di invio.-all(HardFail): indica che le email provenienti da fonti non autorizzate vanno considerate un fallimento definitivo. I server riceventi possono rifiutarle, anche se oggi molti grandi mailbox provider valutano il risultato DMARC invece di rifiutare in base al solo SPF.
include, a, mx, ptr, exists e redirect, compresi i lookup annidati). Se più servizi inviano dallo stesso dominio (ad esempio Google Workspace e Amazon SES), uniscili in un unico record: v=spf1 include:_spf.google.com include:amazonses.com ~all.
3. Configurare DKIM
La configurazione di DKIM prevede di norma la generazione di una coppia di chiavi RSA; oggi il minimo consigliato sono chiavi a 2048 bit. Quando colleghi un provider di invio tramite eMailBase:
- Il provider genera i record DNS per i propri selettori DKIM. Amazon SES Easy DKIM emette tre record
CNAMEnel formato<token>._domainkey.yourcompany.com; SendGrid emette due record DKIMCNAME(s1._domainkeyes2._domainkey) più uno per il proprio sottodominio di return-path; Mailgun fornisce in genere un record TXT contenente la chiave pubblica. - Accedi al pannello di controllo del tuo provider DNS e crea ciascun record esattamente come è stato fornito.
- eMailBase interroga automaticamente il DNS e conferma l'attivazione non appena i record si sono propagati.
4. Applicare DMARC in modo graduale e sicuro
Pubblicare una policy DMARC restrittiva fin dal primo giorno può far rifiutare email legittime, se qualche fonte di invio non è ancora del tutto coperta da SPF o DKIM. Il record DMARC si pubblica come record TXT su _dmarc.yourcompany.com e l'implementazione standard prevede tre fasi:
| Fase | Sintassi della policy | Obiettivo operativo |
|---|---|---|
| Fase 1: monitoraggio | v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com |
Raccogliere i report aggregati e individuare tutte le fonti di invio legittime senza influire sul recapito. |
| Fase 2: quarantena | v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourcompany.com |
Applicare la policy di quarantena (di solito il recapito nella cartella spam) al 25% dei messaggi che non superano il controllo, quindi aumentare la percentuale man mano che i report confermano che le email legittime passano. Il supporto di pct varia da un server ricevente all'altro e la revisione DMARCbis dello standard lo elimina. |
| Fase 3: rifiuto | v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com |
Chiedere ai server riceventi di rifiutare tutte le email che non superano DMARC, bloccando l'uso non autorizzato del tuo dominio. |
5. Verificare i record DNS e risolvere i problemi
Una volta pubblicati i record, puoi controllarli con i normali strumenti da riga di comando:
dig +short TXT yourcompany.com
# Check a DKIM record (replace the selector with your own)
dig +short CNAME selector._domainkey.yourcompany.com
# Check the DMARC record
dig +short TXT _dmarc.yourcompany.com
In un workspace eMailBase questi controlli vengono eseguiti automaticamente dal DNS & Deliverability Manager, che segnala conflitti di sintassi e record mancanti non appena si presentano.
