SPF in pratica: mappare tutti i mittenti

Modulo 4: Recapitabilità: SPF, DKIM e DMARC nella pratica · Tempo di lettura: 12 minuti

Obiettivo della lezione: Al termine di questa lezione sarà in grado di individuare tutti i servizi che inviano posta a nome del Suo dominio, di raccoglierli in un unico record SPF, di contare in modo ricorsivo le ricerche fino al limite di dieci e di scegliere consapevolmente tra ~all e -all.

Concetti chiave: inventario dei mittenti, mittente della busta (Return-Path), un unico record SPF, include, redirect, limite di 10 ricerche DNS (RFC 7208 paragrafo 4.6.4), ricerche vuote (void lookups, massimo 2), conteggio ricorsivo, permerror, flattening, SPF per i sottodomini, SPF su un dominio che non invia posta, ~all e -all

Un breve ripasso

Un record SPF è un record TXT sul Suo dominio che inizia con v=spf1 ed elenca quali server possono inviare posta a nome del Suo dominio. La struttura, i caratteri + - ~ ? e i tre errori più comuni (due record, +all, più di dieci ricerche) sono spiegati nel corso DNS, lezione 4.3. La legga prima se SPF è nuovo per Lei. Questa lezione affronta la parte più difficile: nella pratica quasi nessuno sa con precisione chi invia posta a nome del proprio dominio.

Fase 1: l'inventario

SPF funziona solo se tutti i mittenti sono inclusi. Se ne dimentica uno, quella posta finirà nello spam o verrà rifiutata non appena irrigidirà il DMARC. Esamini quindi questo elenco. In una piccola azienda media se ne trovano facilmente cinque o sei:

Due buoni metodi per individuarli:

1. Leggere le intestazioni. Da ogni sistema, si invii un'email (una fattura, un ripristino password, una newsletter di prova) e osservi nelle intestazioni Return-Path e Authentication-Results (lezione 1.5). Lì vedrà tramite quale dominio e quale server è arrivata.
2. Rapporti DMARC. Imposti il DMARC su p=none con un indirizzo per i rapporti (lezione 4.4). Dopo qualche settimana vedrà nei rapporti (lezione 4.5) ogni server che ha inviato posta a nome del Suo dominio, anche quelli che aveva dimenticato. È l'inventario più affidabile.

Non ogni servizio appartiene al Suo SPF

Qui si sbaglia spesso. SPF controlla il mittente della busta (il Return-Path), non l'indirizzo Da. Molti servizi di newsletter e invio inviano con un Return-Path sul proprio dominio, per esempio bounce-123@mail.mailer.example. Il destinatario verifica allora il record SPF di mailer.example, non il Suo. Un include di quel servizio nel Suo record non serve allora a nulla, se non a costare una ricerca.

Ciò di cui quel servizio ha davvero bisogno per superare il DMARC è una firma DKIM con il Suo dominio (lezione 4.3), oppure un proprio sottodominio Return-Path di Sua proprietà (per esempio bounce.example.com come CNAME verso il servizio). Legga quindi nel manuale del servizio cosa richiede. Se dice "inserisca include: nel Suo SPF", lo faccia. Se dice solo "crei questi record CNAME per il DKIM e il dominio di bounce", allora non serve modificare nulla nel Suo record principale. Il modulo 7 approfondisce questo tema.

Fase 2: un unico record, e un conteggio corretto

Tutti i mittenti vanno in un unico record. Supponiamo che il Suo inventario riveli: il server di posta del Suo provider di hosting, Microsoft 365 per alcuni dipendenti, il Suo programma di contabilità e un helpdesk. Il record diventa allora, ad esempio:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

Quante ricerche sono? Conti ogni a, mx, include, exists, ptr e redirect, e conti poi anche tutto ciò che si trova nei record dietro ogni include:

A 11, il destinatario restituisce un permerror: l'intero record SPF smette allora di contare, per nessun mittente. La Sua posta inviata dal Suo stesso server di posta viene quindi valutata peggio perché l'helpdesk costa tre ricerche. E l'aspetto subdolo è che il Suo record può essere oggi 9 e domani 11, senza che Lei modifichi nulla, perché un servizio amplia il proprio record.

Inoltre: massimo due ricerche vuote

L'RFC 7208 menziona anche le void lookups: ricerche che non producono alcun risultato (il nome non esiste, oppure non ha record SPF o di indirizzo). Più di due di queste portano anch'esse a un permerror. Questo accade soprattutto con vecchi include di servizi che non usa più e che hanno rimosso il proprio record, oppure con un a: verso un server che non esiste più. Occorre quindi fare pulizia.

Fase 3: tornare sotto la soglia di dieci

Se supera le dieci ricerche, ci sono quattro soluzioni, dalla migliore alla meno buona:

