SPF DKIM DMARC pour les nuls

Fonctionnement du mail : la métaphore postale.
Quand vous écrivez une lettre vous êtes celui qui envoie le message.
Pour un mail, on appelle ça le From du message (RFC5322.From), l’adresse e-mail visible dans votre webmail ou lecteur.
Quand vous glissez votre lettre dans une enveloppe, vous indiquez au dos l’adresse en cas d’erreur de distribution.
Pour un mail, on appelle ça le From de l’enveloppe (RFC5321.MailFrom), cette adresse n’est pas visible mais figure dans les en-têtes masquées,
elle sert à recevoir les erreurs (bounce) mais également à transmettre le mail au serveur d’envoi.
Si vous êtes quelqu’un d’important, vous pouvez tamponner les rabats de l’enveloppe avec votre sceau,
ce qui prouvera que vous en êtes bien l’auteur et que l’enveloppe n’a pas été ouverte.
Pour un mail, on appelle ça la signature DKIM.

SPF


Le SPF est relié au From de l’enveloppe,
il indique si le mail a été envoyé par un serveur autorisé ou non.

Vous devez indiquer tous vos canaux d’envoi.
Votre site est sur un serveur dédié, l’IP de ce serveur :
v=spf1 ip4:1.2.3.4 ~all
et vos comptes mails sont chez OVH :
v=spf1 ip4:1.2.3.4 include:mx.ovh.com ~all
vous envoyez aussi à partir de Gsuite
v=spf1 ip4:1.2.3.4 include:mx.ovh.com include:_spf.google.com ~all

Le mécanisme « all » à la fin de l’enregistrement, indique que faire si le mail vient d’une adresse non listée.
all absent ou ?all (neutral) = les autres serveurs sont implicitement acceptés.
all ou +all (pass) = les autres serveurs sont explicitement acceptés.
-all (fail) = les autres serveurs sont refusés.
~all (fail) = les autres serveurs sont acceptés mais avec une note négative (spam, quarantaine).

À ce jour, il faut utiliser le mécanisme ~all.
En utilisant -all, le mail va être rejeté au niveau SMTP si son adresse IP n’est pas listée,
ce qui ne permet pas de tester l’authentification DKIM.
C’est le cas pour les redirections (forward) et pour les requêtes DNS sans résultat (délai ou autre) :
avec -all, le mail est rejeté
avec ~all sans DKIM ou DKIM invalide, le mail est en spam ou rejeté
avec ~all et DKIM valide, le mail est accepté.

Erreurs communes produisant un permerror.
Mutliples enregistrements (txt ou spf).
Espace ou guillemet ouvrant ("⠀v=spf1" ""v=spf1"");
Requêtes DNS > 10 (a mx include ptr exists redirect).
Méchanismes inconnus.
Mauvaises implémentations (a:1.2.3.4 mx:1.2.3.4 a: mx: exemple.com).
Méchanismes récursifs (include présent dans un include enfant).

Autres erreurs.
Lettres capitales.
Conformément à la définition de la notation ABNF dans [RFC5234], les noms utilisés ne sont pas sensibles à la casse,
cependant, certains analyseurs n’acceptent aucune capitale.
(RFC7208 Section 4.6.1).
Les requêtes DNS nulles sont limitées à 2,
cette limite est laissée au choix de l’analyseur et certains renvoient un permerror à la première requête sans résultat.
(RFC7208 Section 4.6.4).
Les adresses IP émettrices doivent avoir un enregistrement DNS inverse valide (PTR, reverse DNS) exigences pour les expéditeurs.

DKIM


La signature DKIM est liée au contenu du message, elle indique si celui-ci a été modifié ou non.
En cas de redirection, et donc de changement du From de l’enveloppe, la signature DKIM reste (normalement) puisqu’elle fait partie des en-têtes.
Cependant, les serveurs intermédiaires (antivirus, antispam ou autres) cassent aussi parfois la signature,
par exemple en ajoutant au sujet "spam vérifié", From de l’enveloppe changé SPF ko, signature cassée DKIM ko, le mail est rejeté.
Les mailing lists cassent également SPF et la signature DKIM en ajoutant leurs liens d’inscription en fin de mail.

ARC


