Posta che parte solo da chi ha il diritto di inviarla.
Un record SPF non basta, se non corrisponde a chi invia davvero. Per più clienti abbiamo stabilito chi può inviare posta, da dove e per quale dominio, e lo abbiamo fatto rispettare.
Su un ambiente di hosting con 23 siti WordPress che inviano tramite Amazon SES, dopo l'uso non autorizzato di una credenziale SMTP abbiamo ruotato le chiavi e dato a ogni sito una policy che consente l'invio solo dal proprio dominio e solo da 11 IP di server. Per un gruppo di laboratori abbiamo portato DMARC fino a p=reject. Per una newsletter con circa 89.500 blocchi in un giorno abbiamo allineato l'invio con SendGrid. E abbiamo fermato un record SPF che avrebbe escluso un mittente legittimo.
Contesto
SPF, DKIM e DMARC si configurano spesso una volta e poi si dimenticano. Nel frattempo cambiano i fornitori di invio, i server, le piattaforme di newsletter. Gestiamo posta e DNS per più clienti, e nel 2026 siamo intervenuti su tutti questi fronti.
Il problema
Gli errori della posta sono silenziosi in due direzioni. Un permesso troppo largo lascia inviare a tuo nome chi non dovrebbe: su un ambiente di hosting, una credenziale SMTP è stata usata per un invio massivo non autorizzato. Una regola troppo stretta, o un invio non allineato, blocca la posta legittima: una newsletter ha visto circa 89.500 blocchi il 27 maggio 2026, per il 97,7% rifiuti DMARC.
Cosa abbiamo fatto
- 01
Una policy per ogni sito
Chiavi ruotate, 39 su 41 erano oltre la scadenza di rotazione, e utenti inutilizzati rimossi. Ogni sito ha il suo utente IAM con una policy restrittiva: invio solo dal proprio dominio e solo da una lista di 11 IP statici, tutto il resto negato in modo esplicito.
- 02
Due errori sottili, trovati in rilascio
Il permesso sul configuration set veniva perso, e SES verifica il permesso sull'indirizzo mittente esatto, non solo sul dominio. Corretti entrambi, con la pubblicazione degli eventi attraverso un configuration set per i bounce e controlli su CloudTrail dei tentativi negati.
- 03
DMARC a gradini
Per i domini di un gruppo di laboratori, dopo un rating di sicurezza esterno: p=none, poi quarantine, poi reject. I domini che non inviano posta ricevono v=spf1 -all e p=reject, così nessuno può usarli per falsificare un mittente.
- 04
Una newsletter riallineata
I blocchi venivano da un invio con SendGrid non allineato al dominio. Autenticazione del dominio su SendGrid con 3 record CNAME, SPF ripulito per restare sotto il limite di 10 lookup DNS, 1.933 hard bounce tolti dalla lista.
- 05
Controllare prima di applicare
Un record SPF proposto, applicato così com'era con p=reject, avrebbe escluso un mittente legittimo. L'abbiamo fermato prima che andasse online.
Com'è andata
Sui domini che seguiamo, chi può inviare è scritto nei DNS e nelle policy, e vale davvero. Una chiave sottratta a un sito non manda posta per gli altri, un dominio che non invia non si può falsificare, una newsletter passa i controlli perché è firmata dal dominio che la manda.
Strumenti
Domande frequenti
Perché non mettere subito p=reject?
Perché con p=reject ogni mittente dimenticato viene respinto. Si parte da p=none, si leggono i rapporti, si allineano i mittenti e solo dopo si passa a quarantine e reject.
Cos'è il limite dei 10 lookup SPF?
Per valutare un record SPF si possono fare al massimo 10 interrogazioni DNS. Oltre, il controllo fallisce e la posta legittima rischia il rifiuto: ogni include in più va pesato.
A cosa serve v=spf1 -all su un dominio che non invia?
Dice a tutti che quel dominio non manda mai posta. Insieme a DMARC p=reject impedisce di usarlo per falsificare un mittente.