Authentification des emails, du début à la fin : SPF, DKIM & DMARC avec une vraie configuration

Technique SPF, DKIM, DMARC, Authentification des E-mails, Délivrabilité July 9, 2026 by Équipe Mailer To Go

Le guide pratique de l'authentification e-mail : vrais enregistrements SPF, DKIM et DMARC prêts à copier-coller, comment les vérifier avec dig et Afficher l'original de Gmail, et comment déployer une politique DMARC de p=none à p=reject sans casser votre messagerie.

Chaque email que vous envoyez fait une affirmation : « Je suis autorisé à envoyer au nom de ce domaine. » SPF, DKIM et DMARC sont les trois enregistrements DNS qui permettent aux serveurs de réception de vérifier cette affirmation. Si vous les configurez correctement, votre courrier arrive dans la boîte de réception ; si vous les configurez mal — ou si vous les omettez — Gmail, Yahoo et Outlook l’envoient de plus en plus vers les indésirables ou le rejettent carrément.

Depuis 2024, Gmail et Yahoo exigent SPF, DKIM, et une politique DMARC pour les expéditeurs en masse. Ceci est le guide pratique et prêt à copier-coller pour configurer correctement les trois, les vérifier depuis la ligne de commande et déployer une politique DMARC sans casser votre courrier existant.

Si vous voulez d’abord la base conceptuelle de chacun, voir Qu’est-ce que DKIM ?, Qu’est-ce qu’un enregistrement SPF ? et Qu’est-ce que DMARC ?. Cet article est le complément pratique de ces trois.

Le modèle mental de 90 secondes

Les trois enregistrements répondent à trois questions différentes sur un message :

SPF — « Ce serveur est-il autorisé à envoyer pour ce domaine ? » Un enregistrement DNS TXT listant les serveurs/services autorisés à envoyer. Vérifié par rapport à l’enveloppe-from (Return-Path), pas le From: visible.
DKIM — « Ce message a-t-il réellement été autorisé par le domaine et est-il arrivé inmodifié ? » L’expéditeur signe cryptographiquement chaque message ; la clé publique se trouve dans DNS. Une signature valide prouve l’authenticité et l’intégrité.
DMARC — « Que dois-je faire si SPF ou DKIM échoue, et où dois-je le signaler ? » Un enregistrement de politique qui lie SPF et DKIM au domaine From: visible (ce lien s’appelle alignement), indique aux destinataires s’il faut mettre en quarantaine ou rejeter les échecs, et demande des rapports.

SPF et DKIM font la vérification ; DMARC transforme ces vérifications en politique et vous donne la visibilité. Vous avez besoin des trois.

SPF : autorisez vos expéditeurs

SPF est un enregistrement TXT unique au domaine qui apparaît dans votre enveloppe-from. Si vous envoyez via MailerToGo depuis mtg.yourdomain.com :

mtg.yourdomain.com.   TXT   "v=spf1 include:_spf.mailertogo.net ~all"

include:_spf.mailertogo.net récupère les adresses IP d’envoi autorisées de MailerToGo (gérées et tenues à jour par nous — vous n’écrivez jamais les adresses IP en dur).
~all est un softfail (marquer mais accepter les expéditeurs non autorisés) ; resserrez à -all (hardfail) une fois que vous êtes sûr que tout expéditeur légitime est listé.

Deux règles qui piègent les gens :

Un enregistrement SPF par domaine. Ne publiez jamais deux enregistrements v=spf1 sur le même nom — c’est un permerror et SPF échoue. Fusionnez-les en un : "v=spf1 include:_spf.mailertogo.net include:_spf.google.com ~all".
La limite de 10 recherches. SPF autorise au maximum 10 recherches DNS lors de l’évaluation. Chaque include: compte. Empiler votre ESP, Google, Microsoft et MailerToGo sur un enregistrement racine peut dépasser la limite et casser SPF pour tout — ce qui est une grande raison d’envoyer le courrier d’application depuis un sous-domaine dédié. (Voir Pourquoi MailerToGo envoie depuis mtg.yourdomain.com.)

DKIM : signez chaque message

DKIM signe chaque message avec une clé privée ; les destinataires récupèrent la clé publique correspondante dans DNS. Avec MailerToGo, vous ne générez ni ne collez de clés — vous publiez un CNAME qui pointe un sélecteur spécifique au compte vers notre clé, et nous faisons pivoter la clé sous-jacente pour vous :

; Le sélecteur est spécifique à votre compte — utilisez la valeur exacte de votre tableau de bord
mtg1._domainkey.mtg.yourdomain.com.   CNAME   mtg1.dkim.mailertogo.net.

Parce que c’est un CNAME vers un enregistrement que nous contrôlons, la rotation des clés est automatique : quand nous faisons pivoter la clé, la clé publique publiée change de notre côté et votre DNS ne nécessite aucune modification. Si vous inspectez un jour l’enregistrement résolu, vous verrez une clé publique DKIM standard :

mtg1._domainkey.mtg.yourdomain.com.   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCSq...QAB"

