Les enregistrements DNS de type SPF et DMARC servent à essayer d’assurer la bonne provenance d’un mail en identifiant l’IP du serveur qui a envoyé le message (SPF), et en définissant des attitudes à adopter dans le cas d’un échec (DMARC).
Il est aussi possible de signer cryptographiquement des messages (DKIM), mais ceci n’est pas couvert ici.

SPF

Un enregistrement spf est de type TXT, s’applique au (sous-)domaine dont on veut essayer de légitimer les mails. Il peut ressembler à ceci, pour example.com :

v=spf1 mx ip4:1.2.3.4 include:spf.fournisseurmailing.fr -all

• v= déclare la version
• mx déclare que tous les serveurs MX de example.com ont le droit d’envoyer des mails en tant que someone@example.com
• ip4: déclare une adresse (ou une plage grâce à un masque) qui a le droit d’envoyer des mails
• include: donne une (sous-)domaine sur lequel aller chercher un enregistrement spf qui déclarerait encore d’autres entrées.

Danc cet exemple, via l’entrée include, tous les serveurs que mon fournisseur de mailing-list a lui-même autorisé via le paramétrage spf de son domaine on le droit d’envoyer des mails en notre nom. On peut vérifier le contenu de ce spf via la commande dig TXT spf.fournisseurmailing.fr.

Le -all sert à définir strictement ces serveurs autorisés, voir cette page.

Dans un cas où il y’aurait besoin d’entrer beaucoup d’adresses ip différentes, cela peut ne pas rentrer dans un seul champ DNS. Il est alors possible de se créer un sous-domaine (par exemple spf.example.com), qui sera inclus dans le spf principal.
Par exemple, pour example.com :

v=spf1 mx ip4:1.2.3.4 ip4:5.6.7.8 ip4:9.10.11.12 include:spf.example.com -all

et pour spf.example.com

v=spf1 ip4:188.12.0.0/16 -all

pour autoriser les adresses IP 1.2.3.4 , 5.6.7.8 , 9.10.11.12 ainsi que toutes les adresses de type 188.12.X.X à envoyer des mails au nom de example.com

Attention, il ne faut toutefois pas déclencher plus 10 requêtes DNS pour évaluer le SPF (y compris les requêtes DNS provoquées par des entrées au sein d’un include).

DMARC

DMARC est apparu après, et a pour objectif de dire aux serveurs qui reçoivent des mails d’une adresse nous appartenant comment recouper les tests SPF et/où DKIM, et quelle action appliquer dans le cas d’un échec.

Ceci se fait également sous la forme d’une entrée DNS, qui doit être appliquée au domaine _dmarc.example.com, et est aussi une entrée TXT.

Elle peut ressembler à ceci :

v=DMARC1; p=quarantine; pct=100; sp=quarantine; aspf=s; adkim=r;

• v= déclare la version
• p= déclare la politique à appliquer en cas d’échec, pour une adresse du domaine. Peut être none, quarantine ou reject
• pct= déclare le pourcentage de mails auxquels on doit appliquer ce filtrage (permet de l’appliquer au fur et à mesure)
• sp= déclare la politique à appliquer en cas d’échec pour une adresse d’un sous-domaine
• aspf= déclare l’alignement concernant SPF. Peut être r (relaxed) ou s (strict)
• adkim= déclare l’alignement concernant DKIM.

Par défaut, le DMARC est passé lorsque soit DKIM soit SPF passe avec succès. Si l’un de ces 2 alignements est défini sur strict, alors il devra être passé avec succès pour que DMARC soit validé.

On peut aussi voir dans des mails une en-tête de type Authentication-Results qui contient les résultats d’un analyse ARC. Elle peut notamment contenir les chaînes dmarc=pass spf=pass dkim=none par exemple. Cette chaîne ARC peut être mise en place lors du transfert d’un mail (par ex liste de diffusion)