L’essentiel à retenir
- SPF (RFC 7208) : publie la liste des adresses IP et des services d’envoi autorisés à expédier des e-mails avec votre domaine dans l’expéditeur d’enveloppe (Return-Path).
- DKIM (RFC 6376) : s’appuie sur une paire de clés asymétriques pour apposer une signature cryptographique sur chaque message, prouvant qu’il a été autorisé par le domaine signataire et qu’il n’a pas été modifié en transit.
- DMARC (RFC 7489) : indique aux serveurs destinataires comment traiter les e-mails qui échouent à l’alignement SPF et DKIM (none, quarantine ou reject) et à quelle adresse envoyer les rapports agrégés.
- Depuis février 2024, Gmail et Yahoo exigent des expéditeurs en masse (Gmail les définit comme ceux qui envoient plus de 5 000 messages par jour vers des comptes Gmail personnels) qu’ils s’authentifient à la fois avec SPF et DKIM, publient un enregistrement DMARC (au minimum
p=none) et alignent le domaine From sur SPF ou DKIM.
Lorsqu’un serveur de messagerie destinataire comme Google Workspace, Microsoft 365 ou Yahoo Mail reçoit un message de contact@yourcompany.com, sa chaîne de filtrage exécute une série de contrôles techniques pour déterminer si le message provient réellement du propriétaire légitime de ce domaine, ou s’il s’agit d’une tentative d’usurpation ou d’hameçonnage.
Si les enregistrements d’authentification requis sont absents du DNS (Domain Name System) de votre domaine, le message est considéré comme à haut risque. Il finira vraisemblablement dans le dossier spam, ou sera rejeté purement et simplement au niveau SMTP, ce que votre plateforme d’envoi enregistrera comme un bounce.
1. Les trois mécanismes fondamentaux d’authentification des e-mails
Pour comprendre comment ces dispositifs de sécurité fonctionnent ensemble, il est utile d’examiner le rôle distinct, mais complémentaire, de chaque protocole :
SPF (Sender Policy Framework)
SPF fonctionne comme une liste d’autorisation publique publiée dans votre DNS. L’enregistrement déclare quels serveurs, identifiés par leur adresse IP ou par un mécanisme include pointant vers un fournisseur comme Amazon SES, SendGrid ou Mailgun, sont autorisés à envoyer des e-mails au nom de votre domaine. Les destinataires vérifient SPF par rapport au domaine de l’expéditeur d’enveloppe (MAIL FROM / Return-Path), et non par rapport à l’adresse From visible.
DKIM (DomainKeys Identified Mail)
DKIM garantit l’intégrité du message. Lorsqu’un message quitte le serveur d’envoi, une signature numérique est générée avec une clé privée et ajoutée au message sous la forme d’un en-tête DKIM-Signature. Le serveur destinataire récupère la clé publique correspondante dans votre DNS et s’en sert pour vérifier la signature, confirmant ainsi que les en-têtes signés et le corps du message n’ont été ni falsifiés ni modifiés en cours de route.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC est la couche qui relie SPF et DKIM. Il impose au serveur destinataire de vérifier si le domaine de l’adresse d’expéditeur visible (le Header From) correspond au domaine authentifié par SPF ou DKIM : c’est ce que l’on appelle l’alignement. Un message réussit le contrôle DMARC si au moins l’un des deux mécanismes est validé et aligné. DMARC définit également ce que le destinataire doit faire en cas d’échec de l’authentification et fournit un canal pour les rapports agrégés (RUA).
2. Structure et syntaxe d’un enregistrement SPF
Un enregistrement SPF est publié sous forme d’enregistrement TXT sur le domaine utilisé dans l’expéditeur d’enveloppe. Pour les e-mails envoyés depuis vos propres serveurs ou depuis Google Workspace, il s’agit généralement du domaine racine :
Host / Name: @ (or yourcompany.com)
Value / Content: v=spf1 include:amazonses.com ~all
Signification de chaque élément de l’enregistrement :
v=spf1: déclare la version de SPF utilisée. Ce doit être le premier terme de l’enregistrement.include:amazonses.com: autorise les plages d’IP d’envoi d’Amazon Simple Email Service (SES) à envoyer des e-mails pour le domaine. Si vous utilisez aussi SendGrid, l’équivalent estinclude:sendgrid.net. À noter : avec Amazon SES, SPF n’est aligné pour DMARC que si vous configurez un sous-domaine MAIL FROM personnalisé (par exemplebounce.yourcompany.com) et publiez cet enregistrement sur ce sous-domaine, accompagné de l’enregistrement MX fourni par SES. Avec l’authentification de domaine SendGrid et la sécurité automatisée activée, SendGrid gère le SPF de son sous-domaine de return-path via un CNAME : aucun include au niveau racine n’est donc nécessaire.~all(SoftFail) : indique que les e-mails provenant de serveurs absents de la liste doivent être considérés comme suspects, mais généralement acceptés malgré tout. C’est le choix le plus courant, en particulier tant que vous recensez encore vos sources d’envoi.-all(HardFail) : indique que les e-mails provenant de sources non autorisées doivent être traités comme un échec définitif. Les destinataires peuvent les rejeter, même si de nombreux grands fournisseurs de messagerie s’appuient désormais sur le résultat DMARC plutôt que de rejeter sur la seule base de SPF.
include, a, mx, ptr, exists et redirect, y compris les requêtes imbriquées). Si plusieurs services envoient depuis le même domaine (par exemple Google Workspace et Amazon SES), regroupez-les dans un seul enregistrement : v=spf1 include:_spf.google.com include:amazonses.com ~all.
3. Configurer DKIM
La configuration de DKIM consiste généralement à générer une paire de clés RSA, des clés de 2048 bits étant aujourd’hui le minimum recommandé. Lorsque vous connectez un fournisseur d’envoi via eMailBase :
- Le fournisseur génère les enregistrements DNS de ses sélecteurs DKIM. Amazon SES Easy DKIM fournit trois enregistrements
CNAMEde la forme<token>._domainkey.yourcompany.com; SendGrid fournit deux enregistrementsCNAMEDKIM (s1._domainkeyets2._domainkey), plus un pour son sous-domaine de return-path ; Mailgun fournit généralement un enregistrement TXT contenant la clé publique. - Connectez-vous au panneau de gestion de votre fournisseur DNS et créez chaque enregistrement exactement tel qu’il a été fourni.
- eMailBase interroge automatiquement le DNS et confirme l’activation dès que les enregistrements se sont propagés.
4. Déployer une politique DMARC stricte en toute sécurité
Publier une politique DMARC stricte dès le premier jour peut entraîner le rejet d’e-mails légitimes si l’une de vos sources d’envoi n’est pas encore entièrement couverte par SPF ou DKIM. L’enregistrement DMARC est publié sous forme d’enregistrement TXT sur _dmarc.yourcompany.com, et le déploiement standard se déroule en trois phases :
| Phase | Syntaxe de la politique | Objectif opérationnel |
|---|---|---|
| Phase 1 : surveillance | v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com |
Collecter les rapports agrégés et identifier toutes les sources d’envoi légitimes, sans impact sur la délivrance. |
| Phase 2 : quarantaine | v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourcompany.com |
Appliquer la politique de quarantaine (en général, une livraison dans le dossier spam) à 25 % des messages en échec, puis augmenter ce pourcentage à mesure que les rapports confirment que les e-mails légitimes passent. La prise en charge de pct varie selon les destinataires, et la révision DMARCbis de la norme le supprime. |
| Phase 3 : rejet | v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com |
Demander aux destinataires de rejeter tous les e-mails qui échouent au contrôle DMARC, afin de bloquer toute utilisation non autorisée de votre domaine. |
5. Vérifier vos enregistrements DNS et résoudre les problèmes
Une fois les enregistrements en place, vous pouvez les contrôler avec les outils en ligne de commande habituels :
dig +short TXT yourcompany.com
# Check a DKIM record (replace the selector with your own)
dig +short CNAME selector._domainkey.yourcompany.com
# Check the DMARC record
dig +short TXT _dmarc.yourcompany.com
Dans un espace de travail eMailBase, ces contrôles s’exécutent automatiquement grâce au DNS & Deliverability Manager, qui signale les conflits de syntaxe et les enregistrements manquants dès qu’ils apparaissent.
