Cos'è DMARC? Allineamento, Policy e gli RFC del 2026

Cos'è DMARC? È un record DNS che dice ai server di ricezione della posta cosa fare quando un messaggio dichiara il tuo dominio nell'intestazione From ma fallisce l'autenticazione, e dove inviare i report. DMARC non autentica nulla di per sé. Verifica che SPF o DKIM abbiano passato e che il dominio che hanno validato corrisponda al dominio che il lettore vede.

Quella corrispondenza si chiama allineamento, ed è la parte in cui la maggior parte dei team si sbaglia. Un messaggio può passare SPF, passare DKIM, e fallire DMARC.

DMARC è un livello di policy sopra SPF e DKIM

SPF elenca quali IP possono inviare per un dominio. DKIM firma il messaggio in modo che un ricevitore possa verificare che non è stato alterato e che il dominio firmatario lo ha approvato. Nessuno dei due guarda l'indirizzo From che un umano legge.

DMARC colma questo gap. Pone una sola domanda: il dominio nell'intestazione From visibile si allinea con il dominio che ha passato SPF o DKIM? Se sì, il messaggio passa. Se no, il ricevitore applica la tua policy.

Il record vive su _dmarc.tuodominio.com come record TXT. Uno minimo e valido assomiglia a questo:

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

Tre tag fanno il lavoro vero. p è la policy, rua è dove vanno i report aggregati, e adkim / aspf impostano quanto severo deve essere l'allineamento. Tutto il resto è opzionale.

L'allineamento è dove i buoni setup falliscono

SPF autentica il mittente della busta, il dominio Return-Path. DKIM autentica il dominio nel tag d= della firma. DMARC ha bisogno che almeno uno di questi corrisponda al dominio From, esattamente (strict) oppure a livello di dominio organizzativo (relaxed, il default).

Ecco il fallimento che vediamo più spesso nei trace. Un team invia attraverso un provider terzo, il provider firma con il proprio dominio (d=provider-mail.net) e usa il proprio bounce domain. SPF passa, DKIM passa, e DMARC fallisce perché nessuno dei due domini corrisponde a example.com.

La soluzione è un dominio di invio personalizzato: una chiave DKIM pubblicata nel tuo dominio, e idealmente un return-path personalizzato su un sottodominio. Ogni provider serio la supporta. Pochi la attivano di default.

Le tre policy: none, quarantine, reject

Il tag p ha tre valori, e non sono una scala che percorri secondo una pianificazione.

• p=none: il ricevitore consegna normalmente e ti invia i report. Usalo per le prime 2-4 settimane, mentre fai l'inventario dei mittenti.

• p=quarantine: il ricevitore indirizza i fallimenti a spam o junk. Usalo una volta che i report mostrano che tutte le fonti legittime sono allineate.

• p=reject: il ricevitore rifiuta i fallimenti alla fase SMTP. Usalo una volta che la quarantena ha girato in modo pulito per un ciclo di invio completo.

p=none è monitoraggio, non protezione. Un dominio fermo su none per due anni ha una checkbox di compliance e nessuna difesa contro lo spoofing. Salta la tentazione di lasciarlo lì perché "non è successo nulla".

p=reject è la destinazione per qualsiasi dominio che invia solo posta che controlli. Domini con traffico massiccia da mailing-list o forwarder legacy hanno bisogno di più attenzione, perché il forwarding spesso rompe SPF e può rompere DKIM se l'intermediario modifica il corpo.

Perché le regole di Gmail e Yahoo hanno reso questo urgente

Da febbraio 2024, le linee guida per i mittenti di Google richiedono a chiunque invii più di 5.000 messaggi al giorno agli account Gmail di pubblicare un record DMARC, con SPF e DKIM in atto. La policy può essere none. Google chiede anche ai mittenti in massa di mantenere il tasso di spam segnalato dagli utenti in Postmaster Tools sotto lo 0,30%, e consiglia di stare sotto lo 0,10%.

