DMARC p=none, quarantine o reject: guida per chi gestisce l'email

Il compromesso di fondo

Scegliere una policy DMARC significa scegliere tra visibilità ed enforcement. p=none offre monitoraggio senza influire sulla consegna. p=quarantine sposta la posta sospetta nella cartella spam. p=reject blocca del tutto la posta non autenticata. Il percorso più sicuro è un rollout a fasi: parti da none per individuare tutti i mittenti legittimi, passa a quarantine per testare l'impatto e arriva infine a reject per proteggere completamente il tuo dominio dallo spoofing.

Perché la policy conta per la coda degli incidenti

Se sei responsabile della deliverability, il tuo obiettivo principale è far arrivare ai destinatari la posta transazionale legittima, impedendo al tempo stesso agli attaccanti di usare il tuo dominio. Se passi direttamente a p=reject senza una fase di monitoraggio, probabilmente scatenerai un incidente ad alta priorità quando un sistema legacy dimenticato o uno strumento di marketing di terze parti smetterà all'improvviso di consegnare posta.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) si basa sull'allineamento di SPF e DKIM. Se un messaggio li fallisce entrambi, il tag p= indica al server di posta ricevente esattamente cosa farne.

I tre livelli di policy

1. p=none (modalità di monitoraggio)

In questa modalità il ricevente non interviene sul messaggio, qualunque sia l'esito dell'autenticazione. Serve solo a raccogliere dati.

Quando usarla:

• Alla prima configurazione di DMARC.
• Quando non conosci con certezza tutti i servizi che inviano posta per tuo conto.
• Durante una migrazione a una nuova API email.

Il record:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

Il compromesso: non hai alcuna protezione contro lo spoofing. Gli attaccanti possono ancora inviare posta a nome del tuo dominio, ma lo vedrai nei report RUA (aggregati).

2. p=quarantine (enforcement morbido)

I messaggi che non superano DMARC vengono trattati come sospetti. La maggior parte dei riceventi li sposta nella cartella spam o nella posta indesiderata.

Quando usarla:

• Dopo aver analizzato i report di p=none e verificato che tutti i flussi legittimi siano allineati.
• Come margine di sicurezza prima di passare al rifiuto completo.

Il record:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com;

Il compromesso: riduce la visibilità della posta contraffatta, ma non la elimina. Una parte della posta legittima potrebbe comunque finire in spam se le chiavi DKIM vengono ruotate in modo errato o se i record SPF raggiungono il limite di 10 lookup DNS.

3. p=reject (enforcement completo)

È lo standard di riferimento per la sicurezza del dominio. Il server ricevente rifiuta direttamente il messaggio se non supera DMARC.

Quando usarla:

• Quando il monitoraggio mostra un allineamento del 99,9% per tutto il traffico legittimo.
• Quando il rischio di spoofing del dominio supera quello di occasionali errori di consegna.

Il record:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;

Il compromesso: non c'è rete di sicurezza. Se un sistema critico è configurato male, la posta va persa. Vedrai questi errori nei report RUA, ma l'utente non riceverà mai il messaggio.

La checklist di rollout per chi gestisce la posta

Non cambiare policy a sensazione. Cambiala in base ai dati dei report aggregati. Usa uno strumento come il controllo DNS email di SendHQ per verificare che i record si propaghino correttamente prima di ogni passaggio.

Fase 1: scoperta (p=none)

1. Pubblica p=none con un indirizzo rua.
2. Attendi da 7 a 14 giorni per coprire un intero ciclo operativo di email (inclusi i report settimanali).
3. Analizza i report per individuare il traffico "non allineato".
4. Individua i mittenti di terze parti legittimi (ad es. Zendesk, Salesforce, Shopify).
5. Configura DKIM per ogni mittente individuato. È il modo più affidabile per garantire l'allineamento.

Fase 2: test (p=quarantine)

1. Aggiorna la policy a p=quarantine.
2. Tieni d'occhio i ticket di supporto del tipo "Non ho ricevuto l'email" o "L'email è finita in spam".
3. Controlla i report RUA per individuare nuovi picchi di errori.
4. Se si verificano errori, correggi l'autenticazione e resta su quarantine per un'altra settimana.

