DMARC è un record TXT su _dmarc.<your domain> che indica ai server riceventi cosa fare con le email che usano il tuo dominio nell’header From ma non superano SPF e DKIM allineati, e dove inviare i report. p=none chiede solo i report, p=quarantine chiede ai server riceventi di trattare come sospette le email che non superano il controllo e p=reject chiede di rifiutarle.

Gmail, Yahoo e Microsoft accettano p=none dai mittenti di grandi volumi, così molti domini lo pubblicano e si fermano lì: vedono lo spoofing nei report, ma non lo bloccano. L’analisi di Red Sift su 73,3 milioni di domini, citata ad aprile 2026, ha rilevato che il 14,9% aveva una qualsiasi policy DMARC e che il 2,5% applicava p=reject. EasyDMARC, un altro fornitore di servizi DMARC, ha riportato nel 2025 che il 62,7% delle aziende Fortune 500 con DMARC usava p=reject, contro il 15,2% delle aziende Inc. 5000.

Ecco un piano di 30 giorni per arrivare a p=reject, record per record, per un dominio che invia dalla posta aziendale, da uno o due ESP, da un help desk e da uno strumento di fatturazione. Trenta giorni vanno bene per un sottodominio di invio. Un dominio che il tuo personale usa per la posta di tutti i giorni richiede più tempo.

Punti chiave

• Pubblica v=DMARC1; p=none; rua=mailto:... il giorno 1. Senza rua, i server riceventi non devono inviare report aggregati.
• Ogni mittente legittimo deve superare SPF o DKIM allineati al tuo dominio From. Per la maggior parte degli strumenti, questo significa firmare con DKIM usando il tuo dominio.
• Tieni SPF entro i 10 termini che generano query DNS, include annidati compresi, altrimenti tutte le tue email ottengono permerror.
• Passa a p=quarantine il giorno 15 e a p=reject il giorno 22, ogni volta dopo una settimana di report puliti. Per un dominio che il personale usa per la posta di tutti i giorni, la RFC 9989 chiede un mese per ciascuna delle prime due fasi.
• La RFC 9989 (maggio 2026) classifica pct come storico. Salta la progressione pct=10, pct=50.
• BIMI richiede p=quarantine o p=reject sul dominio organizzativo, nessun sp=none, un logo SVG Tiny PS e, per Gmail, un VMC o un CMC.

Cosa è cambiato in DMARC nel 2026

A maggio 2026 l’IETF ha sostituito la RFC 7489, un documento informativo (Informational) del 2015, con DMARCbis: la RFC 9989, un Proposed Standard che rende obsoleta anche la RFC 9091, più la RFC 9990 per i report aggregati. Qui contano tre cambiamenti:

• pct diventa storico. L’appendice A.6 afferma che “di solito non veniva applicato in modo accurato, a meno che il valore specificato non fosse 0 o 100”.
• t=y sostituisce pct=0. I server riceventi applicano il livello immediatamente inferiore alla tua policy, quindi p=reject; t=y funziona come quarantine. È un interruttore per i test.
• np è nuovo. Copre i sottodomini che non esistono nel DNS, e i server riceventi meno recenti devono ignorarlo.

Inoltre, per individuare il dominio organizzativo, la public suffix list lascia il posto a una risalita dell’albero DNS (DNS tree walk).

I tre record da cui dipende DMARC

DMARC è superato quando SPF o DKIM sono superati e il dominio che supera il controllo è allineato con il dominio From. Basta un solo controllo superato e allineato.

SPF e il limite di 10 lookup

SPF autorizza i server per il dominio della busta (MAIL FROM o return path), l’unica identità che DMARC usa, non HELO. La RFC 7208, sezione 4.6.4 limita a 10 i termini che generano query DNS: include, a, mx, ptr, exists e redirect, contati attraverso ogni include annidato. ip4, ip6 e all non contano. Oltre il limite, il risultato è permerror. La sezione consente inoltre al massimo due “void lookup” (lookup a vuoto), di solito un include verso un hostname che non esiste più.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all"

Questo record consuma già 4 lookup prima ancora di contare quelli annidati da ogni fornitore, quindi risolvi ciascun include con dig +short TXT <name> lungo tutta la catena. Per restare entro i 10, elimina gli strumenti che non usi più oppure dai a ogni ESP il proprio sottodominio di return path, come bounce.example.com, con il suo budget di 10 lookup. La guida alla configurazione di SPF di Microsoft consiglia di terminare con -all sui domini che usano anche DKIM e DMARC.

