Délivrabilité e-mail : la politique DMARC qui bloque l’usurpation sans perdre de messages

La politique DMARC unique (et pourquoi elle fonctionne)

Si vous voulez une protection contre l’usurpation sans perdre les messages légitimes, vous ne commencez pas par « p=reject » sur un coup de tête. Vous commencez par une politique qui
force l’authentification à devenir réelle, mesurable et exécutable — tout en vous donnant une issue de secours pour les aspects pénibles du courrier (transferts,
listes de diffusion qui cassent tout, émetteurs tiers, et systèmes legacy qui pensent que « DKIM » est un nouveau festival de musique).

La politique

Le réglage par défaut pratique que je recommande pour la plupart des organisations qui envoient du vrai courrier et ont au moins un émetteur tiers :
DMARC sur le domaine organisationnel avec p=quarantine, pct=100, alignement DKIM strict (adkim=s), alignement SPF relaxé (aspf=r), et une configuration de rapports raisonnable.
Ensuite, vous passez à p=reject une fois que vos flux authentifiés sont propres.

Un enregistrement représentatif (ajustez-le pour votre domaine et votre boîte de rapports) :

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; pct=100; adkim=s; aspf=r; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; fo=1; sp=quarantine"

Pourquoi cette forme spécifique ?

• p=quarantine at pct=100 : vous appliquez une règle, mais d’une manière qui a tendance à diriger les échecs vers le spam plutôt qu’à supprimer brutalement les messages.
  Cela maintient le courrier métier en circulation pendant que vous nettoyez les émetteurs. Vous n’êtes pas en « surveillance » ; vous changez les résultats.
• adkim=s (alignement DKIM strict) : DKIM est la voie la plus fiable à travers les transferts et la plomberie moderne du courrier.
  L’alignement strict force vos prestataires et systèmes à signer en utilisant votre domaine (ou une stratégie de sous-domaine correctement alignée).
• aspf=r (alignement SPF relaxé) : SPF casse constamment à cause des transferts et des relais NATés. Le mode relaxé vous évite
  de pénaliser des flux légitimes pendant que vous migrez le monde vers une authentification axée sur DKIM.
• sp=quarantine : n’oubliez pas les sous-domaines. Les attaquants non plus.
• rua/ruf/fo : vous avez besoin de télémétrie. Pas une télémétrie parfaite, mais suffisamment pour identifier quels systèmes échouent et pourquoi.

En résumé : DMARC n’est pas « SPF et DKIM existent ». DMARC, c’est « SPF ou DKIM passe ET s’aligne avec le domaine que l’utilisateur voit ».
Cette clause d’alignement est là où l’usurpation meurt et où la délivrabilité peut accidentellement mourir aussi.

Une citation qui tient toujours en opérations : idée paraphrasée de Werner Vogels : « Tout échoue, tout le temps ; concevez et opérez en l’assumant. »
Les déploiements DMARC échouent de façons ennuyeuses. Prévoyez-le, et vous ne l’apprendrez pas à la dure.

Blague #1 : L’authentification e-mail est le seul système de sécurité où « forwarding » compte comme « altération », mais tout le monde le fait quand même.

Quand aller directement en p=reject

Rare, mais ça existe. Si votre domaine n’est pas utilisé pour aucun e-mail légitime (un domaine en parking, ou un domaine de marque qui ne redirige que vers
un domaine mail séparé), alors allez directement sur :

cr0x@server:~$ dig +short TXT _dmarc.brand-only.example
"v=DMARC1; p=reject; pct=100; adkim=s; aspf=s; rua=mailto:dmarc-rua@brand-only.example; sp=reject"

Si rien de légitime ne devrait provenir de ce domaine, soyez impitoyable. Sinon, commencer par quarantine est la manière de garder les e-mails de facturation hors de la tombe.

DMARC en termes opérationnels : ce qui arrive réellement à un message