Fase 3: consolidamento (p=reject)

1. Aggiorna la policy a p=reject.
2. Verifica che i flussi transazionali più critici (reimpostazione password, fatture) vengano ancora consegnati.
3. Continua a monitorare. DMARC non è una configurazione da "impostare e dimenticare".

L'email come effetto collaterale

Per chi sviluppa agenti AI o flussi automatizzati, inviare un'email è un effetto collaterale esterno. Significa che può fallire per motivi estranei alla logica della tua applicazione (problemi DNS, rifiuto DMARC, limiti di frequenza).

Idempotenza e approvazione

Quando un agente AI attiva un'email, devi evitare invii duplicati durante i nuovi tentativi. Usa una chiave di idempotenza nelle richieste API, così un timeout di rete non farà ricevere al cliente la stessa email cinque volte.

Inoltre, gli agenti non dovrebbero avere il permesso di inviare in autonomia email ad alto impatto. Implementa una coda di approvazione per i contenuti generati dagli agenti, così da garantire che l'indirizzo "From" e il contenuto siano coerenti con il tuo brand e con le tue policy di autenticazione.

Il costo dell'infrastruttura di consegna

La scelta del provider di invio influisce su come gestisci DMARC. Alcuni provider rendono banale la configurazione di DKIM, altri richiedono voci DNS manuali per ogni sottodominio.

Quando valuti i costi, guarda al costo totale di proprietà. Ad esempio, inviare 50.000 email costa circa 5 USD con Amazon SES a consumo (0,10 USD ogni 1.000 email), mentre con i piani di Postmark lo stesso volume costerebbe circa 66 USD (15 USD per 10.000 email più eccedenze tra 1,20 e 1,80 USD ogni 1.000).

Tra le altre opzioni ci sono Resend, che offre un piano gratuito da 3.000 email al mese (con un tetto di 100 al giorno), e Mailgun, a partire da 15 USD al mese per 10.000 email. SendGrid ora usa una prova di 60 giorni al posto del piano gratuito, con Essentials a partire da 19,95 USD al mese.

Qualunque sia il provider, la policy DMARC resta lo scudo principale del tuo dominio. Se usi un provider che supporta solo SPF, rischi di più errori di consegna quando passi a p=reject, perché SPF si rompe con l'inoltro delle email. DKIM è l'unico modo per mantenere l'allineamento attraverso gli inoltri.

Modalità di errore comuni

La trappola dell'inoltro

L'utente A invia un'email all'utente B. L'utente B ha un inoltro automatico verso l'utente C. Il server che inoltra spesso cambia il mittente della busta con il proprio dominio per non essere segnalato come spam. Questo rompe l'allineamento SPF. Se hai p=reject e nessuna firma DKIM, l'utente C non vedrà mai l'email.

Il limite di lookup DNS

I record SPF sono limitati a 10 lookup DNS. Se aggiungi troppi provider al record SPF, il ricevente restituirà un permerror, che provoca un fallimento DMARC. Per risolvere, usa un provider che privilegia l'autenticazione DKIM oppure ricorri all'SPF flattening.

Il problema dello "shadow IT"

I team marketing spesso si iscrivono a nuovi strumenti (ad es. un nuovo servizio di newsletter) senza dirlo all'engineering. Inviano posta dal tuo dominio, questa non supera DMARC e viene rifiutata. Ecco perché la fase p=none non è negoziabile.

Tabella riassuntiva

Policy | Azione | Rischio | Visibilità | Uso consigliato

p=none | Nessuna | Basso | Alta | Scoperta e audit

p=quarantine | Cartella spam | Medio | Alta | Test e transizione

p=reject | Bloccata | Alto | Media | Sicurezza completa in produzione

Per approfondire l'implementazione tecnica di questi record, leggi la nostra guida a DKIM, SPF e DMARC.

Gestire questi record a mano è noioso. SendHQ semplifica il lavoro con l'invio transazionale da domini verificati e con strumenti che rendono la tua infrastruttura pronta per gli agenti.

Scopri di più su https://sendhq.cc.