CF GarageCe que prouve réellement chaque enregistrement
Les serveurs destinataires exécutent trois vérifications indépendantes sur chaque message prétendant venir de votre domaine :
- SPF est un enregistrement TXT listant les serveurs autorisés à envoyer pour votre domaine. À la connexion, le récepteur résout l'enregistrement et compare l'IP émettrice à la liste.
- DKIM est une signature cryptographique ajoutée par votre plateforme d'envoi et publiée en enregistrement TXT. Elle prouve que le message n'a pas été altéré et survit au transfert, contrairement à SPF.
- DMARC est l'enregistrement de politique qui relie les deux : il indique aux récepteurs quoi faire quand aucune vérification ne passe (rien, quarantaine ou rejet) et où envoyer les rapports agrégés.
La subtilité que la plupart des guides escamotent : SPF valide le domaine d'enveloppe, DKIM valide un domaine d'en-tête, et DMARC exige que l'un des deux corresponde à votre domaine From visible. Un SPF techniquement valide mais mal aligné échoue quand même au DMARC.
Configurer les enregistrements pas à pas
Étape 1 : inventorier tous les émetteurs. Listez votre serveur de messagerie ou votre prestataire, mais aussi les SaaS qui envoient en votre nom : CRM, support, facturation, notifications e-commerce, newsletter. Chacun contribue à SPF ou DKIM.
Étape 2 : publier SPF une fois, et une seule. Dans DNS > Enregistrements, créez un unique enregistrement TXT sur le domaine racine : v=spf1 include:_spf.prestataire.com -all. Un domaine doit avoir exactement un enregistrement SPF ; plusieurs enregistrements publiés invalident toute la vérification, ce qui est pire que pas de SPF du tout. Si un second prestataire envoie pour vous, fusionnez les deux mécanismes include dans le même enregistrement.
Étape 3 : activer DKIM sur chaque plateforme. Tout prestataire sérieux génère une paire de clés DKIM dans sa console d'administration. Collez les enregistrements TXT du sélecteur qu'il vous fournit (souvent découpés à cause de la limite de 255 caractères par chaîne DNS ; Cloudflare gère le découpage automatiquement). Envoyez un message de test et vérifiez la signature avec un outil ou dans les en-têtes.
Étape 4 : démarrer DMARC en mode surveillance. Ajoutez _dmarc.votredomaine en TXT avec p=none et une adresse de rapport rua=, par exemple v=DMARC1; p=none; rua=mailto:dmarc@votredomaine; fo=1. Dans ce mode rien n'est bloqué : vous collectez les rapports qui montrent quelles sources envoient pour vous et lesquelles échouent à l'alignement.
Étape 5 : durcir la politique progressivement. Après quelques semaines de rapports propres, passez à p=quarantine avec un pourcentage pct= réduit, puis à p=reject. Cette progression vous évite de bloquer vos propres factures tout en atteignant la protection complète.
Les erreurs fréquentes qui cassent la délivrabilité
- Deux enregistrements SPF sur le même domaine. Cause la plus fréquente d'échec SPF permanent. Un enregistrement, plusieurs
include. - Utiliser
+allou?all. Ces réglages autorisent tout internet à envoyer en votre nom et détruisent l'intérêt du contrôle. Terminez par-allune fois l'inventaire complet. - Dépasser les 10 résolutions DNS du SPF. Chaque
includeet chaque mécanisme compte dans une limite de 10 ; au-delà, SPF échoue intégralement. Aplatissez l'enregistrement ou retirez les émetteurs obsolètes. - Passer directement à
p=reject. Sans phase de surveillance, un émetteur oublié (un ancien serveur, un CRM résilié) devient un émetteur rejeté, et vos clients le remarquent avant vous. - Confondre Cloudflare Email Routing et l'envoi. Email Routing transfère le courrier entrant ; il ne fait pas de votre domaine un émetteur. Ses exigences SPF/DKIM sont distinctes de celles de votre plateforme sortante.
Si votre problème est du courrier entrant qui rebondit depuis le passage de votre zone chez Cloudflare, la cause est probablement ailleurs : enregistrements MX ou choix de proxification. Ce scénario est couvert dans notre guide sur les emails cassés après le passage sous Cloudflare.
Questions fréquentes
La proxification du domaine empêche-t-elle l'authentification email ?
Non. Les enregistrements proxifiés ne couvrent que le web ; le courrier ne passe jamais par le proxy. Il faut que les MX pointent vers des cibles non proxifiées (DNS only) et que les TXT SPF/DKIM/DMARC soient publiés. L'hébergement web proxifié n'empêche pas une authentification email correcte.
En combien de temps arrivent les rapports DMARC ?
Les rapports agrégés arrivent au rythme des récepteurs, en général toutes les 24 heures. Comptez au moins deux à trois semaines de surveillance pour attraper les émetteurs hebdomadaires et mensuels avant toute politique restrictive.
Le DMARC doit-il s'appliquer aux sous-domaines ?
Les sous-domaines héritent de la politique du domaine organisationnel sauf s'ils publient la leur. Si un sous-domaine envoie via des prestataires différents, publiez-lui un enregistrement propre ; s'il n'envoie rien, un sp=reject explicite bloque l'abus de vos sous-domaines.
Peut-on tester la configuration sans risquer ses emails de production ?
Oui, c'est exactement le rôle du mode surveillance p=none : rien n'est bloqué et les rapports montrent qui envoie pour vous et qui échoue à l'alignement. Vérifiez que SPF et DKIM passent avec des messages de test avant de durcir la politique.