SPF, DKIM, DMARC : configurer ses emails

sommaire

Example H2

Example H3

Example H4

Example H5

Example H6

Envie d'en savoir plus ? Contactez nos experts !

Prendre rendez-vous

25/8/2026

SPF, DKIM, DMARC : configurer ses emails

SPF, DKIM et DMARC ne sont pas trois niveaux d'un même dispositif : ce sont trois réponses à trois questions distinctes, et aucune ne remplace les deux autres. Le verdict d'entrée : sur un domaine d'entreprise existant, la configuration complète prend six à douze semaines — pas parce que la technique est longue, mais parce qu'il faut d'abord inventorier tout ce qui envoie en votre nom. Sur un domaine secondaire dédié au cold email, une heure. Cet article donne les enregistrements exacts, la méthode d'audit et le calendrier des deux cas.

À retenir

SPF déclare quelles machines ont le droit d'envoyer pour votre domaine. DKIM signe le message cryptographiquement. DMARC décide quoi faire quand l'un des deux échoue, et vous envoie les rapports (RFC 7208, 6376 et 7489).
Un seul enregistrement SPF par domaine, 10 lookups DNS maximum. Deux enregistrements v=spf1 ou onze include: produisent un PermError : tout le SPF échoue.
Clé DKIM : 1 024 bits minimum exigé par Google, 2 048 recommandé (Google Email Sender Guidelines). Google Workspace génère du 1 024 par défaut : il faut basculer manuellement.
DMARC passe si SPF ou DKIM passe et est aligné. C'est un OU, pas un ET.
Le transfert d'un email casse SPF. Seul DKIM survit. DKIM n'est donc jamais optionnel.
Déploiement complet de p=none à p=reject : 6 à 12 semaines, dont 6 minimum en observation. Sauf sur un domaine secondaire de cold email, où -all et p=reject se posent dès le premier jour.

SPF, DKIM, DMARC : ce que chaque enregistrement fait vraiment

Protocole	RFC	Ce qu'il vérifie	Ce qu'il ne fait pas
SPF	7208	Que l'IP émettrice figure dans la liste publiée par le domaine de l'enveloppe (`MAIL FROM` / Return-Path)	Il ne regarde pas l'adresse affichée au destinataire
DKIM	6376	Qu'une signature cryptographique du corps et de certains en-têtes correspond à une clé publique publiée en DNS	Il ne dit rien de qui a le droit d'envoyer
DMARC	7489	Que le domaine affiché dans le `From:` est aligné avec celui validé par SPF ou DKIM, puis applique une politique et émet des rapports	Il ne signe rien et n'autorise rien lui-même

Le point que la plupart des guides survolent : SPF et DKIM ne regardent pas la même adresse. SPF valide le domaine de l'enveloppe, invisible pour le destinataire ; DKIM valide le domaine qui a signé. Seul DMARC compare l'un ou l'autre avec le From: affiché — c'est l'alignement, et c'est la seule protection réelle contre l'usurpation. Conséquence directe : un domaine peut afficher SPF: PASS et échouer DMARC si le domaine de l'enveloppe diffère du domaine affiché. C'est le cas classique des routeurs tiers mal configurés.

Pour la vue d'ensemble du sujet — les quatre piliers, la réputation, les volumes — reportez-vous au guide de la délivrabilité cold email. Cet article-ci ne traite que le DNS.

Configurer SPF : syntaxe, mécanismes et la limite des 10 lookups

L'enregistrement type, pour un domaine qui envoie via Google Workspace et Microsoft 365 :

Nom : @
Type : TXT
TTL : 3600
Valeur : v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Élément	Rôle	Coût en lookups
`v=spf1`	Version. Obligatoire, en première position	0
`ip4:` / `ip6:`	Autorise une IP ou un bloc CIDR	0
`a`	Autorise l'IP de l'enregistrement A du domaine	1
`mx`	Autorise les IP des serveurs MX	1
`include:`	Délègue à la politique d'un tiers	1 chacun
`redirect=`	Remplace entièrement la politique par celle d'un autre domaine	1
`~all`	Softfail : accepté mais marqué. Valeur de déploiement	0
`-all`	Hardfail : rejet. Valeur cible	0
`+all`	Autorise tout le monde. À ne jamais publier	0

