DMARC p=none, quarantine ou reject : le guide de l’opérateur

Le compromis fondamental

Choisir une politique DMARC, c’est arbitrer entre visibilité et application. p=none permet de surveiller sans affecter la livraison. p=quarantine envoie le courrier suspect dans le dossier spam. p=reject bloque entièrement le courrier non authentifié. La voie la plus sûre est un déploiement progressif : commencez par none pour identifier tous les expéditeurs légitimes, passez à quarantine pour mesurer l’impact, puis atteignez reject pour protéger complètement votre domaine contre l’usurpation.

Pourquoi la politique compte pour votre file d’incidents

En tant qu’ingénieur responsable de la délivrabilité, votre objectif principal est de garantir que le courrier transactionnel légitime atteint ses destinataires tout en empêchant les attaquants d’utiliser votre domaine. Si vous passez directement à p=reject sans phase de surveillance, vous déclencherez probablement un incident prioritaire le jour où un vieux système oublié ou un outil marketing tiers cessera soudainement de délivrer ses e-mails.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) repose sur l’alignement de SPF et de DKIM. Si un message échoue aux deux, la balise p= indique précisément au serveur de messagerie destinataire quoi faire de ce message.

Les trois niveaux de politique

1. p=none (mode surveillance)

Dans ce mode, le destinataire n’applique aucune mesure au message, quels que soient les résultats d’authentification. Il sert uniquement à collecter des données.

Quand l’utiliser :

• Lors de la mise en place initiale de DMARC.
• Lorsque vous ne connaissez pas avec certitude tous les services qui envoient des e-mails en votre nom.
• Pendant une migration vers une nouvelle API e-mail.

L’enregistrement :

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

Le compromis : vous n’avez aucune protection contre l’usurpation. Les attaquants peuvent toujours envoyer des e-mails au nom de votre domaine, mais vous les verrez dans vos rapports RUA (agrégés).

2. p=quarantine (application souple)

Les messages qui échouent à DMARC sont traités comme suspects. La plupart des destinataires les placent dans le dossier spam ou courrier indésirable.

Quand l’utiliser :

• Une fois que vous avez analysé les rapports p=none et vérifié que tous les flux légitimes sont alignés.
• Comme marge de sécurité avant de passer au rejet complet.

L’enregistrement :

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com;

Le compromis : ce mode réduit la visibilité du courrier usurpé sans l’éliminer. Du courrier légitime peut encore finir en spam si la rotation de vos clés DKIM est mal faite ou si vos enregistrements SPF atteignent la limite de 10 requêtes DNS.

3. p=reject (application complète)

C’est la référence en matière de sécurité de domaine. Le serveur destinataire refuse purement et simplement le message s’il échoue à DMARC.

Quand l’utiliser :

• Lorsque votre surveillance montre un alignement de 99,9 % pour tout le trafic légitime.
• Lorsque le risque d’usurpation du domaine l’emporte sur le risque d’échecs de livraison occasionnels.

L’enregistrement :

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;

Le compromis : il n’y a plus de filet de sécurité. Si un système critique est mal configuré, l’e-mail est perdu. Vous verrez ces échecs dans les rapports RUA, mais l’utilisateur ne recevra jamais l’e-mail.

La checklist de déploiement de l’opérateur

Ne changez pas de politique au feeling. Changez-en en vous appuyant sur les données de vos rapports agrégés. Utilisez un outil comme le Vérificateur DNS e-mail de SendHQ pour vous assurer que vos enregistrements se propagent correctement avant chaque changement.

Phase 1 : découverte (p=none)

1. Publiez p=none avec une adresse rua.
2. Attendez 7 à 14 jours pour couvrir un cycle d’activité complet d’e-mails (y compris les rapports hebdomadaires).
3. Analysez les rapports pour repérer le trafic « non aligné ».
4. Identifiez les expéditeurs tiers légitimes (par exemple Zendesk, Salesforce, Shopify).
5. Configurez DKIM pour chaque expéditeur identifié. C’est le moyen le plus fiable de garantir l’alignement.

Phase 2 : test (p=quarantine)

1. Passez la politique à p=quarantine.
2. Surveillez vos tickets de support à la recherche de « Je n’ai pas reçu l’e-mail » ou « L’e-mail est dans les spams ».
3. Vérifiez dans les rapports RUA toute nouvelle hausse des échecs.
4. En cas d’échecs, corrigez l’authentification et restez en quarantine une semaine de plus.

Phase 3 : durcissement (p=reject)

