Il tracciamento delle email aiuta i marketer a capire come i destinatari interagiscono con le campagne, ma la sua accuratezza dipende da come i dati vengono raccolti e interpretati. Il tracciamento delle email...
Punti chiave
- Il formato XML grezzo è intenzionalmente generato automaticamente. Il modo più rapido per ottenere valore è analizzare i report e ricavarne una tabella con le fonti di invio e i risultati; manualmente per una revisione occasionale, oppure tramite un analizzatore DMARC per il monitoraggio continuo.
- L'approccio più efficace per bloccare le email temporanee è il blocco in tempo reale al momento della registrazione, utilizzando un'API di validazione che confronta i dati con un elenco di domini temporanei costantemente aggiornato.
- L'obiettivo della lettura dei report è operativo: catalogare tutti i mittenti, verificare che quelli legittimi superino i controlli di conformità e identificare le fonti non autorizzate o configurate in modo errato prima di inasprire le policy.
- I report "noiosi" (tassi di successo costanti da mittenti noti, senza sorprese) sono il segnale che è sicuro passare da p=none a p=quarantine e p=reject.
Entro 24-72 ore dalla pubblicazione di un record DMARC, arriva il primo report aggregato, che rivela immediatamente ogni server legittimo e non autorizzato che ha inviato email come il tuo dominio durante quel periodo. Il trucco, come documentato in Italiano:La specifica del protocollo prevede che questi report siano file XML formattati automaticamente e progettati per l'analisi automatizzata, non per la lettura umana.
Saper leggere i report DMARC trasforma i dati grezzi in informazioni operative. La visibilità è davvero preziosa, ma solo dopo che l'XML è stato decodificato in qualcosa su cui è possibile agire. statistiche sullo spam via e-mail Dimostra perché questa visibilità è importante: lo spoofing e l'impersonificazione sono comuni, quindi hai bisogno dei report DMARC per identificare le fonti che inviano email utilizzando il tuo dominio.
Come leggere i report DMARC
La prima lettura richiede dai 15 ai 30 minuti. Le letture successive, provenienti dagli stessi mittenti, richiedono dai 2 ai 3 minuti una volta che il modello è stato riconosciuto. I passaggi seguenti illustrano la creazione di un report aggregato DMARC completo, dall'inizio alla fine.
Ecco un frammento XML anonimizzato che illustra la struttura del report utilizzata nelle fasi di revisione descritte di seguito:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>[email protected]</email>
<report_id>10296513920663916120</report_id>
<date_range>
<begin>1716768000</begin>
<end>1716854400</end>
</date_range>
</report_metadata>
<policy_published>
<domain>yourdomain.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>209.85.220.41</source_ip>
<count>847</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<auth_results>
<dkim>
<domain>yourdomain.com</domain>
<result>pass</result>
</dkim>
<spf>
<domain>yourdomain.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>198.51.100.23</source_ip>
<count>312</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<auth_results>
<dkim>
<domain>unknownsender.net</domain>
<result>fail</result>
</dkim>
<spf>
<domain>unknownsender.net</domain>
<result>fail</result>
</spf>
</auth_results>
</record>
</feedback>Passaggio 1: Configura una casella di posta o un servizio per ricevere i report
Conferma che una casella di posta dedicata stia raccogliendo i report all'indirizzo specificato nel tag rua= del tuo record DMARC (ad esempio, [email protected]I provider di caselle di posta inviano report aggregati quotidianamente, quindi anche un dominio con poco traffico accumula decine di file XML al mese; di conseguenza, una casella di posta condivisa generica diventa rapidamente ingestibile.
Per i domini di piccole dimensioni con esigenze di revisione occasionali, una casella di posta dedicata è sufficiente. Per un numero di report superiore a pochi alla settimana, o per le organizzazioni che gestiscono più domini, è consigliabile impostare il tag rua= in modo che punti all'indirizzo di ingestione di un analizzatore DMARC per l'analisi automatizzata.
Passaggio 2: Aprire e decomprimere il file XML
Scarica il file allegato dall'email del report. La maggior parte dei report arriva come archivi .xml.gz o .zip che devono essere prima decompressi (su macOS e Linux, fai doppio clic o usa gunzip; su Windows, fai clic con il pulsante destro del mouse e seleziona "Estrai").
Apri il file .xml risultante in qualsiasi editor di testo, come VS Code, Sublime Text o Notepad++. Puoi anche aprirlo in un browser, il che spesso rende più facile la lettura del codice XML perché le sezioni appaiono come nodi comprimibili anziché come un unico lungo blocco di testo.
Per controllare un singolo report di tanto in tanto, aprire manualmente il file XML va benissimo. Se invece si ricevono più di pochi report a settimana, è consigliabile utilizzare un parser automatico. I report DMARC seguono una struttura coerente, quindi gli strumenti possono convertire l'XML in tabelle e riepiloghi molto più velocemente.
Fase 3: Identificare l'organizzazione e la politica di reporting
Individuare il Il blocco all'inizio del file identifica l'organizzazione che ha generato il report (Google, Microsoft, Yahoo, Mail.ru o altre) e i timestamp Unix di inizio e fine del periodo di riferimento del report. La conversione di questi timestamp in date leggibili conferma il periodo di 24 ore a cui si riferisce il report.
Individuare il blocco subito dopo. Mostra la policy DMARC attiva durante la finestra di report (p=nessuna, p=quarantena o p=rifiuta) e le modalità di allineamento sia per SPF (aspf) che per DKIM (adkim). Il valore r indica un allineamento rilassato; s indica un allineamento rigoroso.
Verifica che la policy mostrata nel report corrisponda a quella attualmente presente nel tuo record DNS. Una discrepanza significa che il report si riferisce a un periodo precedente alla propagazione di una recente modifica della policy, il che è normale e non rappresenta un problema, ma serve solo a fornire un contesto per l'interpretazione dei risultati.
Passaggio 4: Esaminare ciascuna fonte di invio nella sezione dei record
Scorri fino a blocchi. Ogni record rappresenta un IP mittente e i relativi risultati, raggruppati per numero di messaggi. Nell'esempio sopra, 209.85.220.41 ha inviato 847 messaggi e ha superato il test DMARC; 198.51.100.23 ha inviato 312 messaggi e non ha superato né il test SPF né il test DKIM.
Per ogni record, acquisire il E L'indirizzo IP identifica il server che ha dichiarato di inviare i messaggi come se fosse il tuo dominio, mentre il conteggio mostra quanti messaggi sono stati inviati da quel server durante il periodo di riferimento del report.
Eseguite una ricerca DNS inversa su ogni indirizzo IP di origine sconosciuto. I mittenti legittimi si risolvono in nomi host riconoscibili (mail-sor-f41.google.com per Gmail, sendgrid.net per SendGrid e amazonses.com per AWS SES). Gli indirizzi IP non riconosciuti richiedono un'indagine approfondita prima di presumere che siano legittimi.
Passaggio 5: Verificare l'allineamento SPF e DKIM per ciascun mittente
All'interno di ogni record, trova il blocco. Contiene il risultato SPF e il risultato DKIM per quell'indirizzo IP di origine, insieme al dominio per ciascun metodo di autenticazione valutato.
DMARC richiede che solo uno tra SPF e DKIM passi in modalità allineata affinché il messaggio complessivo superi DMARC. Il campo mostra il verdetto finale (nessuno, quarantena o rifiuto) in base alla politica attiva durante il periodo di riferimento del report.
Segnala qualsiasi record in cui sia SPF che DKIM risultano non superati, se la sorgente dovrebbe essere un mittente legittimo. Si tratta di un mittente configurato in modo errato che deve essere corretto prima che la policy possa essere applicata in modo sicuro. Un record che mostra spf=fail ma dkim=pass è in genere corretto, poiché il messaggio supera comunque il controllo DMARC.
Cosa ti dice ciascun campo XML in un report DMARC
I report aggregati DMARC seguono la RFC 7489. Tutti i report conformi utilizzano la stessa struttura, indipendentemente dal provider di posta elettronica che li ha inviati. Utilizzare questo riferimento di campo durante la revisione di qualsiasi report:
- — l'organizzazione che ha inviato il report (Google, Microsoft, Yahoo, ecc.). Conferma quale provider di posta elettronica ha inviato il report. I provider più grandi in genere inviano report separati per ogni dominio.
- — Timestamp Unix per l'inizio e la fine del periodo considerato. La maggior parte dei report copre un intervallo di 24 ore, sebbene alcuni fornitori inviino report con minore frequenza.
- — la policy DMARC attiva durante la finestra (tag p) più le modalità di allineamento per SPF (aspf) e DKIM (adkim). L'allineamento rilassato (r) consente ai sottodomini di soddisfare l'allineamento; l'allineamento rigoroso (s) richiede una corrispondenza esatta.
- — l'indirizzo IP che ha inviato i messaggi. Eseguire una ricerca DNS inversa per identificare il servizio mittente.
- — il numero di messaggi inviati da questo indirizzo IP di origine durante il periodo di riferimento. Un numero elevato di messaggi provenienti da indirizzi IP sconosciuti è un campanello d'allarme.
- — il verdetto finale del DMARC: nessuno (nessuna azione intrapresa), quarantena (spostato nella cartella spam) o rifiuto (respinto).
- — I risultati di SPF e DKIM per la sorgente. Ciascuno mostra il dominio autenticato e un verdetto di superamento/fallimento. L'allineamento tra il dominio autenticato e il dominio di origine è ciò che determina se DMARC ha esito positivo nel complesso, non solo se SPF o DKIM hanno esito positivo singolarmente.
Cosa cercare nei report DMARC
Una volta che avrete familiarizzato con questi quattro schemi, i report DMARC diventeranno molto più facili da leggere. Invece di dover scandagliare una montagna di XML, potrete classificare ogni record in una categoria ben definita.
Mittenti legittimi che mostrano dmarc=pass
Se un mittente noto, come il tuo ESP, la piattaforma di marketing, l'help desk o il CRM, compare nel report con entrambi i tag dkim=pass e spf=pass, significa che la configurazione funziona correttamente per quella fonte.
Verificate che l'indirizzo IP di origine appartenga al provider previsto tramite DNS inverso, soprattutto per i record con un elevato numero di inoltri. È normale ricevere un volume elevato di email da un IP noto con dmarc=pass. Confermatelo una volta e utilizzatelo come riferimento per i report futuri.
Fonti sospette con un elevato numero di messaggi
Gli indirizzi IP sconosciuti che inviano centinaia o migliaia di messaggi con dmarc=fail rientrano in una di queste due categorie: mittenti non autorizzati che falsificano attivamente il tuo dominio, oppure un mittente legittimo dimenticato (un vecchio strumento di marketing, un'integrazione con un sistema IT ombra) che non è mai stato autenticato correttamente.
Effettua un'indagine controllando il WHOIS dell'indirizzo IP e i record DNS inversi. Un IP noto per lo spam di solito indica un tentativo di spoofing, mentre una piattaforma SaaS dimenticata di solito indica un problema di autenticazione. Questi due casi richiedono risposte diverse: bloccare o rifiutare la posta contraffatta, ma correggere l'allineamento SPF o DKIM per i mittenti legittimi.
SPF fallisce, ma DKIM passa: di solito l'inoltro
Un messaggio che non supera il controllo SPF ma supera il controllo DKIM spesso indica un problema di inoltro email. Il server di inoltro non è presente nel record SPF del mittente originale, quindi il controllo SPF fallisce. DKIM, tuttavia, funziona in modo diverso. Firma le intestazioni del messaggio e tale firma spesso rimane intatta quando l'email viene inoltrata. Ecco perché DKIM può comunque superare il controllo anche quando SPF fallisce.
DMARC ha esito positivo in generale quando SPF o DKIM sono allineati, quindi questi record non rappresentano un problema. Per i domini con destinatari che utilizzano l'inoltro di posta, questo è il comportamento previsto. Il report mostra come l'inoltro influisce sull'autenticazione, non un errore nella configurazione di DMARC.
Picchi improvvisi di traffico provenienti da indirizzi IP sconosciuti: solitamente si tratta di spoofing.
Un indirizzo IP precedentemente sconosciuto che improvvisamente invia un elevato volume di messaggi con SPF e DKIM falliti è la classica firma di spoofing. Qualcuno sta inviando email fingendosi proveniente dal tuo dominio attraverso la propria infrastruttura, tentando di aggirare i filtri antispam sfruttando i segnali di fiducia del tuo dominio.
Controlla l'IP negli strumenti di threat intelligence come AbuseIPDB o Cisco Talos. Se l'IP è collegato a spam o abusi, il picco è probabilmente dannoso. È in questo caso che diventa importante passare a p=reject. Una volta allineati tutti i mittenti legittimi, l'applicazione completa aiuta a bloccare la posta contraffatta prima che possa danneggiare la tua attività reputazione del mittente della posta elettronica.
Strumenti per analizzare e visualizzare i report DMARC
La maggior parte dei team passa dalla revisione manuale dei file XML a un parser automatizzato entro la prima settimana dalla ricezione dei report. La scelta dipende dal volume dei dati, dal budget e dal livello di approfondimento richiesto per l'analisi.
Per la maggior parte dei team che iniziano, MXToolbox per controlli manuali occasionali e Postmark DMARC Digests per il monitoraggio passivo rappresentano una combinazione pratica e gratuita. È consigliabile passare a un analizzatore dedicato come DMARCian quando il numero di domini o il volume giornaliero di report rendono impraticabile la revisione manuale.
Dalle segnalazioni all'azione: quando inasprire le politiche
Leggere i report DMARC è utile solo se li si utilizza per prendere decisioni. Il processo è semplice: identificare ogni mittente, correggere i problemi di allineamento e poi passare all'applicazione delle norme.
- Fase di inventario (settimane 1-4 a p=nessuno): Identifica ogni fonte legittima che invia come tuo dominio. Se una fonte necessita di lavoro di allineamento, completa il SPF, DKIM e DMARC impostazione prima di passare all'applicazione della legge.
- Fase di allineamento (settimane 4-8 a p=nessuno): Verificare che ogni fonte legittima superi i controlli SPF o DKIM con allineamento al dominio del mittente. Correggere eventuali fonti che non li superano aggiungendole a SPF, abilitando la firma DKIM o entrambe le cose. L'obiettivo, prima di passare alle misure di controllo, è raggiungere tassi di successo costantemente superiori al 95% per tutti i mittenti legittimi in più cicli di report consecutivi.
- Fase di applicazione (settimana 8+ a p=quarantena, poi p=respingimento): Una volta che i report mostrano un allineamento coerente senza errori di elevato volume da mittenti legittimi, passare a p=quarantine. Rimanere in questa posizione per 2-4 settimane e continuare il monitoraggio. Quindi passare a p=reject. Mantenere il monitoraggio a p=reject, poiché i nuovi mittenti aggiunti allo stack possono introdurre nuovi errori di allineamento.
Abbina il rafforzamento a una solida igiene delle liste in tutto il percorso. L'autenticazione conferma che l'e-mail proviene da te, mentre le liste pulite prevengono i tassi di bounce che danneggiano la reputazione indipendentemente dallo stato di autenticazione. La convalida delle liste prima degli invii importanti mantiene sotto controllo i tassi di bounce e pulizia della tua lista email I contatti obsoleti o non validi proteggono i segnali di reputazione che supportano ogni fase della progressione della politica.
Trasformare i dati DMARC in decisioni
I report aggregati DMARC sono dati operativi. L'obiettivo non è leggerli a fini teorici, ma agire in base a ciò che rivelano. Correggi i mittenti legittimi che non superano l'allineamento. Indaga sugli IP sconosciuti. Passa all'applicazione delle sanzioni una volta che le tue fonti attendibili superano regolarmente i controlli.
L'obiettivo è un report affidabile: fonti note, tassi di successo costanti e nessun picco improvviso di traffico proveniente da IP sconosciuti. Questa prevedibilità è ciò che rende p=reject sicuro, e p=reject è ciò che protegge il tuo dominio dall'impersonificazione.
Nell'ambito della fase di allineamento, convalida le tue liste di invio con DeBounce. Convalida dell'elenco e-mail Rimuove gli indirizzi non validi, temporanei e ad alto rischio dagli elenchi che alimentano i tuoi flussi di invio autenticati, mantenendo bassi i tassi di bounce e proteggendo la reputazione che stai costruendo tramite l'autenticazione. Carica il tuo elenco, rimuovi ciò che non appartiene al tuo gruppo e invia con la certezza che un'autenticazione sicura e dati puliti lavorano insieme.
