DMARC p=reject : configurer DMARC pas à pas sans bloquer vos propres e-mails

Un enregistrement DMARC en p=reject demande aux serveurs de messagerie destinataires de refuser tout message qui utilise votre domaine dans l'adresse d'expéditeur sans réussir l'authentification. Pour une entreprise qui envoie des factures, des appels de loyer ou des coordonnées bancaires par e-mail, DMARC p=reject est le réglage qui empêche l'usurpation d'adresse e-mail à l'identique.

Encore faut-il y arriver sans incident : passez en reject trop tôt, et votre outil de facturation ou votre newsletter peut se retrouver bloqué. Ce guide explique comment configurer DMARC en suivant la RFC 9989, la norme DMARC actuelle (elle a remplacé la RFC 7489 en mai 2026), de l'observation jusqu'au rejet, sans perdre de messages légitimes. Les exemples utilisent le domaine fictif dupont-immo.fr.

SPF, DKIM, DMARC : qui vérifie quoi

SPF : les serveurs autorisés à envoyer

SPF (RFC 7208) est un enregistrement TXT placé sur le domaine, qui liste les serveurs autorisés à envoyer ses e-mails. Le serveur destinataire le compare à l'expéditeur d'enveloppe (l'adresse Return-Path utilisée pendant l'échange SMTP), et non à l'adresse « De » que voit votre correspondant. Ici, spf.example.com représente le domaine SPF de votre fournisseur de messagerie :

dupont-immo.fr.  TXT  "v=spf1 include:spf.example.com ip4:203.0.113.25 -all"

Le -all final fait échouer tout serveur non listé ; ~all (échec « doux ») est un signal plus faible.

DKIM : une signature liée à un domaine

DKIM (RFC 6376) ajoute une signature cryptographique à chaque message. L'en-tête DKIM-Signature indique le domaine signataire (d=) et un sélecteur (s=) ; le destinataire récupère la clé publique publiée sous ce sélecteur et vérifie que le contenu signé n'a pas été modifié. Votre fournisseur de messagerie génère les clés et vous indique l'enregistrement à publier :

selector1._domainkey.dupont-immo.fr.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

DMARC : l'adresse visible et une politique

DMARC rattache ces vérifications à l'adresse que les gens voient réellement : le domaine de l'en-tête « De » (From). Un message réussit DMARC si SPF ou DKIM réussit et si le domaine authentifié est aligné sur celui de l'adresse « De ». L'enregistrement DMARC indique ensuite quoi faire des messages en échec (la politique) et où envoyer les rapports.

L'alignement : souple ou strict

En mode souple (relaxed), le mode par défaut, le domaine authentifié et celui de l'adresse « De » doivent partager le même domaine organisationnel : une signature DKIM de mail.dupont-immo.fr est alignée avec une adresse en @dupont-immo.fr. En mode strict, ils doivent être identiques. Les balises adkim et aspf règlent le mode pour DKIM et SPF. Le mode souple convient à la plupart des PME.

L'enregistrement DMARC et ses balises

Votre politique DMARC est un enregistrement TXT publié à l'adresse _dmarc.dupont-immo.fr. Un seul enregistrement DMARC doit exister à ce nom : en présence de deux enregistrements, les serveurs destinataires n'appliquent pas DMARC à votre domaine.

_dmarc.dupont-immo.fr.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@dupont-immo.fr"

• v=DMARC1 : la version, obligatoire et toujours en premier.
• p : la politique du domaine. none (observation seule), quarantine (message traité comme suspect, en général classé en spam) ou reject (message refusé).
• sp : la politique des sous-domaines. En son absence, ils suivent p.
• np : la politique des sous-domaines qui n'existent pas, très prisés des usurpateurs qui inventent des noms sous votre domaine. En son absence, sp s'applique, puis p.
• rua : l'adresse des rapports agrégés, sous la forme d'une ou plusieurs adresses mailto:.
• ruf : l'adresse des rapports d'échec, message par message. Ils peuvent contenir des extraits des messages, ce qui pose une question de confidentialité.
• t : le mode test. Avec t=y, les serveurs appliquent le niveau inférieur à la politique publiée (reject est traité comme quarantine, quarantine comme none) et continuent d'envoyer les rapports.
• adkim et aspf : le mode d'alignement pour DKIM et SPF, r (souple, par défaut) ou s (strict).

