Prima di rendere più restrittiva la tua policy DMARC, considera tutti i sistemi che inviano email legittime usando il tuo dominio. I report possono rivelare un mittente che necessita di modifiche all'autenticazione prima che l'enforcement ne blocchi la posta.
Quale report dovresti usare?
Usa i report aggregati per confrontare le sorgenti di invio e i risultati di autenticazione in un periodo di reporting. L'indirizzo rua nel tuo record DMARC richiede questi riepiloghi XML ai riceventi partecipanti.
L'indirizzo ruf richiede report individuali di errore, a volte chiamati report forensi. Usano un formato di segnalazione degli errori di autenticazione e possono contenere intestazioni o contenuto del messaggio. I riceventi possono oscurarli o ometterli perché quel contenuto può esporre informazioni personali. Le regole di reporting di RFC 7489 descrivono i due tipi di report.
I report aggregati coprono il traffico osservato da ciascun ricevente. Un report mancante non prova che nessun messaggio abbia usato il tuo dominio. La spiegazione del record DMARC indica dove impostare gli indirizzi di reporting.
Cosa contiene un report aggregato?
Un report aggregato identifica l'organizzazione che lo genera, il periodo di reporting e la policy pubblicata, seguiti da record che raggruppano messaggi con caratteristiche comuni. Un IP sorgente può comparire in più record quando i risultati di autenticazione o altri campi di raggruppamento differiscono.
Questo estratto illustrativo conserva i campi necessari per confrontare una sorgente con i suoi risultati di autenticazione:
<report_metadata>
<org_name>google.com</org_name>
<date_range><begin>1718323200</begin><end>1718409600</end></date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<p>none</p>
</policy_published>
<record>
<row>
<source_ip>203.0.113.10</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers><header_from>example.com</header_from></identifiers>
<auth_results>
<dkim><domain>example.com</domain><result>pass</result></dkim>
<spf><domain>example.com</domain><result>pass</result></spf>
</auth_results>
</record>Questo record rappresenta 42 messaggi da 203.0.113.10 con example.com nell'indirizzo From visibile. Entrambi i metodi di autenticazione sono passati e allineati. Il ricevente non ha applicato nessun enforcement DMARC a quei messaggi; questo non ne stabilisce il posizionamento in inbox.
Quali campi identificano un problema di autenticazione?
Confronta policy_evaluated con auth_results per distinguere un errore di autenticazione da un errore di allineamento del dominio.
| Campo | Cosa verificare |
|---|---|
source_ip | Identifica il server di invio e il servizio responsabile. |
count | Conta i messaggi rappresentati da questo record, non dall'intero report. |
header_from | Conferma il dominio mostrato al destinatario. |
disposition | Controlla se il ricevente ha applicato none, quarantine o reject. |
dkim e spf in policy_evaluated | Controlla se ciascun metodo è passato e allineato per DMARC. |
auth_results | Confronta i risultati di autenticazione grezzi e i domini che hanno autenticato. |
Ad esempio, SPF può passare sotto auth_results ma fallire sotto policy_evaluated quando il suo dominio autenticato non è allineato con il dominio From. Un passaggio allineato di DKIM può comunque far superare DMARC a quel messaggio. Come funziona DMARC spiega questa relazione.
Cosa fare con ogni sorgente di invio?
Associa ogni sorgente a un servizio che autorizzi prima di modificare la policy. I risultati di autenticazione da soli non indicano se la tua organizzazione intendeva che quel servizio inviasse.
- Per un mittente noto che passa e si allinea, conferma che il volume riportato corrisponda al traffico che ti aspetti.
- Per un mittente noto che fallisce, correggi la sua autenticazione o allineamento e controlla i report successivi per il risultato.
- Per un mittente sconosciuto che passa, identifica chi lo ha configurato e se debba mantenere l'autorizzazione.
- Per un mittente sconosciuto che fallisce, verifica se si tratta di un servizio legittimo mal configurato o di un uso non autorizzato del tuo dominio.
Risolvi gli errori legittimi prima di passare dal monitoraggio alla quarantena o al rifiuto, perché quei messaggi sarebbero altrimenti candidati all'enforcement. Correggere gli errori DMARC copre le cause più comuni.
Come ispezionare i report per un dominio di invio Bird?
Puoi instradare i report aggregati alla tua casella di posta tramite l'indirizzo rua nel tuo record DMARC. Usa l'analizzatore di report DMARC per ispezionare l'XML, oppure apri un report in un editor di testo.
La verifica DNS di Bird controlla la policy pubblicata; i report dei riceventi descrivono i risultati di autenticazione per i messaggi. Sono controlli separati. La guida all'autenticazione copre la policy e i record DNS da pubblicare.