DMARC est une politique évaluée par le récepteur (Gmail, Microsoft, Yahoo, la passerelle de votre client). Il lit votre enregistrement DNS, vérifie les résultats d’authentification du message,
et décide quoi faire.

Les trois domaines qui comptent (et pourquoi on se trompe)

• Header From : le domaine que les humains voient dans l’en-tête From:. DMARC s’aligne sur celui-ci. C’est l’identité que vous protégez.
• Domaine SPF : le domaine utilisé pendant l’évaluation SMTP MAIL FROM / Return-Path. Souvent un domaine de rebond.
• Domaine d= DKIM : le domaine qui signe le message.

DMARC passe si (SPF passe et s’aligne) OU (DKIM passe et s’aligne).
Les récepteurs appliquent ensuite votre politique : none, quarantine, ou reject.

Alignement : la partie qui fait trébucher tout le monde

L’alignement est une règle de comparaison de chaînes, pas un concept philosophique.

• Alignement relaxé (r) : les sous-domaines s’alignent. mail.example.com s’aligne avec example.com.
• Alignement strict (s) : doit correspondre exactement. mail.example.com ne s’aligne pas avec example.com.

Pourquoi être strict sur DKIM mais relaxé sur SPF dans la politique recommandée ?
Parce que DKIM est l’identité durable. SPF est une vérification du chemin IP ; le chemin change. DKIM survit lorsque le message prend la route pittoresque.

Réalité de la délivrabilité : les récepteurs n’utilisent pas que DMARC

DMARC est le ticket d’entrée. Les récepteurs évaluent aussi la réputation, le contenu, l’engagement, le taux de plaintes et les schémas d’envoi.
DMARC vous rend éligible à la confiance. Il ne garantit pas la délivrance en boîte de réception. Ce qu’il fait, c’est empêcher les attaquants d’emprunter la réputation de votre domaine pour envoyer des ordures. Cela aide indirectement vos e-mails légitimes.

Si vous voulez stopper l’usurpation sans perdre de messages, traitez DMARC comme le déploiement d’un système distribué : observez, appliquez progressivement, validez avec
de la télémétrie, puis renforcez.

Faits intéressants et contexte historique (ce qui explique les bizarreries)

• DMARC est né parce que SPF et DKIM résolvaient chacun une moitié du problème. SPF authentifie un chemin d’envoi ; DKIM authentifie un message. Aucun seul ne protège de façon fiable le domaine visible dans From.
• SPF précède l’email cloud généralisé. Il a été conçu quand « le serveur qui envoie votre courrier » était un concept plus stable qu’aujourd’hui.
• DKIM a été conçu pour survivre aux transferts. Il signe le corps du message et des en-têtes sélectionnés, donc il peut passer même si le chemin SMTP change — sauf si un transféreur réécrit le contenu.
• DMARC est piloté par le récepteur. Vous publiez la politique ; les destinataires décident de l’application. C’est pourquoi « nous avons mis p=reject » ne signifie pas que tout le monde rejette de la même façon.
• DMARC a popularisé le reporting de domaine à grande échelle. Les rapports agrégés (RUA) sont devenus le premier moyen cohérent pour de nombreuses organisations d’inventorier les émetteurs cachés.
• La politique de sous-domaine (sp=) existe parce que les attaquants aiment les sous-domaines. Les organisations les oublient ; les phisheurs non.
• Les premiers déploiements DMARC se sont appuyés sur la quarantine. Les organisations ont appris que passer directement au reject casse souvent les flux marketing et de billetterie légitimes.
• ARC existe principalement à cause des effets secondaires de DMARC. Les transferts et les listes de diffusion peuvent casser DMARC ; ARC aide à préserver le contexte d’authentification entre les sauts.
• « p=none » n’est pas sans conséquence. C’est un mode de surveillance, mais il signale aussi aux récepteurs que vous n’appliquez pas. Cela peut influencer la manière dont ils traitent les tentatives d’usurpation.

Mini-histoire #1 : la mauvaise hypothèse qui a cassé l’envoi

