Un messaggio può visualizzare il nome di un'azienda familiare mentre utilizza un indirizzo email completamente diverso. Può anche mostrare l'indirizzo della tua azienda mentre il servizio di invio autentica solo il proprio dominio. Comprensione DMARC inizia separando quelle identità.
DMARC sta per Autenticazione, reporting e conformità dei messaggi basati sul dominio. Valuta l'uso autenticato del dominio nell'indirizzo del mittente del messaggio e collega il risultato alla politica pubblicata del proprietario del dominio. Si tratta di una valutazione a livello di dominio, non di un verdetto sulla persona, sulla richiesta o sull'allegato.
Trova l'indirizzo dietro il nome del mittente
Supponiamo che un'applicazione di posta visualizzi questo mittente fittizio:
Account di esempio < notices@shop.example.com >Account di esempio è il nome visualizzato. avvisi è la parte prima del segno di chiocciola. shop.example.com è il dominio nell'indirizzo Da, chiamato dominio dell'autore in DMARC .
La visualizzazione compatta dell'applicazione di posta potrebbe mostrare solo il nome visualizzato. Apri i dettagli del mittente o il messaggio originale per identificare l'indirizzo effettivo. Un logo, un nome e un oggetto riconoscibile non stabiliscono tale relazione di dominio.
Gli esempi in questa guida presuppongono un messaggio ordinario e ben formato con un dominio autore. I campi Da non validi o ambigui richiedono la propria gestione del formato del messaggio; non inventare un'identità preferita da qualunque cosa mostri un'applicazione di posta.
Mantieni gli altri indirizzi nei rispettivi ruoli
Un'e-mail contiene una conversazione di consegna SMTP , nonché le intestazioni e il corpo letti dalle persone. L'identità di ritorno della busta supporta la gestione dello stato di consegna e normalmente è l'identità valutata SPF per la posta ordinaria. Può differire da Da.
A Firma DKIM fornisce un altro dominio nel suo valore d=. Un messaggio può avere più firme, ciascuna con il proprio dominio e risultato. Reply-To è ancora diverso: influenza il luogo in cui viene indirizzata una risposta, non quale dominio dell'autore DMARC valuta.
| Articolo | Domanda a cui aiuta a rispondere |
|---|---|
| Dal dominio | Quale dominio dell'autore dichiarato viene valutato? |
| Identità della busta | Quale dominio viene valutato per l'autorizzazione SPF ordinaria? |
| DKIM d= domain | Quale dominio è associato a questa firma? |
| Rispondi a | Dove è diretta una risposta? |
| Nome da visualizzare | Quale nome viene presentato al lettore? |
Questi campi possono legittimamente differire. Il compito è comprendere le loro relazioni piuttosto che richiedere che ogni indirizzo visualizzato sia identico.
Comprendi la relazione chiamata allineamento
SPF può passare per il dominio busta di un servizio di invio. DKIM può verificare una firma dal dominio di firma di quel servizio. DMARC chiede quindi se un'identità autenticata che passa è in linea con il dominio dell'autore.
Rigoroso allineamento richiede una corrispondenza esatta del dominio. L'allineamento rilassato utilizza la relazione organizzazione-dominio applicabile. Non determinare quel confine semplicemente prendendo le ultime due etichette e non trattare due marchi dall’aspetto simile come domini allineati.
Per un passaggio DMARC a livello di messaggio, almeno un percorso SPF o DKIM qualificante deve essere superato e allineato. Una firma passeggera da un dominio non correlato non può fornire tale percorso semplicemente perché l'azienda possiede un account con il servizio.
Segui due messaggi immaginari
Quello che segue è un esempio didattico sintetico, non un messaggio del cliente catturato o oscurato. Supponiamo che venga trovata la policy DMARC applicabile e che i risultati dichiarati provengano da un sistema di ricezione attendibile.
Entrambi i messaggi hanno From at shop.example.com . Le loro identità differiscono come segue:
| Osservazione | MessaggioA | Messaggio B |
|---|---|---|
| SPF | Passa per returns.example.net | Passa per returns.example.net |
| DKIM | Passa con d=shop.example.com | Passa con d=dispatch.example.org |
| Percorso di passaggio allineato | DKIM corrisponde esattamente a Da | Nessuna delle due identità di passaggio si allinea |
| Convalida DMARC | Passaggio | Fallire |
Il messaggio A ha un percorso DKIM con corrispondenza esatta. Non è necessario rinominare la sua identità SPF separata affinché il risultato DMARC a livello di messaggio venga superato.
Il messaggio B autentica i domini non correlati al suo dominio Da. Due passaggi grezzi quindi non producono alcun percorso allineato. Se si tratta di un mittente autorizzato che necessita di riparazione, seguire le istruzioni guida alla risoluzione dei problemi di allineamento. Tale indagine è diversa dal decidere che ogni messaggio con questo modello è dannoso.
Separa il risultato da ciò che fa il ricevitore
Il proprietario di un dominio pubblica la policy DMARC nel DNS con un nome _dmarc applicabile. La policy esprime la valutazione del proprietario sul mancato utilizzo. Non configura l'identità di firma di un'applicazione né determina l'azione finale di ogni destinatario.
I ricevitori valutano anche le informazioni al di fuori DMARC . Di conseguenza, un passaggio non garantisce il posizionamento della casella di posta e un fallimento non stabilisce autonomamente un attacco bloccato. IL guida alla selezione delle politiche spiega come l'effettivo utilizzo di un dominio influisce sulla decisione del proprietario.
La segnalazione può aiutare il proprietario a indagare su come appare il suo dominio nella posta osservata. I report sono feedback dei destinatari partecipanti, non un registro completo di ogni messaggio inviato. Mantenere le osservazioni riportate separate dall'autorizzazione commerciale e dai risultati finali della consegna.
Leggi un risultato positivo senza sovraleggerlo
Utilizzare i risultati dell'autenticazione prodotti dal limite di ricezione attendibile pertinente. Un mittente può inserire un'intestazione che richiede un passaggio; l'esistenza di quel testo non lo rende affidabile.
Anche un vero passaggio allineato ha dei limiti. Un account autorizzato compromesso può inviare posta autenticata. Un dominio non correlato può autenticare i propri messaggi presentando un nome visualizzato ingannevole. DMARC non controlla la veridicità di una fattura né approva un'istruzione di pagamento.
La spiegazione utile è specifica: questo messaggio ricevuto aveva un dominio autenticato di passaggio che soddisfaceva la relazione richiesta con il suo dominio Da. Questo è un prezioso segnale di identità. Mantieni insieme la protezione dell'account, la valutazione dei contenuti e la verifica indipendente delle richieste sensibili.
Per l'implementazione, continuare con creazione e verifica di un record DMARC. Per la proprietà tra le applicazioni, utilizzare il file inventario del mittente. Entrambi diventano più facili una volta che l'ambito effettivo da valutare è chiaro.
Traccia un risultato in cinque righe
Utilizzare questo breve foglio di lavoro quando un messaggio viene descritto come "autenticato". Inizia con l'indirizzo, non con il nome dell'azienda visualizzato accanto ad esso.
- Da: annotare il dominio dopo @ nell'effettivo indirizzo Da.
- Prova: utilizzare i risultati attendibili del sistema ricevente. Registrare separatamente il dominio SPF e ciascun dominio DKIM d= passante.
- Relazione: confrontare ogni identità transitoria con Da nella modalità rigorosa o rilassata applicabile. Il nome di un account del provider non corrisponde a un dominio.
- Risultato: con una policy applicabile e senza errori DNS irrisolti, è sufficiente un percorso di passaggio allineato. Se non ce n'è, il messaggio fallisce DMARC . Nessuna policy rilevata significa che DMARC non si applica; un errore richiesto nella query DNS non è semplicemente un passaggio o un fallimento.
- Significato: registrare il risultato dell'identità separatamente dalla consegna e se è sicuro agire sulla richiesta.
Per il messaggio A sopra, la spiegazione è: " DKIM passato per shop.example.com , che corrisponde esattamente a Da; questo fornisce un pass DMARC ." Non è: “La fattura è approvata”.
Controlla il Fasi di elaborazione DMARC e il Limite di attendibilità Authentication-Results per queste distinzioni.