Un serveur SMTP correctement configuré ne suffit pas toujours à garantir qu’un e-mail transactionnel arrive en boîte de réception. Les grands fournisseurs de messagerie vérifient systématiquement, avant même de regarder le contenu du message, si le domaine expéditeur a explicitement autorisé le serveur qui l’envoie. Sans cette autorisation publiée dans le DNS, l’e-mail est considéré comme suspect par défaut, quelle que soit sa qualité de rédaction.
Trois mécanismes complémentaires — SPF, DKIM et DMARC — répondent à cette exigence. Aucun des trois ne relève du code WordPress : ce sont des enregistrements DNS à publier une seule fois pour le domaine, qui bénéficient ensuite à tous les e-mails envoyés depuis ce domaine, qu’ils viennent de WordPress ou d’un client de messagerie classique.
SPF, la liste blanche des expéditeurs autorisés
Le Sender Policy Framework publie, sous forme d’un enregistrement TXT dans la zone DNS, la liste des serveurs autorisés à envoyer des e-mails au nom d’un domaine. Un serveur de réception qui reçoit un message prétendant venir de exemple.fr vérifie que l’adresse IP d’envoi figure bien dans cette liste :
exemple.fr. IN TXT "v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all"
Cette ligne autorise les serveurs de Google Workspace (via l’inclusion) ainsi qu’une adresse IP spécifique — typiquement celle du VPS qui héberge WordPress et envoie les e-mails transactionnels. Le suffixe ~all indique un échec « souple » pour tout autre expéditeur, tandis que -all impose un rejet strict, plus sévère mais aussi plus risqué en cas d’oubli d’un serveur légitime.
DKIM, la signature cryptographique
DomainKeys Identified Mail ajoute une signature numérique à chaque e-mail sortant, générée avec une clé privée détenue par le serveur d’envoi. Le serveur de réception vérifie cette signature à l’aide de la clé publique correspondante, publiée elle aussi dans le DNS sous forme d’un enregistrement TXT à un nom spécifique :
selecteur._domainkey.exemple.fr. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
Contrairement à SPF, qui vérifie seulement l’origine du message, DKIM garantit aussi que le contenu n’a pas été modifié en chemin. La configuration de DKIM dépend directement du fournisseur SMTP utilisé : la plupart des services d’e-mail transactionnel génèrent automatiquement la paire de clés et fournissent l’enregistrement TXT à ajouter, sans intervention manuelle sur la cryptographie elle-même.
DMARC, la politique appliquée en cas d’échec
Domain-based Message Authentication, Reporting and Conformance s’appuie sur SPF et DKIM pour définir explicitement ce que doit faire un serveur de réception lorsqu’un e-mail échoue aux deux contrôles : le mettre en quarantaine, le rejeter, ou ne rien faire de spécial. Sans DMARC, cette décision est laissée à la seule discrétion du fournisseur de messagerie destinataire, de façon incohérente d’un fournisseur à l’autre.
_dmarc.exemple.fr. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.fr"Cette politique demande une mise en quarantaine (plutôt qu’un rejet immédiat, plus prudent en phase de mise en place) et envoie des rapports agrégés à une adresse dédiée, ce qui permet de surveiller dans le temps les tentatives d’usurpation du domaine.
Mettre en place les trois progressivement
- Publier l’enregistrement SPF en premier, en listant tous les services qui envoient légitimement des e-mails pour le domaine.
- Activer DKIM auprès du fournisseur SMTP utilisé, puis publier l’enregistrement TXT fourni.
- Publier DMARC en politique
p=nonedans un premier temps, pour observer les rapports sans impact sur la délivrabilité. - Une fois confiant dans la configuration, faire évoluer DMARC vers
quarantine, puis éventuellementreject.
Vérifier la configuration
Plusieurs outils en ligne permettent de tester ces trois enregistrements en simulant une réception réelle, mais un simple dig confirme déjà leur publication effective :
dig TXT exemple.fr
dig TXT _dmarc.exemple.fr
Un domaine sans SPF ni DKIM n’est pas seulement moins bien délivré : il est aussi plus facile à usurper pour envoyer des e-mails frauduleux au nom de l’entreprise. La délivrabilité et la sécurité se rejoignent ici.
En résumé
SPF, DKIM et DMARC ne relèvent pas de WordPress mais du domaine tout entier, et se configurent une seule fois pour bénéficier à tous les e-mails envoyés, y compris ceux générés par le site. Les négliger revient à laisser les grands fournisseurs de messagerie décider seuls du sort des e-mails transactionnels, souvent au détriment de leur livraison.
