Analisi DNS e posta di un dominio

SPF è l'elenco pubblico dei server autorizzati a inviare posta per un dominio. Serve perché il destinatario possa confrontare il server da cui l'email arriva davvero con quelli che il dominio dichiara. Senza record, non c'è niente da confrontare.

La specifica prevede un solo record SPF per nome, e non lascia al destinatario la scelta di quale usare: davanti a due, la valutazione si ferma con un errore permanente. L'effetto pratico è lo stesso di un SPF assente. Succede quasi sempre perché due fornitori diversi hanno pubblicato il proprio senza guardare quello già presente.

SPF viene valutato dal server del destinatario a ogni email ricevuta, e la specifica gli concede al massimo dieci interrogazioni DNS per farlo. Il tetto esiste per non trasformare ogni dominio in un moltiplicatore di query. Superato, il destinatario risponde con un errore permanente — non valutabile, non «fallito» — e molti lo trattano come se SPF non ci fosse.

Il conteggio è ancora dentro il tetto, ma il margine è quello che separa il record di oggi da un errore permanente domani. Da tenere presente: il numero non dipende solo da te — gli `include` dei tuoi fornitori possono contenerne altri e cambiare senza avvisarti, quindi si può passare da nove a undici senza aver toccato niente.

Il qualificatore finale dice al destinatario cosa fare di un'email che arriva da un server non elencato. `~all` significa softfail: accettala comunque, ma segnala che qualcosa non torna. In pratica il messaggio contraffatto arriva — a volte in posta indesiderata, a volte no, dipende da chi lo riceve. `-all` significa invece rifiutalo.

`?all` significa neutral: il dominio dichiara esplicitamente di non esprimere alcun giudizio sui server non elencati. Il destinatario lo tratta come se SPF non ci fosse. È quasi sempre il residuo di una fase di prova che nessuno ha chiuso.

`+all` autorizza qualunque server del mondo a inviare a nome del dominio. È peggio di non avere SPF: un destinatario che si fida di SPF vede un pass su un'email contraffatta, e quel pass è esattamente il segnale che il record dovrebbe negare.

`ptr` chiede al destinatario di risolvere all'indietro l'indirizzo del server che sta consegnando. La specifica lo dichiara deprecato: è costoso per chi riceve, molti lo ignorano, e consuma comunque uno dei dieci lookup disponibili.

DMARC è il record che lega il mittente che l'utente legge a quello che SPF e DKIM hanno autenticato, e dice ai destinatari cosa fare quando i due non coincidono. Serve perché SPF e DKIM, da soli, verificano indirizzi che il destinatario non vede mai.

SPF è l'elenco pubblico dei server autorizzati a inviare posta per un dominio. Su un dominio che non riceve posta serve al contrario: a dichiarare che da qui non parte niente. Senza quella dichiarazione chiunque può usare il nome come mittente, e il destinatario non ha modo di sapere che non doveva.

DMARC dice ai destinatari cosa fare di un'email che si presenta a nome del dominio senza superare i controlli. Un dominio che non riceve posta resta perfettamente falsificabile in uscita — anzi è il bersaglio preferito, perché nessuno ne legge i rapporti e nessuno si accorge di niente. Pubblicare la policy è il modo di dichiarare che da questo nome non deve arrivare nulla.

`p=none` chiede ai destinatari di osservare e riferire, non di bloccare: le email contraffatte a nome del dominio vengono consegnate normalmente. È il gradino di partenza previsto dalla specifica, quello che serve a raccogliere i dati prima di stringere.

`p=quarantine` chiede ai destinatari di consegnare in posta indesiderata i messaggi che non superano i controlli, invece di rifiutarli. È il gradino intermedio fra l'osservazione e il rifiuto: un messaggio in spam resta un messaggio che qualcuno può aprire.

`rua` è l'indirizzo a cui i destinatari inviano i rapporti aggregati: ogni giorno, in XML compresso, l'elenco di chi ha inviato posta a nome del dominio e di come è andata l'autenticazione. Serve perché è l'unico modo di sapere chi manda email a tuo nome — e di accorgersi quando un fornitore legittimo smette di autenticarsi.

CAA elenca le autorità di certificazione autorizzate a emettere certificati per il dominio. Non è un suggerimento: le CA sono obbligate a leggerlo prima di emettere e a rifiutare se non compaiono in elenco. Senza record, qualunque CA pubblica può emettere un certificato valido — e non serve un attacco, basta che una delle centinaia esistenti sbagli una validazione.

DNSSEC firma le risposte DNS di un dominio, e pubblica al registro l'impronta che permette di verificarle. Serve perché un resolver possa distinguere una risposta autentica da una iniettata lungo il percorso. Senza, quella distinzione non è possibile.

Il registro pubblica l'impronta delle chiavi, ma la verifica non riesce: la catena delle firme è interrotta. Non è un rischio, è un guasto in corso — per i resolver che validano, e sono molti, questo dominio in questo momento non si risolve. Colpisce solo una parte degli utenti, il che lo rende difficile da diagnosticare: a chi usa un resolver che non valida, il dominio funziona.

I name server sono i server che rispondono alle domande su un dominio. Le buone pratiche ne chiedono almeno due, e molti registri rifiutano la delega con uno solo: con un name server unico non esiste nessuna ridondanza, e un guasto rende irraggiungibile il dominio e ogni servizio che ne dipende.

I nomi dei name server sono due o più, ma dietro c'è una sola infrastruttura: sito, posta e accessi remoti dipendono dalla disponibilità di un unico fornitore. Per molte organizzazioni è una scelta accettabile e consapevole; diventa un tema quando un'ora di dominio irraggiungibile ha un costo che si sa quantificare.