Passer son DMARC en p=reject sans casser ses emails

p=reject veut dire « si ce message n'est pas authentifié, jette-le ». C'est la seule politique qui empêche vraiment quelqu'un d'envoyer des emails à ta place — et c'est aussi la seule qui peut faire disparaître tes emails si un de tes outils légitimes n'est pas correctement configuré. La méthode sûre tient en une phrase : trois paliers, none → quarantine → reject, et on ne passe au suivant qu'après avoir lu ses rapports. Compte 6 à 10 semaines du début à la fin, dont 90 % de lecture et 10 % de saisie.

Bonne nouvelle avant de commencer : personne ne t'oblige à aller jusqu'à p=reject. Gmail, Yahoo et Outlook.com demandent un DMARC publié, et acceptent explicitement p=none. Tu vises p=reject pour protéger ton nom, pas pour cocher une case.

Ce qu'on ne fait pas : on ne touche jamais à ta zone DNS. Ce guide t'explique quoi taper, quand, et à quoi ressemble un rapport qui dit « tu peux y aller ». C'est toi qui valides, chez ton hébergeur, avec tes accès.

Les trois valeurs à copier-coller, dans l'ordre

Tu ne crées qu'un seul enregistrement, nommé _dmarc, et tu modifies sa valeur à chaque palier. Tu n'en ajoutes jamais un deuxième — un domaine avec deux enregistrements DMARC n'a plus de DMARC du tout.

Palier 1 — observer (2 à 4 semaines)

Ce que tu dois remplacer : TON-ADRESSE@TON-DOMAINE.fr par une adresse que tu relèves vraiment. Sans rua=, tu ne recevras aucun rapport, et tout ce guide devient impossible à suivre.

p=none veut dire « observe et raconte-moi ». Personne n'est bloqué, rien ne change pour tes destinataires, et tu commences à recevoir la liste de tout ce qui envoie en ton nom — y compris ce que tu avais oublié.

Palier 2 — mettre de côté (2 à 4 semaines)

p=quarantine veut dire « si ce n'est pas authentifié, mets-le en indésirable ». Un email légitime que tu aurais oublié n'est pas perdu : il part en spam, ton destinataire peut le récupérer, et il t'appellera pour te le dire. C'est le palier qui rend l'erreur visible sans la rendre irréversible — c'est le vrai filet de sécurité de toute l'opération.

Palier 3 — refuser

p=reject veut dire « jette-le ». Google le formule sans détour : « la politique reject signifie que les messages qui ne passent pas DMARC sont rejetés par les serveurs de réception et ne sont jamais délivrés. »

Les trois options que tu peux ajouter — et celle qu'il ne faut plus utiliser

Pourquoi on te dit d'oublier pct=. Ce réglage a longtemps été la façon standard de durcir progressivement (p=quarantine; pct=5, puis 25, puis 100). Il a été supprimé de la norme DMARC par la RFC 9989, publiée en mai 2026, qui remplace la RFC 7489. Concrètement : les serveurs qui suivent la nouvelle norme ignorent ton pct= et appliquent ta politique à 100 % des messages. Tu crois durcir à 5 %, tu durcis à 100 % chez une partie de tes destinataires — exactement le contraire de ce que tu cherchais.

À noter, parce que tu vas tomber dessus : la documentation de Google recommande toujours pct=5 dans son tutoriel de déploiement DMARC. Ce n'est pas une erreur de leur part, c'est un tutoriel écrit avant la nouvelle norme. Mais si tu suis leur méthode aujourd'hui, tu construis ta progressivité sur un réglage que la norme a retiré. Notre méthode en trois paliers atteint le même objectif — plus lentement, plus sûrement, et sans dépendre d'un tag mort.

Et t=y alors ? C'est le remplaçant prévu par la nouvelle norme : t=y demande au serveur de réception de « ne pas appliquer la politique, mais d'appliquer plutôt les règles de traitement particulières qu'il pourrait avoir en place ». Dans les faits, p=reject; t=y se comporte comme p=quarantine, et p=quarantine; t=y comme p=none. C'est élégant sur le papier. En pratique, la norme date de mai 2026 et on ne sait pas encore quelle proportion des serveurs de réception l'implémente — un serveur qui ne connaît pas t= ignore le tag et applique ton p=reject en entier. Notre position : ne pose pas p=reject; t=y en pensant être protégé du risque. Passe par p=quarantine, qui est compris partout depuis dix ans.

