I record TXT spiegati: SPF, DKIM e DMARC

Un record TXT contiene testo arbitrario associato a un nome di dominio. Sembra banale, ma è così che viene pubblicato l'intero sistema di fiducia della posta, oltre alla maggior parte delle verifiche di proprietà del dominio che farai mai.

Il problema di fondo è che l'SMTP, progettato nel 1982, permette a qualsiasi server di dichiarare di inviare a nome di qualsiasi dominio. Nulla nel protocollo lo impedisce. SPF, DKIM e DMARC sono tre livelli aggiunti in seguito per risolverlo, e tutti e tre risiedono in record TXT.

SPF: quali server possono inviare a tuo nome

SPF (Sender Policy Framework) pubblica un elenco di server autorizzati a inviare posta per il tuo dominio. Un server ricevente confronta l'IP che si connette con quell'elenco.

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ip4:93.184.216.34 ~all"

DKIM: una firma crittografica

DKIM (DomainKeys Identified Mail) firma ogni messaggio in uscita con una chiave privata. Pubblichi la chiave pubblica corrispondente nel DNS e i destinatari verificano la firma.

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

La parte selector1 è scelta dal tuo provider di posta e inclusa in ogni messaggio firmato, così i destinatari sanno quale chiave recuperare. Usare i selector significa poter ruotare le chiavi, o usare più provider, senza conflitti.

Il vantaggio di DKIM rispetto all'SPF è che la firma copre il messaggio stesso, quindi sopravvive all'inoltro. Il suo punto debole è che non dice nulla sui messaggi che arrivano senza alcuna firma, ed è la lacuna che DMARC colma.

DMARC: cosa fare quando i primi due falliscono

DMARC (Domain-based Message Authentication, Reporting and Conformance) lega insieme gli altri due: richiede che SPF o DKIM non solo passino ma siano allineati con l'indirizzo From visibile, e indica ai destinatari cosa fare in caso di fallimento.

_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:reports@example.com; pct=100"

Attivare tutti e tre in sicurezza

L'ordine conta. Passare direttamente a p=reject è il modo classico per rendere non recapitabili le tue stesse fatture.

1. 1

   Fai l'inventario di tutto ciò che invia a tuo nome

   Il tuo provider di posta, certo, ma anche gli strumenti di fatturazione, il CRM, le piattaforme di marketing, i sistemi di ticketing e la posta transazionale della tua app. Tutto ciò che qui viene dimenticato si romperà più tardi.

2. 2

   Pubblica l'SPF con un soft fail

   Includi ogni mittente del primo passaggio e termina con ~all. Il soft fail segna i mittenti non elencati come sospetti senza distruggere la posta mentre verifichi l'elenco.

3. 3

   Abilita la firma DKIM

   Attivala presso ciascun provider e pubblica i record selector che ti forniscono. Invia un messaggio di prova e conferma che la firma venga verificata.

4. 4

   Inizia DMARC con p=none

   Solo monitoraggio. Raccogli i report aggregati per due-quattro settimane: riveleranno mittenti che avevi dimenticato.

5. 5

   Stringi gradualmente

   Quando i report mostrano che passano solo fonti legittime, passa a p=quarantine, se vuoi prima con pct=25, poi a p=reject quando è tutto pulito.

I record TXT non servono solo per la posta

Lo stesso tipo di record trasporta la verifica di proprietà del dominio per decine di servizi: Google Search Console, Microsoft 365, Facebook e altri ti chiedono tutti di pubblicare un token come record TXT e poi lo cercano.

example.com.    IN    TXT    "google-site-verification=rXsLp2..."
example.com.    IN    TXT    "MS=ms12345678"

Questi convivono senza problemi. Un dominio può avere molti record TXT; la regola è solo che deve esserci esattamente un record che inizia con v=spf1.

Passa qualsiasi dominio nello strumento di lookup per vedere insieme tutti i suoi record TXT: un modo rapido per individuare un record SPF duplicato o un token di verifica mai rimosso.