Une entreprise SaaS de taille moyenne a décidé de « terminer le projet DMARC » avant son audit de conformité annuel. Ils avaient SPF, ils avaient DKIM (quelque part),
et un tableau listant les fournisseurs. Quelqu’un a supposé que cela suffisait.

Ils ont basculé DMARC de p=none à p=reject sur le domaine apex un vendredi soir. Lundi matin, le service client ne pouvait plus envoyer les documents d’onboarding.
Les commerciaux se sont plaints que les prospects « arrêtaient de répondre ». La finance a dit que les factures rebondissaient. Les tickets de support se sont accumulés avec des captures d’écran de
« message rejected due to DMARC policy ».

Le problème réel était ennuyeux : leur CRM envoyait des mails en utilisant un Return-Path appartenant au fournisseur (SPF passait, mais ne s’alignait pas), et la signature DKIM
utilisait d=fournisseur.example (DKIM passait, ne s’alignait pas). En p=none, personne ne s’en souciait. En p=reject, les récepteurs s’en sont souciés.

La correction n’a rien d’héroïque. Ils ont configuré le fournisseur pour signer avec d=their-domain.example en utilisant une clé DKIM personnalisée, et ont défini un domaine de rebond dédié
qui s’alignait. La leçon clé : l’authentification qui passe ne suffit pas ; elle doit s’aligner sur le domaine que vous mettez dans From.

Ils ont aussi appris à ne jamais déployer l’application sans une base de rapports récente. Les rapports étaient envoyés vers une boîte aux lettres non surveillée.
Une télémétrie que personne ne lit, c’est de l’art performance.

Mini-histoire #2 : une optimisation qui s’est retournée contre eux

Une grande entreprise avec plusieurs unités métier voulait réduire les requêtes DNS provenant de SPF à cause de la limite des 10 lookups. Un ingénieur a proposé une
optimisation : remplacer une chaîne d’includes par un seul include fournisseur, et restreindre SPF à un ensemble plus petit d’IP « pour la sécurité ».

Le changement a effectivement réduit les lookups. Il a aussi causé des softfails SPF intermittents et des permerrors pour du courrier légitime parce que certains messages passaient par
des relais sortants régionaux non présents dans la liste « stricte ». Pire, les IP d’envoi de la plateforme marketing tournaient, et l’include fournisseur sur lequel ils comptaient
n’était pas celui réellement utilisé pour le flux mail de leur compte.

DMARC était réglé sur quarantine. Les messages qui auparavant passaient via l’alignement SPF échouaient maintenant en SPF, et DKIM n’était pas présent sur certains flux automatisés
à cause d’une application legacy envoyant via un relais interne qui supprimait des en-têtes et ne signait pas.

La délivrabilité n’a pas chuté instantanément. Elle s’est dégradée de cette façon lente et insultante : certains destinataires recevaient, d’autres non, et les motifs
paraissaient aléatoires. L’intervention a perdu du temps car le problème ne se reproduisait pas systématiquement.

La résolution a été d’arrêter de traiter SPF comme l’identité primaire. Ils ont restauré SPF à une base stable et correcte et ont priorisé la signature DKIM
sur chaque flux sortant, en utilisant des d= alignés. L’optimisation était légitime, mais appliquée à la mauvaise couche. SPF doit être précis et minimal, pas « intelligent ».

Mini-histoire #3 : la pratique ennuyeuse qui a sauvé la journée

Une autre organisation — peu sexy, mais mature opérationnellement — avait une pratique : chaque système sortant avait un propriétaire, un runbook et une revue mensuelle des rapports DMARC.
Personne n’était promu pour cela. C’est pourquoi ça fonctionnait.

Ils ont maintenu DMARC en p=quarantine pendant des mois pendant qu’ils migraient les fournisseurs. Chaque fois qu’un nouvel émetteur apparaissait dans les rapports RUA, cela créait un ticket :
identifier le propriétaire, valider le flux, configurer DKIM avec d= aligné, et confirmer l’alignement SPF ou documenter pourquoi il ne sera pas utilisé.