Molti ESP usano per impostazione predefinita il proprio dominio di return path, che non è allineato con il tuo. Configura un return path personalizzato o affidati a DKIM.

DKIM: chiavi a 2048 bit, selettori e rotazione

DKIM firma ogni messaggio con un dominio d= e un selettore s=; il server ricevente recupera la chiave da <selector>._domainkey.<d domain>. Uno strumento che firma con d=vendor-mail.example supera DKIM ma non supera DMARC.

La RFC 8301 stabilisce che chi firma deve usare chiavi RSA di almeno 1024 bit e dovrebbe usarne da 2048. Le linee guida di Google per i mittenti dicono lo stesso per le email dirette agli account Gmail personali. Una chiave a 2048 bit supera il limite di 255 caratteri di una stringa TXT, quindi va inserita come più stringhe tra virgolette in un unico record, e la maggior parte dei provider DNS le divide per te.

s202610._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..."
    "...remainder-of-the-2048-bit-key...IDAQAB" )

Assegna a ogni sistema di invio il proprio selettore e non riutilizzare mai un nome. Una data, come s202610, mantiene leggibile la cronologia. Le pratiche di rotazione delle chiavi di M3AAWG indicano di ruotarle almeno ogni sei mesi:

1. Pubblica il nuovo selettore e lascia che si propaghi.
2. Passa la firma alla nuova chiave.
3. Mantieni la vecchia chiave pubblica nel DNS per un periodo da 7 a 30 giorni, così le email in transito superano la verifica.
4. Dismetti il vecchio selettore con un p= vuoto. Non eliminarlo.

Allineamento: relaxed o strict

La RFC 9989 definisce due modalità:

La RFC 9989 osserva che “quasi tutti i proprietari di domini hanno trovato sufficiente l’allineamento relaxed”. Ometti aspf e adkim. L’allineamento SPF strict non funziona con la configurazione abituale, quella con il return path su un sottodominio.

Il piano di 30 giorni

Il record per ogni fase. Passa alla successiva solo dopo una settimana di report puliti.

Se nella seconda settimana salta fuori una fonte che nessuno riesce a correggere, resta su p=none. Rifiutare le tue stesse fatture è peggio che applicare la policy in ritardo.

Giorni da 1 a 7: pubblica p=none con i report

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

I report sono file XML compressi con gzip, inviati almeno una volta al giorno da ogni server ricevente, quindi fai puntare rua a un servizio che elabora i report, non a una persona. Se l’indirizzo si trova su un altro dominio organizzativo, la RFC 9990 prevede che i server riceventi lo ignorino, a meno che example.com._report._dmarc.<report domain> non lo autorizzi. I servizi di elaborazione pubblicano questo record; per i tuoi domini, aggiungilo tu.

Pubblica esattamente un record DMARC. Se le procedure guidate di configurazione lasciano due record v=DMARC1 su _dmarc.example.com, i server riceventi li scartano entrambi.

Lascia perdere ruf. La RFC 9989 osserva che i server riceventi attenti alla privacy oscurano pesantemente i report sugli errori o non li inviano affatto, e le FAQ contenute nell’annuncio di Microsoft per i mittenti di grandi volumi dicono che Microsoft invia i report rua e non ha in programma di inviare i ruf.

Come leggere un report aggregato

La RFC 9990 descrive report XML “giornalieri (o più frequenti)”, uno per ogni dominio a cui si applica la policy. Ecco un record, adattato dal suo esempio:

<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounces.vendor.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>vendor.example</domain>
      <selector>abc123</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.vendor.example</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

In policy_evaluated, dkim e spf sono i risultati dell’allineamento, e disposition è ciò che ha fatto il server ricevente. auth_results contiene i risultati grezzi e i relativi domini. Qui entrambi i controlli sono superati per vendor.example, quindi entrambi falliscono l’allineamento: è un fornitore che invia a tuo nome senza firmare a tuo nome. Attiva il suo DKIM personalizzato o l’autenticazione del dominio.

Giorni da 1 a 7: trova i mittenti sconosciuti

Raggruppa per source_ip, envelope_from e domain più selector di DKIM, ordina per count e classifica i risultati:

Per attribuire un IP, esegui dig -x 192.0.2.123 +short e controlla il selettore, che spesso contiene il nome del fornitore. Poi chiedi all’amministrazione, al supporto e alle vendite cosa invia email a nome dell’azienda: fatturazione, help desk, inviti del calendario, scanner dell’ufficio.

Le email inoltrate e quelle delle mailing list non supereranno i controlli in modi che non puoi correggere, e le FAQ di Google per i mittenti non richiedono l’allineamento per queste email, quindi non lasciare che ti blocchino.

