Da p=none a p=reject: criteri di uscita per fase in DMARC

La domanda dietro la maggior parte dei progetti DMARC non è come scrivere il record, ma per quanto tempo restare a p=none e cosa deve essere vero prima di passare oltre. Aspettare per sempre lascia il tuo dominio esposto allo spoofing, e muoversi troppo presto manda le tue stesse fatture nello spam. Questa guida ti dà criteri di uscita fase per fase, un piano per i sottodomini, cosa si rompe di solito e come tornare indietro. Le soglie sono un nostro consiglio, non fanno parte di nessuno standard, e le indichiamo come tali.

In breve#

Resta a p=none per almeno un ciclo completo di invio, di solito da due a quattro settimane, di più se hai posta mensile o trimestrale come gli estratti conto. Passa a quarantine quando ogni sorgente legittima che conosci supera DMARC con un controllo SPF o DKIM allineato. Passa a reject dopo un ulteriore periodo a quarantine senza sorprese. Non pianificare la salita attorno a pct=: l'attuale standard DMARC, l'RFC 9989, rimuove quel tag. È stata pubblicata a maggio 2026 e rende obsoleta l'RFC 7489, la specifica DMARC originale. Le basi del record sono nella guida alla configurazione di DMARC, che questo articolo non ripete.

Le fasi e quando uscire da ciascuna#

Ogni fase qui sotto ha un test di uscita. Ogni numero nella tabella è una regola empirica che suggeriamo, perché volume e mix di mittenti decidono cosa è realistico.

Una fase è conclusa quando gli errori inspiegati sono pochi e noiosi: qualche messaggio da server di inoltro, mailing list o sorgenti che puoi identificare come non tue. Se una sorgente con volumi reali non è ancora identificata, non hai finito con la fase 2. Il metodo per identificarle è nella guida su come leggere i report DMARC.

Un calendario di esempio#

Per rendere concreta la tabella, ecco un piano plausibile per un'azienda con un ESP, un CRM e uno strumento di fatturazione. È un'illustrazione, non una promessa.

• Settimane da 1 a 4: pubblica p=none, raccogli i report e costruisci l'elenco di ogni sorgente con il suo responsabile. Includi quella che invia solo a fine mese.
• Settimane da 5 a 8: correggi l'allineamento sorgente per sorgente, partendo dalla più grande per volume. Ricontrolla i report dopo ogni modifica, non alla fine.
• Settimana 9: applica la policy ai domini parcheggiati e che non inviano.
• Settimane da 10 a 13: porta il dominio principale a quarantine e controlla ogni settimana se ci sono nuove sorgenti che falliscono.
• Dalla settimana 14: passa a reject se l'ultimo mese è stato tranquillo, e aggiungi una regola permanente: i nuovi mittenti vengono autenticati prima del lancio.

Se una sorgente è lenta da correggere, il calendario la aspetta. La data è un piano, il test di uscita è la regola.

Cosa fare con pct#

Se hai visto consigli più vecchi come pct=10, poi 25, 50, 100, era un modo per applicare una policy più severa a una quota della posta che falliva. L'RFC 9989 rimuove il tag. La sua stessa motivazione dice che il tag di solito non veniva applicato con precisione se il valore non era 0 o 100. Al suo posto aggiunge un tag t, con y per "testing" e n (il valore predefinito) per il trattamento normale.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com"

Con t=y, un ricevente che lo supporta dovrebbe trattare un messaggio che fallisce un livello più morbido di quanto dice la policy: quarantine diventa none, reject diventa quarantine. Non ha effetto su p=none. Due avvertenze oneste. Primo, il supporto al nuovo tag impiegherà tempo a diffondersi, quindi non fare affidamento su di esso per proteggerti. Secondo, una salita per percentuali non è mai stata una rete di sicurezza affidabile, nemmeno prima del cambiamento.

Un modo più sicuro per limitare il rischio è procedere per ambito invece che per percentuale: applica la policy prima ai sottodomini e ai domini che non inviano, poi al dominio principale, e fermati a quarantine per qualche settimana prima di reject. Se il tuo record attuale contiene ancora pct=, non hai fretta di rimuoverlo, ma non aggiungere una nuova salita che dipenda da esso.

Sottodomini e domini che non inviano nulla#

Il risultato più rapido viene dai domini che non inviano mai posta. I domini parcheggiati e i brand dismessi sono bersagli preferiti dello spoofing, e non hanno sorgenti legittime da rompere. Pubblica subito una policy restrittiva, più un record SPF che non autorizza nulla:

parked.example.com.         TXT  "v=spf1 -all"
_dmarc.parked.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
parked.example.com._report._dmarc.example.com.  TXT  "v=DMARC1;"

La terza riga è il record di autorizzazione. Poiché l'indirizzo rua= è in un dominio diverso da quello protetto dalla policy, i riceventi inviano i report solo se quell'altro dominio pubblica un record TXT chiamato <protected-domain>._report._dmarc.<report-domain>. Se lo salti, o se metti l'indirizzo rua= sul dominio parcheggiato stesso, i report di quel dominio non arriveranno mai. La guida ai report non ricevuti spiega il controllo.