Un jour, une campagne de phishing a frappé le secteur, usurpant les noms d’exécutifs dans plusieurs entreprises. Leur domaine a aussi été ciblé. Les clients ont vu
les attaques en situation réelle, mais les principaux fournisseurs de boîtes mail ont rejeté ou mis en spam presque tout, car l’application DMARC était déjà en place.

Le meilleur : ils n’ont pas eu à paniquer. Ils avaient déjà les bons réglages. Ils ont simplement augmenté la surveillance et vérifié qu’aucun flux légitime n’avait régressé.
Voilà à quoi ressemble le « ennuyeux » quand ça vous paie le salaire.

Blague #2 : Le système e-mail le plus fiable est celui que personne ne remarque — jusqu’à ce que le CFO ne puisse pas envoyer un tableau et que cela devienne un « incident prioritaire ».

Mode opératoire de diagnostic rapide

Quand la délivrabilité ou le contrôle de l’usurpation échoue, vous avez besoin d’un chemin rapide vers le goulot d’étranglement. Voici l’ordre qui sauve le plus de temps dans la plupart
des incidents.

Première étape : confirmer quelle identité de domaine est protégée

• Quel est le domaine du Header From que voient les utilisateurs ?
• Est-ce le domaine apex, un sous-domaine, ou un domaine ressemblant au vôtre ?
• Avez-vous un enregistrement DMARC pour ce domaine exact (incluant le comportement de la politique sur sous-domaines) ?

Deuxième étape : vérifier l’évaluation DMARC sur un exemple réel

• Récupérez un message affecté (ou envoyez un test vers une boîte contrôlée) et lisez les Authentication-Results.
• Déterminez lequel de SPF ou DKIM passe, et s’il s’aligne.
• Si aucun ne s’aligne, DMARC échouera peu importe à quel point SPF ou DKIM semblent « corrects » pris isolément.

Troisième étape : inventoriez les émetteurs via les données agrégées DMARC

• Quelles IP envoient en se faisant passer pour votre domaine ?
• Quelles sources échouent et à quel volume ?
• Les échecs sont-ils concentrés chez un fournisseur, une région ou une application spécifique ?

Quatrième étape : déterminer si l’échec est lié à l’application de la politique ou à la réputation

• Si vous voyez des rebonds durs citant DMARC, c’est un problème d’application/alignement.
• Si vous voyez « accepté mais spam », cela peut être la réputation, le contenu, ou une incohérence d’authentification (DKIM intermittent, permerror SPF, etc.).

Cinquième étape : ne changez qu’une chose à la fois

Le courrier est un système distribué que vous ne contrôlez pas entièrement. Si vous modifiez la politique DMARC, SPF, DKIM et l’infrastructure d’envoi en même temps, vous ne
comprendrez rien et casserez quand même des choses.

Tâches pratiques : commandes, sorties et décisions (12+)

Ce sont des tâches pratiques que vous pouvez exécuter depuis un shell. Elles supposent que vous avez des outils DNS de base et accès aux en-têtes des messages depuis une boîte aux lettres.
Pour l’analyse des en-têtes, vous collerez le contenu dans des fichiers localement. L’important n’est pas l’outil ; c’est la prise de décision.

Task 1: Fetch the DMARC record and validate syntax

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; pct=100; adkim=s; aspf=r; rua=mailto:dmarc-rua@example.com; sp=quarantine"

What the output means: You have a DMARC record, it’s DMARC1, and policy enforcement is quarantine for the domain and subdomains.

Decision: If there’s no record or multiple conflicting records, fix that first. DMARC is “one TXT record” territory.

Task 2: Confirm you don’t have multiple DMARC TXT records (a classic footgun)

cr0x@server:~$ dig TXT _dmarc.example.com +noall +answer
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine; pct=100; adkim=s; aspf=r; rua=mailto:dmarc-rua@example.com; sp=quarantine"

