--- title: "La politica DMARC spiegata: none vs quarantine vs reject | DMARC Report" description: "La politica DMARC (tag p=) indica ai server di posta riceventi cosa fare dei messaggi che falliscono l" image: "https://dmarcreport.com/images/og-default.png" canonical: "https://dmarcreport.com/it/politica-dmarc/" --- Politiche DMARC # 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](/it/record-dmarc/) e, se l'autenticazione delle email è una novità per voi, iniziate da [cos'è DMARC](/it/che-cos-e-dmarc/). Secondo la [RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489), 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. [ Verifica la tua politica DMARC → ](/it/tools/dmarc-checker/) [Vedi la cronologia](#policy-progression) Le tre politiche ## 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. Esempio di record `v=DMARC1; p=none; rua=mailto:dmarc@example.com` Vantaggi - 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 Limiti - 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 Quando usarla 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. Cosa succede a un'email in errore 1 L'email fallisce l'allineamento SPF + DKIM 2 Il ricevente verifica la politica DMARC: p=none 3 L'email viene consegnata normalmente nella casella di posta 4 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. Esempio di record `v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com` Vantaggi - 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 Limiti - 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 Quando usarla 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. Cosa succede a un'email in errore 1 L'email fallisce l'allineamento SPF + DKIM 2 Il ricevente verifica la politica DMARC: p=quarantine 3 L'email viene instradata nella cartella spam/posta indesiderata 4 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. Esempio di record `v=DMARC1; p=reject; rua=mailto:dmarc@example.com` Vantaggi - 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) Limiti - 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 Quando usarla 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. Cosa succede a un'email in errore 1 L'email fallisce l'allineamento SPF + DKIM 2 Il ricevente verifica la politica DMARC: p=reject 3 L'email viene rifiutata a livello SMTP - mai consegnata 4 Rapporto aggregato inviato al proprietario del dominio Il percorso ## 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 minimo Pubblicate 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 minimo Passate 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 continuo Passate 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. Distribuzione graduale ## 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. Esempio `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 settimane `pct=25` Aumentate al 25%. Monitorate i rapporti aggregati per individuare eventuali mittenti legittimi appena colpiti. 2-4 settimane `pct=50` Ora la metà dei messaggi in errore riceve l'azione di applicazione. La maggior parte dei problemi emerge in questa fase. 2-4 settimane `pct=100` Applicazione totale. Tutti i messaggi che falliscono l'allineamento DMARC ricevono l'azione della politica pubblicata. È il valore predefinito quando pct= non è specificato. Permanente DNS TXT Records \_dmarc.example.com `v=DMARC1; p=reject; sp=quarantine; rua=...` example.com p=reject \*.example.com sp=quarantine Il dominio principale è completamente applicato. I sottodomini sono messi in quarantena durante la loro configurazione. Politica dei sottodomini ## 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= Da evitare ## 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. FAQ ## 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 gratuita](https://app.dmarcreport.com/signup?plan=free) ## I team si affidano a DMARC Report per l'applicazione ![G2 Leader - DMARC](https://media.mailhop.org/dmarcreport/images/g2-badges/DMARC_Leader_Leader.png) Rated 4.8/5 on G2 · 469 verified reviews ![G2 Momentum Leader - DMARC](https://media.mailhop.org/dmarcreport/images/g2-badges/DMARC_MomentumLeader_Leader.png) ZK Zunaid K. Director 5/5 ### "Essential tool for email delivery" This tool helps us to implement DMARC reporting for our domains in an easy to use manner. 8/8/2024Verified on G2 VU Verified User in Information Technology and Services 5/5 ### "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. 8/31/2022Verified on G2 LH Larry H. Research & Development Manager 5/5 ### "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. 8/30/2022Verified on G2 [Read all 469 reviews on G2 →](https://www.g2.com/products/dmarc-report/reviews) ```json {"@context":"https://schema.org","@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138898167","https://www.linkedin.com/company/duocircle","https://x.com/duocirclellc","https://www.g2.com/products/dmarc-report/reviews","https://github.com/duocircle","https://www.crunchbase.com/organization/duocircle-llc","https://www.trustradius.com/products/duocircle/reviews"],"aggregateRating":{"@type":"AggregateRating","ratingValue":"4.8","reviewCount":"471","bestRating":"5","worstRating":"1","url":"https://www.g2.com/products/dmarc-report/reviews"},"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://dmarcreport.com/support/"},"knowsAbout":["DMARC","DMARC Reporting","DMARC Aggregate Reports","DMARC Forensic Reports","Sender Policy Framework","DKIM","Email Authentication","Email Security","DNS Management","Email Deliverability"]} ``` ```json {"@context":"https://schema.org","@type":"WebSite","name":"DMARC Report","url":"https://dmarcreport.com","description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","publisher":{"@type":"Organization","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]}}} ``` ```json [{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Qual è la migliore politica DMARC?","acceptedAnswer":{"@type":"Answer","text":"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."}},{"@type":"Question","name":"Per quanto tempo devo restare a p=none prima di applicare?","acceptedAnswer":{"@type":"Answer","text":"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."}},{"@type":"Question","name":"p=quarantine offre una protezione sufficiente?","acceptedAnswer":{"@type":"Answer","text":"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."}},{"@type":"Question","name":"Cosa succede se imposto p=reject e un mittente legittimo fallisce?","acceptedAnswer":{"@type":"Answer","text":"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."}},{"@type":"Question","name":"Posso avere politiche diverse per il mio dominio e i sottodomini?","acceptedAnswer":{"@type":"Answer","text":"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."}},{"@type":"Question","name":"Cos'è il tag pct= e come dovrei usarlo?","acceptedAnswer":{"@type":"Answer","text":"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."}}]}] ``` ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://dmarcreport.com/"},{"@type":"ListItem","position":2,"name":"Impara","item":"https://dmarcreport.com/it/che-cos-e-dmarc/"},{"@type":"ListItem","position":3,"name":"Politica DMARC","item":"https://dmarcreport.com/it/politica-dmarc/"}]} ```