Giorni da 8 a 14: correggi ogni fonte legittima

Procedi dal count più alto verso il basso:

1. Posta aziendale (Google Workspace, Microsoft 365). Attiva DKIM nella console di amministrazione, a 2048 bit dove disponibile, e verifica che l’include del provider sia presente in SPF.
2. ESP e strumenti di marketing. Configura l’autenticazione del dominio in modo che firmino con il tuo d=, più un return path personalizzato se disponibile.
3. Help desk, fatturazione, CRM. Come per gli ESP. Se uno di questi strumenti non può firmare con il tuo dominio, usa un sottodominio per cui può firmare, oppure il suo dominio.
4. Strumenti dismessi. Rimuovi i loro include e selettori.

Alla fine, ricalcola i lookup SPF.

Giorno 15: p=quarantine

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

Di solito, quarantena significa cartella spam. Controlla se ci sono fonti legittime con disposition quarantine. Per fare una prova, p=quarantine; t=y chiede ai server riceventi conformi alla RFC 9989 di applicare none, anche se la RFC ha pochi mesi e non tutti i server riceventi rispettano ancora t.

Giorno 22: p=reject

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com"

I server riceventi che rispettano p=reject rifiutano le email che non superano il controllo durante la sessione SMTP, ma la RFC 9989 indica loro di metterle in quarantena quando la policy è l’unico elemento a disposizione, quindi una parte finisce nello spam.

La stessa RFC afferma che un dominio con p=reject “NON DEVE affidarsi solo a SPF” e deve firmare con DKIM, perché l’inoltro rompe SPF ma non DKIM. Prima, verifica che ogni fonte abbia un DKIM allineato.

Mantieni rua per sempre. Il nuovo strumento del prossimo trimestre comparirà nei tuoi report prima che nella coda del supporto.

Quando allungare il piano

La RFC 9989, alla sezione 7.4, afferma che i domini i cui utenti scrivono sulle mailing list “NON DOVREBBERO” pubblicare p=reject, e che quelli che lo fanno dovrebbero prima restare “almeno un mese” su p=none e “un periodo altrettanto lungo” su p=quarantine. È il caso della maggior parte dei domini principali (apex) delle aziende, quindi lì dedica un mese a ciascuna delle prime due fasi. Un sottodominio usato solo dal tuo ESP non ha traffico di mailing list e può mantenere il ritmo di 30 giorni.

Policy dei sottodomini: sp= e np=

p copre il dominio e i suoi sottodomini. sp lo sostituisce per i sottodomini esistenti, np per quelli inesistenti. Un sottodominio con un proprio record usa quello, e lì la RFC 9989 ignora sp.

Un sottodominio di invio dedicato come mail.example.com, usato da un solo ESP con SPF e DKIM verificati, può pubblicare p=reject fin dal primo giorno. p=none; sp=reject sul dominio principale protegge i sottodomini mentre finisci il lavoro sul dominio stesso, ma blocca BIMI.

I domini parcheggiati dovrebbero pubblicare v=spf1 -all, come indica la guida SPF di Microsoft, più v=DMARC1; p=reject; su _dmarc.

Dal giorno 30 in poi: BIMI

BIMI mostra il tuo logo accanto alle email autenticate nelle inbox che lo supportano:

La bozza BIMI è alla revisione 14 (maggio 2026): è ancora un Internet-Draft scritto sulla base della RFC 7489, da cui il riferimento a pct. Ometti pct e non impostare t=y.

La regola del dominio organizzativo coglie in fallo chi invia da un sottodominio: con mail.example.com su p=reject ed example.com su p=none, i server riceventi non devono mostrare il logo, quindi anche il dominio principale deve completare il piano.

Le indicazioni del BIMI Group sugli SVG consigliano un logo quadrato e centrato su sfondo pieno, sotto i 32 KB. Google ha aggiunto il supporto ai CMC a settembre 2024. Ecco il record, secondo la guida all’implementazione del BIMI Group:

default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem"

La registrazione di un marchio richiede mesi, quindi se ti serve un VMC inizia subito.

Cosa richiedono Gmail, Yahoo e Microsoft

Nessuno dei tre richiede una policy applicata: solo un record DMARC e l’allineamento.

Fonti: linee guida di Google per i mittenti e relative FAQ, best practice di Yahoo per i mittenti, e l’annuncio di aprile 2025 e la pagina di supporto sul codice 5.7.515 di Microsoft. Microsoft ha iniziato ad applicare i requisiti il 5 maggio 2025, dopo che un aggiornamento del 29 aprile aveva cambiato l’azione: dallo spostamento nella posta indesiderata al rifiuto.