Un petit mot sur ARC Authenticated Receivers Chain.
Dans la note sur DKIM, on voit que suite à une mauvaise configuration d’un serveur intermédiaire ou pour de légitimes raisons,
SPF DKIM et DMARC peuvent échouer, c’est là qu’intervient la chaîne d’authentification ARC.
Comment ça marche ?
Le premier serveur, qui reçoit le mail, valide (ou pas) SPF DKIM et DMARC et met le résultat dans une nouvelle en-tête ARC-Authentication-Results.
Deux autres en-têtes sont ajoutées ARC-Seal et ARC-Message-Signature pour confirmer que le résultat transmis a été fait par un intermédiaire de confiance et qu’il n’a pas été modifié.
Les serveurs intermédiaires suivants font de même en utilisant la chaîne ARC-Authentication-Results comme base et acheminent ainsi les résultats initiaux SPF DKIM DMARC jusqu’au serveur destinataire.
Intéressant en pratique ?
Si vous avez vos propres serveurs de mails, en l’état actuel, c’est non.
D’abord parce que la liste des intermédiaires de confiance ne sont pas pléthores (Fastmail, Google, Microsoft, Yahoo…),
si vous n’en faites pas partie, vos en-têtes ARC sont ignorées, et à raison, il suffit de deux serveurs pour construire une chaîne falsifiée.
Certains fournisseurs vous permettent d’ajouter des intermédiaires de confiance inconnus, Microsoft 365 par exemple, mais outre le côté fastidieux (c’est à faire par tenant), si l’intermédiaire ajouté se fait hacké…
Les mailing lists peuvent ajouter une en-tête Authentication-Results et vous pouvez vérifier si le mail a été modifié avant l’ajout des liens de la liste.
Pour simplifier, cela ne concerne que les gros fournisseurs de mails, entre eux.
D’autant que les hackers ont trouvé plusieurs brèches, via les comptes onmicrosoft.com (devrait être corrigé en octobre 2025) ou les groupes.


DMARC


La Poste a apporté le courrier, ok,
le sceau était toujours entier, ok,
mais rien ne me dit que c’est bien untel qui a écrit ce courrier et non un usurpateur.
DMARC va ajouté des liens entre ces différentes méthodes d’authentification.
Il va relier le From de l’enveloppe avec le From du message, s’ils sont différents, il y a erreur.
Il va aussi relier le domaine de la signature DKIM avec le From du message, s’ils sont différents, il y a erreur.
Pour l’instant, il suffit qu’un de ces deux liens soit bon pour que le mail soit accepté.
On indique par la règle « p » ce qu’il faut faire en cas d’erreur :
p=none, on accepte le mail
p=quarantine, on met le mail en spam et/ou on le note négativement (peu sûr)
p=reject, on refuse le mail

Importance d’un enregistrement DMARC, d’une politique et de l’analyse des rapports.
Sans enregistrement ou avec une politique à none, certains opérateurs appliquent une politique à quarantine.
La politique déclarée n’est pas permanente, selon les résultats SPF et DKIM (softfail, permerror),
une politique peut être augmentée (de none à quarantine, de quarantine à reject) ou diminuée (de reject à quarantine).
Seule l’analyse des rapports RUA, Reporting URI for Aggregate data, permet de comprendre comment le flux de mails est traité
et comment corriger ou adapter les enregistrements SPF et DKIM selon les canaux d’envoi.

DÉLIVRABILITÉ


1- envoi sans DMARC
nécessite
un enregistrement SPF pour le domaine d’envoi (RFC5321.MailFrom), même s’il n’est pas celui qui écrit le mail (RFC5322.From)
ou
une signature DKIM, même si celle-ci ne correspond pas au domaine qui écrit
sans correspondance entre les domaines, il y a de fortes chances pour que le mail soit classé en spam.

2- envoi avec DMARC
nécessite
un enregistrement SPF pour le domaine d’envoi qui doit correspondre au domaine qui écrit le mail
ou
une signature DKIM dont le domaine correspond au domaine qui écrit
la correspondance (ou alignement) entre les domaines s’effectue sur le domaine canonique, par exemple, info.domain1.fr est aligné avec domain1.fr
cet alignement peut être plus strict avec les tags adkim=s ou aspf=s, dans ce cas les deux domaines doivent être identiques

3- envoi en masse
nécessite
un enregistrement SPF pour le domaine d’envoi
ET
une signature DKIM
l’un ou l’autre doit correspondre au domaine qui écrit
ET
un enregistrement DMARC


