Les e-mails WordPress vont en spam : SPF/DKIM/DMARC expliqués et configurés

Ce qui se passe réellement quand les mails WordPress tombent en spam

Les fournisseurs de boîtes mail ne « détestent » pas WordPress. Ils détestent les expéditeurs incontrôlables, l’identité incohérente et les schémas d’envoi ressemblant à du spam. WordPress est souvent le messager, pas le coupable.

Quand vous cliquez sur « Envoyer », au moins quatre identités sont impliquées :

• Expéditeur enveloppe / Return-Path : où reviennent les bounces. Généralement contrôlé par le serveur SMTP ou le fournisseur.
• Header From : ce que voient les utilisateurs. Souvent défini par WordPress, un plugin de formulaire ou un réglage « From email ».
• DKIM d= domaine : le domaine qui signe cryptographiquement le message (si DKIM est utilisé).
• IP d’envoi : le serveur qui a réellement effectué la transaction SMTP.

SPF évalue l’IP d’envoi par rapport au domaine d’enveloppe. DKIM valide la signature par rapport à une clé publique dans le DNS. DMARC vérifie si SPF ou DKIM passe et s’aligne avec le domaine Header From.

Si vous ne contrôlez pas ces identités délibérément, vos mails auront l’air d’une falsification même lorsqu’ils sont légitimes. Et les systèmes de mail sont payés pour vous méfier par défaut.

Conseil tranché : arrêtez d’essayer de faire fonctionner PHP mail(). Utilisez SMTP authentifié ou un fournisseur d’e-mails transactionnels. Puis faites correspondre vos enregistrements DNS à la réalité. C’est tout le jeu.

Mode d’urgence : diagnostic rapide (vérifier d’abord/deuxième/troisième)

Premier : confirmer quelle identité est utilisée

1. Récupérez un vrai message qui a atterri en spam (ou le « afficher l’original » d’un destinataire).
2. Notez : Header From, Return-Path, DKIM d=, IP d’envoi, et si SPF/DKIM/DMARC ont réussi.

Goulot que vous traquez : désalignement (DMARC échoue même si SPF passe) ou « aucune authentification du tout ».

Deuxième : valider que les enregistrements DNS sont présents, uniques et corrects

1. Vérifiez que vous avez exactement un enregistrement SPF TXT pour le domaine.
2. Vérifiez que le TXT DKIM existe pour le(s) sélecteur(s) réellement utilisés.
3. Vérifiez que le record DMARC existe et est syntaxiquement valide.

Goulot que vous traquez : « permerror » dû à plusieurs enregistrements SPF, clé DKIM manquante, faute de frappe dans DMARC, ou mauvais sous-domaine.

Troisième : confirmer que WordPress envoie via la voie prévue

1. Si vous attendez SMTP : vérifiez que le plugin WordPress est configuré et que le serveur peut atteindre l’hôte SMTP sur le bon port.
2. Si vous attendez un MTA local : vérifiez que Postfix/Exim relaie via un smarthost réputé, et n’envoie pas directement depuis une IP VPS aléatoire.

Goulot que vous traquez : vous avez corrigé le DNS pour le « Fournisseur A », mais WordPress envoie toujours via le « Serveur B ». C’est le plus fréquent auto-manqué.

Faits intéressants et un peu d’histoire (parce que le mail est plus vieux que votre CTO)

• Le courrier électronique précède le web. Les premiers systèmes de mail en réseau existaient au début des années 1970 ; l’authentification est arrivée des décennies plus tard, comme une idée secondaire.
• SPF a commencé comme un hack pragmatique. Il a été conçu pour permettre aux propriétaires de domaine de publier quelles IP peuvent envoyer, parce que SMTP lui‑même s’en fichait.
• DKIM est né de deux systèmes concurrents. DomainKeys et Identified Internet Mail ont été fusionnés en DKIM — un « compromis ops » avec de la cryptographie.
• DMARC est essentiellement de la colle de politique. Il lie SPF et DKIM plus les règles d’alignement, puis ajoute des rapports pour voir qui vous usurpe.
• L’alignement existe parce que les attaquants peuvent réussir SPF avec un domaine différent. Sans alignement, un message peut « s’authentifier » mais mentir dans le Header From visible.
• Les listes de diffusion sont l’ennemi naturel de DKIM. La modification du corps du message casse les signatures DKIM ; l’industrie a créé ARC pour réduire les dommages collatéraux.
• « p=reject » n’est devenu courant que lorsque les grands fournisseurs l’ont imposé. DMARC a existé des années avant que beaucoup d’organisations n’osent l’appliquer.
• SPF a une limite de 10 requêtes DNS. Cette limite explique pourquoi « ajoute juste un include de plus » finit par exploser en production.
• Certains fournisseurs traitent aujourd’hui les mails non authentifiés comme suspects par défaut. La barre a bougé ; ce qui fonctionnait en 2016 est une responsabilité en 2025.

