Dernière mise à jour : juillet 2026

En bref : après ce guide, ton domaine publie un enregistrement DMARC pour Microsoft 365 — échelonné en toute sécurité de l’observation à l’application, y compris les conséquences propres à Microsoft.

Prérequis

  • Un locataire (tenant) Microsoft 365 avec un domaine personnalisé
  • L’accès à la gestion DNS de ton domaine (chez l’hébergeur du domaine)
  • SPF et DKIM doivent être en place

Qu’est-ce que DMARC ?

DMARC (Domain-based Message Authentication, Reporting & Conformance) combine SPF et DKIM en une politique applicable. L’enregistrement TXT _dmarc définit ce qu’un destinataire doit faire des e-mails non authentifiés — et où il envoie les rapports.

Le point de départ chez Microsoft 365

Deux particularités Microsoft comptent :

L’enregistrement se crée chez l’hébergeur du domaine, pas dans Microsoft 365 — pour ton domaine personnalisé. L’exception : pour le domaine *.onmicrosoft.com, tu crées le TXT DMARC dans le centre d’administration Microsoft 365.

Le pool sortant à haut risque. Si tu règles p=quarantine ou p=reject, Microsoft achemine les e-mails sortants qui échouent à DMARC chez le destinataire via un « pool de distribution à haut risque » — et sans exception : « Il n’existe aucune dérogation à ce comportement. » En pratique, cela signifie : tu dois vraiment avoir capturé tous les expéditeurs proprement authentifiés avant de resserrer, sinon ta réputation d’envoi en souffre.

Guide étape par étape

1. Commencer avec p=none

Chez l’hébergeur du domaine, crée un enregistrement TXT — hôte _dmarc, valeur :

v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de

p=none, selon Microsoft, sert explicitement « à tester et affiner la politique DMARC ». Tu analyses au mieux les rapports rua (quotidiens, XML) avec un moniteur DMARC comme MARCo.

2. Lire les rapports et nettoyer les sources

Le rapport agrégé te montre toutes les adresses IP qui envoient via ton domaine, et si elles passent DMARC. Fais en sorte que toutes les sources légitimes passent SPF/DKIM. Conseil de Microsoft : place les gros expéditeurs externes sur un sous-domaine (marketing.example.com), pour que leurs problèmes n’atteignent pas la réputation de ton domaine principal.

3. Échelonner jusqu’à reject

Utilise d’abord pct, puis applique pleinement :

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@beispiel.de
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@beispiel.de

L’enregistrement d’exemple complet de Microsoft avec rapports forensiques se lit v=DMARC1; p=reject; pct=100; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com.

4. Attendre que la modification soit en ligne

Les modifications DNS prennent du temps — de quelques heures à un jour selon le fournisseur et le TTL.

Vérifier le résultat

Vérifie ta configuration avec le scanner MXAudit gratuit — il te montre DMARC, SPF et DKIM d’un coup d’œil.

Erreurs fréquentes

Trop tôt à reject — et ensuite le pool à haut risque. Avec Microsoft 365, un reject prématuré a un inconvénient supplémentaire : les e-mails sortants échoués passent par le pool à haut risque. Nettoie d’abord toutes les sources.

.onmicrosoft.com oublié. Son enregistrement DMARC se définit dans le centre d’administration, pas chez l’hébergeur du domaine.

Envoi en masse via le domaine principal. Déplace les services de newsletter vers un sous-domaine.

DMARC sans SPF/DKIM. D’abord SPF et DKIM, puis DMARC.

Pour aller plus loin