SPF, DKIM, DMARC : configurer sans casser ses emails légitimes

Les trois acronymes SPF, DKIM et DMARC reviennent à chaque audit de délivrabilité. Ils protègent votre domaine contre l'usurpation d'identité (spoofing) et conditionnent l'arrivée en boîte de réception chez Gmail, Outlook ou Yahoo. Mal configurés, ils font exactement l'inverse : ils mettent vos propres factures en spam.

Cet article explique comment déployer les trois protocoles sans casser vos flux légitimes. On part des définitions, on regarde la syntaxe DNS réelle, puis on déroule la méthode prudente que recommandent l'ANSSI et les grands opérateurs de messagerie.

Trois protocoles, trois rôles complémentaires

Chaque protocole répond à une question précise. Les confondre est la première cause d'erreur de configuration.

• SPF (Sender Policy Framework, RFC 7208) : déclare dans le DNS la liste des serveurs autorisés à envoyer du mail au nom de votre domaine. Le serveur destinataire compare l'IP expéditrice à cette liste.
• DKIM (DomainKeys Identified Mail, RFC 6376) : signe cryptographiquement chaque message avec une clé privée détenue par votre serveur d'envoi. La clé publique est publiée dans le DNS pour permettre la vérification.
• DMARC (RFC 7489) : indique au destinataire ce qu'il doit faire si un message échoue à la fois à SPF et DKIM. C'est la couche de politique, et elle envoie aussi des rapports agrégés vers une adresse de votre choix.

Sans DMARC, SPF et DKIM ne servent pas à grand-chose pour la lutte contre le spoofing : chaque opérateur applique ses propres règles, parfois opposées. DMARC unifie le verdict.

SPF : la liste des expéditeurs autorisés

Un enregistrement SPF est un simple TXT publié à la racine du domaine. Exemple pour un domaine qui envoie via un serveur maison plus une plateforme transactionnelle :

exemple.fr.  IN TXT  "v=spf1 ip4:203.0.113.42 include:_spf.exemple-mailer.fr ~all"

Trois choses comptent :

• la directive v=spf1 en tête (obligatoire) ;
• les mécanismes ip4, ip6, include, a, mx qui déclarent les sources légitimes ;
• le qualifier final : ~all (softfail) ou -all (hardfail).

Règle de prudence : commencez avec ~all pendant la phase de monitoring DMARC. Ne passez à -all qu'une fois que vos rapports DMARC montrent zéro flux légitime en échec.

Limite technique à connaître : SPF ne tolère pas plus de 10 lookups DNS dans la chaîne. Si vous accumulez les include: (Microsoft 365, plateforme marketing, outil de signature, transactionnel...), vous dépassez vite la limite et SPF tombe en permerror. Solutions : nettoyer les inclusions inutiles ou recourir à un service de SPF flattening (qui aplatit les enregistrements en IPs explicites).

DKIM : la signature cryptographique

DKIM repose sur une paire de clés. La clé privée signe les emails au moment de l'envoi, la clé publique est publiée dans le DNS sous un sélecteur. Une signature DKIM ressemble à ceci dans les en-têtes :

DKIM-Signature: v=1; a=rsa-sha256; d=exemple.fr; s=mail2026;
  c=relaxed/relaxed; h=from:to:subject:date;
  bh=...; b=...

L'enregistrement DNS associé suit le format <sélecteur>._domainkey.<domaine> :

mail2026._domainkey.exemple.fr.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Trois recommandations concrètes :

• Clé de 2048 bits : les clés 1024 bits sont considérées comme faibles depuis plusieurs années.
• Rotation : changez la paire de clés tous les 6 à 12 mois. Le sélecteur permet d'avoir plusieurs clés actives en parallèle pendant la transition.
• Une clé par flux : serveur transactionnel, plateforme marketing, mailbox interne. Chaque source signe avec son propre sélecteur, ce qui simplifie l'investigation en cas d'incident.

DMARC : la politique et les rapports

DMARC est un TXT publié sur _dmarc.<domaine>. La syntaxe minimale en mode observation :

_dmarc.exemple.fr.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr; pct=100; adkim=r; aspf=r"

Les balises essentielles :

