Comment corriger les problèmes de DKIM, SPF et usurpation d’identité sur un hébergement mutualisé

Contexte initial : des messages rejetés sans explication claire

Tout a commencé avec un comportement difficile à cerner : certains emails envoyés depuis le formulaire de contact du site n’arrivaient pas à destination, sans raison apparente. Les tests réalisés avec Gmail montraient un comportement aléatoire : certains messages passaient, d’autres non. Aucun message d’erreur clair n’était visible pour l’utilisateur.

L’adresse email concernée était de type contact@domaine.fr, hébergée chez un prestataire mutualisé (en l’occurrence o2switch). Le site tournait sous WordPress avec le plugin WP Mail SMTP configuré pour envoyer via SMTP.

Premiers diagnostics : DKIM, SPF et DMARC sont-ils en place ?

La vérification des en-têtes complètes des emails reçus montre rapidement des lignes clés :

dkim=pass header.i=@domaine.fr
spf=pass smtp.mailfrom=domaine.fr
dmarc=pass header.from=domaine.fr

Tout semble correct. Pourtant, en analysant des emails rejetés ou bloqués, on trouve :

Result: condition check lookup defer
Routeur: reject
Authentification: unauthorized

Cela indique que le serveur de destination a refusé l’email, sans que ce soit une erreur de configuration DKIM/SPF/DMARC directement visible.

Hypothèse : un mail rejeté à cause de l’usurpation d’identité ou d’un routage indirect

En creusant les logs, un nom de domaine récurrent apparaît : jabatus.fr. Plusieurs serveurs comme des.jabatus.fr, guerre.jabatus.fr, subit.jabatus.fr s’intercalent entre l’expéditeur initial (le site o2switch) et le destinataire. Il s’agit du prestataire SMTP utilisé par o2switch. L’IP apparaissant dans le champ SPF correspond bien à une adresse de cette plage, mais certains serveurs de destination n’apprécient visiblement pas ce routage indirect.

Autre signal d’alerte : l’adresse dmarc@domaine.fr a reçu une notification de rejet de la part de Yahoo, avec le message :

Authentification: unauthorized
Adresse IP de l'expéditeur: 66.163.187.71
Expéditeur: noreply@dmarc.yahoo.com

Ce type de message est fréquent lorsque des rapports DMARC sont envoyés vers une adresse du domaine, mais que celle-ci n’est pas configurée pour recevoir ou authentifier correctement ces rapports.

Action 1 : vérification et ajustement du SPF

La zone DNS contenait initialement :

v=spf1 a mx ip4:109.234.162.154 include:spf.jabatus.fr include:zoho.com include:eu-sender.zohoinvoice.com -all

Cette configuration est très permissive. On a nettoyé et réduit le champ SPF pour limiter les sources autorisées :

v=spf1 ip4:109.234.163.0/24 include:spf.jabatus.fr -all

Ce changement permet de mieux cadrer les IPs autorisées tout en gardant la prise en charge des envois via l’infrastructure de l’hébergeur.

Action 2 : verrouillage des sous-domaines en DMARC

Initialement, la politique DMARC était :

v=DMARC1; p=reject; rua=mailto:dmarc@domaine.fr

Elle a été complétée avec :

sp=reject; aspf=s

Ce qui donne :

v=DMARC1; p=reject; sp=reject; aspf=s; rua=mailto:dmarc@domaine.fr

Cela interdit l’envoi d’emails depuis n’importe quel sous-domaine du domaine principal, sauf s’ils sont explicitement autorisés. Cela empêche aussi les relayeurs non conformes de se faire passer pour le domaine.

Action 3 : nettoyage des adresses de destination des rapports DMARC

Les emails de rapport DMARC arrivent sur dmarc@domaine.fr, mais cette adresse ne devait pas être utilisée comme destinataire standard. Elle a été temporairement désactivée ou redirigée vers un récepteur SMTP plus tolérant.

Action 4 : sécurisation du formulaire avec reCAPTCHA v3 et honeypot

Le site était déjà protégé par reCAPTCHA v3, ce qui filtre les bots les plus basiques. Pour renforcer la protection :

• Le plugin WP Armour – Honeypot Anti Spam a été installé et configuré.
• Un seuil de 5 soumissions par heure par IP a été mis en place.
• Les tests de soumission confirment que les emails arrivent toujours, avec DKIM, SPF et DMARC tous à pass.

Cela permet également de protéger contre les spams ou tentatives d’attaques automatisées.

Conclusion : messages acceptés, identité respectée, contrôle regagné

Après l’ensemble des corrections, les envois depuis le site sont bien reçus. Les serveurs de destination acceptent les messages sans signaler de problème d’usurpation. Les configurations SPF et DMARC sont renforcées, et le comportement des serveurs intermédiaires (jabatus) reste sous contrôle.

Si vous constatez des rejets inexpliqués, des pertes d’emails ou des comportements aléatoires similaires, n’hésitez pas à nous contacter pour un audit complet de vos envois. Ce type de problème ne se résout pas avec un simple plugin.

Pour aller plus loin

• Prévoir un enregistrement BIMI avec logo certifié pour les boîtes mail modernes
• Utiliser un fournisseur SMTP dédié si le volume d’envoi devient important
• Activer l’analyse automatique des rapports DMARC avec des outils comme Postmark, DMARCian ou EasyDMARC

