SPF, DKIM et DMARC expliqués (en langage simple) | Scanthra

Scanthra · 7 min de lecture · Mis à jour Mai 2026

L'explication en 30 secondes

• SPF — une liste des serveurs autorisés à envoyer des e-mails depuis ton domaine.
• DKIM — une signature numérique sur chaque message, prouvant qu'il vient vraiment de ton domaine et n'a pas été altéré.
• DMARC — ta politique indiquant aux destinataires quoi faire avec les e-mails qui échouent SPF ou DKIM (autoriser, mettre en quarantaine, rejeter) et où envoyer les rapports.

Les trois sont des enregistrements DNS TXT. Tu les ajoutes une fois et tu les oublies (jusqu'à ce que tu changes de fournisseur de messagerie).

Pourquoi une petite entreprise devrait s'en préoccuper

Deux conséquences concrètes de SPF/DKIM/DMARC manquants, toutes deux courantes :

• Tes clients voient « via mailer.scanthra.net » dans Gmail au lieu de ton domaine. Subtil, mais ça tue la confiance dès le premier e-mail.
• N'importe qui peut t'usurper. Un escroc envoie « Facture en retard — paye ce compte » depuis facturation@taboutique.com à tes clients. Avec un DMARC strict, le message est rejeté avant d'atterrir. Sans, il arrive en boîte de réception.

Microsoft et Google exigent maintenant SPF + DKIM + DMARC pour les envoyeurs en volume (depuis février 2024). Si tu envoies des e-mails — même des reçus transactionnels depuis une boutique WordPress — des enregistrements manquants commenceront à nuire à la délivrabilité.

SPF — la liste blanche

Un enregistrement SPF ressemble à ça :

tondomaine.com.  IN TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Trois choses à savoir :

• v=spf1 — toujours requis, marqueur de version.
• include: — pointe vers le SPF de ta messagerie ou de ton expéditeur transactionnel. Chaque fournisseur t'indique la valeur à utiliser.
• ~all — la politique pour tout autre expéditeur. Utilise ~all (softfail) pendant les tests, -all (hardfail) une fois stable.

Limite : 10 recherches DNS. Chaque include: compte. Empiler trop de fournisseurs casse SPF silencieusement. Si tu atteins la limite, utilise un aplatisseur SPF comme celui intégré à EasyDMARC, Postmark ou Cloudflare.

DKIM — la signature

DKIM signe chaque message sortant avec une clé privée qui vit sur le serveur de messagerie, et publie la clé publique correspondante dans le DNS :

selector1._domainkey.tondomaine.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Chaque fournisseur a son propre sélecteur (selector1, google, k1, etc.). Suis les instructions de ton fournisseur mot pour mot — il génère la valeur exacte à coller. Tu peux avoir plusieurs enregistrements DKIM, un par fournisseur, côte à côte.

DMARC — ta politique

Un enregistrement DMARC de démarrage :

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

Champs clés :

• p=none — reçoit les rapports, ne prend aucune mesure. Commence toujours ici.
• p=quarantine — les e-mails en échec vont en spam.
• p=reject — les e-mails en échec sont rejetés. L'état cible.
• rua=mailto:... — rapports agrégés quotidiens. Canaliselsa-les vers un lecteur gratuit comme Postmark DMARC Digests ou dmarcian.

Le déploiement sûr

1. Ajoute SPF et DKIM pour chaque expéditeur légitime (ta messagerie, ton expéditeur transactionnel, ton outil marketing, ton helpdesk).
2. Publie DMARC avec p=none. Attends 2 à 4 semaines en lisant les rapports agrégés.
3. Quand toutes les sources légitimes sont alignées (pas de lignes « fail » de tes propres services), passe à p=quarantine.
4. Après encore 2 à 4 semaines de rapports propres, passe à p=reject.

Ce déploiement progressif est ce que fait chaque grande entreprise. Passer directement à p=reject fonctionne — jusqu'au jour où le Marketing achète un nouvel outil et cesse de recevoir des e-mails. Là, c'est la panique.

Erreurs courantes

• Deux enregistrements SPF sur le même nom d'hôte — ils ne s'additionnent pas, ils s'annulent mutuellement. Fusionne toujours en un seul.
• Oublier d'ajouter SPF/DKIM pour ton expéditeur marketing (Mailchimp, Brevo, HubSpot). Ceux-ci partent aussi sous ton domaine.
• Mauvaise politique de sous-domaine DMARC (sp=) — si tu as p=reject mais pas de sp=, les sous-domaines héritent d'une politique relâchée. Sois explicite.
• Utiliser ?all dans SPF. C'est effectivement « pas de politique » — les destinataires l'ignorent.

Comment Scanthra vérifie ça

Notre module Email Security fait des recherches DNS passives pour SPF, DKIM (sélecteurs courants) et DMARC. On signale les enregistrements manquants, les politiques faibles (p=none seulement après la période de grâce), les dépassements du nombre de recherches SPF et les enregistrements SPF avec ?all ou +all. Tu verras la lacune exacte dans ton rapport PDF.