DMARC: Come Proteggere la Tua Reputazione Email
Uccello
13 apr 2016
1 min read
Punti Chiave
DMARC aiuta a proteggere il tuo dominio da phishing, spoofing e uso non autorizzato delle email pubblicando le tue pratiche di autenticazione e richiedendo un trattamento specifico per i messaggi non riusciti.
Funziona insieme a SPF e DKIM per garantire l'allineamento del dominio e prevenire che le email fraudolente danneggino la tua reputazione di mittente.
Politiche DMARC forti supportano una maggiore fiducia, un maggiore coinvolgimento e garantiscono che il tuo dominio sia a prova di futuro mentre l'ecosistema si sposta verso modelli di reputazione basati sul dominio.
I controlli di convalida DMARC si basano sull'allineamento del dominio tra il dominio From, il dominio Return-Path (SPF) e il dominio di firma DKIM.
Impostare DMARC richiede di ricevere rapporti, comprendere i dati aggregati rispetto ai dati forensi e configurare strumenti per analizzarli.
Inizi con una politica sicura p=none per monitorare il traffico prima di passare a quarantena o rifiuto.
Pubblicare un record DMARC comporta la creazione di un'entrata DNS TXT su _dmarc.yourdomain.com con politiche, indirizzi di reporting e parametri opzionali come l'implementazione percentuale.
Caselle di posta di reporting adeguate (aggregati + forensi) e strumenti di parsing sono essenziali per monitorare la conformità, rilevare spoofing e garantire che l'allineamento sia corretto.
DMARC richiede solo uno dei seguenti per superare il controllo: SPF allineato o DKIM allineato.
Implementare DMARC rafforza la sicurezza delle email e gioca un ruolo chiave nell'integrità del marchio, nella fiducia e nella consegna a lungo termine.
Punti salienti del Q&A
Cos'è il DMARC e perché è importante?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) è una politica pubblicata nel DNS che protegge il tuo dominio da spoofing e phishing, applicando l'allineamento del dominio e abilitando la visibilità tramite reportistica.
DMARC è un protocollo di autenticazione?
No. DMARC non è l'autenticazione stessa: si basa su SPF e DKIM per autenticare la posta e utilizza politiche + report per controllare come i server di ricezione gestiscono i fallimenti.
Cosa controlla il DMARC?
Verifica:
Autenticazione + allineamento SPF
Autenticazione + allineamento DKIM
Un mittente ha bisogno solo di uno di questi per superare e avere successo con DMARC.
Che cos'è il "domain alignment"?
È necessario che il dominio visibile del mittente corrisponda (rigido) o condivida lo stesso dominio organizzativo (rilassato) con il dominio SPF Return-Path o il dominio di firma DKIM.
Perché DMARC migliora la deliverability?
Perché i fornitori di caselle di posta si fidano di domini autenticati e allineati. DMARC previene i messaggi falsificati dall'intaccare la tua reputazione e migliora il posizionamento nella casella di posta per la posta legittima.
Qual è la differenza tra i rapporti DMARC aggregati e forensi?
Rapporti aggregati (RUA): riepiloghi XML dei risultati dell'autenticazione attraverso tutto il traffico.
Rapporti forensi (RUF): campioni individuali di messaggi non riusciti per un'analisi più approfondita.
Quali caselle email devo avere prima di pubblicare il DMARC?
Dovresti creare due indirizzi, come ad esempio:
agg_reports@yourdomain.com (RUA)
afrf_reports@yourdomain.com (RUF)
Questo mantiene i flussi di reporting separati e più facili da analizzare.
Quale politica DMARC dovrei iniziare a utilizzare?
Inizia sempre con p=none. Monitora l'attività di autenticazione senza influenzare la consegna, consentendoti di identificare problemi di allineamento e tentativi di spoofing in modo sicuro.
Quali sono le politiche DMARC disponibili?
nessuno: solo monitorare
quarantena: inviare i messaggi non riusciti allo spam
rifiuta: blocca completamente i messaggi non riusciti
Dove pubblico un record DMARC?
Nel tuo DNS a:
_dmarc.yourdomain.com
Deve essere un record TXT che specifica la tua politica, versione e gli endpoint di reportistica.
Come appare un record DMARC di base?
Esempio:
v=DMARC1; p=none; rua=mailto:agg_reports@yourdomain.com; ruf=mailto:afrf_reports@yourdomain.com; pct=100
Cosa succede se DMARC fallisce?
Il server di ricezione applica la tua politica richiesta (nessuna, quarantena, rifiuta), anche se la gestione finale spetta in ultima analisi al fornitore. Una politica rigorosa può ridurre significativamente i tentativi di phishing che utilizzano il tuo dominio.
In questo post, ti diremo tutto ciò che devi sapere su come sfruttare DMARC per proteggere la tua reputazione email e ti daremo suggerimenti su come configurarlo per i tuoi domini.
In questo post, ti diremo tutto ciò che devi sapere su come sfruttare DMARC per proteggere la tua reputazione email e ti daremo suggerimenti su come configurarlo per i tuoi domini.
In questo post, ti diremo tutto ciò che devi sapere su come sfruttare DMARC per proteggere la tua reputazione email e ti daremo suggerimenti su come configurarlo per i tuoi domini.
Uno strumento efficace per combattere la posta fraudolenta
Spesso menzionato nella stessa frase dei protocolli di autenticazione email SPF e DKIM, DMARC, o Domain-based Message Authentication, Reporting, and Conformance, non è di per sé un protocollo di autenticazione. Invece, lo scopo di DMARC è quello di permetterci, come proprietari di dominio, di proteggere la nostra reputazione email tramite:
Annuncio delle pratiche di autenticazione email,
Richiesta di trattamento per la posta che non supera i controlli di autenticazione, e
Richiesta di report sulla posta che afferma di provenire dal suo dominio.
DMARC può essere uno strumento efficace da utilizzare nella nostra lotta contro la posta fraudolenta che prende di mira il nostro nome di dominio (ad es., phishing e spoofing), e che può promuovere una maggiore fiducia tra i nostri destinatari per la nostra posta. Per le organizzazioni che richiedono crittografia end-to-end oltre all'autenticazione, implementare S/MIME con metodi efficienti di raccolta di chiavi pubbliche dei destinatari fornisce ulteriori strati di sicurezza. Questa maggiore fiducia dovrebbe, a sua volta, portare a un maggiore coinvolgimento con la nostra posta, e la posta che viene aperta e genera clic alimenta le vendite e un ROI più elevato per le nostre campagne email.
Oltre a proteggere il nostro dominio, prevediamo che implementare DMARC ora sarà un ottimo modo per “futuro-proteggere” il nostro dominio. Qui da Bird, crediamo che, man mano che il settore si sposta verso IPv6, sia quasi certo che passerà da un modello di reputazione basato su IP a un modello di reputazione basato su dominio. La reputazione basata su dominio richiederà autenticazione basata su dominio, e DMARC, insieme a DKIM e SPF, aiuterà i domini a stabilire una reputazione basata su dominio molto prima che possa diventare assolutamente necessaria.
In questo post, ti diremo tutto ciò che devi sapere su come sfruttare DMARC per proteggere la tua reputazione email e ti daremo indicazioni su come configurarlo per i tuoi domini.
Spesso menzionato nella stessa frase dei protocolli di autenticazione email SPF e DKIM, DMARC, o Domain-based Message Authentication, Reporting, and Conformance, non è di per sé un protocollo di autenticazione. Invece, lo scopo di DMARC è quello di permetterci, come proprietari di dominio, di proteggere la nostra reputazione email tramite:
Annuncio delle pratiche di autenticazione email,
Richiesta di trattamento per la posta che non supera i controlli di autenticazione, e
Richiesta di report sulla posta che afferma di provenire dal suo dominio.
DMARC può essere uno strumento efficace da utilizzare nella nostra lotta contro la posta fraudolenta che prende di mira il nostro nome di dominio (ad es., phishing e spoofing), e che può promuovere una maggiore fiducia tra i nostri destinatari per la nostra posta. Per le organizzazioni che richiedono crittografia end-to-end oltre all'autenticazione, implementare S/MIME con metodi efficienti di raccolta di chiavi pubbliche dei destinatari fornisce ulteriori strati di sicurezza. Questa maggiore fiducia dovrebbe, a sua volta, portare a un maggiore coinvolgimento con la nostra posta, e la posta che viene aperta e genera clic alimenta le vendite e un ROI più elevato per le nostre campagne email.
Oltre a proteggere il nostro dominio, prevediamo che implementare DMARC ora sarà un ottimo modo per “futuro-proteggere” il nostro dominio. Qui da Bird, crediamo che, man mano che il settore si sposta verso IPv6, sia quasi certo che passerà da un modello di reputazione basato su IP a un modello di reputazione basato su dominio. La reputazione basata su dominio richiederà autenticazione basata su dominio, e DMARC, insieme a DKIM e SPF, aiuterà i domini a stabilire una reputazione basata su dominio molto prima che possa diventare assolutamente necessaria.
In questo post, ti diremo tutto ciò che devi sapere su come sfruttare DMARC per proteggere la tua reputazione email e ti daremo indicazioni su come configurarlo per i tuoi domini.
Spesso menzionato nella stessa frase dei protocolli di autenticazione email SPF e DKIM, DMARC, o Domain-based Message Authentication, Reporting, and Conformance, non è di per sé un protocollo di autenticazione. Invece, lo scopo di DMARC è quello di permetterci, come proprietari di dominio, di proteggere la nostra reputazione email tramite:
Annuncio delle pratiche di autenticazione email,
Richiesta di trattamento per la posta che non supera i controlli di autenticazione, e
Richiesta di report sulla posta che afferma di provenire dal suo dominio.
DMARC può essere uno strumento efficace da utilizzare nella nostra lotta contro la posta fraudolenta che prende di mira il nostro nome di dominio (ad es., phishing e spoofing), e che può promuovere una maggiore fiducia tra i nostri destinatari per la nostra posta. Per le organizzazioni che richiedono crittografia end-to-end oltre all'autenticazione, implementare S/MIME con metodi efficienti di raccolta di chiavi pubbliche dei destinatari fornisce ulteriori strati di sicurezza. Questa maggiore fiducia dovrebbe, a sua volta, portare a un maggiore coinvolgimento con la nostra posta, e la posta che viene aperta e genera clic alimenta le vendite e un ROI più elevato per le nostre campagne email.
Oltre a proteggere il nostro dominio, prevediamo che implementare DMARC ora sarà un ottimo modo per “futuro-proteggere” il nostro dominio. Qui da Bird, crediamo che, man mano che il settore si sposta verso IPv6, sia quasi certo che passerà da un modello di reputazione basato su IP a un modello di reputazione basato su dominio. La reputazione basata su dominio richiederà autenticazione basata su dominio, e DMARC, insieme a DKIM e SPF, aiuterà i domini a stabilire una reputazione basata su dominio molto prima che possa diventare assolutamente necessaria.
In questo post, ti diremo tutto ciò che devi sapere su come sfruttare DMARC per proteggere la tua reputazione email e ti daremo indicazioni su come configurarlo per i tuoi domini.
Termini da Conoscere
Prima di iniziare a configurare DMARC per il tuo dominio, vogliamo assicurarci che stiamo parlando la stessa lingua. Iniziamo definendo alcuni termini che utilizzeremo nel resto di questo documento.
Dominio RFC5322.From
Il dominio RFC5322.From è la parte di dominio dell'indirizzo email che di solito è vista da un destinatario della nostra email quando viene letta. Nell'esempio seguente, il dominio RFC5322.From è “joesbaitshop.com”
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
Dominio DKIM d=
DKIM è un protocollo di autenticazione che consente a un dominio di assumere la responsabilità di un messaggio in un modo che può essere convalidato dal ricevitore del messaggio; questo viene fatto attraverso l'uso di firme crittografiche inserite negli header del messaggio mentre esce dal punto di origine. Queste firme sono praticamente istantanee di come appariva il messaggio in quel momento, e il ricevitore può utilizzare queste istantanee per vedere se il messaggio è arrivato invariato a destinazione. Il processo di produzione e inserimento di queste istantanee è chiamato firma DKIM, e il dominio che si assume la responsabilità per il messaggio firmandolo inserisce il proprio nome nell'intestazione in un tag chiave-valore come “d=signingDomain”, ed è quindi chiamato dominio DKIM d=.
Dominio Return-Path
Il dominio Return-Path, talvolta chiamato dominio RFC5321.From o dominio Mail From, è il dominio a cui vengono instradati i rimbalzi; è anche il dominio su cui vengono eseguite le verifiche SPF durante la transazione email. Questo dominio non è di solito visto dal destinatario, a meno che il destinatario non sia abbastanza esperto da guardare tutti gli header in un dato messaggio.
Per impostazione predefinita, tutta la posta inviata tramite bird.com avrà birdmail.com come suo dominio Return-Path, come nell'esempio seguente:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Tuttavia, per far funzionare DMARC per il tuo dominio, vorrai approfittare di un dominio di rimbalzo personalizzato, uno che terminerà nello stesso dominio del tuo dominio di invio, ad esempio, bounces.yourdomain.com quando utilizzi yourdomain.com come tuo dominio di invio.
Dominio Organizzativo
Il termine “Dominio Organizzativo” si riferisce al dominio che è stato inviato a un registrar per creare la presenza del dominio su internet. Per Bird, i nostri domini organizzativi sono bird.com e birdmail.com.
Allineamento del Dominio
Il termine finale da comprendere riguardo DMARC è “Allineamento del Dominio”, e si presenta in due varianti: “rilassato” e “rigido”.
Allineamento del Dominio Rilassato
Due domini si dicono avere un allineamento del dominio rilassato quando i loro Domini Organizzativi sono gli stessi. Ad esempio, a.mail.bird.com e b.foo.bird.com hanno un allineamento del dominio rilassato a causa del loro comune Dominio Organizzativo, bird.com.
Allineamento del Dominio Rigido
Due domini si dicono in allineamento del dominio rigido se e solo se sono identici. Quindi, foo.bird.com e foo.bird.com sono in allineamento rigido, poiché i due domini sono identici. D'altra parte, foo.bird.com e bar.foo.bird.com sono solo in allineamento rilassato.
Requisiti per l'Allineamento del Dominio DMARC
Per far passare i controlli di convalida DMARC, DMARC richiede che ci sia un allineamento del dominio come segue:
Per SPF, il dominio RFC5322.From e il dominio Return-Path devono essere in allineamento
Per DKIM, il dominio RFC5322.From e il dominio DKIM d= devono essere in allineamento
L'allineamento può essere rilassato o rigido, in base alla politica pubblicata del dominio di invio.
Prima di iniziare a configurare DMARC per il tuo dominio, vogliamo assicurarci che stiamo parlando la stessa lingua. Iniziamo definendo alcuni termini che utilizzeremo nel resto di questo documento.
Dominio RFC5322.From
Il dominio RFC5322.From è la parte di dominio dell'indirizzo email che di solito è vista da un destinatario della nostra email quando viene letta. Nell'esempio seguente, il dominio RFC5322.From è “joesbaitshop.com”
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
Dominio DKIM d=
DKIM è un protocollo di autenticazione che consente a un dominio di assumere la responsabilità di un messaggio in un modo che può essere convalidato dal ricevitore del messaggio; questo viene fatto attraverso l'uso di firme crittografiche inserite negli header del messaggio mentre esce dal punto di origine. Queste firme sono praticamente istantanee di come appariva il messaggio in quel momento, e il ricevitore può utilizzare queste istantanee per vedere se il messaggio è arrivato invariato a destinazione. Il processo di produzione e inserimento di queste istantanee è chiamato firma DKIM, e il dominio che si assume la responsabilità per il messaggio firmandolo inserisce il proprio nome nell'intestazione in un tag chiave-valore come “d=signingDomain”, ed è quindi chiamato dominio DKIM d=.
Dominio Return-Path
Il dominio Return-Path, talvolta chiamato dominio RFC5321.From o dominio Mail From, è il dominio a cui vengono instradati i rimbalzi; è anche il dominio su cui vengono eseguite le verifiche SPF durante la transazione email. Questo dominio non è di solito visto dal destinatario, a meno che il destinatario non sia abbastanza esperto da guardare tutti gli header in un dato messaggio.
Per impostazione predefinita, tutta la posta inviata tramite bird.com avrà birdmail.com come suo dominio Return-Path, come nell'esempio seguente:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Tuttavia, per far funzionare DMARC per il tuo dominio, vorrai approfittare di un dominio di rimbalzo personalizzato, uno che terminerà nello stesso dominio del tuo dominio di invio, ad esempio, bounces.yourdomain.com quando utilizzi yourdomain.com come tuo dominio di invio.
Dominio Organizzativo
Il termine “Dominio Organizzativo” si riferisce al dominio che è stato inviato a un registrar per creare la presenza del dominio su internet. Per Bird, i nostri domini organizzativi sono bird.com e birdmail.com.
Allineamento del Dominio
Il termine finale da comprendere riguardo DMARC è “Allineamento del Dominio”, e si presenta in due varianti: “rilassato” e “rigido”.
Allineamento del Dominio Rilassato
Due domini si dicono avere un allineamento del dominio rilassato quando i loro Domini Organizzativi sono gli stessi. Ad esempio, a.mail.bird.com e b.foo.bird.com hanno un allineamento del dominio rilassato a causa del loro comune Dominio Organizzativo, bird.com.
Allineamento del Dominio Rigido
Due domini si dicono in allineamento del dominio rigido se e solo se sono identici. Quindi, foo.bird.com e foo.bird.com sono in allineamento rigido, poiché i due domini sono identici. D'altra parte, foo.bird.com e bar.foo.bird.com sono solo in allineamento rilassato.
Requisiti per l'Allineamento del Dominio DMARC
Per far passare i controlli di convalida DMARC, DMARC richiede che ci sia un allineamento del dominio come segue:
Per SPF, il dominio RFC5322.From e il dominio Return-Path devono essere in allineamento
Per DKIM, il dominio RFC5322.From e il dominio DKIM d= devono essere in allineamento
L'allineamento può essere rilassato o rigido, in base alla politica pubblicata del dominio di invio.
Prima di iniziare a configurare DMARC per il tuo dominio, vogliamo assicurarci che stiamo parlando la stessa lingua. Iniziamo definendo alcuni termini che utilizzeremo nel resto di questo documento.
Dominio RFC5322.From
Il dominio RFC5322.From è la parte di dominio dell'indirizzo email che di solito è vista da un destinatario della nostra email quando viene letta. Nell'esempio seguente, il dominio RFC5322.From è “joesbaitshop.com”
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
Dominio DKIM d=
DKIM è un protocollo di autenticazione che consente a un dominio di assumere la responsabilità di un messaggio in un modo che può essere convalidato dal ricevitore del messaggio; questo viene fatto attraverso l'uso di firme crittografiche inserite negli header del messaggio mentre esce dal punto di origine. Queste firme sono praticamente istantanee di come appariva il messaggio in quel momento, e il ricevitore può utilizzare queste istantanee per vedere se il messaggio è arrivato invariato a destinazione. Il processo di produzione e inserimento di queste istantanee è chiamato firma DKIM, e il dominio che si assume la responsabilità per il messaggio firmandolo inserisce il proprio nome nell'intestazione in un tag chiave-valore come “d=signingDomain”, ed è quindi chiamato dominio DKIM d=.
Dominio Return-Path
Il dominio Return-Path, talvolta chiamato dominio RFC5321.From o dominio Mail From, è il dominio a cui vengono instradati i rimbalzi; è anche il dominio su cui vengono eseguite le verifiche SPF durante la transazione email. Questo dominio non è di solito visto dal destinatario, a meno che il destinatario non sia abbastanza esperto da guardare tutti gli header in un dato messaggio.
Per impostazione predefinita, tutta la posta inviata tramite bird.com avrà birdmail.com come suo dominio Return-Path, come nell'esempio seguente:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Tuttavia, per far funzionare DMARC per il tuo dominio, vorrai approfittare di un dominio di rimbalzo personalizzato, uno che terminerà nello stesso dominio del tuo dominio di invio, ad esempio, bounces.yourdomain.com quando utilizzi yourdomain.com come tuo dominio di invio.
Dominio Organizzativo
Il termine “Dominio Organizzativo” si riferisce al dominio che è stato inviato a un registrar per creare la presenza del dominio su internet. Per Bird, i nostri domini organizzativi sono bird.com e birdmail.com.
Allineamento del Dominio
Il termine finale da comprendere riguardo DMARC è “Allineamento del Dominio”, e si presenta in due varianti: “rilassato” e “rigido”.
Allineamento del Dominio Rilassato
Due domini si dicono avere un allineamento del dominio rilassato quando i loro Domini Organizzativi sono gli stessi. Ad esempio, a.mail.bird.com e b.foo.bird.com hanno un allineamento del dominio rilassato a causa del loro comune Dominio Organizzativo, bird.com.
Allineamento del Dominio Rigido
Due domini si dicono in allineamento del dominio rigido se e solo se sono identici. Quindi, foo.bird.com e foo.bird.com sono in allineamento rigido, poiché i due domini sono identici. D'altra parte, foo.bird.com e bar.foo.bird.com sono solo in allineamento rilassato.
Requisiti per l'Allineamento del Dominio DMARC
Per far passare i controlli di convalida DMARC, DMARC richiede che ci sia un allineamento del dominio come segue:
Per SPF, il dominio RFC5322.From e il dominio Return-Path devono essere in allineamento
Per DKIM, il dominio RFC5322.From e il dominio DKIM d= devono essere in allineamento
L'allineamento può essere rilassato o rigido, in base alla politica pubblicata del dominio di invio.
Come funziona DMARC per proteggere la tua reputazione email
Quando parliamo di un fornitore di caselle di posta o di un altro dominio che "controlla DMARC", o "convalida DMARC", o "applica la politica DMARC", ciò che intendiamo è che il dominio che riceve un messaggio sta eseguendo i seguenti passaggi:
Stabilire il dominio RFC5322.From del messaggio
Controllare la politica DMARC di quel dominio in DNS
Eseguire la convalida della firma DKIM
Eseguire la convalida SPF
Controllare l'allineamento del dominio
Applicare la politica DMARC
Affinché un messaggio superi la convalida DMARC, il messaggio deve superare solo uno dei due controlli di autenticazione e allineamento. Quindi, un messaggio supererà la convalida DMARC se uno dei seguenti è vero:
Il messaggio supera i controlli SPF e il dominio RFC5322.From e il dominio del Return-Path sono allineati, oppure
Il messaggio supera la convalida DKIM e il dominio RFC5322.From e il dominio d= DKIM sono allineati, oppure
Entrambi i precedenti sono veri
Panoramica dei percorsi di convalida DMARC
Percorso di autenticazione | Domini confrontati | Allineamento richiesto | Condizione di superamento DMARC |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Flessibile o rigido | SPF supera e i domini si allineano |
DKIM | RFC5322.From ↔ DKIM d= | Flessibile o rigido | DKIM supera e i domini si allineano |
SPF + DKIM | Entrambi i precedenti | Entrambi allineati | Uno o entrambi i controlli di allineamento passano |
Quando parliamo di un fornitore di caselle di posta o di un altro dominio che "controlla DMARC", o "convalida DMARC", o "applica la politica DMARC", ciò che intendiamo è che il dominio che riceve un messaggio sta eseguendo i seguenti passaggi:
Stabilire il dominio RFC5322.From del messaggio
Controllare la politica DMARC di quel dominio in DNS
Eseguire la convalida della firma DKIM
Eseguire la convalida SPF
Controllare l'allineamento del dominio
Applicare la politica DMARC
Affinché un messaggio superi la convalida DMARC, il messaggio deve superare solo uno dei due controlli di autenticazione e allineamento. Quindi, un messaggio supererà la convalida DMARC se uno dei seguenti è vero:
Il messaggio supera i controlli SPF e il dominio RFC5322.From e il dominio del Return-Path sono allineati, oppure
Il messaggio supera la convalida DKIM e il dominio RFC5322.From e il dominio d= DKIM sono allineati, oppure
Entrambi i precedenti sono veri
Panoramica dei percorsi di convalida DMARC
Percorso di autenticazione | Domini confrontati | Allineamento richiesto | Condizione di superamento DMARC |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Flessibile o rigido | SPF supera e i domini si allineano |
DKIM | RFC5322.From ↔ DKIM d= | Flessibile o rigido | DKIM supera e i domini si allineano |
SPF + DKIM | Entrambi i precedenti | Entrambi allineati | Uno o entrambi i controlli di allineamento passano |
Quando parliamo di un fornitore di caselle di posta o di un altro dominio che "controlla DMARC", o "convalida DMARC", o "applica la politica DMARC", ciò che intendiamo è che il dominio che riceve un messaggio sta eseguendo i seguenti passaggi:
Stabilire il dominio RFC5322.From del messaggio
Controllare la politica DMARC di quel dominio in DNS
Eseguire la convalida della firma DKIM
Eseguire la convalida SPF
Controllare l'allineamento del dominio
Applicare la politica DMARC
Affinché un messaggio superi la convalida DMARC, il messaggio deve superare solo uno dei due controlli di autenticazione e allineamento. Quindi, un messaggio supererà la convalida DMARC se uno dei seguenti è vero:
Il messaggio supera i controlli SPF e il dominio RFC5322.From e il dominio del Return-Path sono allineati, oppure
Il messaggio supera la convalida DKIM e il dominio RFC5322.From e il dominio d= DKIM sono allineati, oppure
Entrambi i precedenti sono veri
Panoramica dei percorsi di convalida DMARC
Percorso di autenticazione | Domini confrontati | Allineamento richiesto | Condizione di superamento DMARC |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Flessibile o rigido | SPF supera e i domini si allineano |
DKIM | RFC5322.From ↔ DKIM d= | Flessibile o rigido | DKIM supera e i domini si allineano |
SPF + DKIM | Entrambi i precedenti | Entrambi allineati | Uno o entrambi i controlli di allineamento passano |
Far funzionare DMARC per il tuo dominio
Ora che abbiamo spiegato il funzionamento del DMARC, parliamo di come far funzionare il DMARC per noi, il che comporta i seguenti tre passaggi:
Prepararsi a ricevere report DMARC
Decidere quale politica DMARC utilizzare per il proprio dominio
Pubblicare il proprio record DMARC
Tratteremo ciascuno di questi in dettaglio di seguito, ma ti diciamo subito che il passaggio 1 sopra consumerà circa il 95% del tuo tempo di preparazione.
Ora che abbiamo spiegato il funzionamento del DMARC, parliamo di come far funzionare il DMARC per noi, il che comporta i seguenti tre passaggi:
Prepararsi a ricevere report DMARC
Decidere quale politica DMARC utilizzare per il proprio dominio
Pubblicare il proprio record DMARC
Tratteremo ciascuno di questi in dettaglio di seguito, ma ti diciamo subito che il passaggio 1 sopra consumerà circa il 95% del tuo tempo di preparazione.
Ora che abbiamo spiegato il funzionamento del DMARC, parliamo di come far funzionare il DMARC per noi, il che comporta i seguenti tre passaggi:
Prepararsi a ricevere report DMARC
Decidere quale politica DMARC utilizzare per il proprio dominio
Pubblicare il proprio record DMARC
Tratteremo ciascuno di questi in dettaglio di seguito, ma ti diciamo subito che il passaggio 1 sopra consumerà circa il 95% del tuo tempo di preparazione.
Preparazione per ricevere i rapporti DMARC
Qualsiasi dominio che pubblica una politica DMARC dovrebbe prima prepararsi a ricevere rapporti riguardanti il proprio dominio. Questi rapporti saranno generati da qualsiasi dominio che effettua la convalida DMARC e vede email che affermano di provenire dal nostro dominio, e ci saranno inviati con una frequenza minima giornaliera. I rapporti arriveranno in due formati:
Rapporti aggregati, che sono documenti XML che mostrano dati statistici su quanta posta è stata vista dal reporter da ciascuna sorgente, quali sono stati i risultati di autenticazione e come i messaggi sono stati trattati dal reporter. I rapporti aggregati sono progettati per essere elaborati automaticamente, con i loro dati memorizzati da qualche parte per consentire un'analisi del traffico globale, un'audit dei flussi di messaggi del nostro dominio e forse un'identificazione di tendenze nelle fonti di email non autenticate, potenzialmente fraudolente.
Rapporti forensi, che sono copie individuali di messaggi che non hanno superato l'autenticazione, ciascuna racchiusa in un messaggio completo via email utilizzando un formato chiamato AFRF. I rapporti forensi dovrebbero contenere intestazioni complete e corpi dei messaggi, ma molti reporter rimuovono o redigono alcune informazioni a causa di preoccupazioni sulla privacy. Tuttavia, il rapporto forense può comunque essere utile sia per risolvere i problemi di autenticazione del nostro dominio sia per identificare, dai URI nei corpi dei messaggi, domini e siti web dannosi utilizzati per frodare i clienti del proprietario del nostro dominio.
La preparazione per ricevere questi rapporti comporta prima la creazione di due caselle di posta nel nostro dominio per gestire questi rapporti, come agg_reports@ourdomain.com e afrf_reports@ourdomain.com. Si prega di notare che quei nomi di casella di posta sono completamente arbitrari, e non ci sono requisiti per la denominazione della parte locale della casella di posta; siamo liberi di scegliere qualsiasi nome desideriamo, ma tenere i due separati per facilitare l'elaborazione.
Una volta scelti e creati i nomi delle caselle di posta nel nostro dominio, la prossima cosa da fare è mettere in atto strumenti per leggere queste caselle di posta e utilizzare i dati, specialmente i rapporti sui dati aggregati, che ancora devono essere progettati per essere elaborati automaticamente, piuttosto che letti da un umano. I rapporti forensi, d'altra parte, potrebbero essere gestibili semplicemente leggendoli noi stessi, ma la nostra capacità di farlo dipenderà sia dalla comprensione del nostro client di posta su come visualizzare i messaggi nel formato AFRF sia sul volume di rapporti che riceviamo.
Seppur sia possibile scrivere i propri strumenti per elaborare i rapporti DMARC, fino a quando Bird non fornisce tali servizi per i clienti di bird.com (qualcosa che stiamo considerando, ma non promettendo ancora), raccomandiamo di utilizzare strumenti già disponibili per il compito.
Qualsiasi dominio che pubblica una politica DMARC dovrebbe prima prepararsi a ricevere rapporti riguardanti il proprio dominio. Questi rapporti saranno generati da qualsiasi dominio che effettua la convalida DMARC e vede email che affermano di provenire dal nostro dominio, e ci saranno inviati con una frequenza minima giornaliera. I rapporti arriveranno in due formati:
Rapporti aggregati, che sono documenti XML che mostrano dati statistici su quanta posta è stata vista dal reporter da ciascuna sorgente, quali sono stati i risultati di autenticazione e come i messaggi sono stati trattati dal reporter. I rapporti aggregati sono progettati per essere elaborati automaticamente, con i loro dati memorizzati da qualche parte per consentire un'analisi del traffico globale, un'audit dei flussi di messaggi del nostro dominio e forse un'identificazione di tendenze nelle fonti di email non autenticate, potenzialmente fraudolente.
Rapporti forensi, che sono copie individuali di messaggi che non hanno superato l'autenticazione, ciascuna racchiusa in un messaggio completo via email utilizzando un formato chiamato AFRF. I rapporti forensi dovrebbero contenere intestazioni complete e corpi dei messaggi, ma molti reporter rimuovono o redigono alcune informazioni a causa di preoccupazioni sulla privacy. Tuttavia, il rapporto forense può comunque essere utile sia per risolvere i problemi di autenticazione del nostro dominio sia per identificare, dai URI nei corpi dei messaggi, domini e siti web dannosi utilizzati per frodare i clienti del proprietario del nostro dominio.
La preparazione per ricevere questi rapporti comporta prima la creazione di due caselle di posta nel nostro dominio per gestire questi rapporti, come agg_reports@ourdomain.com e afrf_reports@ourdomain.com. Si prega di notare che quei nomi di casella di posta sono completamente arbitrari, e non ci sono requisiti per la denominazione della parte locale della casella di posta; siamo liberi di scegliere qualsiasi nome desideriamo, ma tenere i due separati per facilitare l'elaborazione.
Una volta scelti e creati i nomi delle caselle di posta nel nostro dominio, la prossima cosa da fare è mettere in atto strumenti per leggere queste caselle di posta e utilizzare i dati, specialmente i rapporti sui dati aggregati, che ancora devono essere progettati per essere elaborati automaticamente, piuttosto che letti da un umano. I rapporti forensi, d'altra parte, potrebbero essere gestibili semplicemente leggendoli noi stessi, ma la nostra capacità di farlo dipenderà sia dalla comprensione del nostro client di posta su come visualizzare i messaggi nel formato AFRF sia sul volume di rapporti che riceviamo.
Seppur sia possibile scrivere i propri strumenti per elaborare i rapporti DMARC, fino a quando Bird non fornisce tali servizi per i clienti di bird.com (qualcosa che stiamo considerando, ma non promettendo ancora), raccomandiamo di utilizzare strumenti già disponibili per il compito.
Qualsiasi dominio che pubblica una politica DMARC dovrebbe prima prepararsi a ricevere rapporti riguardanti il proprio dominio. Questi rapporti saranno generati da qualsiasi dominio che effettua la convalida DMARC e vede email che affermano di provenire dal nostro dominio, e ci saranno inviati con una frequenza minima giornaliera. I rapporti arriveranno in due formati:
Rapporti aggregati, che sono documenti XML che mostrano dati statistici su quanta posta è stata vista dal reporter da ciascuna sorgente, quali sono stati i risultati di autenticazione e come i messaggi sono stati trattati dal reporter. I rapporti aggregati sono progettati per essere elaborati automaticamente, con i loro dati memorizzati da qualche parte per consentire un'analisi del traffico globale, un'audit dei flussi di messaggi del nostro dominio e forse un'identificazione di tendenze nelle fonti di email non autenticate, potenzialmente fraudolente.
Rapporti forensi, che sono copie individuali di messaggi che non hanno superato l'autenticazione, ciascuna racchiusa in un messaggio completo via email utilizzando un formato chiamato AFRF. I rapporti forensi dovrebbero contenere intestazioni complete e corpi dei messaggi, ma molti reporter rimuovono o redigono alcune informazioni a causa di preoccupazioni sulla privacy. Tuttavia, il rapporto forense può comunque essere utile sia per risolvere i problemi di autenticazione del nostro dominio sia per identificare, dai URI nei corpi dei messaggi, domini e siti web dannosi utilizzati per frodare i clienti del proprietario del nostro dominio.
La preparazione per ricevere questi rapporti comporta prima la creazione di due caselle di posta nel nostro dominio per gestire questi rapporti, come agg_reports@ourdomain.com e afrf_reports@ourdomain.com. Si prega di notare che quei nomi di casella di posta sono completamente arbitrari, e non ci sono requisiti per la denominazione della parte locale della casella di posta; siamo liberi di scegliere qualsiasi nome desideriamo, ma tenere i due separati per facilitare l'elaborazione.
Una volta scelti e creati i nomi delle caselle di posta nel nostro dominio, la prossima cosa da fare è mettere in atto strumenti per leggere queste caselle di posta e utilizzare i dati, specialmente i rapporti sui dati aggregati, che ancora devono essere progettati per essere elaborati automaticamente, piuttosto che letti da un umano. I rapporti forensi, d'altra parte, potrebbero essere gestibili semplicemente leggendoli noi stessi, ma la nostra capacità di farlo dipenderà sia dalla comprensione del nostro client di posta su come visualizzare i messaggi nel formato AFRF sia sul volume di rapporti che riceviamo.
Seppur sia possibile scrivere i propri strumenti per elaborare i rapporti DMARC, fino a quando Bird non fornisce tali servizi per i clienti di bird.com (qualcosa che stiamo considerando, ma non promettendo ancora), raccomandiamo di utilizzare strumenti già disponibili per il compito.
Quale politica DMARC utilizzare
La specifica DMARC fornisce tre opzioni per i proprietari di dominio per specificare il loro trattamento preferito della posta che non supera i controlli di validazione DMARC. Esse sono:
nessuno, ovvero trattare la posta come verrebbe trattata indipendentemente dai controlli di validazione DMARC
quarantena, ovvero accettare la posta ma posizionarla in un luogo diverso dalla Posta in arrivo del destinatario (tipicamente la cartella spam)
rifiuta, ovvero rifiutare il messaggio outright
È importante tenere a mente che il proprietario del dominio può solo richiedere tale trattamento nel suo record DMARC; spetta al destinatario del messaggio decidere se onorare o meno la politica richiesta. Alcuni lo faranno, mentre altri potrebbero essere un po' più permissivi nell'applicazione della politica, come ad esempio posizionare la posta nella cartella spam solo quando la politica del dominio è rifiuta.
Consigliamo a tutti i nostri clienti di avviare con una politica di nessuno, semplicemente per essere sicuri. Anche se siamo fiduciosi nella nostra capacità di autenticare correttamente la tua posta tramite firma DKIM, è comunque meglio prendersi del tempo per esaminare i rapporti sul tuo dominio prima di adottare una politica DMARC più aggressiva.
La specifica DMARC fornisce tre opzioni per i proprietari di dominio per specificare il loro trattamento preferito della posta che non supera i controlli di validazione DMARC. Esse sono:
nessuno, ovvero trattare la posta come verrebbe trattata indipendentemente dai controlli di validazione DMARC
quarantena, ovvero accettare la posta ma posizionarla in un luogo diverso dalla Posta in arrivo del destinatario (tipicamente la cartella spam)
rifiuta, ovvero rifiutare il messaggio outright
È importante tenere a mente che il proprietario del dominio può solo richiedere tale trattamento nel suo record DMARC; spetta al destinatario del messaggio decidere se onorare o meno la politica richiesta. Alcuni lo faranno, mentre altri potrebbero essere un po' più permissivi nell'applicazione della politica, come ad esempio posizionare la posta nella cartella spam solo quando la politica del dominio è rifiuta.
Consigliamo a tutti i nostri clienti di avviare con una politica di nessuno, semplicemente per essere sicuri. Anche se siamo fiduciosi nella nostra capacità di autenticare correttamente la tua posta tramite firma DKIM, è comunque meglio prendersi del tempo per esaminare i rapporti sul tuo dominio prima di adottare una politica DMARC più aggressiva.
La specifica DMARC fornisce tre opzioni per i proprietari di dominio per specificare il loro trattamento preferito della posta che non supera i controlli di validazione DMARC. Esse sono:
nessuno, ovvero trattare la posta come verrebbe trattata indipendentemente dai controlli di validazione DMARC
quarantena, ovvero accettare la posta ma posizionarla in un luogo diverso dalla Posta in arrivo del destinatario (tipicamente la cartella spam)
rifiuta, ovvero rifiutare il messaggio outright
È importante tenere a mente che il proprietario del dominio può solo richiedere tale trattamento nel suo record DMARC; spetta al destinatario del messaggio decidere se onorare o meno la politica richiesta. Alcuni lo faranno, mentre altri potrebbero essere un po' più permissivi nell'applicazione della politica, come ad esempio posizionare la posta nella cartella spam solo quando la politica del dominio è rifiuta.
Consigliamo a tutti i nostri clienti di avviare con una politica di nessuno, semplicemente per essere sicuri. Anche se siamo fiduciosi nella nostra capacità di autenticare correttamente la tua posta tramite firma DKIM, è comunque meglio prendersi del tempo per esaminare i rapporti sul tuo dominio prima di adottare una politica DMARC più aggressiva.
Pubblicare la tua politica DMARC
La politica DMARC di un dominio viene annunciata pubblicando un record DNS TXT in un luogo specifico dello spazio dei nomi DNS, vale a dire “_dmarc.nomeDominio.tld” (nota il trattino basso all'inizio). Un record di politica DMARC di base per il nostro esempio di dominio precedente, joesbaitshop.com, potrebbe apparire simile a questo:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Analizzando questo record, abbiamo:
v=DMARC1 specifica la versione DMARC (1 è l'unica opzione attualmente)
p=none specifica il trattamento preferito, o la politica DMARC
rua=mailto:agg_reports@joesbait.com è la casella di posta a cui devono essere inviati i rapporti aggregati
ruf=mailto:afrf_reports@joesbait.com è la casella di posta a cui devono essere inviati i rapporti forensi
pct=100 è la percentuale di posta a cui il proprietario del dominio desidera che venga applicata la sua politica. I domini che stanno iniziando con DMARC, specialmente quelli che probabilmente genereranno un elevato volume di rapporti, potrebbero voler iniziare con un numero molto più basso qui per vedere come i loro processi di gestione dei rapporti reggono il carico.
Ci sono altre opzioni di configurazione disponibili per un proprietario di dominio da utilizzare nel proprio record di politica DMARC, ma i suggerimenti forniti dovrebbero essere un buon punto di partenza.
La politica DMARC di un dominio viene annunciata pubblicando un record DNS TXT in un luogo specifico dello spazio dei nomi DNS, vale a dire “_dmarc.nomeDominio.tld” (nota il trattino basso all'inizio). Un record di politica DMARC di base per il nostro esempio di dominio precedente, joesbaitshop.com, potrebbe apparire simile a questo:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Analizzando questo record, abbiamo:
v=DMARC1 specifica la versione DMARC (1 è l'unica opzione attualmente)
p=none specifica il trattamento preferito, o la politica DMARC
rua=mailto:agg_reports@joesbait.com è la casella di posta a cui devono essere inviati i rapporti aggregati
ruf=mailto:afrf_reports@joesbait.com è la casella di posta a cui devono essere inviati i rapporti forensi
pct=100 è la percentuale di posta a cui il proprietario del dominio desidera che venga applicata la sua politica. I domini che stanno iniziando con DMARC, specialmente quelli che probabilmente genereranno un elevato volume di rapporti, potrebbero voler iniziare con un numero molto più basso qui per vedere come i loro processi di gestione dei rapporti reggono il carico.
Ci sono altre opzioni di configurazione disponibili per un proprietario di dominio da utilizzare nel proprio record di politica DMARC, ma i suggerimenti forniti dovrebbero essere un buon punto di partenza.
La politica DMARC di un dominio viene annunciata pubblicando un record DNS TXT in un luogo specifico dello spazio dei nomi DNS, vale a dire “_dmarc.nomeDominio.tld” (nota il trattino basso all'inizio). Un record di politica DMARC di base per il nostro esempio di dominio precedente, joesbaitshop.com, potrebbe apparire simile a questo:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Analizzando questo record, abbiamo:
v=DMARC1 specifica la versione DMARC (1 è l'unica opzione attualmente)
p=none specifica il trattamento preferito, o la politica DMARC
rua=mailto:agg_reports@joesbait.com è la casella di posta a cui devono essere inviati i rapporti aggregati
ruf=mailto:afrf_reports@joesbait.com è la casella di posta a cui devono essere inviati i rapporti forensi
pct=100 è la percentuale di posta a cui il proprietario del dominio desidera che venga applicata la sua politica. I domini che stanno iniziando con DMARC, specialmente quelli che probabilmente genereranno un elevato volume di rapporti, potrebbero voler iniziare con un numero molto più basso qui per vedere come i loro processi di gestione dei rapporti reggono il carico.
Ci sono altre opzioni di configurazione disponibili per un proprietario di dominio da utilizzare nel proprio record di politica DMARC, ma i suggerimenti forniti dovrebbero essere un buon punto di partenza.
Riepilogo
C'è molto da svelare nelle informazioni sopra! Speriamo che tu trovi utile la guida per creare un record della policy DMARC. Speriamo anche che la nostra spiegazione del perché DMARC sia importante chiarisca perché dovresti iniziare a utilizzare questo strumento fondamentale per proteggere la tua reputazione via email.
Naturalmente, questo non è un documento completo o autorevole sull'argomento. Se desideri approfondire o hai bisogno di ulteriore aiuto, un ottimo punto di partenza è il FAQ ufficiale di DMARC. E, tant'è, il team di supporto di MessageBird è pronto ad aiutarti a configurare il tuo account MessageBird per DMARC.
Grazie per aver letto—e inizia a proteggere i tuoi domini con DMARC oggi stesso!
C'è molto da svelare nelle informazioni sopra! Speriamo che tu trovi utile la guida per creare un record della policy DMARC. Speriamo anche che la nostra spiegazione del perché DMARC sia importante chiarisca perché dovresti iniziare a utilizzare questo strumento fondamentale per proteggere la tua reputazione via email.
Naturalmente, questo non è un documento completo o autorevole sull'argomento. Se desideri approfondire o hai bisogno di ulteriore aiuto, un ottimo punto di partenza è il FAQ ufficiale di DMARC. E, tant'è, il team di supporto di MessageBird è pronto ad aiutarti a configurare il tuo account MessageBird per DMARC.
Grazie per aver letto—e inizia a proteggere i tuoi domini con DMARC oggi stesso!
C'è molto da svelare nelle informazioni sopra! Speriamo che tu trovi utile la guida per creare un record della policy DMARC. Speriamo anche che la nostra spiegazione del perché DMARC sia importante chiarisca perché dovresti iniziare a utilizzare questo strumento fondamentale per proteggere la tua reputazione via email.
Naturalmente, questo non è un documento completo o autorevole sull'argomento. Se desideri approfondire o hai bisogno di ulteriore aiuto, un ottimo punto di partenza è il FAQ ufficiale di DMARC. E, tant'è, il team di supporto di MessageBird è pronto ad aiutarti a configurare il tuo account MessageBird per DMARC.
Grazie per aver letto—e inizia a proteggere i tuoi domini con DMARC oggi stesso!