Les include: les plus courants : _spf.google.com (Google Workspace), spf.protection.outlook.com (Microsoft 365), sendgrid.net, amazonses.com, spf.brevo.com, servers.mcsv.net (Mailchimp), _spf.mailjet.com.

Trois règles qui cassent tout quand on les ignore.

Un seul enregistrement SPF par domaine. Deux TXT commençant par v=spf1 produisent un PermError automatique : le SPF entier devient invalide. C'est l'erreur numéro un quand on ajoute un prestataire, chacun publiant son propre enregistrement. La correction : fusionner les mécanismes dans une seule ligne.

Dix lookups DNS maximum. include, a, mx, ptr, exists et redirect en consomment chacun au moins un ; ip4, ip6 et all aucun. Au onzième, PermError, tout échoue. Un include: peut lui-même en contenir d'autres : trois include: visibles peuvent en coûter huit. Vérifiez la valeur résolue, pas la ligne écrite. Le mécanisme ptr est déconseillé par la RFC 7208 : ne l'utilisez pas.

~all pendant le déploiement, -all à la fin. Le softfail laisse passer les messages non autorisés en les marquant : vous avez le temps de corriger. Le hardfail les fait rejeter. On ne bascule sur -all qu'une fois p=reject stable — seule exception, le domaine de cold email traité plus bas.

Le SPF flattening et son prix caché. Quand on dépasse les 10 lookups, la solution proposée partout consiste à remplacer les include: par les adresses ip4: qu'ils résolvent. Techniquement cela fonctionne : les IP ne coûtent aucun lookup. Le problème est ailleurs. Vous figez dans votre DNS des adresses appartenant à un prestataire, qui peut les changer sans préavis. Le jour où il le fait, votre SPF échoue silencieusement : aucune alerte, simplement des emails qui tombent. Si vous flattenez, il faut un mécanisme de re-résolution automatique. Sinon, la vraie correction est de réduire le nombre de prestataires qui envoient depuis le domaine racine.

Configurer DKIM : sélecteur, tags et taille de clé

L'enregistrement DKIM se publie sur un sous-domaine composé d'un sélecteur et de _domainkey.

Nom : google._domainkey (Google Workspace)
Type : TXT
Valeur : v=DKIM1; k=rsa; h=sha256; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

Chez Microsoft 365, ce ne sont pas des TXT mais deux CNAME :

Nom : selector1._domainkey → selector1-domaine-fr._domainkey.tenant.onmicrosoft.com
Nom : selector2._domainkey → selector2-domaine-fr._domainkey.tenant.onmicrosoft.com
Type : CNAME

Tag	Valeur	Rôle
`v`	`DKIM1`	Version. Obligatoire, en premier
`k`	`rsa` (ou `ed25519`)	Algorithme de la clé
`h`	`sha256`	Algorithme de hachage. `sha1` est obsolète
`p`	clé publique	Le cœur de l'enregistrement. `p=` vide signifie clé révoquée
`t`	`y`	Mode test : les récepteurs ignorent l'échec. À retirer après validation
`s`	`email`	Restreint l'usage de la clé au service email

Le sélecteur permet plusieurs clés en parallèle : une par prestataire d'envoi. google._domainkey pour Workspace, s1._domainkey pour votre routeur marketing, selector1._domainkey pour Microsoft. Elles cohabitent sans se gêner, chacune signant ce qu'elle émet. C'est ce qui rend DKIM bien plus extensible que SPF, limité à un seul enregistrement.

La taille de clé. Google exige 1 024 bits au minimum et recommande 2 048 (Google Email Sender Guidelines). Or Google Workspace propose 1 024 par défaut : il faut sélectionner 2 048 avant de générer la clé. Certains registrars refusant les valeurs TXT longues, l'enregistrement est alors découpé en plusieurs chaînes entre guillemets — géré automatiquement dans la plupart des interfaces. Prévoyez une rotation une à deux fois par an.

