# 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.

- Settore: Più settori
- Ambito: Sicurezza
- Anno: 2026
- URL: https://cloudfactory.it/lavori/enforcement-posta-spf-dkim-dmarc/

## In breve

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.

- **23** siti WordPress con una policy SES dedicata
- **11** IP statici di server nella lista consentita
- **~89.500** messaggi bloccati in un giorno su una newsletter
- **1.933** hard bounce rimossi dalla lista

## 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

1. **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.
2. **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.
3. **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.
4. **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.
5. **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

Amazon SES, IAM, CloudTrail, SendGrid, SPF, DKIM, DMARC, WordPress, WP Mail SMTP

## 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.

---

Cloudfactory S.r.l., Roma. Contatti: hello@cloudfactory.it