Lettore di report DMARC

Un conteggio giornaliero da ogni provider di posta

Un record DMARC è una riga nel DNS del tuo dominio. Uno dei suoi tag, rua=mailto:reports@yourdomain.com, chiede a ogni provider che riceve posta che dice di venire dal tuo dominio di inviare un riepilogo a quell’indirizzo. Google, Microsoft, Yahoo e molti altri lo fanno, di solito una volta ogni 24 ore.

Questi report “aggregati” non contengono il testo dei messaggi né i nomi dei destinatari, solo conteggi. Ogni riga dice che un indirizzo IP ha inviato un certo numero di messaggi con il tuo dominio nella riga From, e che esito hanno avuto quei messaggi:

<record>
  <row>
    <source_ip>198.51.100.24</source_ip>
    <count>312</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>yourdomain.com</header_from></identifiers>
  <auth_results>…</auth_results>
</record>

Un solo dominio con qualche servizio di invio riceve facilmente diversi file al giorno, ognuno con decine di righe. Il lettore li somma al posto tuo.

Perché un pass può comunque fallire: l’allineamento

DMARC si appoggia su due controlli più vecchi. SPF chiede se il server mittente è autorizzato a inviare per il dominio dell’indirizzo di ritorno nascosto. DKIM chiede se il messaggio porta una firma valida di un qualche dominio. Nessuno dei due guarda la riga From che una persona legge.

È DMARC a fare il collegamento. Un messaggio supera DMARC quando SPF o DKIM passano per un dominio che corrisponde alla riga From. Questa corrispondenza si chiama allineamento. Un servizio di newsletter può superare SPF per il proprio dominio e firmare ogni messaggio con la propria chiave DKIM, e fallire comunque DMARC per te, perché nessuno dei due risultati nomina il tuo dominio.

In un report, policy_evaluated contiene i risultati allineati e auth_results quelli grezzi con i domini coinvolti. Il lettore usa i primi per le etichette “Allineato” e stampa i secondi come piccole note sotto, così vedi quale dominio è passato.

Come il lettore classifica i mittenti

Le righe vengono unite per indirizzo IP su tutti i file che trascini, poi raggruppate per servizio. Se l’opzione dei nomi è attiva, il nostro server cerca il nome DNS inverso e il proprietario della rete di ogni indirizzo. Una trentina di servizi comuni, da Google e Microsoft 365 a SendGrid, Mailchimp e Amazon SES, vengono riconosciuti da quei nomi. Ogni indirizzo riceve una di cinque etichette:

Il riepilogo in alto dà il volume totale, la quota conforme (verde dal 98%, arancione dal 75%), il numero di messaggi da mittenti sconosciuti e la policy che secondo i report pubblichi.

Dalla tabella a una policy applicata

1. Correggi ogni gruppo “da correggere”. Nelle impostazioni del servizio, cerca “autenticazione del dominio”, “dominio di invio” o “DKIM”. Ti darà due o tre record DNS da pubblicare, di solito CNAME. Una volta attivi, il servizio firma con il tuo dominio e le righe diventano verdi nei report successivi.
2. Lascia stare gli inoltri. Non puoi riparare ciò che ritrasmette un terzo. Queste righe restano poche.
3. Rendi più severa la policy. Quando i tuoi mittenti sono conformi da due a quattro settimane, cambia p=none in p=quarantine, e più avanti in p=reject. Un tag pct sotto 100 applica la policy solo a quella quota della posta che fallisce. Alla fine toglilo.

Per controllare il record stesso c’è la verifica SPF, DKIM e DMARC. Per scriverne uno nuovo, usa il generatore di record.

Il formato ha i suoi limiti. Un report copre solo i provider che inviano report e solo il periodo del suo intervallo di date, e non ti dice mai a quale persona o campagna apparteneva un messaggio. Il lettore accetta fino a 200 file alla volta, 50 MB ciascuno, e ignora i duplicati.