Le piège Microsoft 365. Par défaut, Microsoft signe vos messages en DKIM avec le domaine tenant.onmicrosoft.com. La signature est valide, mais elle n'est pas alignée avec votre From: en @domaine.fr. DMARC échoue donc, alors que « DKIM passe ». Il faut activer DKIM sur le domaine personnalisé dans le centre d'administration, ce qui suppose les deux CNAME ci-dessus. Microsoft a par ailleurs supprimé l'authentification SMTP basique : les outils qui s'y appuyaient doivent passer par OAuth ou par un autre chemin d'envoi.

Configurer DMARC : les tags, les trois politiques et le tag sp=

Nom : _dmarc
Type : TXT
TTL : 3600
Valeur : v=DMARC1; p=none; rua=mailto:dmarc@domaine.fr; adkim=r; aspf=r; sp=none; fo=1; ri=86400

Tag	Valeurs	Défaut	Note
`v`	`DMARC1`	—	Obligatoire, en première position
`p`	`none` / `quarantine` / `reject`	—	Obligatoire, doit suivre immédiatement `v`
`sp`	`none` / `quarantine` / `reject`	= `p`	Politique appliquée aux sous-domaines
`rua`	`mailto:`	—	Rapports agrégés XML, quotidiens
`ruf`	`mailto:`	—	Rapports forensiques : peu de récepteurs les envoient
`pct`	0-100	100	Pourcentage de messages soumis à la politique
`adkim`	`r` / `s`	`r`	Alignement DKIM : relaxed ou strict
`aspf`	`r` / `s`	`r`	Alignement SPF : relaxed ou strict
`fo`	`0` / `1` / `d` / `s`	`0`	`1` = rapport si l'un des deux échoue. Recommandé
`ri`	secondes	86400	Intervalle entre deux rapports agrégés

REROW Tableau Rerow · rerow.fr

‍

Anatomie d'un enregistrement DMARC, tag par tag

Un seul enregistrement TXT, huit tags, deux obligatoires. L'ordre des deux premiers n'est pas négociable.

Nom / hôteTypeTTL

_dmarcTXT3600

v=DMARC1;¹ p=none;² sp=none;³ rua=mailto:dmarc@domaine.fr;⁴ adkim=r;⁵ aspf=r;⁵ fo=1;⁶ ri=86400⁷

Obligatoire Décisif en pratique Valeur par défaut acceptable

1v= — versionToujours DMARC1, toujours en première position. Une autre valeur, ou une autre place, et l'enregistrement entier est ignoré.
2p= — politiquenone observe, quarantine envoie en indésirables, reject fait rejeter. Doit suivre immédiatement v=.
3sp= — politique des sous-domainesAbsent, il hérite de p=. C'est le tag qui décide si facturation.domaine.fr tombe en même temps que le domaine racine.
4rua= — rapports agrégésSans lui, DMARC ne vous apprend rien. Vers un domaine tiers, il exige un enregistrement d'autorisation _report._dmarc côté destinataire.
5adkim= / aspf= — alignementr (relaxed) accepte un sous-domaine, s (strict) exige l'égalité exacte. On passe en s à la fin, pas au début.
6fo= — déclencheur de rapport1 demande un rapport dès que SPF ou DKIM échoue. La valeur par défaut, 0, n'en génère que si les deux échouent.
7ri= — intervalleEn secondes. 86400 = un rapport agrégé par jour. Peu de récepteurs honorent une autre valeur.
+Les deux absentspct= (100 par défaut) sert de palier pendant la montée. ruf= génère des rapports forensiques : peu envoyés, et porteurs de données personnelles.

Les huit tags d'un enregistrement DMARC, leur position, leur valeur par défaut et celui qui pilote réellement le comportement des sous-domaines.

REROW Graphique Rerow · rerow.fr

L'enregistrement DMARC décomposé tag par tag : deux obligatoires, trois décisifs en pratique, et l'ordre imposé des deux premiers.

