Guida alla policy DMARC: da None a Reject in 4 passaggi
Setup DMARC passo-passo da p=none a p=reject. DMARC checker gratuito incluso. Blocca lo spoofing in meno di un'ora. Conforme Gmail e Yahoo.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) è il livello di policy che lega SPF e DKIM e dice ai server riceventi cosa fare quando un messaggio non supera l'autenticazione. Senza DMARC, un provider di posta potrebbe in silenzio accettare, mettere in quarantena o rifiutare email non autenticate in base alle proprie regole interne. Con DMARC, definisci esplicitamente la policy di gestione per il tuo dominio.
Questa guida ti accompagna nell'intero processo di implementazione DMARC, dalla pubblicazione del primo record di solo monitoraggio fino al raggiungimento dell'enforcement completo con una policy reject.
Perché DMARC è importante#
Lo spoofing delle email rimane uno dei vettori d'attacco più comuni. Un attaccante può falsificare l'header "From" di un'email per far sembrare che il messaggio provenga dal tuo dominio. Senza DMARC, i server riceventi non hanno modo affidabile di conoscere la tua intenzione su come gestire tali messaggi.
DMARC risolve tre problemi:
- Prevenzione del phishing: blocca gli attaccanti dall'inviare email che sembrano provenire dal tuo dominio.
- Protezione del marchio: impedisce che il tuo dominio venga usato in campagne truffa che danneggiano la tua reputazione.
- Visibilità: i report DMARC ti mostrano esattamente chi sta inviando email usando il tuo dominio, inclusi servizi legittimi che potresti aver dimenticato e mittenti non autorizzati di cui non sapevi l'esistenza.
I principali provider di posta, tra cui Google, Microsoft e Yahoo, ora richiedono DMARC per i mittenti bulk. A partire dal 2024, Google richiede ai domini che inviano più di 5.000 email al giorno verso indirizzi Gmail di avere una policy DMARC pubblicata.
Come funziona DMARC con SPF e DKIM#
DMARC non esegue controlli di autenticazione propri. Invece, valuta i risultati di SPF e DKIM e applica un requisito aggiuntivo chiamato alignment (allineamento).
Il requisito di alignment#
Affinché DMARC passi, almeno una delle seguenti condizioni deve essere vera:
-
SPF passa E il dominio autenticato SPF è allineato con il dominio dell'header "From". SPF verifica il mittente di busta (Return-Path). DMARC richiede che questo dominio corrisponda (o sia un sottodominio di) il dominio nell'header "From" visibile.
-
DKIM passa E il dominio firmato DKIM (tag d=) è allineato con il dominio dell'header "From". Il dominio nella firma DKIM deve corrispondere (o essere un sottodominio di) il dominio dell'header "From".
L'allineamento può essere strict (corrispondenza esatta del dominio) o relaxed (sottodomini consentiti). L'allineamento relaxed è il default e funziona per la maggior parte delle configurazioni.
Perché l'allineamento è importante#
Senza allineamento, un attaccante potrebbe configurare SPF e DKIM per attacker.com, inviare un messaggio con From: ceo@yourcompany.com, e l'email passerebbe i controlli SPF e DKIM (per attacker.com), ma il destinatario vede il tuo dominio. L'allineamento DMARC chiude questo varco richiedendo che il dominio autenticato corrisponda a ciò che l'utente vede.
Sintassi del record DMARC#
Un record DMARC è un record DNS TXT pubblicato in _dmarc.yourdomain.com. Ecco un esempio completo:
v=DMARC1; p=reject; rua=mailto:dmarc-agg@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; aspf=r; adkim=r; fo=1;
Riferimento dei tag#
| Tag | Obbligatorio | Descrizione | Valori |
|---|---|---|---|
v | Sì | Versione del protocollo | Sempre DMARC1 |
p | Sì | Policy per il dominio | none, quarantine, reject |
rua | No* | Destinatari report aggregati | URI mailto: |
ruf | No | Destinatari report forensi | URI mailto: |
pct | No | Percentuale di messaggi a cui applicare la policy | 1-100 (default: 100) |
aspf | No | Modalità allineamento SPF | r (relaxed, default) o s (strict) |
adkim | No | Modalità allineamento DKIM | r (relaxed, default) o s (strict) |
sp | No | Policy per i sottodomini | none, quarantine, reject |
fo | No | Opzioni reporting in caso di failure | 0, 1, d, s |
*Anche se rua è tecnicamente opzionale, dovresti sempre includerlo. Senza report aggregati, stai pubblicando una policy alla cieca senza modo di vedere cosa accade.
Valori della policy spiegati#
- none: Solo monitoraggio. I messaggi che non passano DMARC vengono consegnati normalmente. Ricevi report che mostrano i risultati di autenticazione, ma non viene intrapresa alcuna azione. Questo è il punto di partenza.
- quarantine: I messaggi che non passano DMARC sono trattati come sospetti. Tipicamente vengono messi nella cartella spam o posta indesiderata del destinatario.
- reject: I messaggi che non passano DMARC sono rifiutati senza appello. Il server ricevente restituisce un errore e il messaggio non viene consegnato.
Opzioni di reporting failure (tag fo)#
- 0 (default): Genera un report solo se sia SPF che DKIM falliscono l'allineamento.
- 1: Genera un report se SPF o DKIM fallisce l'allineamento. È più utile per il debug ed è l'impostazione consigliata.
- d: Genera un report se DKIM fallisce, indipendentemente dall'allineamento.
- s: Genera un report se SPF fallisce, indipendentemente dall'allineamento.
La progressione in 4 passaggi verso l'enforcement completo#
Saltare direttamente a p=reject senza preparazione è pericoloso. Potresti bloccare email legittime da servizi che hai dimenticato di usare. L'approccio sicuro è una progressione graduale.
Passaggio 1: distribuisci con p=none (monitoraggio)#
Inizia con una policy di solo monitoraggio per raccogliere dati senza influenzare la consegna della posta.
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1;
Cosa fare durante questa fase:
- Pubblica il record e attendi almeno 2-4 settimane per raccogliere dati di report sufficienti.
- Esamina i report aggregati per identificare tutte le sorgenti legittime di email per il tuo dominio. Questo include il tuo server di posta primario, le piattaforme di marketing (Mailchimp, SendGrid, HubSpot), i servizi email transazionali, i sistemi CRM, i sistemi di ticketing e qualsiasi tool SaaS che invia email per tuo conto.
- Per ogni sorgente legittima, assicurati che SPF sia configurato (includi gli IP di invio del servizio nel tuo record SPF) e che DKIM sia impostato (pubblica la chiave pubblica DKIM del servizio nel tuo DNS).
- Indaga su qualsiasi sorgente che non riconosci. Potrebbero essere servizi legittimi dimenticati o mittenti non autorizzati.
Durata: minimo 2-4 settimane. Più a lungo se hai un'infrastruttura di invio complessa.
Passaggio 2: passa a p=quarantine al 25% (enforcement soft)#
Una volta sicuro che tutte le sorgenti legittime passino DMARC, inizia l'enforcement su una piccola percentuale di traffico.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com; fo=1;
Questo dice ai server riceventi di mettere in quarantena (tipicamente inviare in spam) il 25% dei messaggi che non passano DMARC. L'altro 75% è trattato come se la policy fosse none.
Cosa fare durante questa fase:
- Monitora attentamente i report per qualsiasi aumento di failure DMARC da sorgenti legittime.
- Se scopri un nuovo mittente legittimo a cui mancano SPF o DKIM, sistema la configurazione prima di procedere.
- Tieni d'occhio i report di email legittime che finiscono in spam.
- Se tutto sembra pulito dopo 1-2 settimane, passa al passaggio successivo.
Durata: 1-2 settimane.
Passaggio 3: aumenta a p=quarantine al 100% (quarantena completa)#
Rimuovi il limite percentuale in modo che la policy quarantine si applichi a tutti i messaggi che falliscono.
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com; fo=1;
O semplicemente ometti il tag pct, dato che 100 è il default:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; fo=1;
Cosa fare durante questa fase:
- Continua a monitorare i report.
- Verifica che nessuna email legittima venga messa in quarantena.
- Comunica con il tuo team per controllare se qualcuno segnala email mancanti.
- Dopo 2-4 settimane senza problemi, sei pronto per il passaggio finale.
Durata: 2-4 settimane.
Passaggio 4: applica p=reject (protezione completa)#
Questo è lo stato finale. I messaggi che non passano DMARC vengono rifiutati interamente.
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; fo=1;
A questo punto, chiunque tenti di inviare email dal tuo dominio senza autenticazione corretta vedrà i propri messaggi rifiutati. Il tuo dominio è completamente protetto contro lo spoofing.
Manutenzione continua:
- Continua a esaminare i report aggregati almeno mensilmente.
- Quando aggiungi un nuovo servizio di invio email, configura SPF e DKIM prima dell'invio.
- Ruota periodicamente le chiavi DKIM e verifica che le nuove chiavi passino DMARC.
- Considera di aggiungere
rufper i report forensi se la tua casella supporta il volume.
Lettura dei report DMARC#
Report aggregati (rua)#
I report aggregati sono file XML inviati quotidianamente dai server riceventi. Contengono:
- Il nome dell'organizzazione del server di reporting.
- L'intervallo di date coperto.
- La tua policy DMARC pubblicata.
- Per ogni IP sorgente che ha inviato email usando il tuo dominio: il numero di messaggi, i risultati SPF/DKIM/DMARC e gli esiti dell'allineamento.
Un estratto semplificato di un report aggregato appare così:
<record>
<row>
<source_ip>198.51.100.10</source_ip>
<count>1542</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
</record>
L'XML grezzo è difficile da leggere su larga scala. La maggior parte delle organizzazioni usa un servizio o tool di analisi report DMARC per parsare e visualizzare i dati. Servizi come il monitoraggio DMARC gratuito di Postmark, dmarcian o EasyDMARC possono aiutare.
Report forensi (ruf)#
I report forensi contengono dettagli sui singoli messaggi che hanno fallito DMARC, inclusi gli header del messaggio e a volte contenuto parziale. Sono utili per investigare incidenti specifici di spoofing ma generano alti volumi e possono contenere informazioni sensibili. Molti destinatari non inviano più report forensi a causa di preoccupazioni sulla privacy.
Trabocchetti comuni di DMARC#
1. Pubblicare p=reject senza monitoraggio prima#
Questo è l'errore più pericoloso. Se qualsiasi servizio email legittimo non è correttamente configurato con SPF e DKIM, quei messaggi verranno rifiutati. Inizia sempre con p=none ed esamina i report.
2. Dimenticare i mittenti di terze parti#
La causa più comune di failure DMARC da sorgenti legittime è dimenticare un tool SaaS che invia email usando il tuo dominio. I colpevoli comuni includono:
- Piattaforme di marketing automation
- Sistemi di ticketing per il supporto clienti
- Piattaforme CRM che inviano email per tuo conto
- Software di fatturazione e contabilità
- Tool HR e di recruiting
- Tool di calendario e scheduling
Verifica ogni servizio connesso al tuo dominio prima di superare p=none.
3. Record SPF che supera 10 lookup DNS#
SPF ha un limite rigido di 10 meccanismi di lookup DNS (include, a, mx, redirect, exists). Se il tuo record SPF supera questo limite, la valutazione SPF restituisce un "permerror", il che significa che SPF effettivamente fallisce per tutti i messaggi. Dato che DMARC richiede che SPF o DKIM passi con allineamento, un permerror SPF mette più pressione su DKIM.
Se hai molti servizi di invio, considera di appiattire il tuo record SPF o di usare una strategia di sottodomini in cui servizi diversi inviano da sottodomini diversi.
4. Non usare rua#
Senza report aggregati, non hai visibilità su come l'email del tuo dominio viene autenticata. Includi sempre un tag rua, anche con p=none.
5. Sottodomini senza tag sp=#
Per default, se non imposti il tag sp, i sottodomini ereditano la policy del dominio padre. Se usi sottodomini per scopi diversi (ad esempio, marketing.yourdomain.com), considera di impostare una policy esplicita per i sottodomini o di pubblicare record DMARC separati per ciascun sottodominio.
6. Ignorare DMARC dopo aver raggiunto reject#
DMARC non è una configurazione "imposta e dimentica". Vengono aggiunti nuovi servizi di invio, le chiavi scadono, i record SPF vengono modificati. Continua a esaminare i report aggregati mensilmente per individuare regressioni.
Verificare la tua configurazione DMARC#
Puoi verificare il tuo record DMARC attuale interrogando il DNS:
dig TXT _dmarc.yourdomain.com
Per un controllo completo che valuta il tuo DMARC insieme a SPF, DKIM, record MX e stato delle blacklist, usa il Checker di salute email gratuito di Nova Uptime. Il tool ti dà un punteggio su 100, un voto in lettera (da A a F) e raccomandazioni specifiche per migliorare la tua policy DMARC.
Il tool valuta la rigidità della tua policy DMARC come parte del punteggio. Una policy p=reject con reporting aggregato ottiene il punteggio più alto, mentre p=none o un record DMARC mancante comporta significative deduzioni di punti. Questo ti dà un'immagine chiara di dove si trova il tuo dominio e quali passi intraprendere.
Timeline di implementazione DMARC#
Ecco una timeline realistica per un deployment DMARC completo:
| Settimana | Azione | Record DMARC |
|---|---|---|
| 1 | Pubblica record di monitoraggio, configura processing dei report | p=none; rua=mailto:... |
| 2-4 | Esamina report, sistema SPF/DKIM per tutti i mittenti legittimi | p=none; rua=mailto:... |
| 5-6 | Enforcement soft al 25% | p=quarantine; pct=25; rua=mailto:... |
| 7-8 | Quarantena completa | p=quarantine; rua=mailto:... |
| 9-12 | Enforcement completo | p=reject; rua=mailto:... |
| Continuo | Revisione mensile dei report, manutenzione configurazioni | p=reject; rua=mailto:... |
Per organizzazioni con un'infrastruttura email semplice (un servizio di posta primario, uno o due tool di marketing), questo può essere compresso a 4-6 settimane. Per le aziende con dozzine di servizi di invio, prevedi 3-6 mesi.
Punti chiave#
- DMARC si basa su SPF e DKIM aggiungendo enforcement della policy e requisiti di allineamento.
- Inizia sempre con
p=nonee reporting aggregato. Non saltare mai direttamente ap=reject. - Usa il tag
pctper aumentare gradualmente l'enforcement. - Esamina i report aggregati per identificare tutte le sorgenti legittime di email prima dell'enforcement.
- Raggiungere
p=rejectè l'obiettivo, ma richiede preparazione. - Continua il monitoraggio dopo il deployment. DMARC richiede manutenzione continua.
- Usa il Checker di salute email di Nova Uptime per verificare la tua configurazione DMARC e ottenere una valutazione completa dell'autenticazione email.
Una policy DMARC implementata correttamente è una delle protezioni più forti che puoi distribuire per il tuo dominio. Previene lo spoofing, costruisce fiducia con i provider di posta e ti dà chiara visibilità su chi sta inviando email per tuo conto.
Domande frequenti#
Cos'è un controllo DMARC?#
Un controllo DMARC verifica se il tuo dominio ha un record DNS DMARC valido e ne valuta le impostazioni di policy. Conferma che la sintassi del tuo record DMARC sia corretta, che la tua policy (none/quarantine/reject) sia configurata correttamente e che gli indirizzi di reporting siano funzionanti. Esegui un controllo DMARC gratuito per vedere la tua configurazione attuale.
È possibile il monitoraggio DMARC gratuito?#
Sì. Nova Uptime include il monitoraggio DMARC come parte del suo checker di salute email. Verifica il tuo record DMARC insieme a SPF, DKIM e stato delle blacklist su un calendario configurabile e ti avvisa quando qualcosa cambia. Il piano Free copre fino a 5 domini.
Quanto tempo ci vuole per raggiungere p=reject?#
Per la maggior parte delle organizzazioni, la progressione da p=none a p=reject richiede 2-4 mesi. La timeline dipende da quante sorgenti email legittime devi identificare e autenticare. Affrettarsi a reject senza esaminare i report DMARC rischia di bloccare la tua stessa email legittima.
Cosa succede se imposto DMARC su reject senza SPF e DKIM?#
Le tue email saranno rifiutate dai server riceventi. L'enforcement DMARC richiede che almeno uno tra SPF o DKIM passi E sia allineato con il tuo dominio From. Configura prima SPF e DKIM, poi fai progredire DMARC da none a reject gradualmente.
Letture correlate#
- SPF, DKIM e DMARC: guida completa — Come tutti e tre i protocolli lavorano insieme
- Guida a test e configurazione DMARC — Configurazione avanzata della policy DMARC
- Guida al controllo e rimozione blacklist email — Cosa fare quando i problemi di autenticazione portano al blacklisting
- Checklist deliverability email — 15 passi per migliorare il piazzamento in inbox
- Checker salute email gratuito — Controlla DMARC, SPF, DKIM e blacklist in una sola scansione
Monitor Your Website Before It Goes Down
Get uptime monitoring, SSL tracking, domain expiry alerts, and email health checks. Free plan — no credit card required.
Start Monitoring FreeArticoli correlati
Configurazione Policy DMARC: Previeni lo Spoofing Email
Test DMARC gratuito + guida alla configurazione. Imposta p=none, p=quarantine, p=reject. Allinea SPF/DKIM. Richiesto da Gmail e Yahoo da feb 2026.
SPF, DKIM e DMARC: La Guida Completa all'Autenticazione Email
Guida ai tre pilastri dell'autenticazione email. Come SPF, DKIM e DMARC lavorano insieme per proteggere il tuo dominio e l'inbox placement.
Come Configurare i Record SPF: Guida all'Autenticazione Email
Esegui lookup e valida il tuo record SPF. Guida passo passo a sintassi SPF, limiti di lookup DNS, errori comuni e strumenti di test gratuiti.