Yahoo Sender Hub afferma lo stesso requisito fondamentale: una policy DMARC pubblicata di almeno p=none, con il dominio From allineato al dominio SPF o DKIM. L'allineamento relaxed è accettabile.

Nota cosa è e cosa non è in quelle regole. Il requisito è un record pubblicato e un allineamento che passa, non un enforcement. Questo è un livello minimo. Non è un traguardo.

I report aggregati sono il prodotto, la policy è l'interruttore

L'indirizzo rua riceve report XML giornalieri da ogni ricevitore che onora DMARC. Ogni report elenca gli IP sorgente, i conteggi dei messaggi, i risultati di SPF e DKIM, e se l'allineamento ha retto. È così che trovi il mittente dimenticato: il vecchio export CRM, lo strumento di billing che un contractor ha collegato nel 2022, il form di marketing su un sottodominio di cui nessuno è proprietario.

Un XML grezzo è illeggibile a volume. Indirizza rua a una casella postale che un parser può ingerire, oppure a un servizio di reporting DMARC ospitato, e guarda i dati raggruppati per sorgente. Quello che vuoi vedere è ogni sorgente legittima che mostra l'allineamento al 100%, e tutto il resto chiaramente sconosciuto.

Una distribuzione pratica segue questo ordine:

1. Pubblica p=none con un indirizzo rua.

2. Raccogli 2-4 settimane di report. Costruisci l'inventario dei mittenti.

3. Aggiusta ogni sorgente legittima non allineata con un dominio DKIM personalizzato o return-path.

4. Passa a p=quarantine. Stai in ascolto di ticket di supporto riguardanti mail mancante.

5. Passa a p=reject quando la quarantena non mostra fallimenti legittimi.

Spedisci ogni passo separatamente. Cambiare la policy e aggiungere un nuovo provider di invio nella stessa settimana rende qualsiasi regressione impossibile da attribuire.

DMARCbis cambia i tag, non il tuo record

Nel 2026 l'IETF ha pubblicato RFC 9989, RFC 9990 e RFC 9991, che rendono obsoleto RFC 7489. RFC 9989 è la specifica DMARC principale. Il report aggregato e il report di fallimento si sono spostati nei propri documenti.

I cambiamenti pratici per un proprietario di record sono piccoli:

• pct, rf, e ri sono rimossi.

• t (testing mode) sostituisce pct come interruttore tutto-o-niente: t=y riporta senza enforcement.

• np imposta una policy per sottodomini inesistenti, che blocca lo spoofing di indirizzi come abc123.example.com.

• psd marca i domini con suffisso pubblico, e una passeggiata dell'albero DNS sostituisce l'antica ricerca della Public Suffix List.

I record v=DMARC1 esistenti rimangono validi. Nulla si rompe se non cambi nulla oggi. Il supporto dei provider per i nuovi tag si diffonderà in modo incoerente, quindi un nuovo tag che sembra non fare nulla di solito significa che il ricevitore non lo ha ancora implementato.

Il tag np è quello che vale la pena adottare presto. Impostare np=reject mentre p è ancora none chiude il percorso di abuso del falso-sottodominio senza impegnare il resto della tua posta all'enforcement.

Sottodomini, e perché il default eredita

Un record DMARC sul dominio organizzativo si applica ai sottodomini anche, a meno che non lo sovrascrivi con sp. Questa eredità è utile e anche una trappola.

Se il marketing invia da news.example.com attraverso un provider separato, eredita la policy del genitore. Sposta il genitore a p=reject prima che il provider abbia DKIM allineata e la newsletter va a terra. Pubblica un record _dmarc.news.example.com separato quando un sottodominio ha la sua propria flotta di mittenti e il suo proprio ritmo di distribuzione.

Un'architettura più pulita separa i flussi per sottodominio fin dall'inizio. Posta transazionale su uno, lifecycle su un altro, posta umana sulla radice. Ognuno ha le sue proprie chiavi DKIM, la sua propria reputazione, e il suo proprio record DMARC.