Le tag sp=, expliqué pour de vrai. Il est cité partout et expliqué nulle part. En son absence, sp hérite de p. Si vous publiez p=reject sur domaine.fr sans préciser sp, la politique de rejet s'applique à tous vos sous-domaines — y compris ceux que vous n'avez jamais configurés, y compris ceux qu'un prestataire a créés pour vous.

Deux conséquences opposées :

En protection, c'est excellent. Un attaquant qui usurpe facturation.domaine.fr, sous-domaine inexistant, se fait rejeter sans que vous ayez rien publié dessus. C'est la parade la plus efficace contre l'usurpation de sous-domaines.
En casse, c'est brutal. Si votre outil de facturation envoie depuis billing.domaine.fr avec une authentification incomplète, il tombe le jour où vous publiez p=reject.

sp= sert donc à découpler les deux calendriers. Pendant le déploiement : p=quarantine; sp=none, le temps d'inventorier les sous-domaines réellement utilisés. Une fois l'inventaire fait : sp=reject.

Les trois politiques. p=none n'a aucun effet sur la livraison : elle sert uniquement à collecter les rapports. p=quarantine fait basculer les messages non alignés vers les indésirables. p=reject demande leur rejet à la connexion. Le tag pct= permet de n'appliquer la politique qu'à une fraction des messages — utile comme palier de confort, mais tous les récepteurs ne l'interprètent pas identiquement : ne le traitez pas comme une garantie.

adkim et aspf. En mode relaxed (r), un sous-domaine suffit : un message signé par mail.domaine.fr est aligné avec un From: en @domaine.fr. En mode strict (s), l'égalité doit être exacte. On passe en s à la fin du déploiement, jamais au début.

ruf= et le RGPD. Les rapports forensiques contiennent des en-têtes de messages réels, parfois des données personnelles. Peu de récepteurs en émettent, et leur traitement doit être documenté. En pratique, laissez ruf= de côté : rua= suffit. Le sujet réglementaire de la prospection est traité dans l'article cold email et RGPD.

Auditer avant de toucher au DNS : lire 4 à 6 semaines de rapports rua=

C'est l'étape que personne ne publie, et c'est celle qui décide de la réussite du déploiement.

Publiez d'abord p=none avec un rua=, et ne changez rien d'autre.

Nom : _dmarc
Type : TXT
Valeur : v=DMARC1; p=none; rua=mailto:dmarc@domaine.fr; fo=1

Aucun message n'est bloqué. Vous recevez en revanche chaque jour des rapports XML agrégés : quelles IP ont écrit avec votre From:, quel volume, et si SPF et DKIM ont passé. Ces fichiers sont pénibles à lire à la main — passez par dmarcian, Postmark DMARC (gratuit) ou Learn DMARC.

Pourquoi 4 à 6 semaines et pas une. Parce que certains expéditeurs légitimes n'envoient qu'une fois par mois : le récapitulatif de paie, la relance comptable de fin de mois, la campagne trimestrielle. Une fenêtre d'une semaine les manque, et vous les découvrez le jour où ils tombent en reject.

L'inventaire des sources d'envoi que l'on oublie systématiquement :

Facturation et devis : outil comptable, plateforme de paiement, générateur de devis.
Recrutement : l'ATS envoie les accusés de réception et les convocations au nom de vos recruteurs.
Support : helpdesk, chat, système de tickets.
Prise de rendez-vous : les confirmations et rappels d'agenda partent souvent avec le From: du commercial.
CRM et séquences commerciales : les envois automatisés depuis le CRM, notamment les séquences HubSpot, utilisent votre domaine.
Marketing : routeur de newsletter, marketing automation, notifications de formulaires.
Technique : monitoring, alertes, exports planifiés, et le serveur oublié qui envoie un rapport par SMTP depuis 2019.

La règle : tout ce qui écrit @domaine.fr dans le champ From: doit apparaître dans vos rapports avant que vous publiiez reject. Cet inventaire relève de la même hygiène que l'enrichissement du CRM : sans cartographie, aucune décision fiable.

Passer en p=reject sans rien casser