• p= indique la politique appliquée par le destinataire : none (observation seule), quarantine (mise en spam) ou reject (rejet en SMTP). C'est le coeur de DMARC.
• rua= donne l'adresse de réception des rapports agrégés journaliers en XML.
• pct= permet de n'appliquer la politique qu'à un pourcentage du trafic. Utile pour un déploiement progressif.
• adkim et aspf : mode d'alignement, r (relaxed, par défaut, accepte les sous-domaines) ou s (strict, exige une correspondance exacte).

L'alignement est le concept que les débutants ratent le plus souvent. Pour qu'un message passe DMARC, il ne suffit pas que SPF ou DKIM soit valide : le domaine vérifié par SPF (champ Return-Path) ou par DKIM (tag d=) doit s'aligner avec le domaine du From visible. Sans alignement, DMARC échoue même si SPF et DKIM passent individuellement.

La méthode prudente en 4 étapes

C'est là que se joue la différence entre une migration réussie et une catastrophe de délivrabilité.

1. Inventaire des flux sortants

Listez tout ce qui envoie au nom de votre domaine : serveur principal, ERP, CRM, plateforme marketing, transactionnel, signatures, applications métier, prestataires (cabinet comptable, paie, etc.). Les oublis à cette étape sont la première cause d'emails légitimes mis en spam après passage en p=reject.

2. SPF et DKIM en place, DMARC en observation

Déployez SPF (avec ~all) et DKIM sur tous les flux identifiés. Publiez ensuite un DMARC en p=none avec rua. Pendant 2 à 4 semaines, ne touchez plus à rien et lisez les rapports.

3. Analyse des rapports agrégés

Les rapports XML envoyés par les grands opérateurs (Google, Microsoft, Yahoo, La Poste, Free) recensent toutes les sources qui envoient avec votre domaine en From. Vous y trouverez : vos sources légitimes (qu'il faut authentifier proprement), des sources oubliées (anciens prestataires, applications fantômes), et éventuellement de vrais cas d'usurpation. Un parseur DMARC simplifie cette lecture (Postmaster Tools de Google, plusieurs outils open source disponibles).

4. Montée en politique

Une fois que les rapports sont propres :

• passez en p=quarantine; pct=10 pendant 1 à 2 semaines ;
• augmentez le pct à 50, puis 100 ;
• passez en p=reject quand plus rien ne casse.

Ce déploiement progressif est exactement la trajectoire recommandée par la documentation Microsoft 365, par le NIST (Technical Note 1945) et par les guides de l'ANSSI sur la sécurisation de la messagerie.

Les pièges qui cassent les emails légitimes

Plusieurs configurations apparemment correctes provoquent des rejets massifs. Quelques cas récurrents :

• Forwarders : un email transféré depuis une boîte intermédiaire perd son alignement SPF. DKIM continue souvent de passer si la signature reste intacte. C'est l'argument fort pour ne pas s'appuyer uniquement sur SPF.
• Mailing lists : la plupart des listes réécrivent l'en-tête From ou altèrent le contenu, ce qui casse DKIM. ARC (RFC 8617) est la réponse, mais le support reste inégal.
• Sous-domaines : si vous publiez DMARC sur le domaine racine sans sp= explicite, la politique s'applique aux sous-domaines. Vérifiez que les outils qui envoient depuis marketing.exemple.fr ou noreply.exemple.fr sont aussi authentifiés.
• Domaines parqués : pour vos domaines qui n'envoient jamais d'email, publiez un SPF nul (v=spf1 -all) et un DMARC en reject. Cela ferme la porte aux usurpations.

Et côté réception ?

Configurer SPF, DKIM et DMARC en sortie est la moitié du travail. Votre serveur de réception doit aussi vérifier ces protocoles à l'arrivée, sinon vos équipes restent exposées au phishing entrant. Sur une stack open source comme Mailcow (Postfix, Rspamd, Dovecot), tout est activé par défaut. Sur Microsoft 365 ou Google Workspace, les vérifications sont câblées mais les politiques par défaut peuvent être laxistes : prenez le temps de durcir.

Pour aller plus loin sur la souveraineté des emails, lire aussi : Mailcow, la suite email open source pour PME et Cloud Act et RGPD : pourquoi héberger en France.

Datacampus et l'email infogéré

Chez Datacampus, on opère Mailcow infogéré pour les PME et les agences qui veulent reprendre la maîtrise de leur messagerie sans monter une équipe dédiée. SPF, DKIM, DMARC, rotation des clés et lecture des rapports agrégés font partie du forfait. Si la délivrabilité vous coûte du temps ou des ventes, on peut en discuter : voir notre offre Mailcow.