Leggi l'intestazione Authentication-Results prima di indovinare

Quando un messaggio fallisce, il server ricevente registra il perché. In Gmail, "Mostra originale" espone l'intestazione Authentication-Results, e dice più di qualsiasi dashboard.

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=bounce.provider-mail.net;
  dkim=pass header.d=provider-mail.net;
  dmarc=fail (p=NONE) header.from=example.com

Leggilo da sinistra a destra. SPF ha passato per bounce.provider-mail.net. DKIM ha passato per provider-mail.net. DMARC ha fallito perché l'intestazione From dice example.com e nessuno dei due domini che hanno passato lo corrisponde.

La nota (p=NONE) mostra la policy che il ricevitore ha visto. Con none questo messaggio è stato consegnato comunque. Con reject avrebbe rimbalzato con un errore 5.7.x, e il mittente lo avrebbe scoperto da un cliente.

Due controlli catturano la maggior parte di questi casi. Conferma che il valore header.d nel risultato DKIM è il tuo dominio. Poi conferma che il dominio smtp.mailfrom è il tuo dominio o un sottodominio di esso.

SPF ha un limite di ricerca che DMARC espone

SPF consente dieci ricerche DNS per valutazione. Ogni include: per un provider ne spende alcuni, e gli include annidati ne spendono di più. Superare i dieci e SPF restituisce un errore permanente, che conta come un fallimento.

I team con cinque o sei strumenti di invio colpiscono questo senza notarlo, perché i fallimenti SPF erano invisibili prima di DMARC reporting. Una volta che arrivano i report rua, il pattern è ovvio: una sorgente che all'improvviso fallisce SPF su tutti i ricevitori il giorno in cui qualcuno ha aggiunto un altro include:.

Questo è un altro motivo per fare affidamento sull'allineamento DKIM come percorso principale. DKIM sopravvive alla maggior parte del forwarding, non ha budget di ricerca, ed è legato al messaggio piuttosto che all'IP di connessione. Tieni SPF valido, ma non costruire il tuo pass DMARC solo su quello.

Cosa DMARC non farà

DMARC previene lo spoofing del dominio esatto. Non ferma i domini che assomigliano (examp1e.com), non giudica il contenuto, e non aggiusta una cattiva reputazione del mittente. Un dominio perfettamente allineato che invia a liste acquistate finisce comunque nello spam.

Non sostituisce nemmeno il monitoraggio. L'allineamento può rompersi silenziosamente: un cambio DNS rimuove un selettore DKIM, un provider ruota le chiavi, un nuovo strumento inizia a inviare senza che tu lo sappia. I report sono il modo in cui scopri prima che i tuoi utenti.

Tratta il record DMARC come qualsiasi altro pezzo di configurazione di produzione. Appartiene al controllo di versione, i cambiamenti passano per la revisione, e la casella postale rua ha bisogno di un proprietario.

Prima di pubblicare il record

Passa attraverso questo una volta. Ci vogliono meno di un'ora per un singolo dominio.

• Elenca ogni sistema che invia posta come il tuo dominio: prodotto, fatturazione, help desk, CRM, marketing, inviti del calendario.

• Conferma che ognuno firma DKIM con il tuo dominio, non quello del vendor.

• Imposta un return-path personalizzato dove il provider lo consente.

• Scegli una destinazione rua che qualcuno leggerà.

• Inizia con p=none, e metti la data in cui pianifichi di rivederlo sul calendario.

• Controlla il tasso di spam in Google Postmaster Tools settimanalmente durante la distribuzione.

Dove andare da qui

Se non hai mai guardato i tuoi report, pubblica p=none con un indirizzo rua oggi e leggi cosa arriva tra due settimane. Il primo report quasi sempre nomina almeno un mittente che nessuno ricordava. Il prossimo passo concreto è decidere quale di questi mantenere.