DMARC quarantine e reject: come uscire da p=none senza perdere la posta legittima

1. Che cosa chiedono ai destinatari p=none, quarantine e reject

Il tag p nel record DMARC a _dmarc.example.com indica che cosa vorresti che i destinatari facessero con la posta il cui dominio From non supera DMARC, cioè quando né SPF né DKIM hanno dato esito positivo per un dominio allineato. È una richiesta. L’RFC 9989, lo standard DMARC pubblicato a maggio 2026 che sostituisce l’RFC 7489, lascia la decisione finale alla policy locale di ciascun destinatario.

Due punti condizionano il rollout. Primo, p=none da solo non protegge nulla: produce report, e solo se il record ha un indirizzo rua. Secondo, i destinatari non applicano tutti la policy allo stesso modo. L’RFC 9989 raccomanda di non rifiutare unicamente perché una policy dice reject, e alcuni mettono comunque in quarantena quella posta: la stessa modifica può quindi apparire diversa presso fornitori di posta diversi. Pianifica il passaggio come una sequenza di piccoli passi reversibili, non come un interruttore unico.

I grandi fornitori di posta chiedono già ai mittenti di grandi volumi un record DMARC, ma accettano p=none. La guida al controllo di SPF e DMARC elenca i loro requisiti e spiega ogni tag del record.

2. Come leggere i report aggregati DMARC (rua)

I report aggregati rendono possibile un passaggio sicuro. Aggiungi un indirizzo di report al record, ad esempio rua=mailto:dmarc-reports@example.com, e i destinatari che inviano report ti manderanno un file XML compresso, di norma relativo a un giorno UTC, con l’elenco di ogni indirizzo IP che ha inviato posta con il tuo dominio nella riga From e l’esito di quella posta. Il formato è definito nell’RFC 9990. Un nome di file come receiver.example!example.com!1791590400!1791676800.xml.gz indica il destinatario che ha prodotto il report, il tuo dominio, l’inizio e la fine del periodo come timestamp Unix.

Ogni <record> nel file raggruppa i messaggi per fonte ed esito. Questi sono i campi più importanti:

La differenza tra l’ultima riga e policy_evaluated è la cosa più utile da imparare. Una piattaforma di newsletter può mostrare un DKIM pass in auth_results per mailer.example.net e fallire comunque DMARC, perché quel dominio non è allineato con example.com. Solo policy_evaluated dice che cosa ha concluso DMARC.

Leggi i report per diverse settimane, non per un solo giorno: fatture mensili, newsletter trimestrali e avvisi di rinnovo annuali arrivano con tempi propri. Con volumi consistenti l’XML grezzo è faticoso; un parser o uno strumento di reportistica che raggruppa le righe per fonte, allineamento ed esito giorno per giorno rende la revisione praticabile. Non tutti i destinatari inviano report aggregati, quindi una settimana silenziosa non significa un dominio silenzioso. Se l’indirizzo rua appartiene a un altro dominio organizzativo, quel dominio deve pubblicare un record di autorizzazione come example.com._report._dmarc.reports.example.net che inizi con v=DMARC1, altrimenti i destinatari ignorano l’indirizzo (RFC 9990, sezione 4).

3. Trova ogni mittente legittimo prima di applicare la policy

L’applicazione è sicura solo se conosci ogni sistema che mette il tuo dominio nella riga From. Costruisci l’elenco da due direzioni: ciò che l’organizzazione usa e ciò che mostrano i report. Fonti tipiche:

• La piattaforma di posta che il personale usa ogni giorno.
• Marketing e newsletter, compreso un vecchio strumento di campagne in cui qualcuno accede ancora.
• Posta transazionale della tua applicazione: conferme di registrazione, reset delle password, ricevute.
• Strumenti aziendali: CRM, fatturazione, assistenza clienti, HR e selezione del personale, calendario e firma elettronica.
• Moduli e plugin del sito che inviano come noreply@example.com.
• Dispositivi e script: scanner, avvisi di monitoraggio, job pianificati e relay locali.

Poi associa ogni fonte dei report a una voce dell’elenco. Una ricerca inversa dell’indirizzo IP (dig +short -x 192.0.2.10) spesso rivela il provider, e la documentazione del provider spiega l’include SPF e la configurazione DKIM supportati. Conserva il risultato in una tabella come questa:

L’ultima riga è il senso dell’esercizio. Quando ogni fonte nota supera i controlli, ciò che continua a fallire è per lo più posta falsificata o mal configurata, ed è proprio ciò che l’applicazione della policy deve fermare. Le fonti che inviano di rado sono quelle più spesso dimenticate: chiedi a amministrazione, HR e assistenza quali strumenti usano prima di fidarti di un mese tranquillo.

