Scegli la politica DMARC giusta
per il tuo dominio
La politica DMARC (tag p=) indica ai server di posta riceventi cosa fare dei messaggi che falliscono l'autenticazione DMARC. Esistono tre opzioni - none, quarantine e reject - e ogni dominio dovrebbe seguire lo stesso percorso, dal monitoraggio all'applicazione totale. Ogni politica viene pubblicata nel vostro record DMARC e, se l'autenticazione delle email è una novità per voi, iniziate da cos'è DMARC.
Secondo la RFC 7489, la politica si applica solo quando SIA l'allineamento SPF SIA l'allineamento DKIM falliscono entrambi. Se uno dei due riesce e si allinea, il messaggio supera DMARC indipendentemente dalla politica.
none, quarantine, reject
Ogni politica è un passo nel percorso verso l'applicazione. Iniziate dalla visibilità, acquisite fiducia, poi applicate.
p=none Solo monitoraggio Vedi tutto. Non bloccare nulla.
I server di posta riceventi non applicano alcuna misura restrittiva ai messaggi che falliscono DMARC. Inviano comunque i rapporti aggregati al proprietario del dominio, offrendo piena visibilità su ogni fonte che invia email dal dominio.
v=DMARC1; p=none; rua=mailto:dmarc@example.com - Nessun rischio per la consegna delle email legittime
- Piena visibilità su tutte le fonti di invio tramite i rapporti aggregati
- Primo passo indispensabile: bisogna monitorare prima di applicare
- Soddisfa il requisito minimo di Google/Yahoo per i mittenti di massa
- Non offre alcuna protezione contro spoofing o phishing
- Gli aggressori possono comunque inviare email a nome del vostro dominio e queste verranno consegnate
- Non migliora la reputazione del dominio presso i riceventi
Iniziate sempre da qui. Distribuite p=none con la generazione di rapporti rua= e monitorate per almeno 90 giorni. Usate questa fase per identificare ogni mittente legittimo, correggere la configurazione SPF/DKIM e confermare l'allineamento prima di passare all'applicazione.
L'email fallisce l'allineamento SPF + DKIM
Il ricevente verifica la politica DMARC: p=none
L'email viene consegnata normalmente nella casella di posta
Rapporto aggregato inviato al proprietario del dominio
p=quarantine Instrada nello spam La posta sospetta finisce nello spam. La posta legittima continua a circolare.
I messaggi che falliscono DMARC vengono instradati nella cartella spam o posta indesiderata del destinatario. Il messaggio esiste ancora - i destinatari possono trovarlo se lo cercano - ma è chiaramente segnalato come sospetto. È il passo di applicazione che funge da rete di sicurezza.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com - Protezione attiva: i messaggi contraffatti lasciano la casella di posta
- Rete di sicurezza per i mittenti mal configurati (i messaggi non vengono persi)
- Segnala ai riceventi che prendete sul serio la sicurezza delle email
- Buon compromesso durante la transizione verso l'applicazione
- I mittenti legittimi con autenticazione difettosa finiscono nello spam
- I destinatari potrebbero non controllare le cartelle spam, con conseguenti email mancate
- Alcuni riceventi trattano in pratica quarantine come reject
Dopo 90 giorni o più a p=none con tutti i mittenti legittimi identificati e che superano l'autenticazione. Passate qui solo quando i vostri rapporti aggregati mostrano un allineamento SPF/DKIM costante per ogni fonte autorizzata.
L'email fallisce l'allineamento SPF + DKIM
Il ricevente verifica la politica DMARC: p=quarantine
L'email viene instradata nella cartella spam/posta indesiderata
Rapporto aggregato inviato al proprietario del dominio
p=reject Blocca completamente Applicazione totale. La posta contraffatta non arriva mai.
I messaggi che falliscono DMARC vengono rifiutati a livello SMTP - il destinatario non li vede mai e il server di invio riceve un rifiuto (bounce). È la protezione più forte e l'obiettivo finale per ogni dominio.
v=DMARC1; p=reject; rua=mailto:dmarc@example.com - Protezione massima contro lo spoofing del dominio e il phishing
- Gli aggressori non possono consegnare email che impersonano il vostro dominio
- Il segnale di reputazione del dominio più alto presso i server di posta riceventi
- Idoneo per BIMI (Brand Indicators for Message Identification)
- I mittenti legittimi mal configurati vengono bloccati completamente - nemmeno nello spam
- Le catene di inoltro email che rompono l'allineamento falliranno
- Richiede un monitoraggio approfondito prima della distribuzione
Dopo 90 giorni o più a p=quarantine con rapporti aggregati puliti. Tutti i mittenti legittimi devono superare in modo costante l'allineamento SPF o DKIM. Il percorso completo da p=none a p=reject richiede generalmente da 9 a 18 mesi.
L'email fallisce l'allineamento SPF + DKIM
Il ricevente verifica la politica DMARC: p=reject
L'email viene rifiutata a livello SMTP - mai consegnata
Rapporto aggregato inviato al proprietario del dominio
Il cammino verso l'applicazione totale
Ogni dominio segue la stessa progressione. La cronologia dipende dalla complessità - più mittenti ci sono, più tempo serve per la configurazione. Prevedete da 9 a 18 mesi dal primo record al p=reject totale.
p=none Fase 1: Monitorare
90+ giorni minimoPubblicate il record DMARC con p=none e la generazione di rapporti rua=. Analizzate i rapporti aggregati per identificare ogni fonte che invia email dal vostro dominio. Correggete SPF e DKIM per tutti i mittenti legittimi.
p=quarantine Fase 2: Quarantena
90+ giorni minimoPassate a p=quarantine. Iniziate con pct=10 e aumentate gradualmente. Monitorate i rapporti per individuare eventuali mittenti appena colpiti. Correggete i restanti problemi di autenticazione.
p=reject Fase 3: Rifiutare
In continuoPassate a p=reject con la piena certezza che tutte le email legittime superano i controlli. Continuate a monitorare - nuovi mittenti, cambi di IP e aggiornamenti dei fornitori possono rompere l'autenticazione in qualsiasi momento.
Cronologia totale: 9-18 mesi
Le organizzazioni con pochi mittenti possono raggiungere p=reject più rapidamente. Gli ambienti complessi con decine di servizi di terze parti richiedono più tempo. L'essenziale sono le decisioni basate sui dati - non saltate mai le fasi di monitoraggio.
Il tag pct=:
l'applicazione con una rete di sicurezza
Il tag pct= controlla la percentuale di messaggi in errore che riceve l'azione di applicazione. I messaggi al di fuori della percentuale vengono trattati come se la politica fosse p=none. Questo vi permette di distribuire gradualmente l'applicazione monitorando al contempo i problemi.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com Il 25% dei messaggi in errore viene messo in quarantena. Il restante 75% viene consegnato normalmente.
pct=10 Applica l'azione al 10% dei messaggi in errore. Il restante 90% viene trattato come p=none. Ideale per i test iniziali.
2-4 settimanepct=25 Aumentate al 25%. Monitorate i rapporti aggregati per individuare eventuali mittenti legittimi appena colpiti.
2-4 settimanepct=50 Ora la metà dei messaggi in errore riceve l'azione di applicazione. La maggior parte dei problemi emerge in questa fase.
2-4 settimanepct=100 Applicazione totale. Tutti i messaggi che falliscono l'allineamento DMARC ricevono l'azione della politica pubblicata. È il valore predefinito quando pct= non è specificato.
Permanentev=DMARC1; p=reject; sp=quarantine; rua=... Il dominio principale è completamente applicato. I sottodomini sono messi in quarantena durante la loro configurazione.
Il tag sp=: il controllo dei sottodomini
Il tag sp= definisce una politica DMARC distinta per i sottodomini. Senza di esso, i sottodomini ereditano la politica p= del dominio principale. È utile quando il vostro dominio principale è pronto per l'applicazione ma i sottodomini hanno bisogno di più tempo.
- sp=none - i sottodomini sono monitorati durante la loro configurazione
- sp=quarantine - i sottodomini ricevono un'applicazione intermedia
- sp=reject - i sottodomini sono completamente applicati (identico all'assenza di sp= quando p=reject)
- Omettere sp= - i sottodomini ereditano la politica p=
Errori comuni nella politica DMARC
Questi sono gli errori che osserviamo più spesso nelle distribuzioni DMARC. Ognuno di essi può essere evitato con un monitoraggio adeguato e un approccio graduale.
Applicare troppo in fretta
Passare a p=reject senza almeno 90 giorni a p=none provoca il blocco delle email legittime. Le piattaforme di marketing, gli strumenti CRM e i sistemi di ticketing spesso falliscono DMARC se non correttamente configurati.
Nessun monitoraggio dopo l'applicazione
DMARC non è qualcosa da configurare una volta e dimenticare. Nuove fonti di invio, cambi di IP e aggiornamenti dei fornitori possono rompere l'autenticazione in qualsiasi momento. Un monitoraggio continuo individua i problemi prima che influiscano sulla consegna.
Ignorare i mittenti di terze parti
Ogni servizio che invia email per vostro conto - Mailchimp, HubSpot, Salesforce, Zendesk - deve avere gli include SPF o la firma DKIM configurati. Dimenticarne anche solo uno provoca errori al momento dell'applicazione.
Dimenticare i sottodomini
Senza il tag sp=, i sottodomini ereditano la politica del dominio principale. Ma se applicate p=reject senza verificare i mittenti dei sottodomini, rischiate di bloccare email legittime dei sottodomini. Impostate sp= esplicitamente.
Pubblicare senza rua=
Un record DMARC senza la generazione di rapporti rua= equivale a volare alla cieca. Non avete alcuna visibilità sui risultati di autenticazione, nessun modo per rilevare lo spoofing e nessun dato per prendere decisioni di applicazione.
Usare l'allineamento relaxed quando serve strict
L'allineamento relaxed (predefinito) consente a mail.example.com di allinearsi con example.com. Per la maggior parte delle organizzazioni è corretto, ma i domini ad alta sicurezza possono richiedere un allineamento strict per prevenire gli abusi dei sottodomini.
Domande sulla politica DMARC
Qual è la migliore politica DMARC?
La migliore politica DMARC è p=reject, che offre la protezione massima contro lo spoofing del dominio. Tuttavia, dovete raggiungere p=reject con un approccio graduale: iniziate a p=none (monitorate per oltre 90 giorni), passate a p=quarantine (oltre 90 giorni), quindi applicate p=reject. Passare direttamente a reject provoca il blocco delle email legittime.
Per quanto tempo devo restare a p=none prima di applicare?
Restate a p=none per un minimo di 90 giorni - un trimestre completo. Questo vi dà dati sufficienti dai rapporti aggregati per identificare tutte le fonti di invio legittime e correggere la loro autenticazione. Alcune organizzazioni con molti mittenti di terze parti possono aver bisogno di più tempo. Il percorso completo fino a p=reject richiede generalmente da 9 a 18 mesi.
p=quarantine offre una protezione sufficiente?
Quarantine rappresenta un miglioramento significativo rispetto a p=none perché i messaggi contraffatti non raggiungono più la casella di posta. Tuttavia, esistono ancora nella cartella spam. Per una protezione totale, p=reject è l'obiettivo - impedisce del tutto la consegna dei messaggi contraffatti. Alcuni framework di conformità (come PCI DSS v4.0) richiedono specificamente p=reject.
Cosa succede se imposto p=reject e un mittente legittimo fallisce?
L'email del mittente legittimo verrà rifiutata - il destinatario non la riceverà. Ecco perché il monitoraggio a p=none e p=quarantine è essenziale prima dell'applicazione. Usate il tag pct= per distribuire gradualmente l'applicazione (pct=10 per iniziare) in modo da individuare gli errori di configurazione prima che influiscano su tutte le email.
Posso avere politiche diverse per il mio dominio e i sottodomini?
Sì. Il tag sp= (politica dei sottodomini) vi permette di impostare una politica distinta per i sottodomini. Ad esempio, potreste applicare p=reject sul vostro dominio principale mantenendo sp=none sui sottodomini ancora in fase di configurazione. Se sp= non è impostato, i sottodomini ereditano la politica del dominio principale.
Cos'è il tag pct= e come dovrei usarlo?
Il tag pct= controlla la percentuale di messaggi in errore che riceve l'azione di applicazione. A pct=10, solo il 10% dei messaggi in errore viene messo in quarantena o rifiutato - il resto viene trattato come p=none. Aumentate gradualmente da 10 a 25, 50 e poi 100 nell'arco di diverse settimane per passare in tutta sicurezza all'applicazione totale.
Vedi la tua politica DMARC attuale in azione
Prova gratuita - monitora i rapporti aggregati, identifica i mittenti e pianifica il tuo percorso verso l'applicazione.
Inizia la prova gratuitaI team si affidano a DMARC Report per l'applicazione
Rated 4.8/5 on G2 · 469 verified reviews
Zunaid K.
Director
"Essential tool for email delivery"
This tool helps us to implement DMARC reporting for our domains in an easy to use manner.
Verified User in Information Technology and Services
"Best security tool for your own domains"
The weekly reports help me a lot to analyze quickly the emails sent from my domains and that gives me peace of mind.
Larry H.
Research & Development Manager
"Good tool to buy"
I have used many tools for monitoring DMARC reports. But DMARC Report is a good tool to use. It helps avoid sending emails to spam.