Frise de déploiement DMARC : de p=none à p=reject

Sur un domaine d'entreprise existant, la durée n'est pas une précaution : c'est le temps nécessaire pour que les rapports agrégés révèlent tous les expéditeurs légitimes, y compris ceux qui n'envoient qu'une fois par mois.

Domaine principal — inventaire d'expéditeurs inconnu

Semaine 0

1. Observer

v=DMARC1; p=none; rua=mailto:dmarc@domaine.fr; fo=1

On ne change rien d'autre. Aucun email n'est bloqué. On collecte l'inventaire réel des sources d'envoi. 4 à 6 semaines

Semaines 4-6

2. Corriger

SPF : ajouter les include manquants DKIM : activer chez chaque prestataire identifié

Facturation, ATS, support, calendrier, CRM, monitoring, newsletter. Chaque source doit passer SPF ou DKIM en alignement. 1 à 2 semaines

Semaines 6-10

3. Mettre en quarantaine

p=quarantine; pct=25 puis pct=50 puis pct=100

Les échecs partent en indésirables au lieu d'être livrés. On surveille les rapports à chaque palier avant de monter. 2 à 4 semaines

Semaines 10-12

4. Rejeter

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@domaine.fr

Puis, et seulement à ce moment, basculer le SPF de ~all à -all. État cible

6 à 12 semaines au total, dont 6 semaines minimum en p=none. Raccourcir cette phase revient à publier une politique de rejet sur un inventaire incomplet : les emails perdus le sont silencieusement, et personne ne vous prévient.

Le raccourci du domaine secondaire de cold email : J1

Sur un domaine acheté pour la prospection, sans historique et sans aucun outil tiers branché, l'inventaire d'expéditeurs est vide par construction. Il n'y a rien à découvrir. On publie directement l'état cible.

@ TXT v=spf1 include:_spf.google.com -all _dmarc TXT v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@domaine-principal.fr; fo=1

Et on ne touche pas au DMARC du domaine principal : ce sont deux domaines, deux inventaires, deux calendriers.

Le calendrier de déploiement DMARC sur un domaine d'entreprise, et le cas particulier du domaine secondaire de cold email, où l'état cible est atteignable dès le premier jour.

REROW Graphique Rerow · rerow.fr

La frise complète de p=none à p=reject avec les durées de chaque palier, et le raccourci du domaine secondaire de cold email.

La séquence, dans l'ordre :

v=DMARC1; p=none; rua=mailto:dmarc@domaine.fr; fo=1 — 4 à 6 semaines d'observation.
Corriger les sources légitimes identifiées : ajouter les include: SPF manquants, activer DKIM chez chaque prestataire. Comptez 1 à 2 semaines.
p=quarantine; pct=25, puis pct=50, puis pct=100 — 2 à 4 semaines, en relisant les rapports à chaque palier.
v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@domaine.fr; fo=1.
Basculer le SPF de ~all à -all, et seulement à ce moment.

Total : 6 à 12 semaines, dont 6 minimum en p=none.

Ce qui casse en p=reject, et que personne ne liste.

Le transfert. Quand un destinataire fait suivre votre email, le serveur intermédiaire réémet le message depuis sa propre IP. Cette IP n'est pas dans votre SPF, et ne peut pas y être. SPF échoue mécaniquement à chaque transfert. Seul DKIM survit, parce que la signature porte sur le message et non sur le chemin parcouru. En B2B, c'est décisif : le transfert interne est précisément le mécanisme par lequel votre email atteint le décideur. Un domaine authentifié en SPF seul passe DMARC en envoi direct et échoue dès que quelqu'un vous fait suivre.

Ce qui survit au transfert : SPF contre DKIM

DMARC passe si SPF ou DKIM passe, à condition que le mécanisme validé soit aligné avec le domaine affiché. Au transfert, il n'en reste qu'un.

Envoi direct — votre serveur vers le destinataire

votredomaine.frIP autorisée par votre SPF, message signé en DKIM

Serveur du destinataireVérifie l'IP émettrice et la signature