À savoir
SPF et/ou DKIM ne permettent que de passer la première barrière, ensuite il y a toute une batterie d’analyseurs qui vont essayer de classifier le mail en spam ou non,
analyse du contenu, anti-spam, fréquence d’envoi, taux d’erreur, suppression des bounces…
Ces enregistrements sont devenus obligatoires pour les gros fournisseurs (Google, Microsoft, Yahoo…), il est encore possible d’écrire à @laposte.net ou @orange.fr sans aucun SPF et DKIM (novembre 2025),
mais qui n’a pas un gmail ou hotmail dans son carnet d’adresses.

SPOOFING USURPATION


Et voici pourquoi il ne faut pas utiliser les règles p=none ou sp=none de DMARC.
J’écris un mail avec comme From de l’enveloppe xxx@domain1.fr à partir du serveur 1.2.3.4,
le SPF de domain1.fr indique que 1.2.3.4 est autorisé à transmettre ses mails.
1ère authentification réussie.
Je signe le mail avec un DKIM au nom de domain1.fr ou même domain2.fr,
la signature est bonne, le contenu n’a pas été modifié.
2ème authentification réussie.
Enfin, j’utilise president@elysee.fr comme From du message.
Si elysee.fr a une règle DMARC p=none, qui veut dire en clair,
ce n’est pas moi qui ai transmis ce mail, ce n’est pas moi qui l’ai signé,
mais peu m’importe, donc le mail est accepté, et je vais pouvoir spammer à loisir en son nom.

SPF DKIM et DMARC sont généralement interprétés comme étant des mécanismes pour que les mails arrivent bien,
en fait, c’est pour que les spams utilisant votre nom n’arrivent pas.
J’ajoute que si votre règle est p=none et que les spammeurs utilisent votre nom,
votre réputation diminuera, et si vous ne modifiez pas votre politique en quarantine ou reject,
des organisations comme Spamhaus https://www.spamhaus.org/ augmenterons votre note négative,
au risque que la plupart de vos mails soient refusés.
Dit autrement, si on spamme en votre nom mais que vous avez des règles restrictives (quarantine, reject),
vous ne risquez rien vu que vous indiquez ce qu’il y a à faire,
les serveurs de réception savent qu’il faut refuser ces mails,
les spammeurs n’atteignent pas leurs cibles.

CAS DES SOUS-DOMAINES


Il n’y a pas d’héritage du domaine vers le sous-domaine pour SPF et DKIM,
si vous voulez écrire à partir de xxx@info.domain1.fr, il vous faudra
un enregistrement SPF spécifique
une signature DKIM spécifique.
Par contre, il y a un héritage pour DMARC, s’il n’y a pas d’enregistrement spécifique,
la règle « sp= » du domaine parent sera appliquée et en son absence la règle « p= ».
Pour simplifier, il vaut mieux ajouter une règle sp=reject au DMARC du domaine principal,
et créer un enregistrement spécifique au besoin.

Modifications DMARC 2.0 fin 2025 (DMARCbis)


Tags rendus obsolètes :

pct, pourcentage de mails régulés, 100 par défaut.
Exceptés 0 et 100, impossible de savoir si c’est respecté.

rf, format des rapports, afrf par défaut, iodef inutilisé.
Il n’y a que le format afrf d’utiliser, donc inutile.

ri, intervalle d’envoi des rapports en secondes, 86 400 (1 jour) par défaut.
Les autres valeurs étaient, en pratique, peu ou pas du tout respectées.

Nouveaux tags.

t, mode test, n (non) par défaut, y (oui).
Remplace le tag pct sans ambiguïté.

np, règle pour un sous-domaine inexistant.
Si le tag est omis, il prend la valeur de sp, si présent, sinon de p.
Pourqoi ce tag np.
Quand un domaine n’existe pas, les serveurs authoritatifs doivent répondre avec le statut NXDOMAIN, pour non-existant domain,
on sait que le domaine n’existe pas (et donc aucun sous-domaine) ou que le sous-domaine n’existe pas ;
les caches des résolveurs DNS peuvent induire en erreur en ne renvoyant aucun statut, cela permet de protéger les sous-domaines dans ce cas.

psd, Public Suffix Domain, u (selon arborescence DNS) par défaut, n (non, domaine canonique), y (oui, sous-domaines canoniques).

1- Définition de PSD Public Suffix Domains
Les suffixes publics des noms de domaines sont les suffixes des domaines parents de premier niveau, par exemple : fr, com, org, et de second niveau : asso.fr, tm.fr.
Un domaine parent est un domaine qui n’existe pas en propre (pour le web ou les mails) et qui n’a que des sous-domaines.