Un suivi régulier des en-têtes permet d’anticiper les blocages. Sur un hébergement mutualisé, chaque ligne DNS compte.Contexte initial : des messages rejetés sans explication claire

Tout a commencé avec un comportement difficile à cerner : certains emails envoyés depuis le formulaire de contact du site n’arrivaient pas à destination, sans raison apparente. Les tests réalisés avec Gmail montraient un comportement aléatoire : certains messages passaient, d’autres non. Aucun message d’erreur clair n’était visible pour l’utilisateur.

L’adresse email concernée était de type contact@domaine.fr, hébergée chez un prestataire mutualisé (en l’occurrence o2switch). Le site tournait sous WordPress avec le plugin WP Mail SMTP configuré pour envoyer via SMTP.

Premiers diagnostics : DKIM, SPF et DMARC sont-ils en place ?

La vérification des en-têtes complètes des emails reçus montre rapidement des lignes clés :

dkim=pass header.i=@domaine.fr
spf=pass smtp.mailfrom=domaine.fr
dmarc=pass header.from=domaine.fr

Tout semble correct. Pourtant, en analysant des emails rejetés ou bloqués, on trouve :

Result: condition check lookup defer
Routeur: reject
Authentification: unauthorized

Cela indique que le serveur de destination a refusé l’email, sans que ce soit une erreur de configuration DKIM/SPF/DMARC directement visible.

Hypothèse : un mail rejeté à cause de l’usurpation d’identité ou d’un routage indirect

En creusant les logs, un nom de domaine récurrent apparaît : jabatus.fr. Plusieurs serveurs comme des.jabatus.fr, guerre.jabatus.fr, subit.jabatus.fr s’intercalent entre l’expéditeur initial (le site o2switch) et le destinataire. Il s’agit du prestataire SMTP utilisé par o2switch. L’IP apparaissant dans le champ SPF correspond bien à une adresse de cette plage, mais certains serveurs de destination n’apprécient visiblement pas ce routage indirect.

Autre signal d’alerte : l’adresse dmarc@domaine.fr a reçu une notification de rejet de la part de Yahoo, avec le message :

Authentification: unauthorized
Adresse IP de l'expéditeur: 66.163.187.71
Expéditeur: noreply@dmarc.yahoo.com

Ce type de message est fréquent lorsque des rapports DMARC sont envoyés vers une adresse du domaine, mais que celle-ci n’est pas configurée pour recevoir ou authentifier correctement ces rapports.

Action 1 : vérification et ajustement du SPF

La zone DNS contenait initialement :

v=spf1 a mx ip4:109.234.162.154 include:spf.jabatus.fr include:zoho.com include:eu-sender.zohoinvoice.com -all

Cette configuration est très permissive. On a nettoyé et réduit le champ SPF pour limiter les sources autorisées :

v=spf1 ip4:109.234.163.0/24 include:spf.jabatus.fr -all

Ce changement permet de mieux cadrer les IPs autorisées tout en gardant la prise en charge des envois via l’infrastructure de l’hébergeur.

Action 2 : verrouillage des sous-domaines en DMARC

Initialement, la politique DMARC était :

v=DMARC1; p=reject; rua=mailto:dmarc@domaine.fr

Elle a été complétée avec :

sp=reject; aspf=s

Ce qui donne :

v=DMARC1; p=reject; sp=reject; aspf=s; rua=mailto:dmarc@domaine.fr

Cela interdit l’envoi d’emails depuis n’importe quel sous-domaine du domaine principal, sauf s’ils sont explicitement autorisés. Cela empêche aussi les relayeurs non conformes de se faire passer pour le domaine.

Action 3 : nettoyage des adresses de destination des rapports DMARC

Les emails de rapport DMARC arrivent sur dmarc@domaine.fr, mais cette adresse ne devait pas être utilisée comme destinataire standard. Elle a été temporairement désactivée ou redirigée vers un récepteur SMTP plus tolérant.

Action 4 : sécurisation du formulaire avec reCAPTCHA v3 et honeypot

Le site était déjà protégé par reCAPTCHA v3, ce qui filtre les bots les plus basiques. Pour renforcer la protection :

• Le plugin WP Armour – Honeypot Anti Spam a été installé et configuré.
• Un seuil de 5 soumissions par heure par IP a été mis en place.
• Les tests de soumission confirment que les emails arrivent toujours, avec DKIM, SPF et DMARC tous à pass.

Cela permet également de protéger contre les spams ou tentatives d’attaques automatisées.

Conclusion : messages acceptés, identité respectée, contrôle regagné

Après l’ensemble des corrections, les envois depuis le site sont bien reçus. Les serveurs de destination acceptent les messages sans signaler de problème d’usurpation. Les configurations SPF et DMARC sont renforcées, et le comportement des serveurs intermédiaires (jabatus) reste sous contrôle.

Si vous constatez des rejets inexpliqués, des pertes d’emails ou des comportements aléatoires similaires, n’hésitez pas à nous contacter pour un audit complet de vos envois. Ce type de problème ne se résout pas avec un simple plugin.

Pour aller plus loin

• Prévoir un enregistrement BIMI avec logo certifié pour les boîtes mail modernes
• Utiliser un fournisseur SMTP dédié si le volume d’envoi devient important
• Activer l’analyse automatique des rapports DMARC avec des outils comme Postmark, DMARCian ou EasyDMARC

Un suivi régulier des en-têtes permet d’anticiper les blocages. Sur un hébergement mutualisé, chaque ligne DNS compte.