Defaults.Exposed › Corrections › Guides

Configurer l'e-mail sur un nouveau domaine : la checklist SPF, DKIM et DMARC en 20 minutes (2026)

Publié 2026-07-08

Chiffres au 2026-06-29 · méthodologie v7. Données de recensement agrégées sur 261 millions de domaines évalués. Voir comment nous notons.

Un nouveau domaine a besoin de quatre choses avant son premier e-mail : un scan de référence, un enregistrement SPF nommant votre vrai prestataire, une signature DKIM en domaine personnalisé, et un enregistrement DMARC avec rapports activés dès le premier jour. La plupart des domaines n’y arrivent jamais — 46,4 % (121 145 609 sur 261 086 232 domaines évalués) n’ont aucun SPF du tout, selon le recensement Defaults.Exposed (au 2026-06-29).

Tout publier prend environ 20 minutes : scanner pour obtenir une référence, ajouter un enregistrement SPF, activer le DKIM en domaine personnalisé chez votre prestataire, publier DMARC p=none avec une adresse de rapport, éventuellement ajouter MTA-STS, puis rescanner et conserver le rapport. Ce qui prend plus longtemps, c’est ce qu’aucune checklist ne peut accélérer — la propagation DNS et la réputation d’envoi — et ce guide est honnête sur les deux.

20 minutes, est-ce vraiment suffisant ?

Pour publier les enregistrements, oui — chaque étape ci-dessous est une entrée DNS plus quelques clics dans la console d’administration de votre prestataire. Deux choses prennent plus longtemps, et prétendre le contraire est la manière dont les nouveaux domaines finissent dans les spams :

• La propagation. Les nouveaux enregistrements se résolvent généralement en quelques minutes, mais les résolveurs mettent en cache selon le TTL, et un domaine tout juste délégué peut mettre des heures à répondre de façon cohérente. Vérifiez avec dig ; ne modifiez pas frénétiquement pendant que les caches se mettent à jour.
• La montée en puissance. Un nouveau domaine a une réputation d’envoi nulle, et l’authentification est la condition préalable à la réputation, pas un substitut. Commencez avec un volume faible, à échelle humaine, et augmentez progressivement sur plusieurs semaines.

L’affirmation honnête : 20 minutes achètent une authentification correctement publiée. Les semaines suivantes d’envoi raisonnable achètent la délivrabilité.

La checklist en 20 minutes

1. Lancez d’abord le scan gratuit sur defaults.exposed. Scannez le nouveau domaine avant de toucher au DNS. La base de référence notée « rien configuré » prend quelques secondes à capturer et rend le rapport final significatif — vous voudrez la paire avant/après (étape 6).
2. Publiez un seul enregistrement SPF pour votre vrai prestataire. Exactement un enregistrement TXT commençant par v=spf1, contenant l’include de votre prestataire — par exemple v=spf1 include:_spf.google.com ~all pour Google Workspace, ou include:spf.protection.outlook.com pour Microsoft 365 ; si votre DNS vit chez un panneau de registrar, le guide GoDaddy couvre les subtilités de l’interface. Un seul enregistrement : deux enregistrements v=spf1 sont une erreur permanente qui annule totalement SPF — l’état dans lequel sont bloqués 1 013 416 domaines, environ un sur 138 de ceux qui tentent SPF (recensement au 2026-06-29), généralement un reliquat de migration. N’ajoutez pas d’includes « au cas où » : SPF plafonne les recherches DNS à 10, et au moins 797 263 domaines ont annulé leur enregistrement en dépassant ce plafond. Et sachez ce que SPF vérifie réellement : les serveurs de réception l’évaluent contre le domaine du Return-Path (RFC5321.MailFrom) — l’adresse de rebond — pas l’en-tête From que voient vos destinataires.
3. Activez la signature DKIM en domaine personnalisé. Votre prestataire signe le courrier de toute façon ; la question est quel domaine la signature nomme. Tant que vous n’avez pas terminé cette étape, Google Workspace signe avec son défaut gappssmtp.com et Microsoft 365 avec onmicrosoft.com — des signatures qui passent DKIM mais ne s’alignent pas avec votre domaine, donc DMARC échoue quand même. Générez la clé dans la console d’administration et publiez ce que le prestataire vous donne : un enregistrement TXT 2048 bits pour Google, deux CNAME (selector1/selector2) pour Microsoft 365. Si un enregistrement ne tient pas dans votre panneau DNS, voir corriger DKIM — les longues clés massacrées par les interfaces sont un classique.
4. Publiez DMARC dès le premier jour — p=none avec une adresse de rapport. Un enregistrement TXT à _dmarc.votredomaine.com : v=DMARC1; p=none; rua=mailto:[email protected]. Soyez clair sur ce que cela fait : p=none ne protège encore rien — c’est un mode de surveillance. Mais cela ne coûte rien, et les rapports agrégés couvrent alors l’historique d’envoi de votre domaine dès le tout premier message. Les domaines établis passent des semaines de rapports rien qu’à découvrir des expéditeurs qu’ils avaient oubliés ; vous achetez cette visibilité gratuitement, dès le jour zéro. Voir corriger DMARC pour l’anatomie de l’enregistrement.
5. Optionnel mais peu coûteux sur un nouveau domaine : MTA-STS et TLS-RPT. MTA-STS indique aux serveurs émetteurs que votre domaine exige du TLS pour le courrier entrant (un enregistrement DNS plus un petit fichier de politique hébergé) ; TLS-RPT signale les échecs de chiffrement à la livraison. Sur un domaine établi, ces réglages demandent du soin ; sur un nouveau domaine avec un seul prestataire, il n’y a rien à casser, et mode: testing est pratiquement sans risque. Configurez-les maintenant ou passez — mais décidez, ne laissez pas traîner.
6. Relancez le scan et conservez le rapport. Lancez à nouveau le scan — SPF, DKIM et DMARC devraient tous apparaître en vert. Enregistrez le rapport noté : preuve datée de l’état du domaine au lancement, et exactement ce que demanderont un assureur ou un questionnaire client.

