Usare DMARC per convalidare la posta elettronica
Consiglio
Sapevi che puoi provare gratuitamente le funzionalità in Microsoft 365 Defender per Office 365 Piano 2? Usare la versione di valutazione Defender per Office 365 di 90 giorni nell'hub delle versioni di valutazione del portale di Microsoft Defender. Informazioni su chi può iscriversi e sulle condizioni di valutazione qui.
Autenticazione, reporting e conformità dei messaggi basati sul dominio (DMARC) funziona con Sender Policy Framework (SPF) e DomainKeys Identified Mail (DKIM) per autenticare i mittenti di posta.
DMARC garantisce che i sistemi di posta elettronica di destinazione consideri attendibili i messaggi inviati dal dominio. L'implementazione di DMARC con SPF e DKIM fornisce un'ulteriore protezione dallo spoofing e dal phishing. DMARC consente ai sistemi di posta di ricezione di determinare cosa fare con i messaggi inviati dal dominio che non supera i controlli SPF o DKIM.
Consiglio
Vedere il catalogo Microsoft Intelligent Security Association per individuare i fornitori di terze parti che offrono la creazione di report DMARC per Microsoft 365.
Consiglio
Hai visto le nostre guide dettagliate? Configurazione 1-2-3s e senza fronzoli, per gli amministratori in fretta. Vedere la procedura per abilitare la creazione di report DMARC per microsoft online Email indirizzi di routing (MOERA) e domini parcheggiati.
In che modo SPF e DMARC collaborano per proteggere la posta elettronica in Microsoft 365?
Un messaggio di posta elettronica potrebbe contenere più originatori o mittenti, indirizzi. Questi indirizzi sono utilizzati per scopi differenti. Ad esempio, si consideri quanto segue:
Indirizzo "Mail From" (Posta da): Identifica il mittente e consente di specificare dove inviare notifiche di ritorno se si verificano problemi con la consegna del messaggio (ad esempio notifiche di mancato recapito). L'indirizzo mittente visualizzato nella parte della busta di un messaggio di posta elettronica e non viene visualizzato dall'applicazione di posta elettronica e talvolta viene chiamato l'indirizzo mittente.5321 o l'indirizzo del percorso inverso.
Indirizzo "From" (Da) L'indirizzo visualizzato come indirizzo From dall'applicazione di posta elettronica. Indirizzo mittente identifica l'autore del messaggio di posta elettronica. Vale a dire, la cassetta postale dell'utente o del sistema responsabile della creazione del messaggio. L’indirizzo mittente viene talvolta chiamato indirizzo mittente.5322.
SPF usa un record TXT DNS per fornire un elenco di indirizzi IP di invio autorizzati per un determinato dominio. Normalmente, i controlli SPF vengono eseguiti solo in base all'indirizzo 5321.MailFrom. L'indirizzo mittente.5322 non viene autenticato quando si usa SPF da solo, il che consente uno scenario in cui un utente ottiene un messaggio che ha superato i controlli SPF ma ha un indirizzo mittente.5322 falsificato. Si consideri, ad esempio, la seguente trascrizione SMTP:
S: Helo woodgrovebank.com
S: Mail from: phish@phishing.contoso.com
S: Rcpt to: astobes@tailspintoys.com
S: data
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings User,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that Microsoft has the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .
In questa trascrizione, gli indirizzi mittente sono i seguenti:
Posta dall'indirizzo (5321.MailFrom): phish@phishing.contoso.com
Dall'indirizzo (5322.From): security@woodgrovebank.com
Se SPF è stato configurato, il server ricevente esegue un controllo sull'indirizzo phish@phishing.contoso.comMail from . Se il messaggio proviene da un'origine valida per il dominio phishing.contoso.com, allora supera il controllo SPF. Poiché il client di posta elettronica visualizza solo l'indirizzo Da, l'utente vede che questo messaggio proviene da security@woodgrovebank.com. Solo con SPF, la validità di woodgrovebank.com non era mai stata autenticata.
Quando si utilizza DMARC, anche il server di ricezione esegue un controllo sull'indirizzo From. Nell'esempio precedente, se esiste un record TXT DMARC per woodgrovebank.com, allora il controllo sull'indirizzo mittente avrà esito negativo.
Che cos'è un record TXT DMARC?
Come i record DNS per SPF, il record per DMARC è un record di testo DNS che consente di prevenire spoofing e phishing. Viene pubblicato i record TXT DMARC in DNS. I record TXT DMARC consentono di convalidare l'origine dei messaggi di posta elettronica verificando l'indirizzo IP dell'autore della posta elettronica in base al proprietario del dominio del mittente. I record TXT DMARC identificano i server di posta elettronica in uscita autorizzati. I sistemi di posta elettronica di destinazione possono quindi verificare che l'origine dei messaggi ricevuti sia un server di posta elettronica in uscita autorizzato.
Il record TXT DMARC di Microsoft è simile al seguente:
_dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.contoso.com; ruf=mailto:d@ruf.contoso.com; fo=1"
Per altri fornitori di terze parti che offrono report DMARC per Microsoft 365, visitare il catalogo MISA.
Configurare DMARC per la posta in ingresso
Non serve fare nulla per configurare DMARC per la posta ricevuta in Microsoft 365. È tutto sistemato. Per sapere cosa succede alla posta che non supera i controlli DMARC, vedere Modalità di gestione della posta elettronica in ingresso che non supera DMARC da parte di Microsoft 365.
Configurare DMARC per la posta in uscita da Microsoft 365
Se si usa Microsoft 365, ma non si usa un dominio personalizzato (si usa onmicrosoft.co), SPF è già configurato e Microsoft 365 genera automaticamente una firma DKIM per la posta in uscita. Per altre informazioni sulla firma, vedere Comportamento predefinito per DKIM e Microsoft 365. Per configurare DMARC per l'organizzazione, è necessario creare il record TXT DMARC per il dominio onmicrosoft.com e pubblicarlo in DNS tramite Amministrazione di Office 365 Center> Settings > Domains > fare clic su onmicrosoft.com dominio > Aggiungi record.
Se si dispone di un dominio personalizzato o si utilizzano i server Exchange locali oltre a Microsoft 365, è necessario implementare manualmente DMAR per la posta in uscita. L'implementazione DMARC per il dominio personalizzato include questa procedura:
Passaggio 1: identificare le origini valide della posta del dominio
Se è già stato configurato SPF, allora è già stato effettuato questo esercizio. Esistono altre considerazioni per DMARC. Quando si identificano le origini di posta elettronica per il dominio, è necessario rispondere a due domande:
Quali indirizzi IP inviano messaggi da qualsiasi dominio?
Per i messaggi inviati da terze parti per conto dell'utente, i domini 5321.MailFrom e 5322.From corrisponderanno?
Passaggio 2: configurare SPF per il dominio
Ora che si ha un elenco di mittenti validi, è possibile seguire la procedura per Configurare SPF per prevenire lo spoofing.
Ad esempio, presupponendo che contoso.com invia un messaggio da Exchange Online, un server Exchange locale il cui indirizzo IP è 192.168.0.1 e un'applicazione Web il cui indirizzo IP è 192.168.100.100, il record TXT SPFsarà simile alla seguente:
contoso.com IN TXT " v=spf1 ip4:192.168.0.1 ip4:192.168.100.100 include:spf.protection.outlook.com -all"
Come procedura consigliata, assicurarsi che il record TXT SPF tenga in considerazione mittenti di terze parti.
Passaggio 3: configurare DKIM per il dominio personalizzato
Dopo aver configurato SPF, è necessario configurare DKIM. DKIM consente di aggiungere una firma digitale nell'intestazione dei messaggi di posta elettronica. Se non si configura DKIM e si consente invece a Microsoft 365 di usare la configurazione DKIM predefinita per il dominio, DMARC potrebbe non riuscire. Questo errore può verificarsi perché la configurazione DKIM predefinita usa il dominio onmicrosoft.com originale come indirizzo 5321.MailFrom, non il dominio personalizzato. Questo crea una mancata corrispondenza tra gli indirizzi mittente.5321e mittente.5322 in tutti i messaggi di posta elettronica dal dominio.
Se si dispone di mittenti di terze parti che inviano posta per conto dell'utente e la posta inviata presenta indirizzi 5321.MailFrom e 5322.From non corrispondenti, DMARC non riuscirà per tale posta elettronica. Per evitare il problema, è necessario configurare DKIM per il dominio in modo specifico con tale mittente di terze parti. In questo modo Microsoft 365 potrà autenticare la posta elettronica dal servizio di terze parti. Tuttavia, inoltre consente ad altri, ad esempio, Yahoo, Gmail e Comcast, di verificare la posta elettronica inviata a loro da terze parti come se la posta elettronica fosse stata inviata dall'utente. Ciò è utile perché consente ai clienti di creare fiducia nel dominio indipendentemente da dove si trova la loro cassetta postale e, contemporaneamente, Microsoft 365 non contrassegnerà un messaggio come posta indesiderata a causa dello spoofing perché supera i controlli di autenticazione del dominio.
Per istruzioni sulla configurazione di DKIM per il dominio e su come configurare DKIM per mittenti di terze parti affinché possano effettuare lo spoofing del dominio, vedere Usare DKIM per convalidare la posta elettronica in uscita inviata dal dominio personalizzato.
Passaggio 4: formare il record TXT DMARC del dominio
Sebbene ci siano altre opzioni di sintassi che non sono menzionate qui, queste sono le opzioni più comunemente utilizzate per Microsoft 365. Formare il record TXT DMARC per il dominio nel formato:
_dmarc.domain TTL IN TXT "v=DMARC1; p=policy; pct=100"
Dove:
domain è il dominio da proteggere. Per impostazione predefinita, il record protegge la posta elettronica dal dominio e da tutti i sottodomini. Ad esempio, se si specifica _dmarc.contoso.com, DMARC protegge la posta del dominio e da tutti i sottodomini, ad esempio housewares.contoso.com o plumbing.contoso.com.
TTL deve essere sempre l'equivalente di un'ora. L'unità utilizzata per TTL, ore (1 ora), minuti (60 minuti) o secondi (3600 secondi) varia a seconda del registrar del dominio.
pct=100 indica che questa regola deve essere utilizzata per il 100% della posta elettronica.
policy specifica quale criterio deve eseguire il server di ricezione se DMARC ha esito negativo. È possibile impostare il criterio su none, quarantine o reject.
Per informazioni sulle opzioni da usare, acquisire familiarità con i concetti illustrati in Procedure consigliate per l'implementazione di DMARC in Microsoft 365.
Esempi:
Criterio impostato su none
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=none"Criterio impostato su quarantine
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=quarantine"Criterio impostato su reject
_dmarc.contoso.com 3600 IN TXT "v=DMARC1; p=reject"
Dopo aver creato il record, è necessario aggiornare il record nel registrar del dominio.
Posta elettronica DMARC
Attenzione
Le e-mail non possono essere inviate ogni giorno.
In questo esempio di record TXT DMARC: dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.example.com; ruf=mailto:d@ruf.example.com; fo=1"è possibile visualizzare l'indirizzo rua . Questo indirizzo viene usato per inviare "feedback aggregato" per l'analisi, usato per generare un report.
Consiglio
Visita il catalogo MISA per visualizzare altri fornitori di terze parti che offrono report DMARC per Microsoft 365. Per altre informazioni sugli indirizzi "rua" di DMARC, vedere 'Domain-based Message Authentication, Reporting, and Conformance (DMARC)' di IETF.org.
Procedure consigliate per l'implementazione di DMARC in Microsoft 365
È possibile implementare DMARC gradualmente senza influire sul resto del flusso di posta. Creare e implementare un piano di implementazione che segue questi passaggi. Eseguire ognuna di queste operazioni prima con un sottodominio, poi con gli altri sottodomini e infine con il dominio di primo livello nell'organizzazione prima di passare al passaggio successivo.
Monitorare l'effetto dell'implementazione DMARC
Iniziare con un semplice record in modalità monitoraggio per un sottodominio o dominio che richiede che i destinatari DMARC inviino statistiche sui messaggi visualizzati utilizzando tale dominio. Un record in modalità monitoraggio è un record TXT DMARC con i criteri impostati su none (p=none). Molte aziende pubblicano un record TXT DMARC con p=nessuno perché non sono sicuri su quanta posta elettronica potrebbero perdere pubblicando un criterio DMARC più restrittivo.
È possibile farlo anche prima di aver implementato SPF o DKIM nell'infrastruttura di messaggistica. Tuttavia, non sarà possibile mettere in quarantena o rifiutare in modo efficace la posta tramite DMARCA finché non verranno implementati anche SPF e DKIM. Quando si introducono SPF e DKIM, i rapporti generati tramite DMARC forniranno i numeri e le origini dei messaggi che superano questi controlli, rispetto a quelli che non lo fanno. È possibile individuare facilmente la quantità di traffico legittimo coperto o non coperto da questi e risolvere eventuali problemi. Si inizierà anche a vedere quanti messaggi fraudolenti vengono inviati e da dove vengono inviati.
Richiedere che i sistemi di posta esterni mettano in quarantena la posta che non supera DMARC
Quando si pensa che tutto o la maggior parte del traffico legittimo sia protetto da SPF e DKIM e si comprende l'impatto dell'implementazione DMARC, è possibile implementare un criterio di quarantena. Un criterio di quarantena è un record TXT DMARC il cui criterio è impostato su quarantine (p=quarantine). In questo modo, chiedi ai ricevitori DMARC di inserire i messaggi dal tuo dominio che non superano DMARC nell'equivalente locale di una cartella spam anziché nelle caselle di posta dei tuoi clienti.
Richiedere che i sistemi di posta esterni non accettino messaggi che non superano DMARC
Il passaggio finale consiste nell'implementare un criterio reject. Un criterio reject è un record TXT DMARC il cui criterio è impostato su reject (p=reject). Quando si esegue questa operazione, si chiede ai destinatari DMARC di non accettare messaggi che non superano i controlli DMARC.
Come si configura DMARC per il sottodominio?
DMARC viene implementato pubblicando un criterio come record TXT in DNS ed è gerarchico( ad esempio, un criterio pubblicato per contoso.com verrà applicato a sub.domain.contoso.com a meno che non sia definito in modo esplicito un criterio diverso per il sottodominio). Questa operazione è utile perché le organizzazioni possono specificare un numero ridotto di record DMARC di livello elevato per una copertura più ampia. È necessario prestare attenzione per configurare record DMARC di sottodomini espliciti in cui non si desidera che i sottodomini ereditino il record DMARC del dominio di primo livello.
È anche possibile aggiungere un criterio di tipo jolly per DMARC quando i sottodomini non devono inviare messaggi di posta elettronica, aggiungendo il valore
sp=reject. Ad esempio:_dmarc.contoso.com. TXT "v=DMARC1; p=reject; sp=reject; ruf=mailto:authfail@contoso.com; rua=mailto:aggrep@contoso.com"
Rifiuto DMARC
DMARC p=reject è un criterio impostato nel record TXT DMARC dai proprietari di dominio per notificare ai provider di servizi di rifiutare la posta elettronica che non riesce DMARC.
Si è verificato perché quando OReject è impostato come predefinito, il messaggio di posta elettronica rifiutato è stato inviato in quarantena in Enterprise e alla cartella Junk Email in Consumer (a causa della mancanza di quarantena in Consumer). Tuttavia, con DMARC p=reject, il messaggio di posta elettronica viene rifiutato.
La configurazione può essere eseguita nel portale di Microsoft Defender o dai cmdlet New-AntiPhishPolicy o Set-AntiPhishPolicy in Exchange Online PowerShell. Per altre informazioni, vedere gli articoli seguenti:
- Protezione spoofing e criteri DMARC del mittente
- Configurare i criteri anti-phishing in Exchange Online Protection
- Configurare i criteri anti-phishing in Microsoft Defender per Office 365
Come viene gestita la posta elettronica in uscita che non supera il controllo DMARC in Microsoft 365
Se un messaggio è in uscita da Microsoft 365 e non supera DMARC e il criterio è stato impostato su p=quarantine o p=reject, il messaggio viene instradato attraverso il Pool di recapito ad alto rischio per i messaggi in uscita. Non è previsto alcun override per la posta elettronica in uscita.
Se viene pubblicato un criterio di rifiuto DMARC (p=rifiuto), nessun altro cliente in Microsoft 365 può falsificare il dominio perché i messaggi non potranno passare SPF o DKIM per il dominio durante l'inoltro di un messaggio in uscita tramite il servizio. Tuttavia, se viene pubblicato un criterio di rifiuto DMARC ma non si hanno tutti i messaggi di posta elettronica autenticati tramite Microsoft 365, alcuni di essi potrebbero essere contrassegnati come spam per la posta in entrata (come descritto sopra), oppure verranno rifiutati se non vengono pubblicati SPF e si prova a trasmetterli in uscita tramite il servizio. Ciò accade, ad esempio, se si dimentica di includere alcuni degli indirizzi IP per server e app che inviano posta per conto del dominio quando si crea il record TXT DMARC.
Come viene gestita la posta elettronica in ingresso che non supera il controllo DMARC in Microsoft 365
Se il criterio DMARC del dominio di invio è p=reject, Exchange Online Protection (EOP) rifiuta il messaggio per impostazione predefinita. È possibile configurare i criteri anti-phishing per rispettare p=quarantine o meno i p=reject criteri DMARC del mittente e specificare azioni separate per p=quarantine e p=reject. Per altre informazioni, vedere Protezione spoofing e criteri DMARC del mittente.
Quando i criteri anti-phishing sono configurati per non rispettare p=quarantine o p=reject nei criteri DMARC, i messaggi che non riescono DMARC vengono contrassegnati come posta indesiderata e non vengono rifiutati. Gli utenti possono comunque ricevere questi messaggi nella posta in arrivo tramite questi metodi:
- Gli utenti aggiungono mittenti sicuri singolarmente mediante il loro client di posta elettronica.
- Gli amministratori possono usare i dati analitici di spoof intelligence o l'elenco Consenti/Blocca tenant per consentire i messaggi dal mittente oggeto di spoofing.
- Gli amministratori creano una regola di flusso di posta di Exchange, nota anche come regola di trasporto, per tutti gli utenti che consentono messaggi di questi mittenti specifici.
- Gli amministratori creano una regola del flusso di posta elettronica di Exchange per tutti gli utenti per la posta elettronica rifiutata che non soddisfa i criteri DMARC dell'organizzazione.
Per altre informazioni, vedere Creare elenchi di mittenti attendibili.
Come Microsoft 365 usa lo standard ARC (Authenticated Received Chain)
Tutte le cassette postali ospitate in Microsoft 365 otterranno ora i vantaggi di ARC con un migliore recapito dei messaggi e una maggiore protezione anti-spoofing. ARC conserva i risultati dell'autenticazione della posta elettronica di tutti gli intermediari partecipanti, o hop, quando un messaggio di posta elettronica viene instradato dal server di origine alla casella di posta del destinatario. Prima dello standard ARC, le modifiche apportate dagli intermediari nel routing della posta elettronica, come le regole di inoltro o le firme automatiche, potevano causare errori DMARC nel momento in cui il messaggio di posta elettronica raggiungeva la casella di posta del destinatario. Con ARC, la conservazione crittografica dei risultati dell'autenticazione permette a Microsoft 365 di verificare l'autenticità del mittente di un messaggio di posta elettronica.
Microsoft 365 attualmente usa ARC per verificare i risultati dell'autenticazione quando Microsoft è ARC Sealer, ma prevede di aggiungere in futuro il supporto di ARC Sealer di terze parti.
Risoluzione dei problemi relativi all'implementazione di DMARC
Se sono stati configurati i record MX del dominio in cui EOP non è la prima voce, gli errori DMARC non verranno applicati nel dominio.
Se si è clienti e il record MX principale del proprio dominio non punta a Exchange Online Protection, non si usufruirà dei vantaggi di DMARC. Ad esempio, DMARC non funzionerà se si punta il record MX al server di posta locale e si indirizza quindi la posta elettronica a EOP utilizzando un connettore. In questo scenario, il dominio di destinazione è uno dei domini accettati ma EOP non è il principale MX. Ad esempio, si supponga che contoso.com punti il relativo MX a se stesso e utilizzi EOP come un record MX secondario, il record MX di contoso.com avrà il seguente aspetto:
contoso.com 3600 IN MX 0 mail.contoso.com
contoso.com 3600 IN MX 10 contoso-com.mail.protection.outlook.com
Tutta la posta elettronica, o gran parte, verrà prima indirizzata a mail.contoso.com poiché è l'MX principale e poi la posta verrà instradata a EOP. In alcuni casi, potrebbe non essere neanche necessario EOP come record MX, ma potrebbe essere semplicemente sufficiente collegare connettori per instradare la posta elettronica. EOP non deve necessariamente essere la prima voce per la convalida di DMARC. Garantisce solo la convalida, per essere certi che tutti i server locali/non O365 eseguirà controlli DMARC. DMARC è idoneo per essere applicato al dominio di un cliente (non al server) durante la configurazione del record TXT DMARC, ma l'applicazione dipende dal server di ricezione. Se si configura EOP come server di ricezione, EOP esegue l'applicazione di DMARC.
Ulteriori informazioni
Vuoi altre informazioni su DMARC? Queste risorse possono essere utili.
Intestazioni messaggi della protezione da posta indesiderata include la sintassi e i campi di intestazione usati da Microsoft 365 per i controlli DMARC.
Seguire la serie di formazione su DMARC da M 3AAWG (Messaging, Malware, Mobile Anti-Abuse Working Group).
Utilizzare l'elenco di controllo in dmarcian.
Passare direttamente all'origine in DMARC.org.
Vedere anche
Uso di Sender Policy Framework (SPF) in Microsoft 365 per impedire lo spoofing
Commenti e suggerimenti
Invia e visualizza il feedback per