Un client envoie une newsletter depuis son ERP, via une passerelle SMTP tierce, avec un nom de domaine From qui est le sien. Gmail la classe en spam. Le contenu n'y est pour rien, la réputation IP non plus : c'est l'authentification qui manque. Sans SPF, DKIM et DMARC correctement posés, un message légitime et un message usurpé se ressemblent trait pour trait aux yeux du serveur receveur. La différence, ce sont ces trois enregistrements DNS.
Les trois ne prouvent pas la même chose, et confondre leurs rôles est la cause numéro un des ratés en production.
SPF : qui a le droit d'émettre
Le Sender Policy Framework répond à une seule question : cette adresse IP est-elle autorisée à envoyer du mail pour ce domaine ? C'est un enregistrement TXT publié sur le domaine d'enveloppe (MAIL FROM), qui liste les serveurs légitimes.
example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"
Le -all final est un hard fail : tout expéditeur non listé est rejeté. Le ~all (soft fail) tolère le doute et laisse le receveur décider, ce qui revient souvent à ne rien décider du tout. En audit, on trouve encore des enregistrements en ~all posés il y a cinq ans et jamais durcis, ce qui prive SPF de toute utilité pratique.
Ce que SPF ne prouve pas : que le contenu du message n'a pas été modifié, ni que l'en-tête From visible par l'utilisateur correspond au domaine d'enveloppe. C'est là que DKIM intervient, sur un terrain différent.
DKIM : qui a signé le contenu
DomainKeys Identified Mail ajoute une signature cryptographique dans l'en-tête du message, calculée sur un ensemble de champs et le corps, avec la clé privée du serveur d'envoi. Le receveur récupère la clé publique via un enregistrement DNS au format selecteur._domainkey.example.com et vérifie la signature.
mail1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
Contrairement à SPF, DKIM survit à un relais SMTP intermédiaire tant que le contenu et les en-têtes signés ne sont pas altérés. C'est pour ça qu'une passerelle qui réécrit le sujet ou ajoute un pied de page casse la signature, alors que l'IP source, elle, reste souvent inchangée. Deux mécanismes, deux modes de rupture différents : c'est la première raison de ne jamais s'appuyer sur un seul des deux.
DMARC : la politique et le rapport
DMARC ne réinvente rien, il arbitre. Il définit ce qu'un receveur doit faire quand SPF et DKIM échouent tous les deux (rejeter, mettre en quarantaine, ne rien faire), et il ajoute une exigence que SPF et DKIM n'ont pas seuls : l'alignement. Le domaine authentifié par SPF ou DKIM doit correspondre au domaine visible dans l'en-tête From, celui que l'utilisateur voit dans son client mail.
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.com; adkim=r; aspf=r"
Deux tags gouvernent l'alignement : adkim et aspf. En mode relaxed (r, la valeur par défaut), le domaine organisationnel suffit : mail.example.com s'aligne avec example.com. En mode strict (s), il faut une correspondance exacte de domaine. Le mode strict est plus rigoureux, mais il casse en silence tout ce qui envoie depuis un sous-domaine légitime non anticipé, un piège classique sur les infras avec plusieurs équipes qui envoient chacune depuis leur propre sous-domaine.
Le piège des listes de diffusion et des redirecteurs
Voici où la théorie rencontre le terrain. Une mailing-list qui relaie un message casse presque toujours SPF, parce que l'IP qui livre finalement le mail n'est jamais celle du domaine d'enveloppe original. DKIM, lui, survit davantage, sauf si la liste modifie le sujet ou ajoute un pied de page, ce qui invalide la signature.
Un redirecteur de messagerie (.forward, alias catch-all, service de transfert) a le même effet sur SPF : l'IP qui relaie n'est pas celle d'origine. Résultat, DMARC ne passe que si DKIM tient bon et reste aligné, ce qui n'arrive presque jamais dès qu'un intermédiaire touche au message. C'est le scénario numéro un de faux positifs quand on durcit une politique DMARC sans avoir vérifié qui relaie du courrier pour le domaine.
Lire les rapports agrégés avant de rien couper
C'est la partie que la plupart des déploiements sautent, et c'est celle qui évite les incidents. Le tag rua fait remonter des rapports XML quotidiens de la part des gros receveurs (Gmail, Microsoft, Yahoo). Chaque rapport contient, par source IP, le volume de messages, le résultat SPF, le résultat DKIM et la disposition appliquée.
Sur example.com, un premier cycle de rapports révèle typiquement ce genre de répartition :
- 8 400 messages depuis l'IP du MTA principal, SPF et DKIM alignés : conforme.
- 620 messages depuis la passerelle marketing tierce, SPF échoue (IP hors zone), DKIM aligné : conforme via DKIM seul, mais fragile si la passerelle change un jour de config.
- 140 messages depuis une IP inconnue, SPF et DKIM échouent : usurpation probable, ou service SaaS oublié dans l'inventaire des expéditeurs.
Sans ce rapport, il est impossible de distinguer les deux derniers cas. C'est pour ça qu'on ne monte jamais directement une politique en p=reject.
La progression, pas l'option
Le motif d'incident le plus fréquent : passer de p=none à p=reject en une étape, sans avoir regardé un seul rapport. Un service RH qui envoie des convocations via un outil SaaS non recensé, un CRM qui expédie des factures depuis une IP tierce, un forward interne oublié : tout ça part au rejet sans avertissement, et personne ne le remarque avant que le service concerné appelle en disant que plus rien n'arrive.
La règle qu'on applique : p=none pendant plusieurs semaines, le temps de couvrir un cycle mensuel complet d'expéditeurs (facturation, newsletters, alertes). On corrige chaque source légitime qui échoue, soit en l'ajoutant à SPF, soit en activant DKIM dessus. Puis p=quarantine avec un pct progressif, 25 puis 50 puis 100, en surveillant que rien de légitime ne parte en spam. p=reject vient en dernier, seulement quand deux ou trois cycles de rapports sont propres.
Côté ops, ce séquençage protège aussi le serveur SMTP lui-même : un Postfix mal configuré en sortie peut faire échouer SPF pour ses propres utilisateurs si l'IP publique change sans mise à jour de l'enregistrement. Et l'authentification sortante ne dispense pas d'un filtrage antispam en entrée : DMARC protège la réputation de votre domaine à l'extérieur, pas votre boîte de réception contre le reste d'Internet.
Ce que ça change pour la maîtrise du courrier
Poser SPF, DKIM et DMARC correctement, c'est reprendre le contrôle de qui peut légitimement parler au nom d'un domaine, un sujet qui rejoint directement les enjeux de souveraineté du courrier électronique : difficile de revendiquer la maîtrise de sa messagerie si n'importe quel expéditeur usurpé passe aussi facilement qu'un message authentique. La cohérence DNS globale compte aussi : SPF et DKIM reposent sur des enregistrements TXT non signés par défaut, ce qui les rend eux-mêmes vulnérables à un empoisonnement DNS en amont, un risque que seule une zone protégée par DNSSEC referme complètement.
Sur les infrastructures qu'on opère, la remise en conformité de la messagerie suit toujours cet ordre : observer, corriger les sources légitimes, durcir progressivement. Si votre domaine tourne encore en p=none depuis des mois sans que personne ait ouvert un rapport RUA, on peut reprendre la configuration de votre chaîne mail et la durcir sans casser vos flux existants.
Sources
- RFC 7489, DMARC Base Specification : définition officielle des tags de politique et d'alignement adkim/aspf.
- RFC 7208, Sender Policy Framework (SPF) : spécification du mécanisme SPF et de la syntaxe des qualifiers.
- Postmark, How email forwarding can break DMARC : mécanique détaillée de la rupture d'alignement SPF sur les relais et forwarders.
- Google Workspace, DMARC deployment recommendations : progression recommandée p=none vers p=reject et fenêtre d'observation minimale.