What the output means: Exactly one record returned in the answer section.

Decision: If you see two TXT answers, consolidate into one. Some receivers pick one arbitrarily, which is the email equivalent of playing roulette with payroll.

Task 3: Check SPF record and spot the 10-DNS-lookup problem

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.google.com include:mailgun.org include:spf.protection.outlook.com include:spf.vendor.example -all"

What the output means: SPF uses multiple includes; each include can trigger additional DNS lookups.

Decision: If you suspect lookup limits, simplify SPF or move flows to DKIM-first. Don’t “optimize” SPF by removing legitimate senders.

Task 4: Inspect DKIM selector presence for a known sender

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtY..."

What the output means: DKIM selector s1 exists and has a public key.

Decision: If the selector is missing or truncated, fix DNS publishing before touching DMARC policy.

Task 5: Send a test message and verify Authentication-Results header (from a saved header file)

cr0x@server:~$ grep -i "^Authentication-Results:" -A2 message.eml
Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1 header.b=Qd9...
       spf=pass (google.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@example.com

What the output means: DKIM and SPF both pass. DKIM is signing as example.com.

Decision: This stream should pass DMARC assuming Header From is example.com and alignment settings allow it.

Task 6: Check DMARC result in headers (the receiver tells you)

cr0x@server:~$ grep -i "^Authentication-Results:" -A5 message.eml | grep -i dmarc
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

What the output means: DMARC passed and policy would quarantine failures; disposition NONE means no enforcement action was applied.

Decision: If DMARC fails here, stop arguing about SPF “being correct” and fix alignment or DKIM signing.

Task 7: Detect a common failure: DKIM passes but does not align

cr0x@server:~$ grep -i "^Authentication-Results:" -A3 message.eml
Authentication-Results: mail.receiver.example;
       dkim=pass header.i=@vendor.example header.s=selector1 header.b=abc...
       spf=pass smtp.mailfrom=vendor-bounces.example

What the output means: DKIM passes for vendor.example, SPF passes for vendor-bounces.example. If Header From is example.com, neither aligns.

Decision: Configure vendor for custom DKIM d=example.com (or an aligned subdomain strategy) and use an aligned bounce domain where possible.

Task 8: Verify relaxed vs strict alignment implications

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; adkim=s; aspf=r"

What the output means: DKIM must match exactly; SPF can align via subdomain.

Decision: If your legitimate mail is signed as d=mail.example.com but From is example.com, strict DKIM will fail alignment. Either sign with d=example.com or relax adkim (usually not my favorite, but sometimes pragmatic).

Task 9: Confirm MX and who actually receives inbound (spoofing targets inbound too)

cr0x@server:~$ dig +short MX example.com
10 mx1.mailhost.example.
20 mx2.mailhost.example.

What the output means: These are your inbound receivers; they will enforce inbound policies and provide headers/logs.

Decision: If your inbound is split across providers, align enforcement expectations and investigate where failures are observed.

Task 10: Check if subdomains are accidentally unprotected

cr0x@server:~$ dig +short TXT _dmarc.mail.example.com

What the output means: No explicit DMARC record on the subdomain.

Decision: If your apex DMARC has sp=quarantine or sp=reject, subdomains inherit. If not, publish DMARC on high-risk subdomains or set sp= appropriately.

Task 11: Validate reverse DNS (not DMARC, but it will ruin your day)

cr0x@server:~$ dig +short -x 203.0.113.10
mailout.example.com.

What the output means: PTR exists for the sending IP, which helps reputation and acceptance.

Decision: If there’s no PTR or it points to something sketchy, fix rDNS with your ISP/cloud provider. DMARC won’t compensate for bad sender hygiene.

Task 12: Check that the HELO/EHLO name resolves (again, not DMARC, still important)

cr0x@server:~$ dig +short A mailout.example.com
203.0.113.10

What the output means: Forward DNS matches the hostname used by the outbound server.

Decision: If the name doesn’t resolve or points elsewhere, fix it. Some receivers penalize sloppy SMTP identity.

Task 13: Spot SPF permerror risk by listing includes (manual sanity check)

cr0x@server:~$ dig +short TXT _spf.google.com
"v=spf1 ip4:64.233.160.0/19 ip4:66.102.0.0/20 include:_netblocks.google.com ~all"

What the output means: Includes can nest; your original SPF record may exceed the lookup limit depending on what those includes expand into.

Decision: If you’re near the limit, reduce includes, move some streams to dedicated subdomains with separate SPF, or rely on DKIM alignment more consistently.

Task 14: Verify DKIM signature is present in the message

cr0x@server:~$ grep -i "^DKIM-Signature:" -m1 -n message.eml
42:DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; h=from:to:subject:date:mime-version; bh=...; b=...

What the output means: The message is signed with d=example.com. This is the identity DMARC can align to.

Decision: If DKIM signature is missing intermittently, find which system path strips it (relays, gateways, or apps).

Task 15: Confirm that your DMARC report mailbox exists and receives mail

cr0x@server:~$ host -t MX example.com
example.com mail is handled by 10 mx1.mailhost.example.
example.com mail is handled by 20 mx2.mailhost.example.

What the output means: Your domain has working MX. This doesn’t prove the mailbox exists, but it confirms inbound routing.

Decision: If you publish rua to a mailbox that doesn’t exist or rejects large attachments, you’ll be blind. Ensure the mailbox is monitored and can accept report volume.

Listes de contrôle / plan étape par étape

Plan de déploiement étape par étape qui arrête l’usurpation sans perdre de messages

1. Inventoriez les émetteurs légitimes.
   Utilisez les connaissances existantes (IT, marketing, facturation, support) et confirmez avec les données agrégées DMARC une fois disponibles.
   Objectif : une liste des systèmes qui envoient des « From: @votredomaine ».
2. Choisissez votre stratégie de domaine.
   Décidez si vous allez :
   • Tout envoyer depuis le domaine apex (plus difficile), ou
   • Utiliser des sous-domaines fonctionnels pour les tiers (recommandé) : billing.example.com, news.example.com, support.example.com.

   Cela réduit le rayon d’impact et rend l’alignement plus contrôlable.

3. Configurez DKIM pour chaque émetteur.
   Priorisez DKIM sur SPF pour la fiabilité à long terme. Exigez des d= alignés.
4. Publiez un SPF qui est correct, pas malin.
   Gardez-le minimal. Évitez d’enchaîner 9 includes et d’espérer. Utilisez des sous-domaines pour séparer les responsabilités si nécessaire.
5. Publiez DMARC en p=none seulement le temps de collecter la baseline.
   Habituellement 1–2 semaines suffisent si votre trafic est normal.
6. Passez à p=quarantine, pct=100.
   C’est là que l’usurpation devient réellement plus difficile et que vous avez encore une tolérance côté délivrabilité.
7. Corrigez les échecs d’alignement.
   Utilisez les rapports et les en-têtes pour identifier quels émetteurs échouent et pourquoi. Obtenez des fournisseurs qui supportent DKIM personnalisé et des domaines de rebond alignés.
8. Verrouillez les sous-domaines.
   Définissez sp=quarantine ou sp=reject. Publiez des enregistrements DMARC explicites pour les sous-domaines à risque si nécessaire.
9. Passez à p=reject.
   Seulement lorsque :
   • Vos flux légitimes à volume élevé passent DMARC de façon constante.
   • Vous comprenez les échecs restants et les avez acceptés consciemment (ou les avez déplacés vers des sous-domaines avec des politiques séparées).
10. Maintenez la boucle ennuyeuse vivante.
    Revue mensuelle des rapports, responsabilité et changements de fournisseurs. Les écosystèmes e-mail dérivent. Les paramètres fournisseurs aussi.

Checklist opérationnelle avant « nous allons changer la politique DMARC »

• Avons-nous un plan de retour arrière (TTL DNS, chaîne d’enregistrement précédente sauvegardée, fenêtre de modification) ?
• Connaissons-nous le taux de réussite actuel par flux émetteur ?
• Les tiers à risque (marketing, CRM, billetterie) signent-ils DKIM avec un d= aligné ?
• SPF est-il sous la limite de lookups et sans permerrors ?
• Avons-nous défini la politique pour les sous-domaines (sp=) ?
• Avons-nous une boîte surveillée pour RUA/RUF et un moyen de traiter les pièces XML ?
• Sommes-nous prêts pour les cas limites de transferts (listes de diffusion, transferts d’anciens élèves, clients qui transfèrent des reçus) ?

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: “DMARC fail” but SPF and DKIM both say “pass” somewhere

Root cause: One passes for a different domain. No alignment with Header From.

Fix: Ensure DKIM signs with d= aligned to the From domain (prefer exact alignment if you set adkim=s). Use a custom bounce domain for SPF alignment where possible.

2) Symptom: Marketing emails suddenly go to spam after moving to p=quarantine

