E-mails WordPress qui n’arrivent pas : SPF, DKIM, DMARC et envoi SMTP (réduire le spam et sécuriser la délivrabilité)

Un formulaire WordPress peut afficher « message envoyé » et pourtant rien n’arrive. Ce décalage est normal : WordPress envoie via wp_mail(), mais un retour « true » ne signifie pas que l’e-mail sera livré en boîte de réception. La délivrabilité dépend surtout de l’authentification (SPF, DKIM, DMARC) et de la qualité de l’envoi (SMTP). Cela concerne autant une PME à Lausanne (Vaud) qu’à Genève, Fribourg, Sion (Valais), Neuchâtel ou Delémont (Jura).

Sources officielles : WordPress (wp_mail), IETF RFC 7208 (SPF), IETF RFC 6376 (DKIM), IETF RFC 7489 (DMARC), Google Workspace (SPF), Google Workspace (sender guidelines, DMARC), Google Workspace (DKIM), Microsoft Learn (SPF), Microsoft Learn (DKIM).

1) Pourquoi vos e-mails se perdent

• Envoi non authentifié : le domaine peut être usurpé (spoofing), donc les fournisseurs filtrent plus fort.
• SPF incomplet : une source d’envoi manque dans le DNS (site, outil marketing, CRM).
• DKIM absent : pas de signature cryptographique, donc moins de confiance.
• DMARC non défini : pas de politique, pas d’alignement clair avec l’adresse « From ».
• Envoi PHP trop « brut » : certains hébergements et boîtes pénalisent l’envoi non SMTP.

2) Base WordPress : wp_mail() n’est pas une garantie de réception

La documentation WordPress précise qu’un retour positif de wp_mail() indique surtout que la demande d’envoi a été traitée, pas que le destinataire a reçu l’e-mail. En clair : un formulaire peut « fonctionner » côté site et échouer côté délivrabilité.

3) SPF : autoriser les serveurs qui ont le droit d’envoyer pour votre domaine

SPF publie dans le DNS la liste des sources autorisées à envoyer. Point important : Google rappelle qu’un domaine ne doit avoir qu’un seul enregistrement SPF (TXT), mais cet enregistrement peut inclure plusieurs sources. Commencez par lister tous vos expéditeurs (site, Google Workspace, Microsoft 365, outil d’e-mailing, etc.).

Exemple SPF (Google Workspace uniquement)

TXT @
v=spf1 include:_spf.google.com ~all

Si plusieurs services envoient, il faut un SPF unique qui les regroupe, sinon vous risquez un SPF invalide.

4) DKIM : signer vos e-mails pour prouver l’origine

DKIM ajoute une signature, et la clé publique est publiée dans le DNS. Google et Microsoft documentent la mise en place via leurs consoles respectives. L’idée est simple : une fois activé, les messages sortants portent une signature vérifiable par les serveurs de réception.

Exemple DKIM (principe DNS)

Le format exact dépend du fournisseur. En général, vous ajoutez un TXT sur un sous-domaine de type selector._domainkey :

TXT selector1._domainkey
v=DKIM1; k=rsa; p=VOTRE_CLE_PUBLIQUE

5) DMARC : définir une politique et recevoir des rapports

DMARC permet d’exprimer une politique et des préférences de validation, et s’appuie sur SPF et DKIM. Google indique aussi qu’un DMARC « passe » quand le message est authentifié par SPF ou DKIM (ou les deux) et que le domaine authentifiant est aligné avec le domaine du « From ».

Exemple DMARC (démarrage prudent)

TXT _dmarc
v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100

Bon réflexe : commencer avec p=none pour observer, puis durcir seulement quand SPF et DKIM sont stables sur toutes les sources.

6) WordPress : privilégier un envoi SMTP authentifié

Si votre site envoie via PHP « mail » sur un hébergement mutualisé, la délivrabilité peut varier. Un envoi SMTP authentifié (via votre fournisseur e-mail) rend l’expédition plus cohérente. L’objectif : que le site n’envoie pas « comme un script », mais comme un expéditeur légitime, correctement authentifié.

Checklist (20 minutes) : diagnostiquer et corriger

• Identifier toutes les sources d’envoi (site, e-mailing, CRM, facturation).
• Vérifier SPF : un seul enregistrement, complet.
• Activer DKIM chez votre fournisseur (Google Workspace ou Microsoft 365), puis publier la clé.
• Ajouter DMARC en mode observation (p=none) avec une adresse de rapports.
• Basculer l’envoi WordPress en SMTP authentifié.
• Faire un test : envoyer un e-mail vers Gmail et Outlook, puis vérifier les en-têtes (SPF=pass, DKIM=pass, DMARC=pass).

FAQ SPF, DKIM, DMARC et WordPress (Suisse romande)

Pourquoi mes formulaires arrivent en spam à Genève ou à Fribourg ?

Le cas le plus fréquent : domaine non authentifié (SPF/DKIM/DMARC incomplets) ou envoi PHP peu fiable. Une fois SPF + DKIM en place, puis DMARC, la situation s’améliore généralement.

Peut-on avoir deux enregistrements SPF ?

En pratique, non. Google rappelle qu’un domaine doit avoir un seul enregistrement SPF, mais vous pouvez y inclure plusieurs sources autorisées.

DMARC sert à quoi si j’ai déjà SPF et DKIM ?

DMARC exprime une politique et s’appuie sur SPF/DKIM, avec une logique d’alignement avec le « From ». Cela rend votre position plus claire pour les serveurs de réception et vous donne des rapports.

Comment savoir si WordPress a vraiment envoyé l’e-mail ?

Un retour positif de wp_mail() ne prouve pas la réception. Le plus fiable est de tester l’envoi, vérifier les en-têtes côté boîte mail, et stabiliser l’envoi via SMTP authentifié.

Besoin de fiabiliser les e-mails de votre site ?

Pour auditer SPF/DKIM/DMARC, basculer l’envoi WordPress en SMTP, puis valider des tests réels (formulaire, devis, WooCommerce) sur l’ensemble des cantons romands, contactez clickclick.ch.