4. Allineamento di SPF e DKIM: relaxed o strict

DMARC è superato quando SPF o DKIM sono validi e il dominio per cui lo sono è allineato con il dominio From. Basta un solo esito allineato. Per SPF il dominio verificato è il mittente di busta (RFC 7208); per DKIM è il valore d= di una firma valida (RFC 6376). I tag aspf e adkim stabiliscono quanto deve essere stretta la corrispondenza:

• Relaxed (r, il valore predefinito): i due domini condividono lo stesso dominio organizzativo, quindi bounce.example.com e news.example.com sono allineati con example.com.
• Strict (s): i domini devono essere identici.

L’RFC 9989 determina il dominio organizzativo con un DNS Tree Walk, interrogando i record _dmarc dal nome completo verso l’alto, invece di usare la public suffix list su cui si basava l’RFC 7489.

L’RFC 9989 osserva che quasi tutti i titolari di dominio ritengono sufficiente l’allineamento relaxed. L’allineamento strict rompe lo schema diffuso di un sottodominio bounce dedicato per ogni provider, quindi mantieni il valore predefinito salvo motivi specifici, ad esempio sottodomini delegati a fornitori, dove l’allineamento relaxed farebbe passare per example.com posta autenticata per vendor.example.com. Qualunque scelta tu faccia, rendi DKIM il metodo allineato per ogni fonte. SPF si rompe quando la posta viene inoltrata, perché il server che inoltra non è nel tuo record; una firma DKIM di norma sopravvive all’inoltro finché il messaggio non viene modificato.

5. Rollout graduale: pct non c’è più, usa t=y

Le guide più vecchie introducono l’applicazione con pct: p=quarantine; pct=10, poi 25, 50 e 100, così che la policy copra un campione crescente della posta che fallisce. Con l’RFC 7489 la posta fuori dal campione riceveva la policy immediatamente inferiore. L’RFC 9989 ha eliminato il tag; la sua Appendice A.6 spiega che i valori diversi da 0 e 100 di solito non venivano applicati con precisione e che l’imprecisione variava molto tra le implementazioni.

L’eliminazione ha un lato tagliente. L’RFC 9989 dice ai destinatari di ignorare i tag sconosciuti, quindi un destinatario che segue il nuovo standard legge p=quarantine; pct=25 come un semplice p=quarantine e lo applica a tutta la posta che fallisce. Un pct parziale non può più essere considerato un limite all’impatto.

Il sostituto è il flag di test t. Con t=y si chiede ai destinatari di applicare un livello sotto la policy pubblicata: p=quarantine; t=y viene trattato come none e p=reject; t=y come quarantine. I report continuano come al solito e un destinatario può registrare la deviazione con il motivo policy_test_mode. L’RFC 9989 descrive t=y e t=n come i corrispettivi di pct=0 e pct=100.

Durante la transizione alcuni destinatari implementano ancora solo l’RFC 7489 e ignorano t, mentre quelli più recenti ignorano pct. Poiché pct=0 con le vecchie regole e t=y con le nuove chiedono lo stesso trattamento, puoi pubblicare entrambi durante i test:

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

Osserva i report per qualche settimana, poi rimuovi entrambi i tag in modo che p=quarantine si applichi per intero. Ripeti lo schema prima di reject: p=reject; t=y; pct=0 chiede ai destinatari di mettere in quarantena, e togliendo i due tag si attiva reject.

Puoi anche procedere per flusso di posta invece che per percentuale. Un sottodominio come news.example.com può avere un proprio record DMARC e passare all’applicazione prima o dopo del dominio principale; l’esempio di adozione dell’RFC 9989 prova p=quarantine con t=y su un sottodominio prima di irrigidire ulteriormente.

6. Policy dei sottodomini: sp e np

Un record DMARC su example.com copre anche i sottodomini che non hanno un proprio record _dmarc. Due tag permettono di differenziare la policy dei sottodomini da p:

Poche regole rendono tutto prevedibile. sp ha significato solo nel record del dominio organizzativo; un sottodominio che pubblica un proprio record è governato dal p di quel record. Impostare np=reject mentre p è ancora none è un primo passo a basso rischio: la posta falsificata da nomi inventati come billing-support.example.com viene rifiutata, e i destinatari che non supportano np ripiegano semplicemente su sp o p. Prima di affidartici, assicurati che ogni sottodominio da cui invii davvero abbia almeno un record DNS, così da essere considerato esistente. E ricorda che SPF non viene ereditato: ogni nome usato come mittente di busta richiede un proprio record SPF, qualunque sia la policy DMARC.

