# Cos'è DMARC? Allineamento, Policy e gli RFC del 2026 URL: https://notificationharbor.com/it/journal/cosè-dmarc Type: blog Locale: it Published: 2026-09-29 Updated: 2026-09-29 --- > DMARC dice ai ricevitori cosa fare quando la posta fallisce l'allineamento. Ecco come funzionano il record, le policy e i report, e cosa è cambiato nel 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. ![Engineer reviewing DNS records in a terminal on a laptop at a desk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f76a50-inline1.webp) 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](https://support.google.com/mail/answer/81126?hl=en) 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](https://senders.yahooinc.com/best-practices/) 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. ![Lowered customs barrier at a harbor container yard at dusk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/4a2947-inline3.webp) ## 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: - Pubblica `p=none` con un indirizzo `rua`. - Raccogli 2-4 settimane di report. Costruisci l'inventario dei mittenti. - Aggiusta ogni sorgente legittima non allineata con un dominio DKIM personalizzato o return-path. - Passa a `p=quarantine`. Stai in ascolto di ticket di supporto riguardanti mail mancante. - 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](https://www.rfc-editor.org/rfc/rfc9989) è 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. ![Cream envelope being sealed with a red wax stamp](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f3aca9-inline2.webp) ## 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. ## FAQ ### DMARC è obbligatorio? Per i mittenti in massa, sì di fatto. Google richiede un record DMARC per chi invia più di 5.000 messaggi al giorno a Gmail, e Yahoo richiede una policy valida di almeno p=none. L'enforcement non è richiesto, ma il record e l'allineamento sì. ### Cosa significa p=none in DMARC? Significa monitoraggio solamente. I ricevitori consegnano la posta che fallisce normalmente e ti inviano i report. Soddisfa il minimo di Gmail e Yahoo ma non offre protezione contro lo spoofing. ### Un'email può passare SPF e DKIM ma fallire DMARC? Sì. DMARC richiede che il dominio validato da SPF o DKIM si allinei con il dominio From. La posta inviata attraverso un provider che firma con il suo dominio passa entrambi i controlli ma fallisce l'allineamento. ### Quanto tempo devo stare su p=none? Tipicamente da due a quattro settimane di report aggregati, abbastanza a lungo per vedere ogni mittente legittimo inclusi quelli a basso volume. Passa al prossimo step una volta che ogni sorgente legittima mostra allineamento. ### DMARC influenza la consegnabilità? Indirettamente. Un record pubblicato e allineato è un requisito di base su Gmail e Yahoo, e l'allineamento che fallisce può spingere la posta nello spam o causare rifiuto sotto una policy di enforcement. Non risolve reputazione cattiva del mittente o alti tassi di reclamo. ### Cosa è cambiato con DMARCbis e RFC 9989? RFC 9989 rende obsoleto RFC 7489. Rimuove pct, rf e ri, aggiunge t, np e psd, e sostituisce le ricerche della Public Suffix List con una passeggiata dell'albero DNS. I record v=DMARC1 esistenti rimangono validi.