SPF, DKIM, DMARC : ce que c’est et ce que ce n’est pas

SPF : « Cette IP est autorisée à envoyer pour ce domaine »

SPF est un enregistrement TXT DNS qui liste quelles IP (ou quels enregistrements SPF d’autres domaines) sont autorisées à envoyer des mails prétendant provenir d’un domaine — spécifiquement, le domaine expéditeur d’enveloppe (Return-Path). Le destinataire vérifie l’IP de connexion par rapport à cette politique.

SPF n’est pas : un chiffrement, une garantie d’arrivée en boîte de réception, ou une garantie que l’en-tête « From: » visible est honnête. SPF peut passer alors que le Header From est complètement différent.

Ce à quoi SPF sert : empêcher l’usurpation occasionnelle et aider les récepteurs à scorer votre mail comme légitime lorsqu’il est combiné à DKIM/DMARC.

DKIM : « Ce message a été signé par un domaine possédant cette clé »

DKIM ajoute un en-tête de signature qui couvre des en-têtes sélectionnés et (généralement) le corps. Le destinataire récupère une clé publique depuis le DNS (sélecteur + domaine) et vérifie la signature.

DKIM n’est pas : une promesse que le contenu est bon, ni que le Header From convivial correspond au signataire. DKIM dit seulement « un domaine contrôlant cette clé DNS a signé ce contenu ».

Modes d’échec DKIM : corps modifié en transit, mauvais sélecteur, mauvaise clé dans le DNS, ou votre système d’envoi n’a pas signé du tout.

DMARC : « Accepter ou rejeter selon l’alignement et l’authentification ; envoyez-moi des rapports »

DMARC vit à _dmarc.yourdomain en tant qu’enregistrement TXT. Il indique aux récepteurs :

• Que faire si le mail échoue DMARC (none/quarantine/reject).
• Où envoyer les rapports agrégés et judiciaires.
• À quel point l’alignement doit être strict (relaxed vs strict).

DMARC passe si l’un des deux suit : SPF passe avec alignement ou DKIM passe avec alignement.

DMARC n’est pas : un filtre anti-spam. C’est un mécanisme d’application d’identité. Les filtres anti-spam jugent toujours votre contenu et votre réputation.

Une vérité sèche : l’authentification des e-mails est comme une ceinture de sécurité. Elle n’empêche pas les accidents, mais on remarque quand elle manque.

Citation : « L’espoir n’est pas une stratégie. » — Gene Kranz

Blague #1 : SPF, c’est essentiellement votre domaine qui dit : « Oui, cette IP fait partie de mon équipe. » C’est comme une liste VIP pour la sécurité, mais avec plus de DNS et moins de cordes d’accès.

Alignement : la partie que tout le monde saute puis subit

Si vous ne retenez qu’une chose : DMARC ne se contente pas que SPF ou DKIM passent. Il exige qu’ils passent pour le même domaine que celui que l’utilisateur voit en From.

Alignement relaxed vs strict

• Relaxed (adkim=r, aspf=r) : les sous-domaines peuvent s’aligner. Exemple : From est example.com, le signataire DKIM mail.example.com peut s’aligner (domaine organisationnel identique).
• Strict (adkim=s, aspf=s) : correspondance exacte requise. From est example.com, le signataire DKIM doit être exactement example.com.

Échec d’alignement courant dans l’univers WordPress

Vous envoyez un mail « From: you@yourdomain.com » mais votre fournisseur SMTP utilise un domaine de rebond comme bounces.provider-mail.net. SPF passe pour ce domaine fournisseur, mais il ne s’aligne pas avec yourdomain.com. DKIM peut aussi signer avec le domaine du fournisseur si vous n’avez pas configuré DKIM personnalisé.

Résultat : SPF=pass, DKIM=pass, DMARC=fail. C’est le cas le plus déroutant « tout a passé mais ça a échoué » que vous verrez.

Que faire : configurez le fournisseur pour qu’il signe avec votre domaine (DKIM personnalisé) et/ou utilisez un return-path personnalisé (domaine de rebond) qui s’aligne avec votre domaine From.

Tâches pratiques : commandes, sorties et décisions (12+ vérifications réelles)

Voici les vérifications que j’exécute réellement quand l’e-mail se comporte mal. Chacune inclut : la commande, ce que signifie la sortie, et la décision suivante.