7. Una tempistica realistica da p=none a p=reject

Nessuna tempistica va bene per ogni dominio, e l’RFC 9989 avverte che possono servire molti mesi di report prima che un titolare di dominio sia pronto ad applicare la policy. Per i domini i cui utenti scrivono a mailing list suggerisce almeno un mese a p=none e un periodo altrettanto lungo a p=quarantine, confrontando i risultati, e anche in quel caso afferma che tali domini non dovrebbero pubblicare reject. Un’organizzazione con pochi servizi di invio potrebbe pianificare così:

Prima di ogni modifica, abbassa il TTL del record TXT _dmarc, ad esempio a 300 secondi, con almeno un vecchio periodo di TTL di anticipo, così che un rollback raggiunga rapidamente i resolver. Modifica il record all’inizio della settimana, spiega al team di assistenza a che cosa fare attenzione e tieni un registro datato di ogni valore pubblicato. L’RFC 9989 richiede che ogni dominio che pubblica p=reject firmi la propria posta con firme DKIM valide invece di affidarsi al solo SPF. Reject non è l’unico buon punto d’arrivo: per un dominio usato dal personale nelle mailing list una quarantine ben monitorata può essere la scelta migliore, mentre un dominio usato solo per fatture e notifiche è un ottimo candidato per reject.

8. Quando la posta legittima fallisce: diagnosi, correzione, rollback

Prima o poi un report o un collega mostrerà posta legittima che fallisce. Trova le righe corrispondenti nei report aggregati, oppure chiedi gli header completi di un messaggio interessato e leggi il suo header Authentication-Results, poi confronta lo schema:

Se il guasto è esteso, o colpisce posta cruciale come ricevute e reset delle password, prima torna indietro e poi indaga: aggiungi t=y e pct=0, oppure ripristina la policy precedente. Con un TTL breve la modifica raggiunge la maggior parte dei resolver in pochi minuti. Un rifiuto 5xx è permanente, quindi la posta già respinta non viene recapitata in seguito; indica al team coinvolto quali messaggi reinviare. Poi correggi la fonte, verifica che passi in alcuni giorni di report e avanza di nuovo. Inoltri e liste che preservano i risultati di autenticazione con ARC (RFC 8617) possono aiutare, ma l’RFC 9989 nota che nessun meccanismo del genere è ancora ampiamente usato, quindi DKIM su ogni fonte resta la correzione affidabile.

9. Come verificare il record DMARC pubblicato

Controlla che cosa è realmente pubblicato, non ciò che mostra il pannello DNS:

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com
dig +short NS example.com
dig +short TXT _dmarc.example.com @ns1.example.net

Le prime due righe mostrano ciò che restituiscono i resolver; l’ultima interroga direttamente un server autorevole, mostrando una modifica prima che le risposte in cache scadano. Verifica che:

• esattamente un record TXT a _dmarc inizi con v=DMARC1; se ce ne sono due, i destinatari li scartano entrambi e il dominio si comporta come se non avesse DMARC;
• v=DMARC1 sia il primo tag e p contenga none, quarantine o reject;
• la casella rua esista e, se appartiene a un altro dominio, sia autorizzata con un record _report._dmarc;
• i tag siano separati da punto e virgola, senza virgolette tipografiche o caratteri estranei incollati da un documento.

Poi invia un messaggio da ciascun servizio di invio a una casella che controlli e leggi l’header Authentication-Results: dmarc=pass insieme al tuo dominio From è il verdetto del destinatario, ed è quello che conta.

Per una veloce vista dall’esterno, la verifica gratuita dei record SPF e DMARC legge il record _dmarc sull’hostname esatto che inserisci, senza ripiegare sul dominio padre. Segnala un record mancante (medio, quando l’host ha record MX) e p=none (basso, come modalità di monitoraggio); quarantine e reject non generano alcun segnale. Non legge i tuoi report né valuta sp, np, t, pct, rua o l’allineamento. Lo stesso controllo DNS della posta legge anche SPF, MTA-STS e CAA ed è uno degli otto controlli passivi dello snapshot gratuito di preparazione al lancio, che non richiede registrazione e restituisce un punteggio con un risultato per ogni controllo. Per una routine di revisione continuativa, consulta la guida alla sicurezza di DNS e posta.