Enregistrement SPF et DMARC : créer, tester et corriger

Pourquoi SPF et DMARC

Depuis 2024, Google et Yahoo exigent DMARC des expéditeurs en masse, ceux qui envoient 5 000 emails par jour ou plus. Chez Google, depuis février 2024, ces expéditeurs doivent avoir configuré SPF, DKIM et DMARC. Sans authentification, vos emails risquent davantage d’arriver en spam ou d’être rejetés. Ces enregistrements protègent aussi votre domaine contre l’usurpation : sans eux, n’importe qui peut envoyer des emails qui semblent venir de chez vous.

Sur le .fr, l’Afnic mesure en 2025 un taux d’adoption de 69,0 % pour SPF, de 40,7 % pour DKIM et de 19,5 % seulement pour DMARC.

Mettez-les en place dans cet ordre, chacun s’appuyant sur le précédent : SPF pour autoriser vos serveurs d’envoi, DKIM pour signer vos emails, DMARC pour fixer la politique en cas d’échec (en commençant par p=none), puis, si vous le souhaitez, BIMI pour afficher votre logo. Ce guide couvre SPF et DMARC. Pour DKIM, le test DKIM vérifie que votre clé publique est publiée.

L’enregistrement SPF

SPF (Sender Policy Framework) définit les serveurs autorisés à envoyer des emails pour votre domaine. Les serveurs de réception lisent votre enregistrement SPF et vérifient que l’adresse IP du serveur d’envoi y figure. C’est un enregistrement TXT publié sur le domaine lui-même, dont la valeur commence par v=spf1.

v=spf1 include:_spf.google.com include:sendgrid.net ~all

• v=spf1 : la version, toujours en premier.
• include: : autorise les serveurs d’un service d’envoi (ici Google Workspace et SendGrid). Chaque service vous donne le sien.
• ip4: et ip6: : autorisent une adresse IP ou une plage d’adresses.
• ~all (softfail) : signale comme suspects les serveurs non listés. -all (hardfail) les marque en échec. N’utilisez jamais +all : il autorise tous les serveurs du monde.

Faut-il finir par ~all ou -all ? Avec ~all, c’est DMARC qui décide du sort des emails non autorisés. Sans politique DMARC stricte, un softfail n’arrête donc rien. Notre test SPF valide -all, et ne valide ~all que si DMARC est à p=quarantine ou p=reject. Ne passez pas à -all avant d’avoir vérifié tous vos expéditeurs : vos emails légitimes seraient rejetés.

Un seul enregistrement SPF par domaine

La RFC 7208 autorise un seul enregistrement v=spf1 par domaine. Avec deux, les serveurs de réception renvoient une permerror et SPF échoue. Cela arrive souvent quand le guide de configuration d’un nouveau fournisseur demande « d’ajouter » un enregistrement SPF : fusionnez plutôt ses include dans l’enregistrement existant et supprimez l’autre. En 2023, l’Afnic relevait que 99,16 % des domaines .fr qui publient SPF ont exactement un enregistrement TXT contenant une politique SPF.

Les oublis les plus courants

• Un service d’envoi absent de l’enregistrement : votre ESP, votre CRM ou votre outil de support envoie en votre nom sans y figurer.
• Les emails transactionnels oubliés : le service qui envoie vos emails marketing (par exemple Mailchimp) est listé, celui qui envoie vos emails transactionnels (par exemple Resend ou Postmark) ne l’est pas.
• Trop de requêtes DNS, voir la section suivante.

SPF seul ne protège pas votre adresse From. Il vérifie l’expéditeur d’enveloppe (le Return-Path), pas l’adresse que voient les destinataires. C’est DMARC qui relie les deux.

La limite de 10 requêtes DNS

La RFC 7208 plafonne une évaluation SPF à 10 termes qui demandent une requête DNS : include, a, mx, ptr, exists et redirect, comptés à travers chaque include imbriqué. ip4 et ip6 ne coûtent rien. Au-delà de 10, les serveurs de réception renvoient une permerror et SPF échoue pour tous vos emails.

Le piège : un include peut en contenir d’autres, et chacun compte. Pour revenir sous la limite, supprimez les include des services que vous n’utilisez plus, ou déplacez un expéditeur sur son propre sous-domaine (par exemple news.yourdomain.com) avec son propre enregistrement SPF.

La RFC limite aussi les requêtes DNS vides (void lookups), les include ou redirect dont la cible ne publie aucun enregistrement SPF : au-delà de 2, c’est aussi une permerror. Le test SPF compte les deux.

L’enregistrement DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) indique aux serveurs de réception que faire quand un email échoue à SPF et à DKIM, et leur demande de vous envoyer des rapports agrégés. C’est un enregistrement TXT publié sur _dmarc.yourdomain.com. Pour commencer :

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Et l’objectif, une fois vos sources authentifiées :

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

v=DMARC1

La version. Obligatoire, et toujours en premier.

p=

La politique pour le domaine : none (surveillance seule), quarantine (placer en quarantaine) ou reject (rejeter).

rua=