PASSSPF — l'IP émettrice figure bien dans votre enregistrement

PASSDKIM — la signature correspond au contenu reçu

DMARC : PASS — deux mécanismes sur deux

Transfert — le destinataire fait suivre en interne

votredomaine.frMessage d'origine, identique

Serveur intermédiaireRéémet le message depuis sa propre IP

Boîte du décideurVérifie ce qu'il reçoit, sans savoir d'où ça vient à l'origine

FAILSPF — l'IP du relais n'est pas dans votre enregistrement, et ne peut pas y être

PASSDKIM — la signature porte sur le message, pas sur le chemin

DMARC : PASS — mais grâce à DKIM seul

DKIM n'est donc pas une option. Un domaine authentifié en SPF seul passe DMARC en envoi direct et échoue au premier transfert. Or en B2B, le transfert interne est précisément le mécanisme par lequel votre email atteint le décideur. Publier p=reject sans DKIM, c'est faire rejeter vos propres emails au moment où ils commençaient à circuler.

Le transfert d'un email casse mécaniquement SPF et laisse DKIM intact : c'est la raison technique pour laquelle DKIM doit être actif avant toute politique de rejet.

REROW Graphique Rerow · rerow.fr

Envoi direct contre transfert : pourquoi SPF tombe, pourquoi DKIM tient, et pourquoi DKIM n'est jamais optionnel.

Les listes de diffusion. Elles réécrivent souvent le sujet ou ajoutent un pied de page, ce qui invalide la signature DKIM ; beaucoup contournent en réécrivant le From:. Le protocole ARC permet à un intermédiaire de transmettre le résultat d'authentification d'origine : Google et Microsoft le lisent, mais tous les récepteurs ne l'honorent pas.

Les notifications réémises : auto-répondeurs, accusés de lecture, systèmes de tickets qui renvoient le message d'origine avec votre From:.

Le cas du domaine secondaire de cold email : `-all` et `p=reject` dès J1

Voici l'exception, et elle est totale.

La frise de six à douze semaines existe pour une seule raison : découvrir un inventaire d'expéditeurs accumulé pendant des années. Sur un domaine acheté trois semaines plus tôt pour de la prospection, cet inventaire est vide par construction. Aucun outil tiers n'y est branché. Aucun sous-domaine n'existe. Vous savez exactement qui envoie : les boîtes que vous venez de créer.

Il n'y a donc rien à observer. On publie directement l'état cible.

Nom : @ TXT v=spf1 include:_spf.google.com -all
Nom : _dmarc TXT v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@domaine-principal.fr; fo=1
Nom : google._domainkey TXT v=DKIM1; k=rsa; h=sha256; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

Attention au rua= qui pointe vers un autre domaine. Vous ne voulez pas recevoir vos rapports DMARC dans une boîte de prospection. Mais envoyer les rapports du domaine secondaire vers une adresse du domaine principal exige une autorisation explicite, publiée sur le domaine destinataire (RFC 7489) :

Nom : domaine-secondaire.fr._report._dmarc (sur le domaine PRINCIPAL)
Type : TXT
Valeur : v=DMARC1

Sans cet enregistrement, la plupart des récepteurs refusent d'envoyer les rapports, et vous ne recevez rien sans qu'aucune erreur ne vous soit signalée.

Et on ne touche pas au DMARC du domaine principal. C'est le contresens le plus fréquent : le passer en p=reject dans l'urgence « pour améliorer la délivrabilité du cold email ». Deux domaines, deux inventaires, deux calendriers. Le domaine principal a un historique d'expéditeurs réel et exige la frise complète. Le secondaire existe précisément pour que la réputation du principal ne soit jamais engagée par la prospection — c'est l'objet de l'article sur le domaine secondaire de cold email.

Trois éléments complètent la configuration du domaine secondaire, hors périmètre de cet article : un MX pour recevoir les réponses, une redirection vers votre site principal, et un warm-up avant le premier envoi commercial.

Vérifier sa configuration et corriger les erreurs fréquentes

Les trois commandes qui répondent à tout :