Des rapports envoyés vers un autre domaine, par exemple un service d'analyse de rapports, exigent que ce domaine publie un enregistrement TXT acceptant les rapports pour le vôtre.

DMARC quarantine ou reject : quelle différence ?

Les deux politiques s'appliquent aux messages qui échouent à DMARC. Avec quarantine, le serveur destinataire accepte le message mais le traite comme suspect, le plus souvent en le classant en spam : l'e-mail falsifié arrive donc quand même dans la messagerie, où un lecteur pressé peut y donner suite. Avec reject, le serveur doit refuser le message pendant l'échange SMTP : il n'arrive jamais.

Reject est l'objectif : sous cette politique, les serveurs qui appliquent DMARC ne distribuent pas les messages falsifiés à votre nom exact. Chaque serveur garde le dernier mot selon ses propres règles : DMARC est une consigne forte, pas une garantie absolue.

De p=none à DMARC p=reject en cinq étapes

1. Publier p=none avec des rapports

Commencez en mode observation avec l'enregistrement ci-dessus. p=none ne change rien à la distribution, mais les serveurs qui prennent en charge les rapports commencent à envoyer des rapports agrégés à l'adresse rua, en général une fois par jour. Chaque rapport liste les adresses IP qui ont envoyé des e-mails avec votre domaine et indique si SPF et DKIM ont réussi et sont alignés. Ce sont des fichiers XML : un outil d'analyse de rapports les rend lisibles.

Créez la boîte de réception avant de publier l'enregistrement. L'analyse gratuite de votre domaine par Spamr lit aussi vos enregistrements SPF et DMARC actuels et propose l'étape suivante (none, quarantine puis reject) avec l'enregistrement exact à publier.

2. Recenser tous les expéditeurs légitimes

Croisez les rapports avec votre propre liste de tous les services qui envoient avec une adresse « De » sur votre domaine :

• votre fournisseur de messagerie (les boîtes de votre équipe) ;
• votre CRM ou votre logiciel de gestion locative ;
• votre outil de facturation ou de comptabilité ;
• les formulaires de contact de votre site, souvent envoyés via l'hébergeur web ;
• votre outil de newsletter ou d'e-mailing ;
• les appareils et services qui envoient des notifications, comme un outil de prise de rendez-vous.

Couvrez au moins un cycle mensuel complet, pour voir apparaître les outils qui n'envoient qu'en fin de mois (appels de loyer, factures).

3. Corriger SPF et DKIM pour chaque expéditeur

Pour chaque service, activez la signature DKIM avec votre propre domaine (il fournit les enregistrements à publier sous _domainkey), et ajoutez son include à votre unique enregistrement SPF s'il envoie avec votre domaine comme expéditeur d'enveloppe. Un DKIM aligné reste la voie la plus fiable, car beaucoup de services conservent leur propre domaine de retour : SPF réussit, mais sans alignement avec le vôtre. Un service incapable d'authentifier votre domaine doit envoyer depuis un sous-domaine dédié, ou cesser d'utiliser votre adresse.

4. Passer en quarantine

Quand les rapports ne montrent plus que des services connus, tous alignés, passez en quarantine. Une erreur reste rattrapable à ce stade : un message légitime en échec arrive dans le dossier spam, où il peut être retrouvé.

_dmarc.dupont-immo.fr.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@dupont-immo.fr"

Les anciens guides appliquent la politique à une partie des messages avec pct=25, puis 50, puis 100. La RFC 9989 a supprimé pct : les serveurs qui la suivent ignorent cette balise. Son mode test t=y ne le remplace pas non plus, car les serveurs encore conformes à la RFC 7489 ignorent t et appliquent la politique complète. Laissez plutôt quarantine en place un cycle d'activité complet, et lisez les rapports.