Task 1: Find your public sending IP (if you’re sending direct from a server)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.42

Sens : si votre MTA envoie directement, c’est probablement cette IP que voient les destinataires.

Décision : si cette IP appartient à une plage VPS générique sans réputation, n’envoyez pas directement. Utilisez un smarthost/fournisseur transactionnel.

Task 2: Check reverse DNS (PTR) for the sending IP

cr0x@server:~$ dig +short -x 203.0.113.42
wp01.mail.example.com.

Sens : les récepteurs aiment voir un PTR qui mappe l’IP à un nom d’hôte volontaire.

Décision : si vous n’obtenez rien ou un PTR par défaut du fournisseur, corrigez le PTR avec votre FAI/cloud ou cessez d’envoyer directement.

Task 3: Verify forward-confirmed reverse DNS (FCrDNS)

cr0x@server:~$ dig +short wp01.mail.example.com A
203.0.113.42

Sens : le PTR pointe vers un nom d’hôte ; le nom d’hôte résout vers la même IP.

Décision : s’il ne correspond pas, corrigez le DNS (enregistrement A) ou le PTR. Certains récepteurs pénalisent les discordances.

Task 4: Inspect SPF record (and catch the “two SPF records” disaster)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

Sens : vous avez une seule chaîne SPF. Bien.

Décision : si vous voyez plusieurs chaînes distinctes v=spf1, vous devez les fusionner en un seul enregistrement SPF.

Task 5: Validate SPF syntax and the 10-lookup limit risk

cr0x@server:~$ python3 - <<'PY'
import dns.resolver, re
domain="example.com"
txt=[]
for r in dns.resolver.resolve(domain,"TXT"):
    s=b"".join(r.strings).decode()
    if s.startswith("v=spf1"):
        txt.append(s)
print("SPF records:", len(txt))
print(txt[0] if txt else "none")
print("includes:", len(re.findall(r'\\binclude:', txt[0])) if txt else 0)
PY
SPF records: 1
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all
includes: 2

Sens : comptage simpliste, mais ça signale des chaînes d’includes incontrôlées.

Décision : si vous êtes proche de 10 requêtes DNS, aplatissez SPF ou retirez des expéditeurs inutilisés avant que SPF ne devienne permerror.

Task 6: Check DMARC record exists and is readable

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

Sens : DMARC est publié avec la politique quarantine, alignement relâché et rapports agrégés.

Décision : si absent, publiez-en un. Si la politique est p=none, vous êtes en mode surveillance (correct temporairement, pas pour toujours).

Task 7: Check DKIM selector record for your provider

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Sens : la clé publique DKIM existe pour le sélecteur s1.

Décision : si vide/NXDOMAIN, soit vous avez publié le mauvais sélecteur, soit le fournisseur ne signe pas encore avec votre domaine.

Task 8: Confirm what Postfix thinks its identity is (common on self-hosted WordPress)

cr0x@server:~$ postconf -n | egrep 'myhostname|mydomain|myorigin|relayhost|inet_interfaces'
myhostname = wp01.mail.example.com
mydomain = example.com
myorigin = $mydomain
relayhost = [smtp.mailprovider.net]:587
inet_interfaces = loopback-only

Sens : le serveur est configuré pour relayer via un smarthost, pas pour envoyer directement ; il n’écoute que sur loopback (durcissement utile).

Décision : si relayhost est vide et que le serveur envoie directement, attendez-vous à des problèmes de délivrabilité sauf si vous gérez sérieusement la réputation.

Task 9: Verify SMTP connectivity to your relay (network and firewall reality check)

cr0x@server:~$ nc -vz smtp.mailprovider.net 587
Connection to smtp.mailprovider.net 587 port [tcp/submission] succeeded!

Sens : le serveur peut atteindre le port de soumission SMTP.

Décision : si échec, corrigez les règles de pare-feu sortant, les groupes de sécurité ou les restrictions du fournisseur (certains clouds bloquent 25/587 par défaut).

Task 10: Send a test email from the server with explicit envelope sender

cr0x@server:~$ printf "Subject: SMTP test\nFrom: wp@example.com\nTo: you@example.net\n\nhello\n" | sendmail -f bounce@example.com you@example.net

Sens : ceci teste le chemin MTA local et définit l’expéditeur d’enveloppe à bounce@example.com.

Décision : si des bounces reviennent ou que les logs montrent un rejet, examinez les logs du MTA et l’authentification vers le relayhost.

Task 11: Read mail logs for immediate rejects (the truth is in the logs)