Per i sottodomini di un dominio che invia, vale la policy del dominio padre a meno che il sottodominio pubblichi un proprio record. Il tag sp= imposta una policy diversa per i sottodomini che non ne hanno. L'RFC 9989 definisce anche un tag np per i sottodomini che non esistono nel DNS, utile contro nomi host inventati. Se prevedi di impostare sp=reject sul dominio padre, verifica prima che ogni sottodominio di invio passi, oppure dagli un record proprio. La guida al sottodominio di invio spiega perché ogni flusso di posta sta meglio su un proprio sottodominio fin dall'inizio.

Cosa si rompe di solito quando applichi la policy#

Quasi ogni incidente di applicazione risale a uno di questi punti. Cercali nelle fasi 1 e 2, non dopo il cambio di policy.

• Il mittente che nessuno ricordava. Uno strumento di fatturazione, una piattaforma di sondaggi o un sistema di selezione del personale che invia una volta al mese. Un ciclo completo di report ne cattura la maggior parte, ed è per questo che la fase 1 non si può saltare.
• Allineato nel test, non in produzione. Un servizio passa da un pool di IP di invio e fallisce da un altro. Giudica ogni sorgente in base al suo volume reale nel tempo.
• Server di inoltro e mailing list. L'inoltro rompe SPF, e le liste che modificano un messaggio rompono DKIM. Non puoi prevenirlo del tutto. Aspettati un piccolo tasso residuo di errori e decidi in anticipo che è accettabile. L'RFC 9989 è esplicita: un dominio che pubblica p=reject non deve affidarsi al solo SPF e deve firmare la posta con DKIM, e un dominio i cui utenti scrivono a mailing list non dovrebbe pubblicare affatto p=reject. Per quel tipo di dominio suggerisce almeno un mese a p=none, poi un periodo altrettanto lungo a p=quarantine, prima di confrontare i risultati. Le nostre finestre più brevi qui sopra si adattano ai domini che inviano soprattutto posta di sistema, quindi allungale se il tuo staff scrive su liste pubbliche.
• Un nuovo strumento aggiunto dopo l'applicazione. Il team marketing si iscrive a una piattaforma di martedì e la sua posta inizia a rimbalzare. È un problema di processo: stabilite che i nuovi mittenti configurano l'autenticazione prima del primo utilizzo.
• Allineamento strict lasciato attivo. adkim=s o aspf=s trasformano una configurazione relaxed funzionante in errori. La guida alla risoluzione dei problemi di allineamento passa in rassegna ogni causa.

Seguire il passaggio con numeri reali#

Nelle fasi da 2 a 4 ti serve un'unica vista: per ogni sorgente, quale quota della sua posta supera DMARC, e quali sorgenti sono nuove questa settimana. I report DMARC di Qualisend mostrano questo per dominio, su 7, 30 o 90 giorni, e ti inviano un'email il giorno dopo che un dominio ha almeno 10 messaggi che falliscono sia SPF sia DKIM, oppure una nuova sorgente con almeno 5 messaggi che falliscono. Non ha un punteggio "pronto per reject", quindi il giudizio è tuo: osserva ogni sorgente legittima arrivare al 100% e restarci. I dati aggregati inoltre hanno un ritardo di uno o due giorni e coprono solo i riceventi che inviano report, quindi una settimana tranquilla non prova che nulla sia fallito.

Il monitoraggio check-up del dominio di Qualisend elenca p=none come avviso tra i problemi di un dominio, e avvisa su pct sotto il 100, il che aiuta se gestisci più domini e vuoi vedere quali non si sono ancora mossi.

Rollback#

Pianifica la strada del ritorno prima di muoverti. Tre abitudini rendono rapido un rollback.

1. Conserva il testo del record precedente nelle note di modifica, così il ripristino è un copia e incolla.
2. Abbassa il TTL del record _dmarc a pochi minuti circa un giorno prima di un cambio di policy, poi rialzalo quando tutto è stabile. I riceventi mettono in cache il DNS, e un TTL lungo rallenta il tuo stesso rollback.
3. Torna indietro di un passo, non fino in fondo. Se una sorgente legittima inizia a fallire con reject, torna a quarantine mentre la correggi. I messaggi già rifiutati in quella finestra di solito rimbalzano al mittente e non sono recuperabili dal lato del ricevente, quindi è meglio che la prima finestra di applicazione sia breve e sorvegliata.

Dove l'applicazione si collega a tutto il resto#

Raggiungere quarantine o reject sul dominio organizzativo è anche il presupposto per i loghi BIMI, e la guida a BIMI elenca cosa richiede lo standard. Non elimina la necessità delle altre basi descritte nei requisiti di Google e Yahoo. Il quadro completo di come l'autenticazione si lega alla reputazione è nella guida alla deliverability.

Una policy DMARC applicata dimostra che la posta è tua, ma non può rendere buona una lista cattiva. Il piano gratuito nella pagina dei prezzi include 100 crediti che eseguono la verifica completa su una lista. Un dominio protetto ha comunque bisogno di una lista sana per meritarsi la inbox.