⚠️ Et l'alignement strict (adkim=s / aspf=s) ? Ne le fais pas — sauf si tu sais exactement pourquoi. Jusqu'ici on ne t'a donné que des raisons d'aller vers plus strict. En voici une, documentée, d'arrêter avant : l'alignement strict casse des emails légitimes chez de vrais services. Shopify l'écrit noir sur blanc dans sa documentation : vérifie que ton DMARC « ne contient pas adkim=s ni aspf=s » — l'alignement strict fait échouer ses emails transactionnels, qui partent d'un sous-domaine. HubSpot dit la même chose pour d'autres raisons : adkim et aspf « doivent tous deux être en r ». L'alignement relâché (r, la valeur par défaut — tu n'as rien à écrire) accepte les sous-domaines du même domaine ; c'est le bon réglage pour presque tout le monde. p=reject avec alignement relâché protège déjà très bien ton nom.

Le chemin : ce qu'il faut faire à chaque palier

Avant de commencer — les deux prérequis non négociables

1. SPF et DKIM doivent être en place et fonctionner depuis au moins 48 heures. Google est explicite : « configure DKIM et SPF au moins 48 heures avant de configurer DMARC ». Si tu n'en es pas là, commence par le guide de ton hébergeur (liens en bas de page) et reviens.
2. Tu dois avoir une adresse rua= que tu relèves. Les rapports DMARC sont des fichiers XML compressés, illisibles à l'œil nu quand tu en reçois quarante par jour. C'est précisément le travail qu'on fait pour toi — mais tu peux aussi commencer à la main.

Palier 1 → 2 : les questions auxquelles tes rapports doivent répondre

Tu ne passes en quarantine que quand tu peux répondre oui aux quatre :

1. Est-ce que je reconnais tous les expéditeurs qui apparaissent dans mes rapports ? Fais la liste. Elle est presque toujours plus longue que prévu : les boîtes de ton hébergeur, ta suite bureautique, ton outil de campagnes, ton logiciel de facturation, le formulaire de contact de ton site, ton CRM, ta billetterie, ton prestataire de recrutement, l'ERP qui envoie les bons de commande, et parfois le copieur du couloir.
2. Est-ce que chacun d'eux passe SPF ou DKIM — et surtout, est-ce qu'il est aligné ? Voir l'erreur n°2 plus bas : ce n'est pas la même question.
3. Est-ce que le volume non authentifié restant est marginal et identifié ? Un petit reste de messages en échec est normal (transferts, listes de diffusion). Un reste que tu ne sais pas expliquer, non.
4. Est-ce que j'ai regardé pendant au moins deux semaines complètes ? Les envois mensuels — la facturation, la paie, la newsletter — n'apparaissent pas dans une semaine de rapports. C'est exactement ce genre d'expéditeur qu'on découvre en le cassant.

Palier 2 → 3 : la même liste, plus une

Deux à quatre semaines en quarantine, puis :

5. Est-ce que quelqu'un s'est plaint ? Le palier 2 sert à ça. Si personne n'a signalé d'email disparu ou retrouvé en indésirable, et que les rapports sont propres, tu peux passer en reject.

Où se change la valeur

Tu modifies l'enregistrement _dmarc dans ta zone DNS, chez celui qui l'héberge. Le chemin exact dépend de ton hébergeur — on l'a détaillé pour chacun :

• OVH
• IONOS
• Gandi
• o2switch
• Infomaniak
• Hostinger
• Cloudflare

Réflexe à prendre avant de durcir : baisse le TTL de ton enregistrement _dmarc à 300 secondes (5 minutes) 24 heures avant de passer au palier suivant. Si tu dois faire marche arrière, ton retour en arrière prendra 5 minutes au lieu d'une journée. Tu remonteras le TTL quand tout sera stable.

Et le corollaire que presque personne n'écrit — AWS est le seul à le documenter : « baisser le TTL maintenant ne fera pas prendre effet ton changement plus vite. Les résolveurs DNS ont déjà l'ancienne valeur en cache, et ils ne verront la nouvelle qu'à l'expiration du délai fixé par l'ancien réglage. » Autrement dit : baisser le TTL après avoir durci ne sert à rien. C'est avant que ça se joue — d'où les 24 heures d'avance.

Les 3 erreurs qu'on voit le plus souvent

1. Passer directement de p=none à p=reject

C'est l'erreur qui coûte le plus cher, et elle vient toujours de la même bonne intention : « quarantine, c'est une demi-mesure, autant faire les choses bien ». Sauf que quarantine n'est pas une demi-mesure, c'est le seul palier où une erreur est récupérable. En reject, l'email n'est pas en spam : il n'existe pas. Ton destinataire ne le retrouvera jamais, et toi tu ne l'apprendras qu'en recevant un coup de fil — dans le meilleur des cas.