cr0x@server:~$ sudo tail -n 50 /var/log/mail.log
Dec 27 10:42:11 wp01 postfix/smtp[21455]: to=, relay=smtp.mailprovider.net[198.51.100.10]:587, delay=1.2, delays=0.1/0.1/0.6/0.4, dsn=2.0.0, status=sent (250 2.0.0 queued as 9A1BC2D3)

Sens : Postfix a remis le mail au relais avec succès (2.0.0 sent).

Décision : si vous voyez des rejets 5xx, corrigez l’authentification, les politiques du domaine From, ou le statut du compte fournisseur avant de toucher au DNS.

Task 12: Check WordPress is actually using SMTP (not falling back to PHP mail)

cr0x@server:~$ grep -R "WP_MAIL_SMTP" -n /var/www/html/wp-config.php
37:define('WP_MAIL_SMTP_HOST', 'smtp.mailprovider.net');
38:define('WP_MAIL_SMTP_PORT', 587);
39:define('WP_MAIL_SMTP_AUTH', true);

Sens : la configuration existe (la méthode varie selon le plugin). Cela suggère que WordPress a l’intention d’utiliser SMTP.

Décision : vérifiez quand même avec les logs du plugin ou en corrélant les horaires dans mail.log. La dérive de configuration est réelle.

Task 13: Inspect a received message’s authentication results (from headers)

cr0x@server:~$ python3 - <<'PY'
import sys, re
raw = """Authentication-Results: mx.example.net;
 spf=pass smtp.mailfrom=bounce.example.com;
 dkim=pass header.d=example.com header.s=s1;
 dmarc=pass header.from=example.com
"""
print("SPF:", re.search(r"spf=\\w+", raw).group(0))
print("DKIM:", re.search(r"dkim=\\w+", raw).group(0))
print("DMARC:", re.search(r"dmarc=\\w+", raw).group(0))
PY
SPF: spf=pass
DKIM: dkim=pass
DMARC: dmarc=pass

Sens : voici à quoi ressemble un cas « bon » : DMARC passe avec identités alignées.

Décision : si DMARC échoue, vérifiez l’alignement : header.from est-il différent de smtp.mailfrom et de header.d ?

Task 14: Detect multiple SPF records (explicitly)

cr0x@server:~$ dig +short TXT example.com | grep -c "v=spf1"
2

Sens : deux enregistrements SPF existent. C’est un permerror SPF pour beaucoup de récepteurs.

Décision : fusionnez-les en un seul enregistrement SPF immédiatement. « Mais ça marchait la semaine dernière » n’est pas une défense.

Task 15: Check that your domain isn’t missing the provider’s include

cr0x@server:~$ dig +short TXT example.com | tr ' ' '\n' | grep -E '^include:'
include:_spf.google.com
include:spf.protection.outlook.com

Sens : SPF inclut deux écosystèmes. Ça peut être correct, ou hérité.

Décision : si vous n’émettez plus depuis l’un d’eux, retirez-le. Les includes inutilisés augmentent la surface d’erreur et le nombre de requêtes.

Enregistrements DNS qui fonctionnent réellement (exemples adaptables)

Le DNS est l’endroit où les bonnes intentions meurent. Gardez-le ennuyeux et correct.

SPF : un seul enregistrement, expéditeurs minimaux nécessaires, politique explicite

Exemple : vous envoyez depuis un fournisseur transactionnel et Microsoft 365. Vous n’envoyez pas directement depuis votre serveur web.

cr0x@server:~$ cat spf-example.txt
example.com. 300 IN TXT "v=spf1 include:spf.protection.outlook.com include:send.mailprovider.net -all"

Ce que cela signifie : seuls ces systèmes inclus peuvent envoyer ; tout le reste échoue fermement (-all).

Décision : utilisez ~all seulement pendant les transitions. Laisser ~all indéfiniment, c’est comme laisser la porte du bureau déverrouillée parce que les clés sont embêtantes.

DKIM : publier les clés utilisées par votre expéditeur

Votre fournisseur vous indiquera le sélecteur et la valeur TXT. Publiez-les exactement. Ne les « habillez » pas joliment.

cr0x@server:~$ cat dkim-example.txt
s1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Décision : faites pivoter les clés périodiquement, mais ne les faites pas tourner « pour le fun » pendant une semaine de lancement marketing.

DMARC : commencer par la surveillance, puis appliquer

DMARC est de la politique. Traitez‑le comme tel.

cr0x@server:~$ cat dmarc-monitoring.txt
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; fo=1"

Décision : utilisez p=none suffisamment longtemps pour apprendre qui envoie en votre nom. Ensuite passez à quarantine, puis à reject.

DMARC enforcement example