Root cause: The vendor signs with their own domain or uses a non-aligned Return-Path; DMARC now fails and receivers quarantine.

Fix: Configure vendor custom DKIM for your domain or send from a dedicated subdomain with its own DMARC policy and authentication.

3) Symptom: Some transactional emails pass, others fail, from the same “system”

Root cause: Multiple outbound paths: some signed, some not; or some routed through a relay that modifies content and breaks DKIM.

Fix: Trace the path and standardize: either sign at the edge after all rewriting, or ensure intermediaries don’t modify signed parts. Verify with message samples from each path.

4) Symptom: DMARC reports show a ton of unknown IPs sending as your domain

Root cause: Spoofing attempts are common, and p=none lets them “look” more legitimate to some receivers. Also, you may have shadow IT senders.

Fix: Move to quarantine enforcement; investigate high-volume sources. For legitimate unknowns, assign ownership and configure aligned DKIM/SPF.

5) Symptom: Receivers say SPF “permerror” or “temperror”

Root cause: SPF lookup limit exceeded, malformed SPF record, or DNS timeouts.

Fix: Reduce includes, flatten SPF responsibly (without breaking ownership), or segment by subdomain. Improve DNS reliability.

6) Symptom: Forwarded messages (customers auto-forwarding invoices) fail DMARC and get quarantined

