Intégrations & dataTutoGoogle Workspace, WordPress 6.x–7.x

SPF, DKIM, DMARC : pourquoi les e-mails de votre formulaire WordPress n’arrivent pas

Votre domaine est protégé par DMARC, votre WordPress envoie avec mail() depuis l’hébergeur : les notifications du formulaire sont rejetées sans bruit. Le diagnostic et la correction.

En bref

  • Par défaut, WordPress envoie ses e-mails avec la fonction mail() de PHP, depuis le serveur de l’hébergeur.
  • Si votre domaine publie une politique DMARC p=reject, un message qui n’est ni signé DKIM par votre domaine, ni validé SPF avec un domaine aligné, est refusé par le destinataire.
  • Ajouter include:_spf.google.com au SPF ne suffit pas : cela n’autorise que les serveurs de Google.
  • La correction durable : faire partir les e-mails de WordPress par votre messagerie (SMTP authentifié ou API), qui signe en DKIM avec votre domaine.

En sécurisant ce site, j’ai relevé une configuration à risque très courante : messagerie chez Google Workspace, DMARC en p=reject avec alignement strict, et un WordPress hébergé en mutualisé qui envoie ses notifications lui-même. Sur le papier, tout est « sécurisé ». En pratique, le formulaire de contact peut perdre des demandes sans qu’aucune erreur n’apparaisse.

Les trois mécanismes en deux minutes

MécanismeCe qu’il vérifieOù il vit
SPF (RFC 7208)Que le serveur d’envoi est autorisé pour le domaine de l’enveloppe (Return-Path), pas celui du « De : » visibleUn enregistrement TXT v=spf1 … sur le domaine
DKIM (RFC 6376)Une signature cryptographique du message, liée à un domaine (d=)Une clé publique en TXT sur <sélecteur>._domainkey.domaine
DMARC (RFC 9989)Que SPF ou DKIM réussit avec un domaine aligné sur le « De : », et quoi faire sinonUn TXT sur _dmarc.domaine : p=none, quarantine ou reject

Le mot clé est alignement. En mode strict (adkim=s, aspf=s), le domaine SPF ou DKIM doit être exactement celui du « De : ». En mode relâché (la valeur par défaut), un sous-domaine du même domaine suffit. Au passage, DMARC est désormais un standard IETF : la RFC 9989, publiée en mai 2026, remplace la RFC 7489.

Pourquoi WordPress échoue

La documentation de wp_mail() le dit clairement : la fonction s’appuie sur PHPMailer configuré pour utiliser mail(). Le message part donc du serveur de l’hébergeur, avec un expéditeur d’enveloppe fixé par l’hébergeur (souvent un compte technique du serveur mutualisé).

  • SPF : même si l’hébergeur est autorisé dans votre SPF, le domaine de l’enveloppe n’est pas le vôtre, donc SPF n’est pas aligné.
  • DKIM : le serveur ne signe pas avec la clé de votre domaine (chez Google Workspace, le sélecteur est google, et seule la messagerie Google signe avec).
  • DMARC : ni SPF ni DKIM ne sont alignés, donc échec, et p=reject demande au destinataire de refuser le message.

Autre piège : wp_mail() renvoie « vrai » dès que le message a été confié au serveur. La documentation précise que cela ne garantit pas qu’il a été reçu. Votre formulaire affiche « Merci », et la demande n’arrive jamais.

La correction : envoyer par votre messagerie

La page d’aide Google « Envoyer des e-mails depuis une imprimante, un scanner ou une application » propose trois voies. Pour un site WordPress, deux sont pertinentes :

  1. Le serveur SMTP de Gmail (smtp.gmail.com, port 587 en TLS ou 465 en SSL) avec l’adresse complète et un mot de passe d’application (validation en deux étapes requise). Limite indiquée : 2 000 messages par jour, largement assez pour un formulaire.
  2. Le relais SMTP (smtp-relay.gmail.com), configuré dans la console d’administration, avec authentification par identifiants et TLS. L’authentification par adresse IP ne convient pas à un hébergement mutualisé, dont l’IP est partagée.

Côté WordPress, une extension SMTP fait le travail (elle se branche sur le hook phpmailer_init, documenté dans la référence développeur). L’idéal est une extension qui gère la connexion OAuth à l’API Gmail, ce qui évite de stocker un mot de passe. Vérifiez que l’adresse d’expédition est bien une adresse (ou un alias) de votre domaine Workspace.

Une fois les envois passés par Google, include:_spf.google.com dans votre SPF devient utile, et le message est signé DKIM avec votre domaine : DMARC passe, même en alignement strict.

; Enregistrements DNS typiques (domaine exemple.fr, messagerie Google Workspace)
exemple.fr.                 TXT  "v=spf1 include:_spf.google.com ~all"
google._domainkey.exemple.fr. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.exemple.fr.          TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

Astuce

Un seul enregistrement SPF par domaine : chaque service d’envoi supplémentaire (outil d’emailing, CRM…) s’ajoute avec un include: dans le même enregistrement. Et gardez un œil sur la limite de 10 recherches DNS fixée par la RFC 7208 : les include imbriqués comptent aussi.

Diagnostiquer en cinq minutes

  1. Vérifiez vos enregistrements avec l’outil Check MX de la Google Admin Toolbox (SPF, et DKIM si vous donnez le sélecteur).
  2. Envoyez-vous un message depuis le formulaire vers une adresse Gmail. Dans Gmail, menu « Plus » → « Afficher l’original ».
  3. Lisez l’en-tête Authentication-Results : comparez smtp.mailfrom= (domaine SPF) et header.d= (domaine DKIM) avec header.from=. Un dmarc=fail confirme le diagnostic.
  4. Collez les en-têtes dans l’outil Messageheader de la même boîte à outils pour une lecture guidée.

Si le message n’arrive pas du tout, testez d’abord vers une boîte extérieure à votre domaine, puis activez les rapports DMARC (rua=) : ils listent les sources qui envoient en votre nom et leur taux d’échec.

Questions fréquentes

Ajouter include:_spf.google.com suffit-il à débloquer mon formulaire ?

Non, tant que WordPress envoie depuis le serveur de l’hébergeur. Cet include n’autorise que les serveurs de Google. Il faut faire partir les e-mails par Google (SMTP authentifié ou API) pour être signé en DKIM et aligné.

Faut-il passer DMARC en p=none pour que ça marche ?

Ce serait retirer la protection de votre domaine contre l’usurpation. Mieux vaut corriger la source d’envoi. p=none est utile au démarrage, pour observer les rapports avant de durcir.

Pourquoi WordPress dit-il que l’e-mail est parti ?

Parce que wp_mail() renvoie vrai dès que le message est remis au serveur local. La documentation précise que cela ne garantit pas la réception. Les rejets DMARC se produisent plus loin, chez le destinataire.

L'auteur

François Legrand

Je fabrique des modules Odoo sur mesure, des intégrations entre logiciels et des sites WordPress.

Besoin d’un outil ?

Des outils qui ne se parlent pas ?

Je relie votre ERP, votre emailing, votre mesure d’audience et votre site.

Voir l’offre intégrations