1. Passez la politique à p=reject.
2. Vérifiez que vos flux transactionnels les plus critiques (réinitialisations de mot de passe, factures) sont toujours délivrés.
3. Maintenez la surveillance. DMARC n’est pas une configuration qu’on « installe et qu’on oublie ».

Traiter l’e-mail comme un effet de bord

Pour les ingénieurs produit qui construisent des agents IA ou des workflows automatisés, envoyer un e-mail est un effet de bord externe. Autrement dit, l’envoi peut échouer pour des raisons extérieures à la logique de votre application (problèmes DNS, rejet DMARC, limites de débit).

Idempotence et approbation

Lorsqu’un agent IA déclenche un e-mail, vous devez empêcher les envois en double lors des nouvelles tentatives. Utilisez une clé d’idempotence dans vos requêtes API pour qu’un timeout réseau n’aboutisse pas à ce que le client reçoive cinq fois le même e-mail.

En outre, les agents ne devraient pas avoir la permission d’envoyer de façon autonome des e-mails à fort enjeu. Mettez en place une file d’approbation pour le contenu généré par les agents, afin de garantir que l’adresse « From » et le contenu sont conformes à votre marque et à vos politiques d’authentification.

Le coût de l’infrastructure de livraison

Le choix de votre fournisseur d’envoi influe sur la gestion de DMARC. Certains fournisseurs rendent la configuration DKIM triviale, tandis que d’autres exigent des entrées DNS manuelles pour chaque sous-domaine.

Pour évaluer les coûts, regardez le coût total de possession. Par exemple, envoyer 50 000 e-mails coûte environ 5 USD avec Amazon SES à la carte (à 0.10 USD pour 1 000 e-mails), alors que les paliers de Postmark coûteraient environ 66 USD pour le même volume (15 USD pour 10 000, plus des dépassements facturés entre 1.20 et 1.80 USD pour 1 000).

Parmi les autres options figurent Resend, qui propose une offre gratuite de 3 000 e-mails par mois (plafonnée à 100 par jour), et Mailgun, à partir de 15 USD par mois pour 10 000 e-mails. SendGrid a désormais remplacé son offre gratuite par un essai de 60 jours, avec une formule Essentials à partir de 19.95 USD par mois.

Quel que soit le fournisseur, la politique DMARC reste le principal bouclier de votre domaine. Si vous utilisez un fournisseur qui ne prend en charge que SPF, vous courez un risque plus élevé d’échec de livraison en passant à p=reject, car SPF casse lors du transfert des e-mails. DKIM est le seul moyen de conserver l’alignement à travers les transferts.

Modes de défaillance courants

Le piège du transfert

L’utilisateur A envoie un e-mail à l’utilisateur B. L’utilisateur B a configuré un transfert automatique vers l’utilisateur C. Le serveur de transfert remplace souvent l’expéditeur d’enveloppe par son propre domaine pour éviter d’être signalé comme spam. Cela casse l’alignement SPF. Si vous êtes en p=reject sans signature DKIM, l’utilisateur C ne verra jamais l’e-mail.

La limite de requêtes DNS

Les enregistrements SPF sont limités à 10 requêtes DNS. Si vous ajoutez trop de fournisseurs à votre enregistrement SPF, le destinataire renverra un permerror. Cela provoque un échec DMARC. Pour y remédier, utilisez un fournisseur qui privilégie l’authentification DKIM ou recourez à l’aplatissement SPF (SPF flattening).

Le problème du « shadow IT »

Les équipes marketing s’inscrivent souvent à de nouveaux outils (par exemple un nouveau service de newsletter) sans prévenir l’équipe technique. Ces outils envoient des e-mails depuis votre domaine, échouent à DMARC et sont rejetés. C’est pourquoi la phase p=none n’est pas négociable.

Tableau récapitulatif pour les opérateurs

Politique | Action | Risque | Visibilité | Usage recommandé

p=none | Aucune | Faible | Élevée | Découverte et audit

p=quarantine | Dossier spam | Moyen | Élevée | Test et transition

p=reject | Bloqué | Élevé | Moyenne | Sécurité complète en production

Pour approfondir la mise en œuvre technique de ces enregistrements, consultez notre guide sur DKIM, SPF et DMARC.

Gérer ces enregistrements manuellement est fastidieux. SendHQ vous simplifie la tâche avec l’envoi transactionnel depuis des domaines vérifiés et des outils qui préparent votre infrastructure aux agents.

En savoir plus sur https://sendhq.cc.