Root cause: SPF fails on forward (different sending IP), and DKIM may break if the forwarder rewrites content or modifies headers.

Fix: Prioritize DKIM robustness (sign the final form, avoid content rewriting). Consider ARC support if you operate forwarders; for external forwards, accept some loss and mitigate with alternate delivery (portals, authenticated customer accounts).

7) Symptom: Subdomain spoofing continues even after apex is locked down

Root cause: No sp= tag and no DMARC records on subdomains.

Fix: Set sp=quarantine or sp=reject on the apex DMARC record, and explicitly publish DMARC for high-value subdomains.

8) Symptom: You set p=reject and now a partner says your emails “disappear”

Root cause: Their gateway rejects DMARC failures; your legitimate mail is failing alignment due to a vendor or relay.

Fix: Temporarily move to quarantine while you remediate, or move the failing stream to a subdomain with a less strict policy as an interim measure. Then fix alignment properly.

FAQ

1) Is “p=none” useless?

C’est utile pour la découverte, mais ça n’empêche pas l’usurpation. Traitez-le comme du logging sans alertes : acceptable brièvement, irresponsable indéfiniment.
Passez à quarantine une fois que vous avez une baseline et des propriétaires assignés.

2) Why not start with p=reject if spoofing is bad?

Parce que votre courrier légitime a probablement des émetteurs inconnus et des problèmes d’alignement. Reject transforme ces cas en échecs durs immédiatement.
Quarantine est une application avec filet de sécurité pendant que vous nettoyez l’environnement.

3) Should I rely on SPF or DKIM for DMARC pass?