cr0x@server:~$ cat dmarc-enforce.txt
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=r; pct=100"

Sens : alignement DKIM strict, alignement SPF relâché. C’est un schéma courant quand vous comptez fortement sur DKIM signé par votre domaine exact.

Décision : l’alignement strict n’est pas un signe de supériorité. Ne l’utilisez que lorsque vous êtes sûr que tous les expéditeurs légitimes s’alignent exactement.

Stratégie de sous-domaine : séparer le mail transactionnel du mail humain

Si votre plateforme marketing, WooCommerce et les réinitialisations de mot de passe partagent example.com, vous mélangez des réputations. Parfois c’est acceptable ; parfois c’est un incident en cours.

Envisagez d’envoyer le mail transactionnel depuis mail.example.com ou notify.example.com tout en conservant le mail humain sur example.com. Vous aurez toujours besoin de DMARC et d’alignement, mais vous aurez réduit le périmètre d’impact.

Modèles d’envoi WordPress : PHP mail vs SMTP vs API

Option A : PHP mail() (par défaut). Bon marché. Fragile.

Sur beaucoup d’hébergements, mail() transmet à un MTA local ou une infrastructure partagée que vous ne contrôlez pas. L’en-tête From peut être réécrit. DKIM peut être absent. SPF peut pointer vers autre chose. Vous obtenez la délivrabilité que vous méritez pour avoir délégué l’identité au hasard.

À n’utiliser que si : votre hébergeur fournit un envoi authentifié, signé et aligné pour votre domaine (certains le font ; la plupart non).

Option B : SMTP authentifié via un plugin. L’approche raisonnable par défaut.

WordPress soumet le mail à un serveur SMTP que vous contrôlez ou louez. Ce serveur SMTP signe avec DKIM et gère les bounces. Vous publiez SPF/DMARC pour le domaine. Tout le monde est plus heureux.

Décisions clés :

• Utilisez le port 587 avec STARTTLS (ou 465 TLS implicite) selon les recommandations du fournisseur.
• Utilisez un compte dédié au site, pas la boîte mail personnelle de quelqu’un.
• Assurez-vous que le fournisseur peut signer DKIM avec votre domaine (et pas simplement le leur).

Option C : API e-mail (HTTP) vers un fournisseur transactionnel. Très fiable, moins de « drame SMTP ».

Cela évite les blocages réseau SMTP et les bizarreries d’identifiants. Le fournisseur envoie toujours le mail, mais votre application parle HTTPS.

Opérationnellement : excellent. Côté délivrabilité : nécessite toujours l’alignement SPF/DKIM/DMARC. Les API ne contournent pas la physique.

Blague #2 : Envoyer des e-mails sans DKIM en 2025, c’est comme déployer sans sauvegardes : techniquement possible, spirituellement inquiétant.

Trois mini-histoires d’entreprise depuis les tranchées de la délivrabilité

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Ils ont migré leur site WordPress d’un hébergeur managé vers un nouveau cluster Kubernetes brillant. L’application fonctionnait. Le checkout fonctionnait. Les réinitialisations fonctionnaient en staging. Le passage en production a eu lieu un jeudi après-midi, comme la tradition l’exige.

Puis les tickets de support ont afflué : personne ne recevait les confirmations de commande. Pas « dans le spam ». Juste manquantes. L’équipe marketing a renvoyé les campagnes depuis sa plateforme et elles ont bien atterri. C’était le premier indice : seuls les e-mails transactionnels originant de WordPress échouaient.

La mauvaise hypothèse était simple : « Notre domaine a SPF et DMARC déjà, donc l’authentification e-mail est faite. » Ce n’était pas le cas. Leur SPF autorisait Microsoft 365 et un outil marketing. Leur nouveau chemin d’envoi était un pod Postfix sortant par une IP NAT qui n’était pas dans SPF. La signature DKIM n’était pas configurée du tout, car l’ancien hébergeur signait silencieusement les mails sortants pour eux.

Les récepteurs ont fait ce qu’ils devaient : SPF a échoué, DKIM manquait, DMARC a échoué, la politique du domaine était quarantine. Certains fournisseurs ont mis en spam ; d’autres ont rejeté selon la politique et la réputation locales.

La correction fut aussi simple, mais pas rapide : ils ont arrêté l’envoi direct et routé tout le transactional via un fournisseur transactionnel signant avec le domaine, puis mis à jour SPF pour l’inclure. Ce n’est qu’après que les rapports DMARC ont montré un alignement propre qu’ils ont renforcé la politique. Leçon : « Nous avons DMARC » ne veut pas dire « ce nouvel expéditeur est autorisé ». Cela veut dire « ce nouvel expéditeur sera puni s’il ne l’est pas ».