L’adresse de rapport qui reçoit les rapports agrégés, par exemple mailto:dmarc@yourdomain.com. Sans elle, vous ne saurez jamais ce qui échoue.

pct=

Le pourcentage des emails en échec auquel la politique s’applique. En dessous de 100, une partie des emails en échec relève de la politique inférieure.

sp=

La politique des sous-domaines qui n’ont pas leur propre enregistrement DMARC. Absente, les sous-domaines reprennent p=.

adkim= / aspf=

Le mode d’alignement pour DKIM et pour SPF : r, relaxed (souple), la valeur par défaut, ou s, strict.

L’alignement

Un email échoue à DMARC quand ni SPF ni DKIM ne réussit pour un domaine aligné sur le domaine From, celui que voit le destinataire. Il suffit que l’un des deux réussisse et soit aligné.

• Alignement SPF : le domaine From est comparé au domaine d’enveloppe (Return-Path). Le transfert d’un email le casse en général.
• Alignement DKIM : le domaine From est comparé au domaine qui a signé l’email (le d= de la signature). Il résiste au transfert, c’est pourquoi DKIM aligné est le plus robuste des deux.
• relaxed (souple) ou strict : en mode relaxed, la valeur par défaut, mail.acme.com est aligné sur acme.com. En mode strict, les domaines doivent être identiques, ce qui casse souvent des expéditeurs légitimes sur un sous-domaine. Sauf raison précise, gardez le mode relaxed.

Les trois politiques

• p=none (surveillance seule) : rien ne change pour la distribution. Les emails en échec sont distribués normalement, mais vous recevez les rapports. C’est par là que tout le monde commence, et cela ne protège pas contre l’usurpation.
• p=quarantine : les emails en échec sont traités comme suspects, en général placés en spam plutôt que dans la boîte de réception.
• p=reject : les emails en échec sont rejetés dès l’échange SMTP et n’arrivent jamais au destinataire. C’est la protection la plus forte contre l’usurpation.

L’Afnic appelle politique DMARC stricte p=quarantine sans terme pct, p=quarantine avec pct=100, ou p=reject. C’est le niveau qu’exige BIMI.

Votre politique est une demande, pas un ordre. Un fournisseur de messagerie peut distribuer quand même un email en p=reject venant d’une source à bonne réputation, ou placer en quarantaine un email qui a réussi. Les rapports agrégés notent ce qu’il a réellement fait (disposition) à côté de la politique que vous avez publiée.

Sous-domaines et domaines sans email

L’enregistrement DMARC de _dmarc.acme.com couvre le domaine organisationnel et tous ses sous-domaines, sauf ceux qui publient leur propre enregistrement DMARC. Pour un email venant de news.acme.com, le serveur de réception cherche d’abord _dmarc.news.acme.com. S’il n’existe pas, il prend la balise sp= de _dmarc.acme.com, et, sans sp=, la balise p=.

v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc@acme.com

Ici, un email en échec venant de acme.com est placé en quarantaine, et un email en échec venant de n’importe quel sous-domaine est rejeté. Les usurpateurs aiment les sous-domaines sans protection : rien ne les empêche d’envoyer de fausses factures depuis billing.acme.com si votre politique ne les couvre pas.

Pour un domaine qui n’envoie aucun email, verrouillez tout : aucun serveur autorisé et un échec franc, pour que rien ne puisse réussir.

SPF :   v=spf1 -all
DMARC : v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@acme.com

Créer les enregistrements chez OVHcloud, Gandi et Infomaniak

Les étapes ci-dessous sont celles que donne la documentation de chaque hébergeur. Ailleurs, le principe est le même : un enregistrement TXT sur le domaine pour SPF, un enregistrement TXT sur le sous-domaine _dmarc pour DMARC.

OVHcloud

1. Dans l’espace client, ouvrez Web Cloud > Noms de domaine, sélectionnez votre domaine, puis l’onglet Zone DNS.
2. Cliquez sur Ajouter une entrée au-dessus du tableau et choisissez le type SPF : un formulaire construit l’enregistrement champ par champ. Pour saisir vous-même la valeur complète, choisissez plutôt le type TXT. Pour modifier un enregistrement existant, ouvrez son menu ⋮ puis Modifier l’entrée.
3. Pour DMARC, choisissez le type DMARC. Le champ du sous-domaine doit commencer par _dmarc : pour le domaine entier, saisissez seulement _dmarc.

Pour les offres email d’OVHcloud (mutualisé, Email Pro, Hosted Exchange), la valeur SPF indiquée est v=spf1 include:mx.ovh.com ~all. OVHcloud annonce un délai de propagation de 4 à 24 heures et recommande, comme ce guide, de commencer DMARC par p=none.

Gandi

1. Dans la section Nom de domaine, cliquez sur votre domaine, puis sur l’onglet Enregistrements DNS.
2. Cliquez sur Ajouter, choisissez le type d’enregistrement (TXT), remplissez la boîte de dialogue et confirmez pour lancer la propagation.

Gandi donne ces deux enregistrements pour Gandi Mail :