Une signature DKIM valide est aussi ce qui fait survivre votre courrier au transfert, où SPF échoue souvent — donc DKIM est le signal d’authentification le plus durable des deux.

DMARC : définissez une politique et obtenez des rapports

DMARC se trouve à un nom fixe, _dmarc.<domain>, et lie les résultats SPF/DKIM au domaine From: visible. Commencez en mode moniteur pour apprendre ce qui envoie réellement avant de forcer quoi que ce soit :

_dmarc.yourdomain.com.   TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1; adkim=s; aspf=s"

Balise par balise :

p=none — monitorer seulement ; ne prenez aucune mesure sur les échecs (pour l’instant).
rua=mailto:... — envoyer des rapports agrégés ici (résumés XML quotidiens de qui envoie pour vous). C’est tout l’intérêt de commencer à none — vous obtenez la visibilité sans aucun risque.
fo=1 — demander les détails des échecs quand soit SPF soit DKIM échoue.
adkim=s / aspf=s — alignement strict (le domaine de signature/enveloppe doit correspondre exactement au domaine From:). Utilisez relâché (r, par défaut) si vous signez avec un domaine parent.
Ajoutez sp= pour définir une politique séparée pour les sous-domaines si vous en avez besoin.

L’alignement DMARC est la partie subtile : ce n’est pas assez que SPF ou DKIM passent — le domaine pour lequel ils passent doit s’aligner avec le domaine du From: visible. C’est pourquoi l’architecture d’envoi compte, et pourquoi un sous-domaine que vous contrôlez entièrement rend l’alignement simple.

Vérifiez tout depuis la ligne de commande

Ne supposez jamais qu’un enregistrement est en ligne — vérifiez-le. dig (ou nslookup sur Windows) vous montre exactement ce que les résolveurs voient :

# SPF — attendez-vous à une seule ligne v=spf1
dig +short TXT mtg.yourdomain.com

# DKIM — suivez le CNAME jusqu'à la clé publiée
dig +short CNAME mtg1._domainkey.mtg.yourdomain.com
dig +short TXT   mtg1._domainkey.mtg.yourdomain.com

# DMARC — toujours à _dmarc.<domain>
dig +short TXT _dmarc.yourdomain.com

Puis envoyez-vous un vrai message et lisez les reçus. Dans Gmail, ouvrez le message → ⋮ → Afficher l’original. Vous voulez voir :

SPF:   PASS  with domain mtg.yourdomain.com
DKIM:  PASS  with domain mtg.yourdomain.com
DMARC: PASS

Si les trois affichent PASS avec un domaine aligné, vous avez terminé.

Déployez l’application DMARC sans casser le courrier

L’erreur qui fait tomber le courrier légitime est de sauter directement à p=reject. Augmentez plutôt, en regardant vos rapports rua à chaque étape :

p=none — monitorer pendant 1-2 semaines. Lisez les rapports agrégés ; confirmez que tout expéditeur légitime passe et s’aligne.
p=quarantine; pct=25 → augmentez progressivement pct vers 100. Les échecs vont au spam, pas au néant, donc les erreurs sont récupérables.
p=reject — application complète. Arrivez ici seulement une fois que vos rapports sont propres. C’est le niveau que Gmail/Yahoo récompensent et qui arrête l’usurpation de domaine exact.

Défaillances courantes et ce qu’elles signifient

Permerror SPF / « trop de recherches DNS » — vous avez dépassé 10 recherches. Consolidez les includes ou déplacez le courrier d’application vers un sous-domaine.
Deux enregistrements SPF — fusionnez en une seule chaîne v=spf1.
DKIM « body hash did not verify » — quelque chose a modifié le message en transit (un pied de page de liste de diffusion, un scanner). DKIM fonctionne ; le contenu a changé après la signature.
DMARC échoue bien que SPF/DKIM passent — un problème d’alignement : le domaine qui passe ne correspond pas au domaine From:. Vérifiez que votre enveloppe-from/domaine DKIM et votre From: partagent un domaine organisationnel.

La version courte, et comment MailerToGo aide

SPF indique qui peut envoyer, DKIM prouve que le message est authentique et inmodifié, et DMARC lie les deux à votre domaine visible et indique aux destinataires quoi faire. Configurez les trois, vérifiez avec dig et l’option Afficher l’original de Gmail, et augmentez DMARC de none → quarantine → reject.

Avec MailerToGo, la clé DKIM et sa rotation sont gérées pour vous, et votre tableau de bord affiche les enregistrements SPF/DKIM/DMARC exacts à publier. Si vous utilisez le sous-domaine délégué mtg.yourdomain.com, nous les publions et les maintenons tous depuis un seul enregistrement NS — aucun DNS manuel du tout. Vous préférez posséder les enregistrements vous-même ? Le guide de configuration du sous-domaine manuel explique pas à pas la configuration de l’application (enveloppe-from vs. From:).

Pour les standards sous-jacents, MailerToGo maintient également des références en langage clair pour SPF, DKIM, DMARC et comment ils s’assemblent.