# SPF, DKIM et DMARC expliqués simplement aux PME

Source : https://cybercaribou.com/blogue/spf-dkim-dmarc-explication · Cyber Caribou

> SPF, DKIM et DMARC sans jargon : exemples d'enregistrements DNS, exigences de Gmail, Yahoo et Outlook, et un plan pour protéger le domaine de votre PME.

Un manufacturier de la Beauce apprend par un client que des « factures » à son nom circulent. Elles viennent de son adresse exacte, facturation@ suivi de son vrai domaine. Le client a failli payer. Pourtant, personne n'a piraté la messagerie de l'entreprise : le fraudeur a simplement tapé cette adresse dans le champ « De ».

C'est possible parce que le courriel a été conçu, au début des années 1980, pour un réseau où tout le monde se faisait confiance. Rien dans le protocole d'origine ne vérifie que l'expéditeur affiché est le vrai.

Trois normes publiées dans votre DNS corrigent ce défaut : SPF, DKIM et DMARC. Elles sont gratuites, ne demandent aucun logiciel et sont maintenant exigées par Gmail, Yahoo et Outlook pour plusieurs expéditeurs. Voici comment elles fonctionnent, avec des exemples concrets.

- **SPF** liste les serveurs autorisés à envoyer pour votre domaine ; **DKIM** signe chaque message ; **DMARC** dit aux destinataires quoi faire si les vérifications échouent, et vous envoie des rapports.
- Sans DMARC en mode « reject », n'importe qui peut encore envoyer des courriels qui semblent venir de votre domaine.
- Déployez par étapes : inventaire des expéditeurs, SPF et DKIM, DMARC en observation (p=none), puis quarantine et reject.

## Pourquoi n'importe qui peut écrire « De : votre entreprise »

Un courriel contient en fait deux adresses d'expéditeur. La première, l'adresse d'enveloppe, sert aux serveurs pour acheminer le message et recevoir les retours. La seconde, l'en-tête « De » (*From*), est celle que vous voyez dans Outlook ou Gmail. Les deux peuvent être différentes, et aucune n'était vérifiée à l'origine.

SPF, DKIM et DMARC sont trois enregistrements TXT que vous ajoutez dans la zone DNS de votre domaine, là où se trouvent déjà les adresses de votre site Web et de votre messagerie. Les serveurs qui reçoivent vos courriels les consultent pour décider si un message est légitime.

## SPF : la liste des serveurs autorisés

SPF (*Sender Policy Framework*) publie la liste des serveurs qui ont le droit d'envoyer du courriel pour votre domaine. Exemple pour une entreprise sur Google Workspace qui envoie aussi ses factures depuis un serveur dont l'adresse IP est 203.0.113.25 :

```txt
exemple.ca.  3600  IN  TXT  "v=spf1 include:_spf.google.com ip4:203.0.113.25 -all"
```

Avec Microsoft 365, l'inclusion serait plutôt `include:spf.protection.outlook.com`. Le `-all` final signifie « tout autre serveur est refusé » ; `~all` (échec léger) est plus permissif.

Trois pièges courants :

- **Un seul enregistrement SPF par domaine.** Deux enregistrements qui commencent par `v=spf1` rendent SPF invalide.
- **Dix recherches DNS au maximum.** Chaque `include` en consomme au moins une. Avec un logiciel de paie, une plateforme d'infolettre et un CRM, on dépasse vite la limite.
- **SPF vérifie l'adresse d'enveloppe, pas l'adresse affichée.** À lui seul, il n'empêche donc pas l'usurpation du champ « De ». C'est le rôle de DMARC.

## DKIM : la signature qui voyage avec le message

DKIM (*DomainKeys Identified Mail*) ajoute une signature cryptographique à chaque courriel. Votre service d'envoi signe le message avec une clé privée ; la clé publique est publiée dans votre DNS, sous un « sélecteur ». Le destinataire vérifie la signature : si le message a été modifié en route ou ne vient pas de vous, elle ne correspond pas.

```txt
google._domainkey.exemple.ca.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu3x…"
```

(La clé publique réelle est beaucoup plus longue ; elle est générée par votre fournisseur.) Avec Microsoft 365, vous publiez plutôt deux enregistrements CNAME, `selector1` et `selector2`, qui pointent vers des clés gérées par Microsoft.

Le point le plus souvent oublié : DKIM doit être activé pour **chaque** service qui envoie en votre nom, pas seulement pour votre messagerie principale. Privilégiez des clés de 2 048 bits.

## DMARC : la règle du jeu et les rapports

DMARC relie le tout à l'adresse que voit le destinataire. Un message réussit DMARC si SPF **ou** DKIM réussit **et** que le domaine vérifié correspond au domaine du champ « De ». C'est ce qu'on appelle l'alignement.

DMARC indique aussi quoi faire en cas d'échec, et à qui envoyer des rapports quotidiens sur tous les courriels qui utilisent votre domaine. On commence en observation :

```txt
_dmarc.exemple.ca.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@exemple.ca"
```

Puis, une fois tous les expéditeurs légitimes authentifiés, on resserre :

```txt
; Étape 2 : les messages non conformes vont aux indésirables
_dmarc.exemple.ca.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.ca"

; Étape 3 : les messages non conformes sont refusés
_dmarc.exemple.ca.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@exemple.ca"
```

| Balise | Rôle | Exemple |
|---|---|---|
| `v` | Version, toujours en premier | `v=DMARC1` |
| `p` | Politique : none, quarantine ou reject | `p=reject` |
| `rua` | Adresse qui reçoit les rapports agrégés | `rua=mailto:dmarc@exemple.ca` |
| `sp` | Politique des sous-domaines (sinon, celle de `p`) | `sp=reject` |
| `adkim` / `aspf` | Alignement relâché (`r`, par défaut) ou strict (`s`) | `adkim=s` |

