SPF indique quels serveurs peuvent envoyer des courriels au nom de votre domaine, DKIM signe chaque message pour que l’on puisse vérifier qu’il n’a pas été modifié, et DMARC dit au destinataire quoi faire si les deux échouent, et vous envoie des rapports. Google, Yahoo et Microsoft les exigent des expéditeurs en masse ; tout domaine d’entreprise gagne à les avoir.
Ce que fait chaque enregistrement
Tous trois sont des enregistrements TXT du DNS du domaine (exemple : votredomaine.ad).
| Enregistrement | Où il est publié | Ce qu’il dit | Norme |
|---|---|---|---|
| SPF | Sur votredomaine.ad, en commençant par v=spf1 | Liste les serveurs et services autorisés à envoyer et se termine par -all (rejeter) ou ~all (suspect) | RFC 7208 (2014) |
| DKIM | Sur selector._domainkey.votredomaine.ad | Publie la clé publique avec laquelle le destinataire vérifie la signature ajoutée par le serveur d’envoi | RFC 6376 (2011) |
| DMARC | Sur _dmarc.votredomaine.ad | Fixe la politique (p=none, quarantine ou reject) et l’adresse des rapports (rua) | RFC 9989 (mai 2026) |
Un domaine ne peut avoir qu’un seul enregistrement SPF, et si le destinataire en trouve plusieurs, le résultat est une erreur permanente (RFC 7208, sections 3.2 et 4.5). L’évaluation admet aussi un maximum de 10 mécanismes qui déclenchent des requêtes DNS ; au-delà, c’est de nouveau une erreur permanente (section 4.6.4).
DMARC compare le domaine affiché dans l’adresse de l’expéditeur (le "From") avec le domaine validé par SPF ou par DKIM : il suffit que l’un des deux réussisse et soit aligné. La RFC 9989 (mai 2026) remplace la RFC 7489.
Comment le vérifier
- Regardez le DNS. Avec
dig +short TXT votredomaine.ad,dig +short TXT _dmarc.votredomaine.adetdig +short TXT selector._domainkey.votredomaine.ad, vous verrez ce qui est publié. Le sélecteur figure dans l’en-tête de la signature (s=). - Envoyez-vous un message sur un compte externe et ouvrez-en les en-têtes d’origine. La ligne
Authentication-Results(RFC 8601) doit afficherspf=pass,dkim=passetdmarc=pass. - Recommencez avec chaque outil qui envoie avec votre domaine : le courriel du bureau, la lettre d’information, le CRM, l’ERP, la facturation ou les formulaires du site.
Ce qu’exigent Google, Yahoo et Microsoft
| Fournisseur | Depuis | À qui cela s’applique | Exigences |
|---|---|---|---|
| Google (Gmail) | 1er février 2024 | À tous les expéditeurs, et plus strictement à ceux qui envoient près de 5 000 messages par jour ou plus vers des comptes Gmail personnels | Tous : SPF ou DKIM, TLS, PTR valide, taux de spam inférieur à 0,3 %. En masse : SPF, DKIM et DMARC aligné (au moins p=none), et désabonnement en un clic dans les messages de marketing |
| Yahoo | Février 2024 | Aux expéditeurs en masse (la page n’en fixe pas le volume) | SPF et DKIM, DMARC au moins p=none et aligné, en-tête de désabonnement (en un clic recommandé, RFC 8058) et taux de plaintes inférieur à 0,3 % |
| Microsoft (Outlook.com, Hotmail, Live) | Annoncé le 2 avril 2025 ; application à partir du 5 mai 2025 | Domaines qui envoient 5 000 messages par jour ou plus vers des adresses grand public de Microsoft | SPF et DKIM doivent réussir, et DMARC au moins p=none avec alignement de l’un des deux |
Google indique que, depuis novembre 2025, il renforce l’application avec des rejets temporaires et permanents, et qu’un expéditeur qui a rempli le critère une fois est considéré comme expéditeur en masse pour toujours. Microsoft a décidé de rejeter les messages non conformes, avec l’erreur 550 5.7.515.
Une PME envoie rarement 5 000 messages par jour vers Gmail, mais une lettre d’information ou une campagne de CRM peut y arriver, et Google demande SPF ou DKIM à tous les expéditeurs. Selon Google, les messages d’un même domaine principal s’additionnent.
Erreurs types
| Erreur | Effet | Solution |
|---|---|---|
| Deux enregistrements SPF sur le même domaine | SPF renvoie une erreur permanente | Les fusionner en un seul |
Plus de 10 requêtes DNS dans SPF (trop de include) | Erreur permanente | Retirer les services qui ne sont plus utilisés |
| Un outil envoie avec votre domaine sans figurer dans SPF ni signer avec DKIM | Ses messages échouent ou finissent dans les indésirables | L’ajouter à l’inventaire des expéditeurs et le configurer |
| DKIM activé dans l’outil, mais l’enregistrement TXT n’a pas été publié | Il n’y a pas de clé pour vérifier la signature | Publier l’enregistrement avec le bon sélecteur |
| L’outil signe avec son domaine et non avec le vôtre | DKIM réussit mais DMARC ne s’aligne pas | Configurer la signature avec votre domaine |
+all ou ?all dans SPF | Autorise tout le monde ou ne dit rien | Terminer par -all ou ~all |
DMARC à p=reject sans avoir regardé les rapports | Du courriel légitime est perdu | Suivre la politique progressive |
rua pointe vers une boîte que personne ne lit | On ne voit pas qui utilise le domaine | Envoyer les rapports vers une boîte ou un service qui les traite |
Une politique DMARC progressive
La RFC 9989 décrit le chemin : avec SPF, DKIM et une boîte de rapports en place, on publie DMARC en p=none avec rua ; on analyse les rapports pour découvrir les expéditeurs oubliés ; on corrige ceux qui échouent ou ne s’alignent pas ; et ce n’est qu’alors que l’on décide de passer à une politique d’application, quarantine d’abord et reject ensuite. Selon cette même norme, il peut s’écouler de nombreux mois avant d’avoir la certitude que tout le courriel légitime est authentifié.
La RFC 9989 supprime la balise pct et y ajoute t=y ou t=n pour indiquer un test ; vérifiez ce que prend en charge votre fournisseur avant de changer quoi que ce soit.
Andorre et Catalogne
Un cabinet ou un commerce a en général au moins deux expéditeurs avec le même domaine : le courriel de l’équipe et un outil qui envoie des factures ou des lettres d’information.
Hosting Andorra est l’une de nos marques et nous avons donc un intérêt. Selon son site, consulté le 25 octobre 2026, le DNS des domaines qui y sont hébergés s’édite depuis l’espace client avec des enregistrements A, AAAA, CNAME, MX, TXT, SRV, NS et CAA, elle propose une messagerie professionnelle et, si vous ouvrez un ticket, on vous aide à configurer le courriel. Le diagnostic gratuit de cybersécurité de TutumSec examine, selon la fiche, la configuration du courriel du domaine.
Que faire maintenant
- Dressez la liste de tout ce qui envoie du courriel avec votre domaine.
- Publiez un seul SPF qui les couvre et se termine par
-allou~all. - Activez DKIM chez chaque expéditeur et vérifiez que l’enregistrement est dans le DNS.
- Publiez DMARC en
p=noneavec une adresseruaque quelqu’un ou un service lit. - Examinez les rapports pendant quelques semaines, corrigez et, quand tout réussit, passez à
quarantine, puis àreject.
Questions fréquentes
Ai-je besoin de DMARC si j’envoie peu de courriels ?
Les règles de Google, Yahoo et Microsoft l’exigent des expéditeurs en masse, mais nous le recommandons pour tout domaine : en p=none, il n’affecte pas la remise et vous permet de voir qui utilise le domaine.
DMARC empêche-t-il qu’on usurpe mon identité ?
Seulement avec une politique d’application (quarantine ou reject), et seulement pour votre domaine exact. Il n’arrête pas les domaines ressemblants qu’enregistrerait un tiers.
Que se passe-t-il avec les messages transférés ?
Le transfert peut casser SPF parce que le serveur qui transfère n’est pas autorisé, alors que la signature DKIM se conserve en général si le message n’est pas modifié (RFC 7208, annexe D ; RFC 6376).
Sources
- IETF. RFC 7208, Sender Policy Framework (SPF) (en anglais). Avril 2014. Consulté le 25 octobre 2026. https://www.rfc-editor.org/rfc/rfc7208
- IETF. RFC 6376, DomainKeys Identified Mail (DKIM) Signatures (en anglais). Septembre 2011. Consulté le 25 octobre 2026. https://www.rfc-editor.org/rfc/rfc6376
- IETF. RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC) (en anglais). Mai 2026. Consulté le 25 octobre 2026. https://www.rfc-editor.org/rfc/rfc9989
- IETF. RFC 8601, Message Header Field for Indicating Message Authentication Status (en anglais). Mai 2019. Consulté le 25 octobre 2026. https://www.rfc-editor.org/rfc/rfc8601
- Google. Exigences pour les expéditeurs de courriel (Email sender guidelines) et questions fréquentes (en anglais). Consulté le 25 octobre 2026. https://support.google.com/a/answer/81126 et https://support.google.com/a/answer/14229414
- Yahoo. Sender Hub, best practices (en anglais). Consulté le 25 octobre 2026. https://senders.yahooinc.com/best-practices/
- Microsoft. Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders (Microsoft Tech Community, 2 avril 2025, avec mise à jour du 29 avril ; en anglais). Consulté le 25 octobre 2026. https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730
- Microsoft. Fix NDR error "550 5.7.515" in Outlook.com (assistance Microsoft, en anglais). Consulté le 25 octobre 2026. https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com
- Hosting Andorra. Gestió DNS et Correu professional (gestion du DNS et messagerie professionnelle ; en catalan). Consulté le 25 octobre 2026. https://www.hostingandorra.com/dns.php et https://www.hostingandorra.com/correu.php
Vous voulez faire examiner le courriel de votre domaine ?
Si vous voulez une première revue de la configuration du courriel et du DNS de votre domaine, commencez par la fiche du service : Cybersécurité pour les entreprises. La messagerie professionnelle et la gestion du DNS se trouvent chez Hosting Andorra.
