SPF, DKIM et DMARC expliqués : Un guide pratique pour la configuration de l'authentification des e-mails (2026)

Pourquoi l'authentification par e-mail est non négociable en 2026

Chaque message que vous envoyez est une affirmation : "Je suis autorisé à envoyer des e-mails en tant que ce domaine." Sans preuve, les fournisseurs de boîtes aux lettres tels que Gmail, Yahoo, Outlook et Apple Mail n'ont aucun moyen de distinguer votre e-mail légitime d'un spammeur falsifiant votre adresse. Trois normes basées sur DNS fournissent cette preuve : SPF, DKIM et DMARC. Obtenir les trois correctement est la chose la plus importante que vous puissiez faire pour atteindre la boîte de réception et protéger votre marque contre le spoofing.

Ce guide passe en revue chaque enregistrement, montre de vrais exemples DNS et vous donne un ordre de déploiement sûr. Vous configurez cela une fois par domaine d'envoi, puis vous l'oubliez pendant des années.

SPF : autorisez vos serveurs d'envoi

Le cadre de politique d'expéditeur (SPF) est un enregistrement TXT listant quels serveurs peuvent envoyer des e-mails pour votre domaine. Le destinataire vérifie l'expéditeur de l'enveloppe (le MAIL FROM / Return-Path) par rapport à votre politique. Un enregistrement typique ressemble à ceci :

v=spf1 include:_spf.yourtrend.online include:_spf.google.com ~all

Points clés : l'enregistrement doit commencer par v=spf1, vous publiez exactement un enregistrement SPF par domaine, et vous devez terminer par ~all (softfail) ou -all (hardfail). Évitez +all, qui autorise l'ensemble d'Internet. Faites attention à la 10 limite de recherche DNS : chaque include: compte, et le dépassement produit une permerror qui échoue SPF. Si vous utilisez plusieurs fournisseurs, aplatissez ou consolidez vos inclusions.

DKIM : signez cryptographiquement votre e-mail

DomainKeys Identified Mail (DKIM) ajoute une signature numérique à chaque message dans un en-tête DKIM-Signature. Le destinataire récupère votre clé publique depuis le DNS et vérifie que les en-têtes signés et le corps n'ont pas été modifiés en transit. Vous publiez la clé publique à un sous-domaine selector :

s1._domainkey.yourdomain.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNAD..."

Le s1 est le sélecteur, référencé à l'intérieur de l'en-tête de signature comme s=s1. Utilisez des clés RSA de 2048 bits là où votre fournisseur DNS le permet, et faites tourner les clés périodiquement. Avec YourTrend, nous générons la paire de clés pour vous et vous donnons l'enregistrement exact à coller, y compris le sélecteur.

DMARC : définissez la politique et obtenez des rapports

DMARC lie SPF et DKIM ensemble avec alignement et indique aux destinataires quoi faire lorsqu'un message échoue. L'alignement signifie que le domaine dans l'en-tête visible De : doit correspondre au domaine validé par SPF ou DKIM. Vous le publiez à _dmarc:

_dmarc.votredomaine.com IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.com; adkim=s; aspf=s; pct=100"

Les trois politiques sont p=none (surveillance uniquement), p=quarantine (envoyer les échecs dans le spam) et p=reject (les bloquer). L'adresse rua reçoit des rapports XML agrégés quotidiens montrant chaque source envoyant en tant que votre domaine — inestimable pour trouver des systèmes mal configurés avant de renforcer la politique.

Un plan de déploiement sûr

• Semaine 1 : Publiez SPF et DKIM. Envoyez un mail de test et confirmez que les deux passent en lisant l'en-tête Authentication-Results d'un message reçu.
• Semaine 2 : Publiez DMARC à p=none avec une adresse rua. Collectez les rapports et corrigez toute source légitime qui n'est pas alignée.
• Semaine 3–4 : Passez à p=quarantine; pct=25, puis augmentez le pourcentage à mesure que les rapports restent propres.
• Final : Passez à p=reject. Vous êtes maintenant entièrement protégé contre le spoofing, et c'est ce que Gmail et Yahoo attendent des expéditeurs en masse.

Erreurs courantes

• Deux enregistrements SPF sur un domaine — fusionnez-les en un seul.
• Dépassement de la limite de 10 recherches SPF — consolidez les inclusions.
• Clé DKIM divisée en plusieurs chaînes TXT incorrectement — la plupart des interfaces DNS gèrent cela, mais vérifiez la clé assemblée.
• Passer directement à p=reject sans surveillance — vous pourriez bloquer vos propres factures et réinitialisations de mot de passe.

Comment confirmer que cela fonctionne

Après publication, envoyez un message à un compte que vous contrôlez et ouvrez la source brute. Recherchez l'en-tête Authentication-Results que le destinataire a ajouté — il résume les trois vérifications en une ligne :

Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass (p=REJECT) header.from=yourdomain.com

Trois résultats pass avec des domaines correspondants signifient que l'alignement est correct et que vous êtes prêt à renforcer la politique. Un piège fréquent est de voir dkim=pass mais dmarc=fail : le message a été signé, mais avec le domaine du fournisseur au lieu du vôtre, donc il ne s'aligne pas avec votre From: visible. La solution est de signer avec une clé DKIM sur votre propre domaine — exactement ce qu'une configuration appropriée vous donne. Au-delà des vérifications ponctuelles, vos rapports agrégés quotidiens rua montrent le même verdict chez chaque fournisseur de boîte aux lettres à la fois, c'est pourquoi vous ne devez jamais sauter la phase de surveillance avant de passer à p=reject.

L'authentification est la fondation sur laquelle tout le reste se construit. Créez un compte gratuit YourTrend et notre processus d'intégration vérifie SPF, DKIM et DMARC pour vous, génère vos clés DKIM et surveille vos rapports DMARC afin que vous puissiez atteindre p=reject en toute confiance.