Mini-histoire 2 : L’optimisation qui a mal tourné

Une entreprise a voulu « réduire les requêtes DNS » en aplatissant agressivement SPF et en supprimant les includes. Sur le papier, c’est valable : la limite de 10 lookup SPF est réelle, et les includes peuvent devenir une chaîne de dépendances que vous ne contrôlez pas.

Le retour de bâton est venu du processus, pas du principe. Ils ont aplati SPF en prenant un instantané des plages IP actuelles du fournisseur, puis ont supprimé l’include qui suivait automatiquement les changements. C’était plus rapide. C’était plus léger. C’était aussi figé dans le temps.

Des semaines plus tard, leur fournisseur a ajouté de nouvelles infrastructures d’envoi et a commencé à délivrer depuis des IP non listées dans le SPF aplati. Certains récepteurs ont traité les échecs SPF comme un fort signal négatif, et DMARC a commencé à échouer pour un sous-ensemble de messages parce que la signature DKIM était parfois désactivée pendant un incident côté fournisseur. Le résultat global ressemblait à des « problèmes aléatoires de délivrabilité », le pire type — car cela pousse les équipes vers des chasses aux superstitions.

Ils ont fini par réintroduire des includes pour les fournisseurs qui changent fréquemment et n’aplatir que les parties qu’ils contrôlaient réellement. Ils ont aussi ajouté une vérification hebdomadaire qui échantillonne les rapports agrégés DMARC pour détecter des sources inattendues. Leçon : optimiser les contrôles de délivrabilité sans mécanisme de mise à jour transforme votre « durcissement » en bombe à retardement.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une autre organisation avait une habitude profondément peu sexy : chaque fois qu’un nouvel outil SaaS voulait envoyer au nom du domaine, il passait une courte revue. Ils vérifiaient le domaine From, si le vendeur supportait DKIM personnalisé, quel serait le domaine return-path, et si l’alignement DMARC passerait.

Une équipe produit a déployé un nouveau plugin de formulaire WordPress intégré à un outil d’assistance. Le comportement par défaut du fournisseur était d’envoyer comme noreply@vendor.example avec un reply-to sur l’adresse du client — acceptable. Mais l’équipe voulait un rendu brandé : support@theircompany.com. C’est là que DMARC tue les rêves.

Parce que la revue existait, ils ont détecté le problème avant la production : le fournisseur ne pouvait pas aligner DKIM sur le domaine de l’entreprise à moins de configurer un domaine d’envoi personnalisé et de publier les enregistrements DKIM. Sans cela, DMARC échouerait sous leur politique p=reject.

Ils ont fait la chose ennuyeuse : créé un sous-domaine support-mail.theircompany.com, publié DKIM, ajouté un SPF minimal et défini une politique DMARC dédiée pour ce sous-domaine. Le jour du lancement, les e-mails ont atterri. Personne n’a rien remarqué. C’est le meilleur résultat que les opérations puisse obtenir.

Erreurs courantes : symptôme → cause racine → correction

1) « SPF passe mais DMARC échoue »

Symptôme : Authentication-Results montre spf=pass et dmarc=fail.

Cause racine : SPF a réussi pour le domaine d’enveloppe, mais ce domaine n’est pas aligné avec le domaine visible en From.

Correction : utilisez un return-path/bounce personnalisé aligné sur votre domaine From, ou reposez-vous sur DKIM aligné sur votre domaine From (DKIM personnalisé).

2) « DKIM échoue seulement pour certains destinataires »

Symptôme : certains fournisseurs montrent DKIM pass, d’autres échouent ; ou les échecs ont commencé après l’ajout d’une liste de diffusion/forwarder.

Cause racine : un intermédiaire modifie le corps du message ou des en-têtes couverts par DKIM, cassant la signature.

Correction : signez avec une canonicalisation relaxée (paramètre fournisseur), évitez les systèmes qui réécrivent le corps, ou appuyez-vous sur SPF+alignement quand approprié. Pour les listes de diffusion, ARC peut aider mais n’est pas universel.

3) « SPF permerror »

Symptôme : les en-têtes montrent spf=permerror ou les récepteurs traitent SPF comme échoué malgré une IP correcte.

Cause racine : plusieurs enregistrements SPF publiés, ou SPF dépasse les limites de requêtes DNS.

Correction : fusionnez en un seul enregistrement SPF ; aplatissez ou taillez les includes ; retirez les services hérités.

4) « Tout s’authentifie mais Gmail spamme quand même »