2- Définition de PSL Public Suffix List
La liste des suffixes publics est un annuaire regroupant tous les domaines parents de premier et second niveau (Top Level Domain TLD),
mais avec la multiplication des domaines publics ou privés, il n’est pas toujours complet.

asso.fr est un domaine parent de second niveau qui n’existe pas en propre, il n’a que des sous-domaines.

cci.fr, par contre, est à la fois un domaine qui existe en propre (le premier niveau étant .fr) et un domaine parent de second niveau ayant des sous-domaines.
https://www.cci.fr/
https://www.nom-domaine.fr/cci.fr.html
https://www.essonne.cci.fr/

3- Pourqoi est-ce important pour DMARC
Quand on veut évaluer une politique DMARC, on demande l’enregistrement correspondant au domaine qui envoie le mail (RFC5321.MailFrom),
si aucun enregistrement n’est trouvé, on fait une nouvelle demande pour le domaine canonique (ou organisationnel).

Un mail est envoyé par xxx@info.domain1.fr, la première requête va porter sur _dmarc.info.domain1.fr, si aucune réponse la seconde requête portera sur _dmarc.domain1.fr,
il n’y a pas d’ambiguïté, c’est bien la politique de domain1.fr qui sera appliquée.

Pour écourter le nombre de requêtes, il n’y en a que 2, les millisecondes ça compte (> 500, temperror assurée), une pour le sous-domaine d’envoi (même si c’est un sous sous-domaine, newsletter.info.domain1.fr), une pour le domaine canonique (domain1.fr).
Il est prévu de passer à 8 requêtes pour ceux qui utilisent une dizaine de sous-domaines, essentiellement les services d’envoi de mails (Brevo, Mailchimp, Mailjet…).
Si le domaine d’envoi utilise 15 sous-domaines, 1 requête pour le 15ème sous-domaine, puis on zappe les sous-domaines intermédiaires jusqu’au 7ème, puis 1 requête pour chaque sous-domaine suivant jusqu’au domaine canonique, selon la PSL ou si le tag psd=n est trouvé.

Ce parcours de l’arborescence DNS n’est pas adapté pour les domaines qui existent en propre et comme domaine parent de second niveau.

Un mail est envoyé par xxx@info.essonne.cci.fr, si l’enregistrement _dmarc.info.essonne.cci.fr n’existe pas et que cci.fr n’est pas dans la liste des suffixes parents (PSL),
la requête suivante portera sur _dmarc.cci.fr, et on va appliquer une politique qui ne correspond pas au domaine qui envoie le mail.

4- Pour lever toute ambiguïté, le tag PSD
cci.fr utilisera le tag psd=y, qui veut dire, je suis un domaine qui existe en tant que tel et qui est aussi un domaine parent de second niveau,

essonne.cci.fr utilisera le tag psd=n, qui veut dire, je suis LE domaine canonique (organisationnel), ne pas requêter cci.fr.

Sans ce tag psd, il faut espérer que le domaine cci.fr soit bien déclaré dans la liste des suffixes parents (PSL), ET que le serveur de réception maintienne cette liste à jour.



Autre modification.
Les domaines tiers déclarés pour la réception des rapports DMARC (rua=mailto:xxx) doivent avoir un enregistrement spécifique _report._dmarc "v=DMARC1".
Aujourd’hui, les vérifications ne sont généralement pas effectuées, elles vont devenir obligatoires.


RFC


RFC 8616 text

RFC 8616 html


Outils SPF


SPF Checker

SPF Policy Tester

SPF Record Testing Tools


Outils DKIM


DKIM Record Check

DKIM Record Checker

DKIM Validator


Outils DMARC


DMARC Check Tool

DMARC Policy Validator

DMARC Record Lookup


Analyse des rapports DMARC en français


En direct

DMARC ASSIST

DMARC None Record


Sur inscription

DMARC ASSIST

DMARC None Report


Ajouter un service d’analyse DMARC en français

Crédits


Drapeaux du monde drapeauxdespays.fr
David Krmela

Export PDF wkhtmltopdf
Ashish Kulkarni, Jakob Truelsen

Géolocalisation IP DBIP
Eris Networks S.A.S

Illustrations iStock
Getty Images

Public Suffix List PSL
Mozilla, registres, bénévoles

Requêtes DNS Pear Net_DNS2_Resolver
Mike Pultz

Vérification de la signature DKIM Perl Mail::DKIM::Verifier
Marc Bradshaw


Modification DNS

OVH - paramétrage DMARC