1. Rimuova ciò che non serve. Servizi che non usa più. Servizi che inviano con un proprio Return-Path (si veda sopra) e che quindi non appartengono al Suo SPF. a se il Suo sito web stesso non invia posta. mx se il Suo MX punta a un servizio già presente come include nel Suo record.
2. Usi un sottodominio. Faccia inviare un servizio da nieuws.example.com oppure factuur.example.com. Quel sottodominio riceve un proprio record SPF con solo quel servizio, e non conta ai fini del limite di dieci del Suo dominio principale. L'allineamento nel DMARC (lezione 4.4) funziona per impostazione predefinita anche per i sottodomini.
3. Usi ip4: e ip6: per i Suoi server fissi. Questi non costano alcuna ricerca. Lo faccia solo per indirizzi che Lei gestisce e che non cambiano.
4. Flattening (sostituzione di tutti gli include con gli indirizzi IP che vi si trovano attualmente). Questo porta il numero a 0, ma il record smette di essere corretto non appena un servizio cambia i propri indirizzi, e i grandi servizi lo fanno regolarmente. Lo faccia solo con uno strumento che lo aggiorna automaticamente, o meglio ancora non lo faccia affatto.

redirect o include?

redirect= significa: utilizzi il record SPF di quell'altro dominio al posto di questo record. Costa una ricerca, come un include. È utile se ha molti domini che devono ricevere esattamente la stessa policy: v=spf1 redirect=_spf.example.com su ogni dominio, e il record effettivo in un solo punto. Un record con redirect= non può avere all, perché altrimenti il redirect viene ignorato. Gmail lo usa Lei stesso: gmail.com ha v=spf1 redirect=_spf.google.com.

Fase 4: ~all o -all?

La linea guida di questo corso, uguale a quella del corso DNS:

• Inizi con ~all (softfail). La posta da un server non presente nel Suo record viene considerata sospetta, ma solitamente non viene rifiutata subito. Se dimentica un mittente, il danno è limitato.
• Passi a -all (fail) quando è sicuro che tutti i mittenti sono inclusi, per esempio dopo aver esaminato per qualche settimana i rapporti DMARC e non ci sono più fonti sconosciute.

Con il DMARC accanto, la differenza è minore di quanto spesso si pensi. Il DMARC decide in base a "SPF o DKIM superato e allineato". Un softfail per il DMARC equivale semplicemente a "non superato". La vera protezione deriva quindi da una policy DMARC rigorosa, non da -all. Alcuni destinatari rifiutano già con -all prima della valutazione DMARC; questo è un motivo per scegliere -all solo quando il Suo record è davvero completo.

Un dominio che non invia mai posta

Ha dei domini che non inviano mai posta (un vecchio nome di marchio, un dominio per errori di battitura)? Li protegga dall'uso improprio con:

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Qui -all va bene da subito: non c'è nessuno autorizzato a inviare posta. L'ultima riga è un null MX (RFC 7505): "questo dominio non riceve posta". example.com stesso è configurato esattamente così.

Nella pratica: ecco come appare in un pannello

In un pacchetto di hosting di WebOké è impostato di default v=spf1 a mx include:webawere.nl ~all. Se aggiunge un servizio, modifica quel record (in DirectAdmin: Gestione DNS, la matita accanto al record SPF, campo Includi dominio; in Mio WebOké: l'assistente SPF nella scheda DNS). Lasci include:webawere.nl finché la Sua posta o il Suo sito web passano tramite quei server. Presso altri fornitori l'include predefinito ha un nome diverso, ma il principio è lo stesso: integrare, non creare un secondo record.

Riepilogo

• Faccia prima un inventario di tutti i mittenti; i rapporti DMARC e le intestazioni aiutano in questo.
• Un servizio con un proprio Return-Path non appartiene al Suo SPF; ha bisogno di DKIM con il Suo dominio.
• Conti in modo ricorsivo: ogni include, a, mx, exists, ptr e redirect, anche all'interno degli include. Oltre dieci, o più di due ricerche vuote, significa permerror.
• Torni sotto la soglia di dieci facendo pulizia e usando sottodomini; il flattening solo con manutenzione automatica.
• Inizi con ~all, passi a -all quando è sicuro. Domini che non inviano mai posta: -all, DMARC reject e null MX.

Quiz

Esercizio

Esercizio Z4.2: Contare in modo ricorsivo l'SPF del Suo dominio. Inserisca il Suo dominio (oppure sidn.nl se non ha un dominio proprio). Conti prima Lei stesso quante ricerche DNS costa il record SPF, incluso tutto ciò che si trova all'interno degli include, e inserisca il numero, insieme alla fine del record (~all, -all, ?all o +all). Il programma esegue il conteggio in tempo reale, incluse le ricerche vuote, e mostra l'albero.

Esercizio O4.2: Il Suo inventario dei mittenti. Usando la tabella di questa lezione, crei un elenco di tutti i sistemi che inviano posta a nome del Suo dominio. Indichi per ciascuno: tramite quale server o servizio, se deve rientrare nel Suo SPF (Return-Path proprio o no), e se firma con DKIM usando il Suo dominio. Invii a Se stesso un'email di prova da almeno due sistemi e annoti dalle intestazioni il dominio del Return-Path e il dominio DKIM (d=).

Per approfondire

I passaggi descritti in questi articoli valgono per i pannelli di WebOké; presso altri fornitori il funzionamento è simile.

• Corso gratuito DNS 4.3: SPF: chi può inviare email a nome del Suo dominio?
• Guida DirectAdmin 5.7: Impostare e integrare l'SPF
• Come funziona il record SPF nel DNS?
• Aggiungere o modificare un record SPF in DirectAdmin
• Guida WebOké 5.5: Assistenti DNS: MX, SPF, DMARC, CAA e SRV
• RFC 7208 (SPF), paragrafo 4.6.4 (limiti) e 6.1 (redirect); RFC 7505 (null MX)