Symptôme : SPF/DKIM/DMARC passent, pourtant la placement en boîte est médiocre.

Cause racine : problèmes de réputation/contenu : pics de volume soudains, faible engagement, modèles spammy, mauvaise hygiène de liste ou mauvaise réputation IP.

Correction : segmentez transactional vs marketing, réchauffez les volumes, réduisez le taux de plainte, et assurez des schémas d’envoi cohérents. L’authentification est le ticket d’entrée, pas le concert entier.

5) « L’adresse From WordPress est @votredomaine mais l’envoi se fait via un hébergeur partagé »

Symptôme : les messages affichent votre domaine en From, mais le Return-Path est le domaine de l’hébergeur ; DMARC échoue ou met en quarantaine.

Cause racine : l’hébergeur partagé réécrit l’expéditeur d’enveloppe ; vous n’avez pas d’authentification alignée pour votre domaine.

Correction : utilisez SMTP/API avec votre propre domaine d’envoi et DKIM ; cessez de dépendre de l’envoi sortant partagé.

6) « Après activation de p=reject, certains mails légitimes disparaissent »

Symptôme : les utilisateurs arrêtent de recevoir certains e-mails automatisés (CRM, ticketing, vieux imprimantes, SaaS aléatoires).

Cause racine : ces expéditeurs n’étaient pas alignés ; l’application DMARC a fait exactement ce que vous avez demandé.

Correction : inventoriez les expéditeurs via les rapports DMARC, puis migrez-les vers un envoi aligné (préférable) ou changez leur domaine From vers un sous-domaine que vous contrôlez avec l’authentification appropriée.

7) « Les réponses des formulaires vont au mauvais endroit ou échouent »

Symptôme : vous avez mis From à l’e-mail du visiteur pour que « répondre » aille à lui ; maintenant DMARC échoue.

Cause racine : vous usurpez le domaine du soumetteur dans From ; les récepteurs le détectent.

Correction : gardez From sur votre domaine ; mettez l’adresse du soumetteur en Reply-To. C’est non négociable pour DMARC.

8) « Microsoft 365 fonctionne, mais les reçus WooCommerce non »

Symptôme : le mail humain est OK ; le mail transactionnel WordPress a des problèmes.

Cause racine : vous avez authentifié un écosystème d’envoi mais pas l’autre. SPF inclut 365, mais WordPress envoie via une IP serveur ou un autre fournisseur.

Correction : routez le mail WordPress via le même système aligné (SMTP 365 avec authentification correcte, ou un fournisseur transactionnel) et mettez à jour SPF/DKIM en conséquence.

Listes de contrôle / plan étape par étape

Étape par étape : faire sortir les mails transactionnels WordPress du spam de façon fiable

1. Choisissez une voie d’envoi que vous pouvez contrôler. Privilégiez un fournisseur transactionnel ou SMTP authentifié. Évitez l’envoi direct-to-MX depuis un serveur web aléatoire.
2. Définissez la stratégie de domaine From. Décidez si vous envoyez depuis example.com ou un sous-domaine comme mail.example.com.
3. Configurez WordPress pour utiliser SMTP/API. Vérifiez avec des logs (logs serveur mail, logs fournisseur, ou en-têtes des messages).
4. Publiez DKIM pour cet expéditeur. Assurez-vous que DKIM signe comme votre domaine (et non celui du fournisseur). Confirmez le sélecteur dans le DNS.
5. Publiez exactement un enregistrement SPF. Incluez uniquement les expéditeurs légitimes pour ce domaine/sous-domaine. Gardez le nombre de lookups raisonnable.
6. Publiez DMARC en mode surveillance d’abord (si vous débutez). Utilisez p=none, collectez les rapports, identifiez les expéditeurs inconnus.
7. Corrigez les problèmes d’alignement découverts par les rapports. Passez les expéditeurs sur DKIM aligné et/ou un return-path aligné.
8. Appliquez DMARC délibérément. Passez à p=quarantine puis à p=reject. Ne mettez pas « reject » un vendredi après-midi.
9. Séparez marketing et transactionnel. Utilisez différents sous-domaines si nécessaire ; des réputations distinctes sont volontaires.
10. Retestez avec de vrais destinataires et de vrais en-têtes. Ne vous fiez pas aux messages « test réussi » du plugin. Ils signifient souvent « SMTP accepté », pas « livré en boîte ».

Checklist opérationnelle : empêcher la régression