dig TXT domaine.fr +short
dig TXT google._domainkey.domaine.fr +short
dig TXT _dmarc.domaine.fr +short

Sous Windows : nslookup -type=TXT _dmarc.domaine.fr. Puis un test réel : envoyez un message vers une boîte Gmail, ouvrez « Afficher l'original » et vérifiez SPF: PASS, DKIM: PASS, DMARC: PASS. Mail-tester donne en complément une note globale — visez 9/10.

Erreur	Symptôme	Correction
Deux enregistrements `v=spf1`	`PermError`, tout le SPF échoue	Fusionner les mécanismes en une seule ligne
Plus de 10 lookups	`PermError` intermittent selon le résolveur	Retirer des `include:`, réduire le nombre de prestataires
SPF publié sur `www` ou un sous-domaine	Aucun effet, aucun message d'erreur	Publier sur `@`
`p=` vide dans le DKIM	DKIM échoue	Clé révoquée : en régénérer une
`t=y` laissé en place	Les échecs DKIM sont ignorés	Retirer le tag après validation
DKIM actif sur `onmicrosoft.com` seul	`DKIM: PASS` mais `DMARC: FAIL`	Activer DKIM sur le domaine personnalisé
`rua=` vers un domaine tiers sans `_report._dmarc`	Aucun rapport reçu	Publier l'enregistrement d'autorisation
`p=reject` publié sans observation	Emails légitimes perdus, silencieusement	Revenir en `p=none`, refaire l'audit

REROW Tableau Rerow · rerow.fr

FAQ

Quelle est la différence entre SPF, DKIM et DMARC ?

SPF déclare les serveurs autorisés à envoyer pour votre domaine. DKIM signe le message pour prouver qu'il n'a pas été modifié et qu'il vient bien de vous. DMARC vérifie que le domaine affiché correspond à celui validé par SPF ou DKIM, décide du sort des messages non conformes et vous envoie les rapports.

Faut-il vraiment les trois ?

Google exige au minimum SPF ou DKIM pour tout expéditeur, et les trois au-delà de 5 000 messages par jour vers Gmail (Google Email Sender Guidelines). En pratique, oui : sans DKIM vous cassez au premier transfert, et sans DMARC vous n'avez aucune visibilité sur ce qui échoue.

Peut-on avoir plusieurs enregistrements SPF ?

Non. Deux TXT commençant par v=spf1 provoquent un PermError et invalident l'ensemble. Il faut fusionner tous les mécanismes dans un enregistrement unique.

Faut-il publier `~all` ou `-all` ?

~all pendant le déploiement, -all une fois p=reject stable. Exception : sur un domaine secondaire neuf dédié au cold email, -all dès le premier jour, puisqu'aucun autre expéditeur ne peut exister.

Combien de temps pour passer en `p=reject` ?

Six à douze semaines sur un domaine d'entreprise, dont six minimum en p=none pour inventorier les expéditeurs réels. Un jour sur un domaine secondaire de prospection.

SPF ou DKIM survit-il au transfert d'un email ?

DKIM. Le serveur qui fait suivre réémet depuis sa propre IP, ce qui fait échouer SPF mécaniquement. La signature DKIM, elle, porte sur le message et reste valable tant que le contenu n'est pas modifié.

L'authentification est un prérequis, pas un levier

Un domaine parfaitement authentifié n'a jamais généré un rendez-vous. SPF, DKIM et DMARC ne font pas monter votre placement : ils empêchent qu'il s'effondre. L'infrastructure d'envoi n'est pas une stratégie d'acquisition, c'est ce qui permet à une stratégie d'exister.

Ce qui produit du pipeline se situe en amont : un ICP défini, des signaux qui déclenchent le bon timing, une donnée fiable, un message qui parle du problème du prospect — la méthode posée dans le guide du cold email B2B, prolongée par les règles de contenu de l'article éviter le spam en cold email. Le DNS est la dernière brique de cette chaîne, celle qui ne se voit que lorsqu'elle manque. C'est pour cela qu'une agence outbound marketing doit tenir les deux bouts : la stratégie et la plomberie.