Les rapports arrivent en XML, illisibles à l'œil nu. Un outil d'analyse DMARC, dont plusieurs offrent un forfait gratuit pour les petits volumes, les transforme en tableau clair.

Bonne nouvelle : vous n'avez pas à vérifier tout ça à la main. Notre audit éclair gratuit vérifie automatiquement vos enregistrements SPF, DKIM et DMARC et signale les erreurs les plus fréquentes.

## Gmail, Yahoo et Outlook ont serré la vis

Ces normes existent depuis des années, mais les grands fournisseurs les rendent maintenant obligatoires :

- **Google** : depuis le 1er février 2024, tous les expéditeurs vers Gmail doivent utiliser SPF ou DKIM. Ceux qui envoient plus de 5 000 messages par jour à des comptes Gmail doivent avoir SPF, DKIM **et** DMARC (p=none accepté), un champ « De » aligné, un désabonnement en un clic et un taux de plaintes sous 0,3 %. Depuis novembre 2025, Gmail resserre l'application : les messages non conformes peuvent subir des rejets temporaires et permanents.
- **Yahoo** : des exigences semblables s'appliquent depuis février 2024, dont DMARC (au moins p=none) pour les expéditeurs en volume.
- **Microsoft** : depuis le 5 mai 2025, les domaines qui envoient plus de 5 000 messages par jour vers Outlook.com, Hotmail et Live doivent réussir SPF et DKIM et publier DMARC (au moins p=none) avec alignement. Les messages non conformes sont rejetés avec l'erreur « 550 5.7.515 ».

Votre PME n'envoie peut-être pas 5 000 courriels par jour. Votre infolettre ou votre logiciel de facturation, si. Et la tendance est claire : un domaine sans authentification sera de plus en plus traité comme suspect.

## Plan de déploiement en six étapes

- [ ] **Inventorier** tous les services qui envoient du courriel en votre nom : messagerie, infolettre, CRM, facturation, paie, formulaires du site Web, imprimantes multifonctions.
- [ ] **Corriger SPF** : un seul enregistrement, moins de dix recherches DNS, terminé par `-all` ou `~all`.
- [ ] **Activer DKIM** pour chacun de ces services, avec le domaine de l'entreprise.
- [ ] **Publier DMARC en p=none** avec une adresse `rua`, puis analyser les rapports pendant quelques semaines.
- [ ] **Passer à p=quarantine**, puis à **p=reject** une fois que tous les envois légitimes réussissent DMARC.
- [ ] **Verrouiller les domaines inutilisés** : un domaine réservé pour protéger votre nom, mais qui n'envoie jamais de courriel, devrait refuser tout envoi.

Pour ce dernier point, deux lignes suffisent :

```txt
example.com.         3600  IN  TXT  "v=spf1 -all"
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject"
```

Les réglages précis varient selon votre plateforme : nous les détaillons dans nos guides d'[audit Microsoft 365](https://cybercaribou.com/blogue/audit-securite-microsoft-365) et d'[audit Google Workspace](https://cybercaribou.com/blogue/audit-securite-google-workspace).

## En conclusion

SPF, DKIM et DMARC ne coûtent rien et protègent à la fois votre délivrabilité et votre réputation. Sans eux, votre domaine est une arme toute prête pour la [fraude du président](https://cybercaribou.com/blogue/fraude-president-courriel-affaires-compromis) et les fausses factures envoyées à vos clients.

Le chemin jusqu'à p=reject demande surtout de la méthode : repérer chaque service qui envoie en votre nom et l'authentifier correctement. Si vous préférez déléguer, nos [services de remédiation et de durcissement](https://cybercaribou.com/services/remediation-durcissement) prennent en charge le déploiement, jusqu'à la politique finale.

## FAQ

**DMARC protège-t-il contre les domaines qui imitent le nôtre ?**
Non. DMARC protège uniquement votre domaine exact. Un fraudeur qui enregistre un domaine sosie (une lettre changée, un .com au lieu d'un .ca) peut publier ses propres enregistrements SPF, DKIM et DMARC parfaitement valides. Contre les domaines sosies, il faut une surveillance des nouveaux domaines, un bandeau « expéditeur externe » et des procédures de vérification des paiements.

**SPF, DKIM et DMARC bloquent-ils les virus dans les courriels ?**
Non. Ces trois mécanismes vérifient qui a envoyé le message, pas ce qu'il contient. Un courriel parfaitement authentifié peut provenir d'un compte compromis et contenir une pièce jointe malveillante. Le filtrage antipourriel et antimaliciel de votre messagerie reste indispensable.

**Qu'est-ce que BIMI et est-ce utile pour une PME ?**
BIMI permet d'afficher le logo de votre entreprise à côté de vos courriels dans certaines messageries. Il exige une politique DMARC appliquée (quarantine ou reject) et, chez Gmail, un certificat de marque payant. C'est un bonus d'image intéressant une fois DMARC en place, pas une priorité de sécurité.

## Sources

- [Google : exigences pour les expéditeurs de courriels vers Gmail](https://support.google.com/a/answer/81126?hl=fr)
- [Google : FAQ sur les exigences pour les expéditeurs (application depuis novembre 2025)](https://support.google.com/a/answer/14229414?hl=fr)
- [Yahoo Sender Hub : bonnes pratiques et exigences pour les expéditeurs](https://senders.yahooinc.com/best-practices/)
- [Microsoft : erreur 550 5.7.515 et exigences pour les expéditeurs en volume vers Outlook.com](https://support.microsoft.com/outlook/fix-ndr-error-550-5-7-515-in-outlook-com)