5. Passer en reject

Une fois quarantine en place un cycle complet sans perte de courrier légitime, publiez reject. Gardez rua : les rapports révéleront tout nouveau service ajouté par un collègue sans vous prévenir.

_dmarc.dupont-immo.fr.  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@dupont-immo.fr"

Protéger les sous-domaines et les domaines qui n'envoient pas d'e-mails

Quand un serveur ne trouve pas d'enregistrement DMARC sur un sous-domaine, il se replie sur celui du domaine organisationnel et applique sp s'il est présent. sp=reject couvre donc factures.dupont-immo.fr comme n'importe quel nom qu'un fraudeur inventerait sous votre domaine. Un sous-domaine qui envoie via son propre service peut publier son propre enregistrement _dmarc.

Les domaines que vous possédez sans jamais les utiliser pour l'e-mail (ancien nom commercial, enregistrement défensif, simple redirection) sont des cibles faciles, car personne ne les surveille. Déclarez qu'ils n'envoient et ne reçoivent rien :

example.com.         MX   0 .
example.com.         TXT  "v=spf1 -all"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=reject"

Le « MX nul » (RFC 7505) indique que le domaine n'accepte aucun e-mail, v=spf1 -all n'autorise aucun serveur, et p=reject demande de refuser tout message envoyé en son nom.

Les erreurs fréquentes avec une politique DMARC

• Deux enregistrements SPF. Un domaine ne doit publier qu'un seul enregistrement SPF. Avec deux, SPF renvoie une erreur permanente. Fusionnez-les.
• Trop de requêtes DNS dans SPF. Les mécanismes include, a, mx, ptr et exists et le modificateur redirect comptent dans une limite de 10 requêtes DNS fixée par la RFC 7208, includes imbriqués compris. Au-delà, SPF renvoie une erreur permanente. Retirez les services que vous n'utilisez plus.
• Oublier un service d'envoi. Un outil de facturation qui écrit avec votre adresse sans DKIM ni SPF alignés sera rejeté en p=reject. Les rapports l'auraient montré.
• Passer en reject sans rapports. Sans rua, vous découvrez un expéditeur cassé le jour où un client vous signale une facture jamais reçue.

Ce que DMARC p=reject ne fait pas

DMARC protège une seule chose : le domaine exact de l'adresse « De ». Si un fraudeur enregistre une variante de dupont-immo.fr avec une lettre changée, ou le même nom sous une autre extension, il s'agit d'un autre domaine. Son titulaire peut publier SPF, DKIM et même DMARC p=reject : ses messages réussissent toutes les vérifications, puisqu'ils viennent réellement du domaine annoncé.

DMARC ne vérifie pas non plus le nom affiché : un message affichant le nom « Dupont Immo » et envoyé depuis une messagerie gratuite est authentifié pour le domaine de cette messagerie. Ces techniques sont au cœur de la fraude au faux RIB : un domaine sosie, un message crédible et de nouvelles coordonnées bancaires.

DMARC et surveillance des sosies vont donc de pair. Spamr génère plusieurs centaines de variantes d'un domaine (fautes de frappe, autres extensions, homoglyphes) et interroge uniquement le DNS public et les données d'enregistrement pour repérer celles qui sont déjà réservées, sans jamais visiter leurs sites. Notre guide pour détecter les domaines sosies détaille les signaux à surveiller.

À retenir

• SPF et DKIM authentifient un domaine ; DMARC exige qu'il soit aligné sur l'adresse « De » visible.
• Publiez p=none avec rua, recensez chaque expéditeur légitime, puis corrigez SPF et DKIM pour chacun.
• Passez en quarantine, puis en DMARC p=reject, en lisant les rapports à chaque étape.
• Protégez les sous-domaines avec sp, et les domaines inutilisés avec un MX nul, v=spf1 -all et p=reject.
• DMARC n'arrête pas les domaines sosies : surveillez-les à part.