Chiunque può firmarsi con il tuo dominio
La posta elettronica è nata senza un controllo sul mittente. Come sul retro di una busta, chi spedisce può scrivere l'indirizzo che vuole: se il dominio non è protetto, un truffatore può mandare ai tuoi clienti una mail da amministrazione@tuodominio.it, con il tuo nome in bella vista e una fattura con un IBAN diverso. Il cliente paga, il denaro sparisce, e la telefonata arrabbiata arriva a te.
Tre controlli pubblicati nel DNS del dominio permettono a chi riceve la posta di distinguere i messaggi veri da quelli falsificati. Non serve cambiare fornitore di posta, ma vanno attivati con metodo.
I tre controlli, senza gergo
SPF (Sender Policy Framework): un elenco, pubblicato nel DNS, dei server autorizzati a spedire posta per il tuo dominio. Chi riceve controlla se il server che ha consegnato il messaggio è nell'elenco.
DKIM (DomainKeys Identified Mail): una firma digitale aggiunta a ogni messaggio dal server che lo spedisce. Chi riceve la verifica con una chiave pubblica pubblicata nel DNS: se il messaggio è stato alterato, o non viene da chi possiede la chiave, la firma non torna.
DMARC (Domain-based Message Authentication, Reporting and Conformance): la regola che dice ai destinatari cosa fare con i messaggi che non superano i controlli, e chiede loro di mandarti un report su ciò che hanno ricevuto a tuo nome.
DMARC aggiunge un requisito che spesso sfugge: l'allineamento. Non basta che un messaggio superi SPF o DKIM per un dominio qualsiasi; il dominio verificato deve corrispondere a quello che il destinatario vede nel campo mittente. È ciò che impedisce al truffatore di superare i controlli con un dominio suo e mostrare il tuo.
Le tre policy di DMARC
| Policy | Cosa chiede a chi riceve | Quando si usa |
|---|---|---|
| p=none | Nessuna azione: consegna come al solito, ma manda i report | All'inizio, per vedere chi spedisce a tuo nome |
| p=quarantine | Trattare come sospetti i messaggi che falliscono, di solito spostandoli nello spam | Quando i mittenti legittimi sono stati sistemati |
| p=reject | Rifiutare i messaggi che falliscono | Il punto d'arrivo: i falsi non vengono consegnati |
Da febbraio 2024 Google e Yahoo richiedono SPF, DKIM e DMARC a chi invia grandi volumi di email ai loro utenti. Anche se non spedisci newsletter a migliaia di persone, la direzione è questa: una fattura legittima da un dominio non configurato rischia di finire nello spam come una falsa.
Il primo passo: chi spedisce a tuo nome
Il lavoro vero è sapere chi deve comparire nei record. Quasi ogni azienda spedisce posta a proprio nome da più punti di quanti immagini:
- la posta aziendale, per esempio Microsoft 365;
- il gestionale che manda fatture, solleciti e conferme d'ordine;
- la piattaforma delle newsletter;
- il CRM usato dai commerciali;
- il sito web, con i moduli di contatto e gli ordini online;
- il centralino che inoltra fax e messaggi vocali per email.
Nell'autorizzarli in SPF c'è un limite tecnico da conoscere: lo standard SPF (RFC 7208) ammette al massimo 10 consultazioni DNS per verificare un record. Ogni servizio aggiunto con un "include" ne consuma almeno una, il limite si supera prima di quanto sembri, e a quel punto SPF fallisce anche per i messaggi legittimi.
Il percorso, una fase alla volta
- Inventario: tutti i servizi che spediscono a nome del dominio, con il fornitore di ciascuno.
- SPF e DKIM configurati per ogni servizio, restando dentro il limite delle consultazioni.
- DMARC in p=none, con un indirizzo che riceve i report. Per alcune settimane si leggono: mostrano chi spedisce a tuo nome, chi supera i controlli e chi no. Spesso compare un servizio che nessuno aveva elencato.
- Correzione dei mittenti che falliscono, uno per uno, coinvolgendo i rispettivi fornitori.
- Passaggio a quarantine, continuando a leggere i report.
- Infine reject, quando i report mostrano che a fallire sono soltanto i messaggi falsi.
Gli errori frequenti
- Passare subito a reject. Le fatture del gestionale, spedite da un server del fornitore mai autorizzato, vengono rifiutate dai clienti. Lo si scopre quando un cliente telefona per chiedere dove sono.
- Fermarsi a p=none. Il record c'è, i report arrivano, nessuno li legge. Il dominio resta falsificabile come prima.
- Dimenticare i domini che non spediscono. Il vecchio marchio, il dominio comprato per difesa: se non mandano posta, lo si dichiara con un SPF che non autorizza nessun server e un DMARC in reject. Altrimenti diventano il mittente perfetto per una truffa.
- Nessuno responsabile del DNS. Nella storia Sette fornitori, nessun responsabile la posta è rimasta ferma tre giorni, quasi tutti spesi a capire di chi fosse il compito. Chi può modificare questi record va scritto nero su bianco, come spieghiamo nella guida sull'IT che vive nella testa di una persona.
Questi controlli proteggono il tuo dominio da chi lo falsifica, ma non fermano chi registra un dominio simile al tuo con una lettera cambiata. Per quello servono persone allenate a riconoscere il phishing.
In sintesi
SPF dice quali server possono spedire per il tuo dominio, DKIM firma i messaggi, DMARC decide cosa fare di quelli che non superano i controlli e ti manda i report. Si parte dall'inventario di chi spedisce a tuo nome, si osserva in p=none, si correggono i mittenti e solo dopo si arriva a reject, senza dimenticare i domini che non mandano posta.