Pourquoi un parc de clients ne passe pas en reject d'un seul geste
Un domaine unique se pilote à vue. Un portefeuille, non : chaque client a des outils que l'agence ne connaît pas toujours en entier. Le déclencheur est souvent externe. Depuis le 1er février 2024, Gmail demande SPF, DKIM et DMARC aux expéditeurs de plus de 5 000 messages par jour, Yahoo pose une exigence voisine et Outlook.com applique des règles comparables aux gros volumes. Chez Gmail comme chez Yahoo, le plancher est un DMARC publié avec p=none : ces exigences ne vous demandent pas de passer en reject. Ce qui y pousse, c'est l'usurpation : un client dont le nom sert à envoyer de fausses factures, ou dont les vraies factures finissent en spam.
Le risque est symétrique. Un reject posé trop tôt refuse du courrier légitime, et c'est vous que le client appellera. La norme DMARCbis (RFC 9989, publiée en mai 2026, qui remplace RFC 7489) recommande une progression : p=none au moins un mois, puis p=quarantine pour une durée comparable, en comparant les résultats. Les définitions des trois politiques sont dans notre guide sur DMARC p=quarantine, et ce qui change avec la nouvelle norme dans DMARCbis. Ici, on traite le travail propre à un parc : inventaire, calendrier, communication.
Publier p=none avec une adresse de rapports, client par client
Pour chaque domaine, la première écriture est un enregistrement TXT sur _dmarc.votre-domaine.com : v=DMARC1; p=none; rua=mailto:[email protected]. Le p=none ne change rien à la livraison ; il demande aux récepteurs de vous envoyer des rapports agrégés, un fichier XML compressé par récepteur et par jour. Si vous centralisez les rapports de tous vos clients sur une adresse de l'agence, par exemple [email protected], le domaine de cette adresse diffère de celui du client, et le récepteur doit vérifier votre accord. La norme sur les rapports (RFC 9990) prévoit pour cela un enregistrement TXT sur client-exemple.com._report._dmarc.agence-exemple.com, qui contient au moins v=DMARC1. Sans lui, le récepteur ignore l'adresse et vous ne recevez rien. Un enregistrement générique *._report._dmarc.agence-exemple.com autorise tous les domaines d'un coup.
Centraliser donne une vue d'ensemble, mais mélange les clients dans la même boîte. Une adresse par client, ou un tri par domaine du champ header_from, évite de lire les rapports d'un client en y cherchant un autre.
Lire une ligne de rapport : les champs qui comptent
- source_ip — l'adresse qui a remis le message ; une recherche inverse ou l'en-tête
Receivedd'un message d'essai donne le fournisseur derrière. - count — le nombre de messages de la ligne ; il hiérarchise le travail, on traite d'abord les gros volumes.
- disposition — ce que le récepteur a appliqué :
none,quarantineoureject. En p=none tout vautnone; la colonne devient utile aux paliers suivants. - dkim et spf — le résultat évalué pour DMARC, donc avec alignement. Un DKIM valide mais non aligné y apparaît en
fail. - header_from — le domaine visible dans le champ From, celui que DMARC protège.
- envelope_from — le domaine d'enveloppe (Return-Path) sur lequel SPF s'aligne ; un domaine de fournisseur à cet endroit explique un échec SPF.
- Lignes sans propriétaire — une IP inconnue avec un gros
countest soit un outil oublié du client, soit une usurpation : on demande au client avant de conclure.
Alignement : pourquoi un outil qui passe SPF et DKIM échoue quand même
DMARC exige que SPF ou DKIM soit aligné avec le domaine du champ From. SPF s'aligne sur le domaine d'enveloppe (Return-Path), pas sur le From ; DKIM s'aligne sur le domaine d= de la signature. Un service de newsletter qui envoie avec son propre Return-Path et signe avec son propre d= passe SPF et DKIM chez lui, et échoue DMARC chez votre client, puisqu'aucun des deux domaines n'est celui du From. Par défaut l'alignement est relaxed (aspf et adkim valent r) : un sous-domaine du même domaine organisationnel suffit. En strict (s), le domaine doit être identique. Gardez le relaxed, sauf besoin précis.
La parade est presque toujours la même : faire signer l'outil avec le domaine du client, en publiant les enregistrements CNAME DKIM que le fournisseur fournit. Un seul alignement suffit, donc le Return-Path propre au fournisseur est sans conséquence si DKIM est aligné. Quand vous ajoutez un include: SPF, comptez : RFC 7208 limite l'évaluation à 10 recherches DNS, et au-delà le résultat est une erreur permanente (permerror).
Matrice des expéditeurs tiers à aligner
Faites défiler le tableau
| Expéditeur | Ce que fournit le prestataire | À publier chez le client |
|---|---|---|
| Newsletter, e-mailing | Clé DKIM et domaine d'envoi | CNAME DKIM ; sous-domaine d'envoi dédié recommandé |
| CRM, automatisation marketing | Signature DKIM au nom du client | CNAME DKIM ; `include:` SPF seulement si le prestataire l'exige |
| Facturation, paiement en ligne | Envoi depuis ses serveurs | CNAME DKIM du prestataire ; à défaut, envoi depuis un sous-domaine d'envoi dédié |
| Helpdesk, tickets | Adresse d'expédition à valider | CNAME DKIM et validation du domaine d'expédition |
| Messagerie principale | Enregistrements SPF et DKIM documentés | `include:` SPF et clé DKIM du fournisseur de messagerie |
| Site web (formulaires, boutique) | Envoi par le serveur du site ou un relais | SMTP authentifié avec le domaine du client |
Le calendrier type d'un domaine, palier après palier
Semaine 0 : publier p=none
Relevez le domaine, puis publiez
v=DMARC1; p=none; rua=mailto:[email protected]. Contrôlez avecdig +short TXT _dmarc.votre-domaine.com. Les premiers rapports arrivent sous 24 à 48 heures.Semaines 1 à 4 : observer et revoir chaque semaine
La norme recommande au moins un mois de p=none. Chaque semaine, regroupez les lignes par fournisseur et remplissez le tableau de suivi : expéditeur, volume, aligné ou non, légitime ou non.
Corriger chaque expéditeur légitime non aligné
Publiez les CNAME DKIM du prestataire, envoyez un message d'essai vers une boîte Gmail et vérifiez
dmarc=passdans l'en-tête. Un outil abandonné ne se corrige pas : on le note comme à refuser.Semaines 5 à 8 : poser quarantine
Remplacez par
v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:[email protected], pour une durée comparable à celle de la phase précédente. Les échecs vont en spam au lieu d'être refusés : la colonnedispositiondes rapports montre ce qui serait perdu.Ne pas compter sur pct comme filet
RFC 9989 a retiré la balise
pct, jugée peu fiable hors des valeurs 0 et 100, et ajoutét=ypour demander de ne pas appliquer la politique. Le support detpar Gmail, Yahoo et Microsoft n'est pas documenté à ce jour : ne bâtissez pas un palier dessus.Semaines 9 à 12 : passer en reject
Si quarantine n'a révélé aucun expéditeur légitime en échec, publiez
v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]. Prévenez le client la veille, et surveillez les rapports quotidiennement pendant une semaine.Garder la revue après le reject
Chaque nouvel outil que le client adopte devient un expéditeur à aligner. Demandez-le dans le contrat d'accompagnement : tout nouvel outil d'envoi est déclaré avant sa mise en service, puis reporté au tableau de suivi.
Sous-domaines : sp, np et sous-domaine d'envoi dédié
Un sous-domaine sans enregistrement propre hérite de la politique du domaine organisationnel. La balise sp fixe la politique des sous-domaines existants, np celle des sous-domaines inexistants ; à défaut de np on retombe sur sp, puis sur p (RFC 9989, définition des balises). Sur un enregistrement publié dans un sous-domaine, sp est ignoré. np est récente : un récepteur qui ne la connaît pas l'ignore et applique sp.
L'usage typique concerne les faux sous-domaines. Un fraudeur qui écrit depuis facture.client-exemple.com, un sous-domaine qui n'existe pas, est arrêté par np=reject sans risque pour le courrier réel, puisque rien de légitime n'en part. Pour les outils tiers, préférez un sous-domaine d'envoi dédié, par exemple news.votre-domaine.com : l'outil y est aligné en relaxed, ses clés et son SPF n'encombrent pas le domaine principal, et vous pouvez durcir celui-ci sans attendre ce flux. Un enregistrement _dmarc propre au sous-domaine permet même un calendrier distinct.
Les flux qui cassent : listes de diffusion, transferts, alias
Certains messages légitimes échouent DMARC par construction, parce qu'un intermédiaire les retransmet en gardant le From d'origine. Une liste qui ajoute un pied de page invalide la signature DKIM ; une redirection invalide SPF, car l'IP qui remet le message n'est plus celle que le domaine autorise. La norme le dit en toutes lettres (RFC 9989, partie interopérabilité) : p=reject peut être incompatible avec ces flux indirects, et les domaines dont les utilisateurs écrivent sur des listes ne devraient pas le publier. ARC (RFC 8617) est cité comme tentative de solution, mais aucune méthode n'est devenue largement utilisée. La norme demande aussi aux récepteurs de ne pas rejeter sur la seule base d'un p=reject et, faute d'autre analyse, de traiter le message comme avec quarantine : le reject n'est donc pas toujours appliqué à la lettre, ce qui n'est pas une raison de l'ignorer.
Ces cas se repèrent avant de basculer. Cherchez dans les rapports des lignes dont l'IP appartient à un relais de liste ou à un service de transfert, dont spf et dkim échouent et dont le count est faible mais régulier. Interrogez ensuite le client : alias d'anciens élèves, association, adresse qui redirige vers une boîte personnelle. Pour un domaine dont les adresses servent à écrire sur des listes publiques, restez en quarantine : c'est un choix défendable, à consigner dans le tableau de suivi.
Prouver le résultat avant de prévenir le client
Envoyez un message d'essai depuis chaque outil vers une boîte Gmail, ouvrez « Afficher l'original » et cherchez la ligne Authentication-Results : elle doit contenir dmarc=pass header.from=votre-domaine.com. Après le passage en reject, un refus SMTP porte un code en 5.7.x et un texte propre au récepteur. Gardez la capture du message de refus et la ligne correspondante du rapport rua : elles montrent au client que l'outil fautif était identifié et signalé, et non découvert après coup.
Le message à envoyer au client avant chaque palier
Le client n'a pas à comprendre DMARC, mais il doit savoir ce qui change, quand, et ce qu'on attend de lui. Quatre phrases suffisent.
Objet : protection de votre domaine contre l'usurpation d'e-mail
Bonjour, nous renforçons la protection de votre domaine votre-domaine.com contre l'usurpation de vos adresses. À partir du [date], les messages qui se présentent comme venant de votre domaine sans être authentifiés seront placés en spam, puis refusés à partir du [date suivante]. Pour ne perdre aucun envoi légitime, pouvez-vous nous lister avant le [date] tous les outils qui envoient des e-mails en votre nom (newsletter, facturation, CRM, support, site) ? Un risque subsiste pour les listes de diffusion et les redirections d'adresses : dites-nous si vous en utilisez.
Conservez la réponse dans le dossier du client : elle fixe qui a déclaré quels outils, et à quelle date.
Tableau de suivi du parc
Faites défiler le tableau
| Domaine | Politique actuelle et prochain palier | Expéditeurs validés et statut du client |
|---|---|---|
| client-a-exemple.com | p=none, quarantine à S+4 | Messagerie et newsletter validées ; facturation à confirmer |
| client-b-exemple.com | p=quarantine, reject à S+8 | Quatre expéditeurs alignés ; aucun échec légitime en rapport |
| client-c-exemple.com | p=reject, revue hebdomadaire | CRM ajouté par le client, DKIM à publier |
| client-d-exemple.com | p=quarantine, sans reject prévu | Adresses utilisées sur des listes ; choix consigné |
| client-e-exemple.com | p=none, aucun palier prévu | Client sans réponse ; relance à planifier |
Dépannage : cinq échecs fréquents sur un parc
Sur un portefeuille, les mêmes cinq incidents reviennent. Les voici avec leur cause et le geste qui les lève.
Symptômes et remèdes
- Aucun rapport n'arrive — l'adresse
ruaest sur un autre domaine que celui du client et l'enregistrement_report._dmarcd'autorisation manque : publiez-le, sinon le récepteur ignore l'adresse. - Un outil passe SPF et DKIM mais échoue DMARC — son Return-Path et son
d=sont ceux du prestataire : publiez les CNAME DKIM au nom du client pour aligner DKIM. - SPF en permerror — plus de 10 recherches DNS (RFC 7208) : retirez les
include:d'outils abandonnés ou déplacez l'outil sur un sous-domaine d'envoi dédié. - Un nouvel outil est refusé après le reject — le client l'a adopté sans prévenir : revenez en quarantine le temps d'aligner l'outil, plutôt que d'assouplir l'alignement.
- Le client ne répond pas — restez en p=none ou en quarantine, notez la relance et la date dans le tableau de suivi ; un reject posé sans inventaire engage votre responsabilité.
La documentation officielle
RFC 9989, DMARCbis (balises, sous-domaines, interopérabilité) : https://www.rfc-editor.org/rfc/rfc9989.html
RFC 9990, rapports agrégés DMARC (destinations externes) : https://www.rfc-editor.org/rfc/rfc9990.html
RFC 7208, SPF (limite de 10 recherches DNS) : https://www.rfc-editor.org/rfc/rfc7208.html
RFC 8617, ARC : https://www.rfc-editor.org/rfc/rfc8617.html
Exigences Gmail pour les expéditeurs en masse : https://support.google.com/a/answer/81126
Bonnes pratiques Yahoo pour les expéditeurs : https://senders.yahooinc.com/best-practices/
Exigences Outlook pour les gros volumes : https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730