Usurpation échouée
Received: from unknown (HELO abaxe.net) (62.60.130.76)
RFC5322.From:abaxe.net
RFC5321.MailFrom:abaxe.net
SPFnon aligné [softfail]
DKIM header.d:abaxe.net
non signé
DMARC policyreject
DMARC dispositionreject [rejeté]
Envoi sans DMARCdélivré [en spam]
Envoi en masserejeté
Avec enregistrement DMARC, le mail est refusé.
Sans enregistrement DMARC, le mail est accepté, potentiellement en spam.

Erreur sur l’envoi d’un formulaire
Hi. This is the mail-send program at ns1.server.com
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<info@siteweb1001.fr> 83.166.143.57 failed after I sent the message.
Remote host said: 550 5.7.1 rejected by DMARC policy for yahoo.fr

--- Below this line is a copy of the message.

Received: from unknown (HELO ns1.server.com) (1.2.3.4)
Return-Path: <postmaster@siteweb1001.fr>
To: info@siteweb1001.fr
Subject: Formulaire de contact
From: siteweb <tagada@yahoo.fr>

L’adresse IP 1.2.3.4 est autorisée par le SPF de siteweb1001.fr
Le mail a une signature DKIM valide pour siteweb1001.fr

Infomaniak (MX de siteweb1001.fr) refuse le mail, puisque
le SPF de yahoo.fr n’autorise pas l’adresse IP 1.2.3.4
le mail n’a pas de signature DKIM pour yahoo.fr

Les paramètres d’envoi du formulaire doivent être
Return-Path: <postmaster@siteweb1001.fr>
To: info@siteweb1001.fr
Subject: Formulaire de contact
From: siteweb <postmaster@siteweb1001.fr>
Reply-To: <tagada@yahoo.fr>

Usurpation échouée
Return-Path: <---@planete-aventure.fr>
Received: from [91.98.177.41] (54.18.23.93.rev.sfr.net [93.23.18.54])
by nc-smtp1.sdv.fr (Postfix) with ESMTP id 71D642215D
for <---@outlook.com>; Sun, 9 Nov 2025 14:05:29 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============1503998954182585733=="
MIME-Version: 1.0
From: ---@planete-aventure.fr
To: ---@outlook.com

<---@outlook.com>: host
outlook-com.olc.protection.outlook.com[52.101.124.116] said: 550 5.7.509
Access denied, sending domain [PLANETE-AVENTURE.FR] does not pass DMARC
verification and has a DMARC policy of reject.
[DB8P193MB0757.EURP193.PROD.OUTLOOK.COM 2025-11-09T13:21:41.722Z
08DE1ECD601B77E4] [TYCP286CA0354.JPNP286.PROD.OUTLOOK.COM
2025-11-09T13:21:36.466Z 08DE1F1F67257D8F]
[TY2PEPF0000AB8A.apcprd03.prod.outlook.com 2025-11-09T13:21:41.828Z
08DE1E7E0AF11064] (in reply to end of DATA command)

Usurpation réussie
From - Sun Nov 16 05:55:17 2025
Return-Path: <baoguan@hotmail.com>
Received: (qmail 124312 invoked by uid 89); 16 Nov 2025 04:42:29 -0000
Message-ID: <20251116044229.124311.qmail@ns200.abaxe.com>
Delivered-To: ---@abaxe.com
Received: (qmail 124308 invoked by uid 89); 16 Nov 2025 04:42:29 -0000
Received: from unknown (HELO hotmail.com) (112.96.59.255)
by ns200.abaxe.com with SMTP; 16 Nov 2025 04:42:28 -0000
Received-SPF: fail (ns200.abaxe.com: SPF record at _spf-ssg-c.microsoft.com does not designate 112.96.59.255 as permitted sender)
From: =?GB2312?B?wdbPyMn6?= <baoguan@hotmail.com>
Subject: =?GB2312?B?tPq/qreixrExMzUzODcxOTY3Mw==?=
To: ---@abaxe.com
Content-Type: text/plain;charset="GB2312"
Content-Transfer-Encoding: 8bit
Date: Sun, 16 Nov 2025 12:42:30 +0800
X-Priority: 3
X-Mailer: Foxmail 4.2 [cn]

112.96.59.255, China Unicom Guangdong province network

_dmarc.hotmail.com
v=DMARC1; p=none; rua=mailto:rua@dmarc.microsoft;ruf=mailto:ruf@dmarc.microsoft;fo=1:s:d
p=none, le mail est accepté, potentiellement en spam.