Préférez l’alignement DKIM pour la durabilité. SPF casse sur le forwarding et les routages complexes. Utilisez SPF comme signal utile, pas comme identité primaire.

4) What does “alignment” practically mean for vendors?

Cela signifie que le fournisseur doit signer avec votre domaine en DKIM (DKIM personnalisé), et idéalement utiliser un bounce/Return-Path qui appartient à votre domaine
(return-path personnalisé). Sans cela, DMARC échouera lorsque le From est votre domaine.

5) What are adkim and aspf settings I should choose?

Un bon défaut est adkim=s et aspf=r pendant le déploiement. Cela pousse les fournisseurs à faire DKIM correctement sans trop pénaliser la variance du chemin SPF.
Si votre environnement signe depuis des sous-domaines volontairement, ajustez adkim en conséquence ou changez votre stratégie de domaine From.

6) Do I need RUF (forensic) reports?

Parfois. Beaucoup de récepteurs limitent ou redigent ces rapports pour des raisons de confidentialité, et le volume peut être difficile à gérer. Les rapports RUA agrégés sont l’outil principal.
Si vous activez RUF, orientez-les vers une boîte contrôlée et préparez-vous à traiter des contenus sensibles de manière responsable.

7) What about mailing lists that modify the subject or add footers?

Elles peuvent casser les signatures DKIM en modifiant le contenu signé. Si SPF échoue également (commun avec le forwarding), DMARC échoue.
Vos options : encourager les opérateurs de listes à préserver DKIM, compter sur ARC lorsque supporté, ou accepter que certains flux de listes ne seront pas fiables sous une application stricte.

8) How do subdomains help deliverability and security?

Ils isolent la réputation et la politique. Mettez le marketing sur news.example.com, le transactionnel sur billing.example.com, et le courrier humain sur l’apex.
Puis ajustez DMARC par sous-domaine si nécessaire tout en protégeant la marque.

9) If DMARC passes, why are messages still going to spam?

Parce que l’authentification n’est pas la réputation. Vérifiez la réputation des IP d’envoi, les taux de plainte, l’engagement, les schémas de contenu et la cohérence.
Le passage DMARC est nécessaire ; il n’est pas suffisant.

10) How long does it take for DMARC changes to take effect?

Le TTL DNS gouverne la propagation, mais les récepteurs mettent en cache et évaluent à leur propre rythme. Prévoir des heures, pas des minutes.
Planifiez les changements avec des réductions de TTL en amont si vous avez besoin d’un retour rapide.

Conclusion : prochaines étapes à livrer cette semaine

La « politique DMARC unique » qui fonctionne en production n’est pas une chaîne magique ; c’est une posture : appliquer en quarantine à 100 %, imposer l’alignement DKIM,
garder SPF assez souple pour éviter les blessures auto-infligées, et utiliser les rapports pour traquer chaque émetteur qui se fait passer pour vous.

Faites ceci ensuite

1. Publiez ou vérifiez DMARC à l’apex avec p=quarantine; pct=100; adkim=s; aspf=r; sp=quarantine.
2. Exécutez les tâches pratiques ci-dessus pour vos 3 principaux flux sortants et confirmez le passage DMARC et l’alignement dans de vrais en-têtes.
3. Choisissez une stratégie de sous-domaine pour les tiers et commencez à déplacer les fournisseurs les plus problématiques là-bas s’ils ne peuvent pas faire du DKIM aligné rapidement.
4. Programmez un rappel mensuel : revue des rapports DMARC avec propriétaires assignés. C’est ainsi que vous évitez les régressions.
5. Une fois que vos flux légitimes passent de façon constante, passez en toute confiance à p=reject, pas par optimisme.

L’usurpation s’arrête quand les récepteurs peuvent dire de façon fiable ce qui vous appartient. La délivrabilité survit quand vous arrêtez de deviner et commencez à gérer l’identité comme un système :
avec télémétrie, responsabilité et application graduelle.