@ 10800 IN TXT "v=spf1 include:_mailcust.gandi.net ?all"
_dmarc 10800 IN TXT "v=DMARC1; p=reject; rua=mailto:user@domain.tld"

Remplacez l’adresse rua par la vôtre. Notre test SPF signale ?all par un avertissement. L’exemple DMARC de Gandi passe directement à p=reject, et Gandi prévient lui-même que les emails transférés risquent alors de ne pas être distribués. Si vous n’avez pas encore lu vos rapports, publiez d’abord p=none.

Infomaniak (DMARC)

1. Dans le Manager, cliquez sur le nom du domaine, puis sur Zone DNS dans le menu latéral gauche.
2. Cliquez sur le bouton d’ajout d’un enregistrement, choisissez DMARC, puis Suivant.
3. Laissez (ou ajoutez) _dmarc dans le champ Source. Le champ Cible contient vos balises, séparées par des ;. Laissez le TTL par défaut et cliquez sur Enregistrer.

Infomaniak indique jusqu’à 48 heures de propagation.

Passer à une politique DMARC stricte sans bloquer vos emails

Tout l’intérêt de commencer à p=none est d’arriver à p=reject sans casser la distribution.

1. Publiez p=none avec une adresse rua=. Ne changez rien d’autre pendant quelques semaines, le temps que les rapports s’accumulent.
2. Lisez les rapports. Repérez chaque source légitime et vérifiez qu’elle réussit SPF ou DKIM aligné. Corrigez celles qui échouent : c’est là qu’est le vrai travail.
3. Passez à p=quarantine. Vous pouvez monter progressivement avec pct=25, puis 50, puis 100. Surveillez les emails légitimes qui arrivent en spam.
4. Passez à p=reject quand la quarantaine n’a rien bloqué de légitime et que votre taux de réussite reste stable, proche de 100 %.

pct= fixe le pourcentage des emails en échec auquel la politique s’applique. Avec p=quarantine; pct=20, les 80 % restants relèvent de la politique inférieure (la surveillance).

Ne sautez pas l’étape du milieu. Publier p=reject avant que vos sources soient authentifiées est le moyen le plus courant de bloquer vos propres emails transactionnels et marketing. Le détail de chaque politique est dans p=none, quarantine ou reject (en anglais), et celui des sous-domaines dans DMARC et la balise sp= (en anglais).

Lire les rapports rua

Les fournisseurs de messagerie (Google, Microsoft, Yahoo…) envoient en général une fois par jour un rapport agrégé à l’adresse de votre balise rua= : un fichier XML, compressé en .gz ou en .zip, qui résume tous les emails qu’ils ont vus au nom de votre domaine, regroupés par adresse IP d’envoi, avec les résultats d’authentification de chaque groupe. Les rapports d’échec (ruf=) sont rares : Gmail et Outlook n’en envoient pas, pour des raisons de confidentialité.

Dans chaque rapport, regardez d’abord ces balises :

• source_ip et count : qui a envoyé, et combien d’emails. Une ligne peut représenter des milliers d’emails : comptez en emails, pas en lignes.
• dkim et spf sous policy_evaluated : le résultat aligné, pass ou fail. C’est le chiffre qui compte.
• header_from : le domaine From annoncé.
• disposition : ce que le serveur de réception a réellement fait (none, quarantine ou reject).

Une source que vous reconnaissez échoue ? C’est une correction de configuration : ajoutez-la à SPF, configurez la signature DKIM ou corrigez l’alignement. Une source inconnue échoue ? C’est peut-être une usurpation de votre domaine, et c’est exactement ce que DMARC doit faire échouer : avec une politique stricte, elle sera bloquée.

Pour ne pas lire le XML à la main, le lecteur de rapports DMARC (en anglais) calcule votre taux de réussite et classe vos sources en échec, dans votre navigateur. Chaque champ est expliqué dans comment lire un rapport DMARC (en anglais).

Tester votre enregistrement SPF et votre enregistrement DMARC

Après chaque modification, et une fois la propagation terminée, vérifiez vos enregistrements :

• Le test SPF trouve votre enregistrement, signale un doublon, compte les requêtes DNS face à la limite de 10 et les requêtes vides, et lit le qualificateur all au regard de votre politique DMARC.
• Le vérificateur DMARC lit votre politique, sp=, pct=, l’adresse rua= et les modes d’alignement, et vous dit si votre politique est stricte.
• Le test DKIM vérifie que votre clé publique est publiée pour votre sélecteur.

Pour un email précis, ouvrez ses en-têtes et cherchez la ligne Authentication-Results :

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of sender@yourdomain.com)
  dkim=pass header.d=yourdomain.com
  dmarc=pass (p=QUARANTINE) header.from=yourdomain.com

Si un résultat indique fail ou softfail, remontez la piste : l’enregistrement DNS existe-t-il, l’adresse IP d’envoi est-elle autorisée (SPF), le sélecteur DKIM correspond-il, le domaine From est-il aligné sur le domaine authentifié ? La vue d’ensemble des quatre protocoles, BIMI compris, est dans le guide SPF, DKIM, DMARC et BIMI (en anglais).