# SPF, DKIM et DMARC expliqués pour la délivrabilité des e-mails d’un site WordPress

> Trois enregistrements DNS suffisent à prouver qu'un e-mail envoyé au nom d'un domaine est légitime. Sans eux, même un envoi SMTP correctement configuré finit en spam.

- Auteur : Clément Hadrot
- Publié le : 2022-01-27
- Mis à jour le : 2022-01-27
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/spf-dkim-dmarc-delivrabilite-emails-wordpress/

## L’essentiel

- SPF liste les serveurs autorisés à envoyer pour un domaine
- DKIM signe cryptographiquement chaque e-mail envoyé
- DMARC indique quoi faire des e-mails qui échouent aux deux contrôles

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..."
```

> L'essentiel à retenir : SPF liste les serveurs autorisés à envoyer pour un domaine ; DKIM signe cryptographiquement chaque e-mail envoyé ; DMARC indique quoi faire des e-mails qui échouent aux deux contrôles

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

1. Publier l'enregistrement SPF en premier, en listant tous les services qui envoient légitimement des e-mails pour le domaine.
2. Activer DKIM auprès du fournisseur SMTP utilisé, puis publier l'enregistrement TXT fourni.
3. Publier DMARC en politique `p=none` dans un premier temps, pour observer les rapports sans impact sur la délivrabilité.
4. Une fois confiant dans la configuration, faire évoluer DMARC vers `quarantine`, puis éventuellement `reject`.

## 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.