Creiamo un record DMARC per definire le azioni da eseguire nel caso in cui i controlli SFP e DKIM falliscano.

di Giulio di Bari :: 22 maggio 2018

Abbiamo già visto in precedenti articoli come massimizzare della deliverability delle email attraverso la configurzione di un record SPF, per rafforzare la reputazione del mittente, ed un record DKIM, per verificare l’autenticità del contenuto della mail.

In questo articolo ci occupiamo di quali azioni eseguire nel caso in cui i controlli SFP e DKIM falliscano, cioè nel caso in cui la mail risultasse falsificata o non autenticata.

A questo scopo occorre creare un record DMARC (Domain-based Message Authentication, Reporting & Conformance)

Il DMARC è un sistema che indica ai server, che ricevono le mail provenienti dal nostro dominio, quale azione eseguire sui messaggi che apparentemente provengono dal nostro dominio, ma che non sono autenticati, cioè che non superano i controlli effettuati tramite SPF e DKIM. In poche parole, se vanno rifiutati, o se vanno messi in spam, o se non bisogna fare nulla.

Per fare questo viene creata una "policy", cioè una azione da intraprendere qualora i controlli SPF e DKIM falliscano, e questo viene fatto attraverso la creazione di un record DNS sul dominio della nostra email (dove già abbiamo creato i record DNS per SPF e DKIM).

Inoltre il DMARC consente di ricevere via email un report delle azioni eseguite in formato XML.

Vediamo subito come implementarlo!

Nel pannello della gestione DNS del vostro dominio "miosito.it" aggiungete un record TXT:

come "nome" del record indicate "_dmarc.miosito.it"
come "valore" indicate una stringa come questa "v=DMARC1; p=none; rua=mailto:postmaster@miosito.it"

Vediamo nel dettaglio i parametri indicati:

v: è un parametro obbligatorio ed è la versione del protocollo (DMARC1).
p: è un parametro obbligatorio ed indica è l'azione da eseguire.
I possibili valori sono i seguenti
"none": non fare nulla, cioè nessun avviso specifico sarà dato al server di posta di destinazione
"quarantine": contrassegna i messaggi come spam, cioè avvisa il server di posta di destinazione di trattare qualsiasi email che fallisce il test DKIM e/o SPF come sospetta ed esegue controlli aggiuntivi. La gran parte di queste e-mail finirà quindi nella cartella spam del destinatario
"reject": non consegnare il messaggio, cioè avvisa il server di posta di destinazione di rifiutare qualsiasi email che fallisce il test DKIM e/o SPF
rua: è un parametro facoltativo ed indica l'indirizzo email a cui verranno inviati i report giornalieri aggregati, quindi sintetici, sulle azioni eseguite

Esistono altri parametri facoltativi:

pct: , valore compreso tra 0 e 100, indica la percentuale di messaggi sottoposta al filtro (es. pct=20 indica che il 20% dei messaggi saranno soggetti all'azione scelta, come il "quarantine")
ruf: indica la mail a cui inviare "report forensi" , cioè report dettagliati (e non sintentici come per il parametro "rua") sulle azioni eseguite
sp: indica l'azione da eseguire per i sottodomini del dominio. I possibili valori sono gli stessi del parametro "p": reject, quarantine, none
aspf: si riferisce alla "modalità di allineamento per SPF", e cioè alla precisione con cui i record del mittente vengono confrontati con SPF.
I valori possibili sono:
"r" ("relaxed"), consente corrispondenze parziali, ad esempio solo i sottodomini di un determinato dominio. E' il valore di default.
"s" ("strict"), richiede una corrispondenza esatta
adkim: si riferisce alla "modalità di allineamento per DKIM"
I valori possibili sono:
"r" ("relaxed"): è il valore di default
"s" ("strict")
rf: definisce il formato dei report
I valori possibili sono:
"afrf": Il formato del messaggio per il report degli errori (Abuse Report Format) è definito dall’RFC 5965
"iodef": Il formato del messaggio per il report degli errori (Incident Object Description Exchange Format) è definito dall’RFC 5070
ri: definisce l’intervallo di tempo, in secondi, tra l'invio di un report DMARC e l'altro. Se non indicato, il valore di default è 86400, cioè 1 giorno.

Sulla base di quanto detto ecco alcuni esempi di record DMARC.

Non compiere nessuna azione

"v=DMARC1; p=none; rua=mailto:postmaster@miosito.it"

In questo record TXT, se un messaggio si presenta come proveniente dal tuo dominio ma non supera i controlli DMARC, non viene eseguita alcun azione.
Tutti i messaggi interessati in ogni caso verranno inseriti nel report giornaliero inviato a "postmaster@miosito.it".

Messa in quarantena del messaggio

"v=DMARC1; p=quarantine; pct=6; rua=mailto:postmaster@miosito.it"

In questo caso, se un messaggio si presenta come proveniente dal tuo dominio ma non supera i controlli DMARC, viene messo in quarantena, cioè considerato spam, il 6% delle volte. I report giornalieri vengono inviati a "postmaster@miosito.it".

Rifiuto del messaggio

"v=DMARC1; p=reject; rua=mailto:postmaster@miosito.it, mailto:pippo@miosito.it"

In questo caso, se un messaggio si presenta come proveniente dal tuo dominio ma non supera i controlli DMARC, viene rifiutato. I report giornalieri vengono inviati a "postmaster@tuo_dominio.com" ed a "dmarc@tuo_dominio.com" (le email vanno separate da una virgola).

Verifica configurazione

Dopo la configurazione, possiamo verificare il DMARC utilizzando ad esempio MXtoolbox.com

Il report XML

I report XML hanno una grande utilità, in quando aiutano gli amministratori:

a verificare che i vari IP che inviano email che provengono dal tuo dominio siano effettivamente legittimati a farlo
a garantire che le origini della posta in uscita siano autenticate correttamente
a intervenire rapidamente qualora si verifichiano problemi di configurazione di DKIM o di SPF.

Questo un estratto di un report XML

<record>
    <row>
        <source_ip>207.126.144.129</source_ip>
        <count>1</count>
        <policy_evaluated>
            <disposition>none</disposition>
        </policy_evaluated>
    </row>
    <identities>
        <header_from>miosito.it</header_from>
    </identities>
    <auth_results>
        <dkim>
            <domain>miosito.it</domain>
            <result>pass</result>
            <human_result></human_result>
        </dkim>
        <spf>
            <domain>miosito.it</domain>
            <result>pass</result>
        </spf>
    </auth_results>
</record>

<record>
<row>
    <source_ip>207.126.144.131</source_ip>
    <count>1</count>
    <policy_evaluated>
        <disposition>none</disposition>
        <reason>
            <type>forwarded</type>
            <comment></comment>
        </reason>
    </policy_evaluated>
</row>
<identities>
    <header_from>miosito.it</header_from>
</identities>
<auth_results>
    <dkim>
        <domain>miosito.it</domain>
        <result>pass</result>
        <human_result></human_result>
    </dkim>
    <spf>
        <domain>miosito.it</domain>
        <result>pass</result>
    </spf>
</auth_results>
</record>

In questo esempio viene mostrato il risultati per i messaggi inviati da due indirizzi IP (source ip) 207.126.144.129 e 207.126.144.131), uno inviato direttamente e l'altro inoltrato (<type>forwarded</type>). In entrambi i casi il controllo è stato superato con successo (<result>pass</result>).