Comment tu le reconnais : ton comptable ne reçoit plus les factures, un client dit n'avoir « jamais eu » ton devis, ton formulaire de contact ne fait plus rien. Le point commun : ça a commencé le jour où tu as modifié ton DMARC.

Le correctif : repasse en p=none tout de suite (c'est l'affaire d'une modification et d'un TTL), attends que ça se calme, puis reprends la méthode au palier 1. Le retour en arrière est instantané et sans effet secondaire — c'est le grand avantage de DMARC.

2. Confondre « SPF passe » et « SPF est aligné »

Le piège le plus technique de la page, et le seul qui mérite qu'on te dise le mot exact.

Un email envoyé par ton outil de campagnes peut très bien passer SPF — parce que l'outil a sa propre adresse d'enveloppe, chez lui, avec son propre SPF valide — tout en échouant DMARC. DMARC ne demande pas « est-ce que SPF passe ? », il demande « est-ce que le domaine qui passe SPF est le même que celui affiché dans le champ De: ». C'est ça, l'alignement. Google le dit en une phrase : « pour passer l'authentification DMARC, les messages sortants doivent passer soit SPF, soit DKIM » — sous-entendu : de façon alignée.

Cas concret : Brevo et Mailchimp n'ont même pas besoin d'un SPF pour authentifier ton domaine ; ils s'alignent par DKIM uniquement. Un outil qui n'expose pas de DKIM à ton nom ne sera jamais aligné, quoi que tu fasses de ton SPF.

Comment tu le reconnais : dans tes rapports, une source affiche spf: pass et dmarc: fail sur la même ligne. C'est la signature exacte du problème.

Le correctif : active la signature DKIM à ton domaine chez ce prestataire. Si le prestataire ne le propose pas, tu as deux options honnêtes : le faire envoyer depuis un sous-domaine dédié (notifications.tondomaine.fr) avec son propre sp=, ou changer de prestataire. Il n'y a pas de troisième option — et surtout pas « mettre ~all au lieu de -all ». Du point de vue de DMARC, ~all et -all sont un échec SPF identique.

3. Oublier les transferts et les listes de diffusion

Quand un destinataire fait suivre automatiquement ton email vers une autre adresse, ou quand ton message passe par une liste de diffusion qui ajoute [Association] dans l'objet et un pied de page, deux choses se produisent : le SPF échoue (l'expéditeur technique n'est plus toi) et la signature DKIM se casse si le message a été modifié. Google le confirme : une signature échoue quand « le message a été modifié en transit ou après l'ajout de la signature DKIM ».

Comment tu le reconnais : un reste irréductible de messages en échec dans tes rapports, provenant de serveurs que tu ne reconnais pas, en petit volume et de façon régulière. Souvent des universités, des associations, des adresses professionnelles redirigées vers une adresse personnelle.

Le correctif : il n'y en a pas de complet, et c'est important de le savoir avant de durcir — pas après. Une liste de diffusion bien configurée réécrit l'expéditeur pour éviter le problème. Pour le reste, c'est un dommage collatéral accepté de p=reject, que tu arbitres en connaissance de cause. Si ton activité repose sur des messages massivement retransmis, p=quarantine est peut-être ton point d'arrivée raisonnable, et c'est un choix défendable.

Combien de temps avant que ça prenne effet

• La modification de ton enregistrement : enregistrée immédiatement chez ton hébergeur, visible sur Internet en quelques minutes à 48 heures selon lui (généralement 5 à 15 minutes chez Cloudflare, jusqu'à 24 h chez OVH).
• L'ancienne valeur reste en cache aussi longtemps que le TTL que tu avais fixé avant la modification. D'où le conseil de baisser le TTL en avance — après coup, ça ne sert plus à rien.
• Les rapports : les premiers arrivent 24 à 72 h après la publication, puis environ une fois par jour, par domaine de destination. Il faut donc bien compter 2 semaines minimum par palier pour avoir de la matière.
• La durée totale, en pratique : 6 à 10 semaines pour un domaine d'entreprise ordinaire. Plus court si tu n'as qu'un seul expéditeur ; plus long si tu découvres des outils à reconfigurer, ce qui est le cas normal.

Le seul chiffre à retenir : le retour en arrière, lui, est immédiat. C'est ce qui rend l'opération raisonnable.

Pour aller plus loin

• Mes emails partent en spam alors que SPF, DKIM et DMARC sont bons
• Configurer SPF, DKIM et DMARC chez OVH
• Configurer SPF, DKIM et DMARC sur Cloudflare
• Configurer Google Workspace (SPF, DKIM, DMARC) chez OVH
• Configurer Microsoft 365 (SPF, DKIM, DMARC) chez IONOS