• Quand vous ajoutez un nouveau SaaS qui envoie des mails, ajoutez‑le à l’inventaire des expéditeurs et validez l’alignement avant le lancement.
• Mensuel : vérifiez que SPF n’est pas devenu une grenade à 10 lookups.
• Trimestriel : faites pivoter les clés DKIM si votre fournisseur le supporte proprement, et confirmez que les anciens sélecteurs sont retirés en toute sécurité.
• Après des migrations : vérifiez que le chemin d’envoi n’a pas changé (nouvelle IP, nouveau relais, nouveau fournisseur par défaut).
• Gardez la boîte de rapports DMARC surveillée. Traitez‑la comme de la télémétrie, pas comme du spam.

FAQ (les questions que votre futur vous posera à 2 h du matin)

1) Ai-je besoin de SPF, DKIM et DMARC, ou un seul suffit-il ?

Utilisez les trois. SPF seul est facile à contourner et ne protège pas l’en-tête From visible. DKIM seul peut casser via des intermédiaires. DMARC relie le tout et vous fournit des rapports.

2) Pourquoi les e-mails fonctionnaient avant et vont maintenant en spam ?

Parce que les politiques des fournisseurs de boîte se sont durcies, votre IP d’envoi a changé, votre volume d’envoi a changé, ou vous avez ajouté un nouveau expéditeur sans mettre à jour SPF/DKIM. Une dégradation « soudaine » de la délivrabilité est généralement une réaction différée à une dérive.

3) Quelle est la politique DMARC la plus sûre pour commencer ?

p=none avec rapports agrégés, puis corrigez les expéditeurs inconnus. Une fois propre, passez à quarantine, puis à reject. Passer directement à reject sans visibilité revient à découvrir qu’un SaaS oublié envoie encore des factures.

4) Que signifie « alignement » en clair ?

Le domaine que voient vos utilisateurs dans l’en-tête From doit correspondre (ou être lié organisationnellement) au domaine prouvé par SPF et/ou DKIM. DMARC est conçu précisément pour appliquer cette relation.

5) Mon formulaire de contact WordPress doit-il définir From sur l’e-mail du visiteur ?

Non. Cela cause un échec DMARC pour les visiteurs dont les domaines appliquent DMARC (de plus en plus fréquent). Mettez From sur votre domaine et Reply-To sur l’adresse du visiteur.

6) Puis-je envoyer les mails WordPress via Microsoft 365 SMTP et m’arrêter là ?

Oui, si vous le faites correctement : soumission authentifiée, domaine From correct, et DKIM/DMARC configurés pour ce domaine. Faites attention aux limites de débit et aux identifiants applicatifs ; n’utilisez pas le compte personnel de quelqu’un.

7) Pourquoi je vois « SPF neutral » ou « softfail » ?

Cela signifie généralement que votre SPF se termine par ?all (neutral) ou ~all (softfail). C’est acceptable en transition, mais c’est une application plus faible qui peut réduire la confiance. Serrez à -all quand vous êtes prêt.

8) Comment savoir si mon fournisseur signe DKIM avec mon domaine ?

Regardez un message reçu : trouvez DKIM-Signature et lisez la valeur d=. Elle doit être votre domaine (ou le sous-domaine d’envoi choisi). Si c’est le domaine du fournisseur, vous n’êtes pas aligné à moins que votre From corresponde à ce domaine fournisseur (ce qui ne devrait pas être le cas).

9) Quelle est la différence entre Header From et Return-Path, et pourquoi m’en soucier ?

Header From est ce que voient les humains. Return-Path est où vont les bounces et ce que SPF vérifie. Le désalignement entre eux est le scénario classique d’échec DMARC.

10) Corriger SPF/DKIM/DMARC garantira-t-il la boîte de réception ?

Non. Cela vous évitera d’échouer aux contrôles d’identité de base, ce qui est obligatoire. La placement en boîte dépend aussi de la réputation, du contenu, de l’engagement, du taux de plaintes et de la cohérence.

Conclusion : étapes pratiques suivantes

Si les e-mails WordPress vont en spam, cessez de modifier les sujets comme si vous soudoyiez un filtre. Réparez votre identité d’expéditeur.

1. Décidez comment vous allez envoyer : SMTP/API via un fournisseur de confiance, pas la roulette PHP mail.
2. Faites correspondre l’authentification : SPF autorise le véritable expéditeur ; DKIM signe avec votre domaine ; DMARC applique l’alignement.
3. Validez avec des preuves : en-têtes, requêtes DNS et logs mail. Pas des captures d’écran de plugin.
4. Appliquez délibérément : DMARC p=none → quarantine → reject, soutenu par des rapports réels et un inventaire des expéditeurs.

Faites-le une fois, faites‑le bien, et vos e-mails de réinitialisation de mot de passe cesseront de faire des détours pittoresques par les dossiers spam.