Le FAQ di Google affermano che l’allineamento sia con SPF sia con DKIM “diventerà prima o poi un requisito per i mittenti”, quindi allineali entrambi nella seconda settimana. Per i tassi di disiscrizione e di spam, leggi cosa vale ancora quando è un agente a inviare le tue email e la nostra guida alla deliverability.

DMARC su un dominio di invio di Brew

La configurazione del dominio di Brew richiede:

• DKIM, un record TXT su un selettore ._domainkey sotto il tuo dominio di invio. Obbligatorio.
• SPF, un record MX e un record TXT su send.<your sending domain>, il return path di Brew. Obbligatorio.
• DMARC, un record TXT su _dmarc.<your sending domain>. Facoltativo, ma consigliato.
• Un CNAME per il tracciamento dei clic, solo con un sottodominio di tracciamento personalizzato.

Il dominio può inviare non appena SPF e DKIM risultano verificati, e Brew suggerisce un valore DMARC adatto:

; dedicated sending subdomain, e.g. mail.example.com
_dmarc.mail.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com"
 
; apex domain, or a domain Brew can't prove is dedicated
_dmarc.example.com.       TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

A un sottodominio dedicato Brew suggerisce p=reject, perché da lì non parte nulla prima che SPF e DKIM di Brew siano verificati. A un dominio principale suggerisce p=none, perché probabilmente anche gli altri tuoi strumenti inviano a suo nome: in quel caso segui il piano descritto sopra. L’allineamento resta relaxed, perché il return path send.<domain> è allineato solo in modalità relaxed.

Brew legge il record _dmarc.<sending domain> pubblicato quando aggiungi il dominio, quando lo verifichi e a ogni nuovo controllo. Il risultato compare in Domini, oltre che in get_domain_health tramite MCP e in GET /v1/domains/{domainId}/health:

• dmarc_missing, un avviso con il record esatto da aggiungere.
• dmarc_invalid, se ci sono due record DMARC sullo stesso nome, oppure una versione o una policy non valida o tag duplicati. Indica il record da eliminare.
• Verificato, quando viene trovato esattamente un record valido.

La configurazione DNS automatica scrive il record DMARC solo quando non ne esiste già uno, quindi non lo duplica mai. Il controllo avviene sul dominio di invio, non sul dominio padre, quindi dai a ogni sottodominio di invio il proprio record, compreso quello per le email transazionali se separi i due tipi di invio come consiglia la documentazione. È nel servizio che elabora i tuoi report rua che leggi i report e decidi quando passare a reject.

Domande frequenti

Quanto tempo devo restare su p=none prima di passare a quarantine?

Finché un’intera settimana di report non mostra che ogni fonte legittima supera SPF o DKIM allineati: di solito da una a due settimane per un sottodominio di invio. Per un dominio che il personale usa per la posta di tutti i giorni, la RFC 9989 chiede almeno un mese. Due anni su p=none senza che nessuno legga i report non valgono nulla.

Il tag pct di DMARC è deprecato?

Sì. La RFC 9989 classifica pct come “historic” (storico) e sostituisce i suoi unici valori affidabili con t: t=y si comporta come pct=0, t=n come pct=100. I server riceventi meno recenti potrebbero ancora leggere pct, ma non hanno mai applicato in modo coerente i valori intermedi, quindi procedi per passi interi.

Con p=reject le mie email inoltrate verranno bloccate?

Un inoltro semplice di solito rompe SPF ma non DKIM, quindi il DKIM allineato viene comunque superato. Le mailing list che modificano l’oggetto o il footer rompono DKIM, e alcune riscrivono l’header From per compensare. Un DKIM allineato ovunque è la tua protezione migliore.

Gmail e Yahoo richiedono p=reject?

No. Entrambi chiedono ai mittenti di grandi volumi di pubblicare DMARC e accettano p=none, come fa Microsoft oltre i 5.000 messaggi al giorno verso Outlook.com. Una policy applicata blocca lo spoofing ed è obbligatoria per BIMI, ma nessuno dei tre la richiede.

Mi serve un VMC per BIMI?

Per Gmail ti serve un VMC, che richiede un marchio registrato e mostra un segno di spunta, oppure un CMC, che mostra il logo senza spunta. Il BIMI Group segnala che alcuni provider, tra cui Yahoo e Fastmail, mostrano anche loghi autodichiarati, senza alcun certificato.