Combien de domaines complètent réellement cette checklist ?

Très peu — et la plupart échouent dès le premier obstacle. Sur les 261 086 232 domaines évalués dans le recensement Defaults.Exposed (au 2026-06-29) :

Les 20 minutes décrites sur cette page placent un domaine tout neuf devant environ 96 % d’Internet sur la triade complète. Le modèle de maturité d’adoption SPF détaille chaque échelon de cette échelle.

À quelle vitesse un nouveau domaine peut-il atteindre p=reject ?

Des semaines, pas des mois — le véritable avantage de partir de zéro. Ce qui rend l’application de DMARC lente sur les domaines établis, c’est l’héritage : le connecteur CRM oublié, l’outil de facturation branché par quelqu’un en 2019, la plateforme de newsletter que personne n’a documentée. Chacun doit être trouvé dans les rapports et corrigé avant que la politique puisse se resserrer — d’où le déploiement habituel de plusieurs mois.

Un nouveau domaine n’a aucun expéditeur hérité : vous avez configuré vous-même chaque source d’envoi, cette semaine, et les rapports de l’étape 4 le confirmeront. Faites tourner p=none pendant deux à quatre semaines d’envoi réel, vérifiez que les rapports couvrent tout ce que vous utilisez réellement (boîtes aux lettres, factures, reçus, le formulaire de contact du site), puis passez à p=quarantine puis à p=reject une fois que les rapports sont propres. La mécanique par paliers — montée en pct, politique de sous-domaines, ce qu’il faut surveiller — se trouve dans de p=none à p=reject ; sur un nouveau domaine, vous les franchirez rapidement, jusqu’à un point que seuls 10,59 % des domaines évalués ont atteint.

Et l’ancien domaine que vous remplacez ?

Si ce nouveau domaine s’inscrit dans un changement de marque, le domaine que vous quittez est désormais votre plus gros risque e-mail : toujours à vous, toujours de confiance pour vos contreparties, plus jamais surveillé. Ne l’abandonnez pas — verrouillez-le explicitement. C’est un job court à part : ce vieux domaine de votre changement de marque est une porte laissée ouverte.

Questions fréquentes

Puis-je publier ces enregistrements avant de choisir un prestataire de messagerie ? DMARC, oui — p=none avec rua est indépendant du prestataire, donc publiez-le le jour où vous enregistrez le domaine. SPF a besoin de l’include de votre prestataire ; tant que vous n’en avez pas choisi un, publiez v=spf1 -all (personne n’est autorisé à envoyer) et remplacez-le à l’étape 2. C’est strictement mieux que l’absence d’enregistrement où se trouvent 121 145 609 domaines (46,4 % des 261 086 232 évalués, au 2026-06-29).

Ai-je besoin de DKIM si SPF passe déjà ? Oui. SPF casse sous le transfert par conception, et il valide le domaine du Return-Path, qui pour de nombreux outils n’est pas le vôtre — le DKIM aligné est la branche qui survit aux deux. Seuls 3,87 % des domaines évalués complètent la triade complète SPF+DKIM+DMARC appliqué (recensement au 2026-06-29) ; DKIM est l’étape que la plupart des abandonnistes sautent. Commencez par corriger DKIM si le scan le signale.

Un nouveau domaine doit-il utiliser ~all ou -all ? Sur un domaine établi, ~all est le choix prudent pendant que vous trouvez les expéditeurs oubliés. Un nouveau domaine n’en a aucun à trouver : une fois l’include de votre prestataire en place et DKIM en train de signer, -all est sûr bien plus tôt. Vous voulez ceinture et bretelles ? Confirmez d’abord avec deux semaines propres de rapports DMARC.

Les trois enregistrements passent — pourquoi mon courrier va-t-il encore dans les spams ? Parce que l’authentification et la réputation sont deux choses différentes : des enregistrements qui passent signifient que les destinataires peuvent vérifier que le courrier est bien de vous, pas qu’ils vous font déjà confiance. Les nouveaux domaines gagnent la confiance en envoyant du courrier cohérent, désiré, à faible volume, avec une montée en puissance progressive. Si le courrier échoue aux vérifications plutôt que d’atterrir simplement en spam, commencez par corriger SPF et descendez dans les résultats du scan.

Envoyez le rapport au propriétaire

Si vous configurez ce domaine pour un client, terminez le travail avec des preuves. Relancez le scan gratuit après l’étape 6 et transmettez le rapport noté au chef d’entreprise : SPF, DKIM et DMARC qui passent, en langage clair, daté au lancement. C’est l’artefact dont il aura besoin pour le renouvellement de la cyberassurance et le prochain questionnaire de sécurité fournisseur — et cela prouve que le domaine a commencé sa vie comme 96 % d’Internet n’y parvient jamais.

Vérifiez votre domaine → · De p=none à p=reject sans perdre d’e-mails légitimes → · Données agrégées uniquement. Données stockées et traitées dans l’UE.