Depuis mars 2024, des envois Microsoft 365 vers Yahoo/AOL échouent avec des NDR « didn’t respond ». Voici une analyse pragmatique et un plan d’action pas‑à‑pas pour remettre vos messages en boîte de réception : SPF/DKIM/DMARC, tests, diagnostics avancés et modèles prêts à l’emploi.
Vue d’ensemble
Des organisations utilisant Microsoft 365, souvent avec un domaine personnalisé, constatent des non‑remises vers des adresses Yahoo et AOL. Les messages de non‑remise (NDR) indiquent typiquement que le « système du destinataire n’a pas répondu » après plusieurs tentatives. La plupart de ces expéditeurs ne sont pas des expéditeurs en masse : il s’agit d’équipes internes, d’associations, de PME…
Le point commun : une authentification de domaine incomplète ou mal alignée (SPF/DKIM/DMARC), dans un contexte où les FAI ont durci leurs politiques d’acceptation en 2024. Résultat : files d’attente, deferrals répétés, délais qui expirent, puis NDR qui parlent d’un destinataire « qui n’a pas répondu ».
Ce qui a réellement changé côté réception
- Politiques renforcées chez Yahoo/AOL (et aussi chez Gmail) : même si les annonces visaient surtout les bulk senders, la réalité est que tout domaine mal authentifié est désormais ralenti (codes 4.x), parfois rejeté (codes 5.x).
- Alignement DMARC exigé de fait : pour un message, au moins SPF ou DKIM doit passer et être aligné sur le domaine visible dans l’en‑tête
From:. - Conséquence visible dans Microsoft 365 : les serveurs distants répondent par des temporisations ou refus temporaires ; Exchange Online retente, puis finit par abandonner, produisant des NDR parlant d’un destinataire silencieux. En réalité, le destinataire répond… par un « pas maintenant » répété.
Ne faites pas fausse route
- Copier des enregistrements DNS prévus pour Mandrill/SendGrid/Mailchimp ne vous aidera que si vous utilisez effectivement ces prestataires. Sinon, c’est inutile, voire nuisible.
- Les valeurs à publier diffèrent selon l’émetteur : Microsoft 365 n’a pas les mêmes cibles DKIM qu’un prestataire tiers.
- Un incident ponctuel a pu exister, mais les domaines non conformes restent pénalisés tant que la configuration n’est pas corrigée.
Plan d’action concret pour Microsoft 365 avec domaine personnalisé
Vérifier l’état actuel du domaine
Avant de changer quoi que ce soit, dressez un état des lieux :
- Vérifiez vos enregistrements SPF/DKIM/DMARC dans le DNS (outil de votre registrar ou de votre hébergeur DNS).
- Récupérez un message sortant récent et inspectez les en‑têtes :
Authentication-Results,Received-SPF,DKIM-Signature,DMARC.
Extraits attendus dans Authentication-Results :
spf=pass smtp.mailfrom=example.com
dkim=pass header.d=example.com header.s=selector1
dmarc=pass (p=none sp=none dis=none) header.from=example.com
SPF sans doublons
Objectif : autoriser Microsoft 365 à envoyer en votre nom.
Modèle de base pour un domaine qui n’envoie que via Microsoft 365 :
v=spf1 include:spf.protection.outlook.com ~all- Un seul enregistrement SPF par domaine (un seul TXT qui commence par
v=spf1). Plusieurs SPF = résultat permerror. - Si vous utilisez aussi un prestataire (ex. SendGrid), ajoutez son
include:dans le même SPF. Ne créez pas un deuxième SPF. - Évitez
+all. Démarrez en~all, puis envisagez-allaprès inventaire complet des sources. - Respectez la limite de 10 recherches DNS côté SPF ; regroupez les prestataires si nécessaire.
DKIM indispensable pour l’alignement
Objectif : signer chaque message avec une clé liée à votre domaine afin d’obtenir un dkim=pass aligné.
- Dans le centre d’administration Microsoft 365, activez la fonctionnalité DKIM pour votre domaine.
- Publiez deux CNAME que Microsoft 365 vous fournit (généralement
selector1._domainkeyetselector2._domainkeypointant vers des hôtes onmicrosoft.com spécifiques à votre domaine). - Attendez la propagation, puis activez la signature dans le portail (ou via PowerShell).
PowerShell Exchange Online (exemple) :
Connect-ExchangeOnline
# Vérifier si une config existe déjà
Get-DkimSigningConfig -Identity example.com
# Créer/activer si nécessaire (clé 2048 recommandée)
New-DkimSigningConfig -DomainName example.com -Enabled $true -KeySize 2048
# Ou activer si déjà créée
Set-DkimSigningConfig -Identity example.com -Enabled $true
DMARC en observation puis durcissement
Objectif : déclarer que le domaine exige un alignement de l’expéditeur avec SPF ou DKIM.
Point de départ :
Host : _dmarc.example.com
Value : v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s- Collectez et analysez les rapports agrégés (
rua) pour repérer les sources d’envoi non conformes. - Après correction, passez à
p=quarantine, puisp=reject. - Options utiles :
pct=(progressif),sp=(politique pour sous‑domaines),ruf=(rapports forensiques si utile).
Prestataires d’e‑mailing tiers
- Activez l’authentification d’expéditeur chez le prestataire (signature DKIM au nom de votre domaine).
- Publiez uniquement les enregistrements fournis (CNAME/TXT) et complétez votre SPF avec son
include:si requis. - Sans cette étape : non‑alignement DMARC persistant, deferrals et rejets probables.
Tester et observer après changements DNS
- Attendez la propagation (en pratique quelques minutes à quelques heures selon TTL).
- Envoyez des messages vers des boîtes Yahoo/AOL ; inspectez les en‑têtes : viser dkim=pass ou spf=pass et dmarc=pass avec alignement strict (
adkim=s,aspf=s). - Si des NDR persistent, notez le code SMTP et la mention précise pour cibler la correction.
Tableau des symptômes, causes probables et actions
| Symptôme / message | Cause la plus probable | Action recommandée |
|---|---|---|
| NDR : « Recipient system didn’t respond » | Déferrals répétés côté Yahoo/AOL (contrôles d’authentification/réputation). | Vérifier SPF/DKIM/DMARC et leur alignement ; tester depuis un message avec en‑têtes complets. |
| Codes 421/451/4.7.x | Refus temporaires (taux, réputation, manque d’authentification). | Corriger l’authentification et ralentir la cadence d’envoi le temps que la réputation se stabilise. |
| Codes 550/554/5.7.x | Rejet définitif (DMARC fail, blocage politique). | Assurer au moins un alignement (SPF ou DKIM) et republier une politique DMARC adaptée. |
spf=neutral/softfail | Source d’envoi non autorisée ou SPF mal formé/doublonné. | Inventorier les sources, unifier le SPF, supprimer les doublons, respecter la limite de 10 recherches. |
dkim=none/fail | DKIM non activé, CNAME absents, sélecteur incorrect, clé obsolète. | Publier/valider les CNAME fournis par M365, activer DKIM et vérifier dans les en‑têtes. |
dmarc=fail | Mauvais alignement du domaine From: avec l’identité SPF (smtp.mailfrom) ou DKIM (d=). | Mettre adkim=s, aspf=s, signer DKIM avec le même domaine que dans From:. |
Diagnostics avancés côté Microsoft 365
Tracer les messages
Utilisez les traces pour voir les tentatives et réponses distantes.
Connect-ExchangeOnline
# Tracer les envois vers un domaine cible sur 2 jours
Get-MessageTrace -RecipientAddress user@yahoo.com -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) |
Get-MessageTraceDetail
Recherchez des motifs de type « Deferred by remote server » ou des codes 4.x/5.x associés au domaine distant.
Lire et interpréter les en‑têtes
| Champ | Ce qu’il faut voir | Interprétation |
|---|---|---|
Authentication-Results | spf=pass, dkim=pass, dmarc=pass | Les contrôles ont réussi côté serveur de réception. |
Received-SPF | pass avec votre domaine | L’adresse IP de sortie est autorisée par votre SPF. |
DKIM-Signature | d=example.com, s=selector1 | Le domaine signé (d=) doit correspondre au From: (alignement strict recommandé). |
From: | user@exemple.com | Le domaine visible par l’utilisateur est celui qui doit s’aligner. |
Cas avec d’autres domaines destinataires
Les mêmes principes s’appliquent à d’autres FAI (ex. comcast.net) : SPF correct, DKIM activé, DMARC publié et aligné. La pression accrue sur l’authentification et la réputation est désormais généralisée.
Modèles d’enregistrements DNS à adapter
Important : remplacez
example.compar votre domaine et utilisez exactement les cibles fournies dans votre portail Microsoft 365 ou par votre prestataire.
SPF pour Microsoft 365 uniquement
v=spf1 include:spf.protection.outlook.com ~allAjoutez d’autres include: uniquement si vous expédiez aussi via ces services.
DKIM pour Microsoft 365
selector1._domainkey.example.com CNAME (cible fournie par Microsoft 365)
selector2._domainkey.example.com CNAME (cible fournie par Microsoft 365)DMARC en mode observation
_dmarc.example.com TXT "v=DMARC1; p=none; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com"Bonnes pratiques de configuration DNS
| Enregistrement | But | Où | Conseil TTL | Pièges courants |
|---|---|---|---|---|
| SPF (TXT) | Autoriser les IP/relays d’envoi | Zone de votre domaine apex | 3600 s au départ | Plusieurs SPF, dépassement des 10 lookups, usage de +all |
| DKIM (CNAME) | Signer le message | selector._domainkey | 3600 s | Deviner la cible, clé 1024 dépassée, sélecteur erroné |
| DMARC (TXT) | Exiger l’alignement et définir la politique | _dmarc | 3600 s | Adresse rua invalide, politique trop stricte trop tôt |
Chemin de résolution recommandé
- État des lieux : relire un message avec en‑têtes ; noter
spf=,dkim=,dmarc=. - SPF unique : un seul enregistrement TXT
v=spf1, inclurespf.protection.outlook.com, ajouter les prestataires réellement utilisés. - DKIM activé : publier les deux CNAME puis activer.
- DMARC publié : démarrer en
p=none, strict (adkim=s,aspf=s), collecterrua. - Tests réels : envoyer vers Yahoo/AOL, relire les en‑têtes, viser pass + alignement.
- Durcissement : passer à
p=quarantine, puisp=reject, quand tout s’aligne. - Surveillance continue : rapports DMARC, traces Microsoft 365, corrections ciblées.
Exemples d’en‑têtes réussis et échoués
Succès (exemple) :
Authentication-Results: mx.example.net;
spf=pass smtp.mailfrom=example.com;
dkim=pass header.d=example.com header.s=selector1;
dmarc=pass (policy=none) header.from=example.com
Échec (exemple) :
Authentication-Results: mx.example.net;
spf=pass smtp.mailfrom=provider-mail.com;
dkim=none;
dmarc=fail (p=quarantine) header.from=example.com
Interprétation :
* Succès : au moins SPF ou DKIM passe ET s’aligne sur example.com.
* Échec : SPF passe mais pour un autre domaine (provider-mail.com), DKIM absent : DMARC échoue.Gestion des rejets temporaires et réputation
- Après correction technique, réduisez temporairement la cadence d’envoi vers Yahoo/AOL et évitez d’importants pics.
- Sur les listes de diffusion, nettoyez les adresses rebondies ; la réputation se bâtit avec des signaux d’engagement positifs.
- Privilégiez une clé DKIM 2048 bits et faites tourner le sélecteur périodiquement.
FAQ ciblée
Pourquoi un NDR « didn’t respond » alors que le destinataire « répond » ?
Parce que le serveur destinataire oppose des deferrals (réponses 4.x) à répétition. Vu du côté Microsoft 365, cela ressemble à un destinataire silencieux ; en réalité, il a répondu « réessayez plus tard » jusqu’à expiration.
Est‑ce que SPF seul suffit ?
Non. Beaucoup de FAI attendent un alignement DMARC : SPF ou DKIM doit passer et correspondre au domaine du From:. Si vous utilisez des prestataires, DKIM au nom de votre domaine est crucial.
Dois‑je passer directement en DMARC p=reject ?
Commencez par p=none, corrigez toutes les sources, puis passez progressivement à quarantine et reject. Un basculement immédiat peut bloquer des flux légitimes non encore alignés.
Et si j’envoie aussi via un outil marketing ?
Activez l’authentification d’expéditeur chez ce prestataire, publiez ses CNAME/TXT, ajoutez son include: au SPF, puis testez l’alignement. Sans cela, vos campagnes seront freinées ou rejetées, même si Microsoft 365 est correct.
Liste de contrôle express
- [ ] Un seul enregistrement SPF, sans
+all. - [ ] DKIM activé et aligné avec le domaine du
From:. - [ ] DMARC publié (
p=none), puis durci. - [ ] Tous les prestataires tiers configurés pour signer votre domaine (et inclus dans SPF).
- [ ] Tests d’en‑têtes : viser
dkim=passouspf=pass+dmarc=pass. - [ ] Surveillance des rapports DMARC et correction des sources non conformes.
Annexe : commandes utiles
Vérifier rapidement les DNS
# Depuis un poste admin
nslookup -type=txt example.com
nslookup -type=txt _dmarc.example.com
nslookup -type=cname selector1._domainkey.example.com
nslookup -type=cname selector2._domainkey.example.com
# Ou avec dig
dig txt example.com +short
dig txt \_dmarc.example.com +short
dig cname selector1.\_domainkey.example.com +short
dig cname selector2.\_domainkey.example.com +short Moduler DMARC en douceur
# Observation stricte (alignement strict)
"v=DMARC1; p=none; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com"
# Quarantaine à 25% des messages non conformes (progressif)
"v=DMARC1; p=quarantine; pct=25; adkim=s; aspf=s; rua=mailto\:dmarc-reports\@example.com"
# Rejet complet (après vérifications)
"v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto\:dmarc-reports\@example.com"Conclusion
Les échecs vers Yahoo/AOL depuis Microsoft 365 ne relèvent pas d’un « caprice » mais d’un durcissement structurel : domaines mal authentifiés sont désormais ralentis ou bloqués. En appliquant méthodiquement : SPF unique, DKIM activé, DMARC aligné, puis tests et pilotage par les rapports, la délivrabilité revient à la normale — même pour des envois non « bulk ».
En procédant ainsi, vous corrigez la cause racine (authentification et alignement), vous réduisez la pression réputationnelle, et vous évitez les faux remèdes consistant à copier des enregistrements DNS de prestataires que vous n’utilisez pas.