Defaults.Exposed

Defaults.ExposedCorrectionsGuides

Outlook rejette votre e-mail : 550 5.7.515, 550 5.7.509 et compauth=fail, expliqués et corrigés (2026)

Publié 2026-07-08

Chiffres au 2026-06-29 · méthodologie v7. Données de recensement agrégées sur 261 millions de domaines évalués. Voir comment nous notons.

Deux systèmes Microsoft distincts rejettent le courrier. L’Outlook.com grand public renvoie les expéditeurs à fort volume qui échouent l’authentification (550 5.7.515, appliqué depuis mai 2025) ; Exchange Online renvoie le courrier qui échoue votre propre politique DMARC reject (550 5.7.509). Sur 10 205 070 domaines autorisant spf.protection.outlook.com, 85,0% ont un SPF strict mais seuls 21,7% appliquent DMARC, selon le recensement Defaults.Exposed portant sur 261 086 232 domaines.

La plupart des problèmes « Outlook rejette mon e-mail » ne sont pas des rejets du tout — c’est du courrier qui atterrit silencieusement dans les Indésirables avec compauth=fail dans les en-têtes. Ce guide décode les codes Microsoft, montre comment lire l’en-tête Authentication-Results, et parcourt la correction dans l’ordre : confirmer SPF, activer DKIM pour votre domaine personnalisé, publier et appliquer DMARC, retester.

Quelle erreur Microsoft avez-vous réellement ?

Microsoft exploite deux surfaces de réception distinctes, et elles rejettent pour des raisons différentes. Faites d’abord correspondre votre symptôme — un mauvais diagnostic fait perdre une journée.

Code / signalD’où cela vientCe que cela signifieDonnées au 2026-06-29
550 5.7.515Outlook.com / Hotmail / Live grand publicVous envoyez plus de 5 000 messages/jour vers Outlook grand public et échouez les exigences d’authentification (SPF + DKIM + DMARC), appliquées depuis mai 2025
550 5.7.509Exchange Online / EOP (locataires professionnels)Le serveur de réception a honoré votre propre politique DMARC p=reject — votre courrier a échoué DMARCSeuls 10,59% de tous les 261 086 232 domaines évalués appliquent DMARC
550 5.7.511Exchange Online / EOPVotre adresse ou domaine d’envoi figure sur la liste des expéditeurs bannis de l’organisation destinataire ou de Microsoft
S3140 / S3150Outlook.com grand publicVotre IP d’envoi a une mauvaise réputation — un blocage, pas un échec d’authentification
compauth=fail (en-têtes)Les deux surfaces — le cas le plus fréquentLe courrier a été accepté mais mis en spam : l’authentification composite de Microsoft a échoué. Pas de rebond, pas de NDR — juste le dossier spamSur 10 205 070 domaines envoyant via M365, seuls 21,7% appliquent DMARC

La formulation exacte du NDR change ; vérifiez les chaînes que vous citez contre un rebond réel avant de vous y fier.

Que signifie le 550 5.7.515 ?

C’est l’exigence grand public d’Outlook.com/Hotmail, pas une erreur de locataire Microsoft 365. Depuis mai 2025, les expéditeurs de plus de 5 000 messages par jour vers des adresses Outlook grand public doivent passer SPF, passer DKIM, et publier un enregistrement DMARC (au moins p=none) aligné avec le domaine From. Sous cette barre, l’Outlook grand public rejette avec une formulation du type :

550 5.7.515 Access denied, sending domain [votredomaine.com] does not meet the required authentication level.

Deux choses que ceci n’est pas : ce n’est pas un mandat de 2026 (si votre courrier vient tout juste de commencer à rebondir, c’est votre volume ou votre DNS qui a changé, pas la règle), et cela ne concerne pas les réglages du locataire M365 du destinataire. Le correctif est l’échelle d’authentification ci-dessous — et les journées de campagne occasionnelles qui franchissent 5 000/jour comptent aussi.

Que signifie le 550 5.7.509 ?

Celui-ci vient d’Exchange Online Protection sur les locataires professionnels, et il signifie que votre propre politique DMARC est honorée :

550 5.7.509: Access denied, sending domain [votredomaine.com] does not pass DMARC verification and has a DMARC policy of reject.

Lisez cela attentivement — ce n’est pas Microsoft qui fait des difficultés. Votre domaine publie p=reject, ce message a échoué DMARC, et le destinataire a fait exactement ce que vous demandiez. Si le courrier rejeté est légitime, une source d’envoi (un outil de newsletter, un CRM, un appareil de numérisation vers e-mail) n’est pas authentifiée de façon alignée. N’affaiblissez pas la politique ; donnez à cette source un SPF ou un DKIM aligné — voir corriger DMARC et de p=none à p=reject.

Pourquoi Outlook met-il mon courrier en spam avec compauth=fail au lieu de le rejeter ?

La plupart des difficultés de délivrabilité Microsoft ne produisent jamais de rebond. Le message est accepté, noté, et classé en Indésirables — la seule preuve est l’en-tête Authentication-Results. Dans la boîte du destinataire (ou votre propre boîte de test outlook.com), ouvrez le message, choisissez Afficher la source du message, et trouvez la ligne :

Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001

compauth est le verdict d’authentification composite de Microsoft : même quand un domaine ne publie aucun enregistrement DMARC, Microsoft applique des vérifications implicites, de type DMARC. Valeurs couramment observées :

La leçon : sur Microsoft, lisez l’en-tête, pas seulement le NDR. Les verdicts spf=, dkim= et dmarc= sur cette même ligne vous disent exactement quelle branche corriger.

Comment corriger les rejets et mises en spam d’Outlook ?

  1. Lancez d’abord le scan gratuit. Il note SPF, DKIM et DMARC en une passe et montre quelle branche échoue avant que vous touchiez au DNS.
  2. Confirmez SPF — généralement déjà correct sur Microsoft 365. L’enregistrement standard est v=spf1 include:spf.protection.outlook.com -all, et la configuration M365 le place là : 85,0% des 10 205 070 domaines autorisant spf.protection.outlook.com se terminent déjà par un -all strict (données au 2026-06-29). Une garde-fou : les destinataires évaluent SPF contre le domaine du Return-Path (RFC5321.MailFrom), pas l’en-tête From — donc un outil de newsletter peut passer SPF sur son domaine de rebond tout en ne faisant rien pour le vôtre. C’est pourquoi les étapes 3 et 4 comptent davantage.
  3. Activez DKIM pour votre domaine personnalisé — deux CNAME de sélecteur. M365 signe avec un défaut non aligné onmicrosoft.com tant que vous n’activez pas la signature en domaine personnalisé : publiez les CNAME selector1._domainkey et selector2._domainkey pointant vers les clés de votre locataire, puis activez la signature dans le portail Defender. Chemin de clics complet : configurer DKIM sur Microsoft 365. Si DKIM montre « pass » mais que DMARC échoue toujours, vous êtes dans le piège de la signature par défaut.
  4. Publiez DMARC, puis appliquez-le. Commencez par v=DMARC1; p=none; rua=mailto:... pour obtenir des rapports, corrigez chaque source légitime qu’il révèle, puis passez à p=quarantine et p=reject — le chemin par paliers se trouve dans corriger DMARC. C’est l’étape que la plupart des boutiques Microsoft sautent : seuls 21,7% des domaines envoyant via M365 appliquent DMARC.
  5. Retestez en lisant l’en-tête. Envoyez à une boîte outlook.com grand public, ouvrez la source du message, et confirmez spf=pass, dkim=pass, dmarc=pass et compauth=pass.
  6. Expéditeurs à fort volume : atteignez le seuil de l’Outlook grand public. Au-delà de 5 000/jour, vous avez aussi besoin d’un From/reply-to valide et surveillé, d’un désabonnement fonctionnel, et de listes propres — l’authentification lève le 5.7.515 ; le taux de plainte vous garde hors des blocages d’IP S3140/S3150. Si vous êtes déjà bloqué au niveau IP, corriger SPF/DKIM/DMARC ne lève pas le blocage : demandez une levée via le support expéditeur de Microsoft, et traitez l’authentification comme la raison pour laquelle vous n’y retournerez pas.

Pourquoi tant de domaines Microsoft 365 échouent-ils encore ?

Parce que le réglage par défaut fait la première étape pour vous et rien du reste. Parmi les 10 205 070 domaines qui autorisent spf.protection.outlook.com, 85,0% portent un SPF strict — l’enregistrement que M365 vous donne à la configuration — mais seuls 21,7% appliquent DMARC, selon le recensement Defaults.Exposed portant sur 261 086 232 domaines. M365 vous donne un SPF strict par défaut, puis la plupart des locataires s’arrêtent là — exactement la population que compauth a été conçu pour attraper (bien que toujours devant les 10,59% d’application DMARC sur l’ensemble des domaines évalués). Comparaison complète des prestataires : notre classement SPF des fournisseurs d’e-mail.

Questions fréquentes

Le 550 5.7.515 est-il une erreur Microsoft 365 ? Non. Il vient de l’Outlook.com/Hotmail grand public et cible les expéditeurs de plus de 5 000 messages/jour, appliqué depuis mai 2025. Les rejets Exchange Online professionnels utilisent d’autres codes — le plus souvent 550 5.7.509 (votre politique DMARC reject) ou 5.7.511 (expéditeur banni).

Nous avons reçu un 550 5.7.509 mais le courrier était légitime — devrions-nous abandonner p=reject ? Non — votre politique a intercepté une source non authentifiée, ce qui prouve qu’elle fonctionne. Trouvez la source dans l’en-tête ou vos rapports DMARC et donnez-lui un DKIM aligné (ou un SPF aligné). Affaiblir vers p=none rouvre l’usurpation du domaine exact pour tout le monde.

compauth=fail signifie-t-il que quelqu’un nous usurpe ? Pas nécessairement. reason=001 signifie généralement que votre propre courrier ne peut pas prouver qu’il est le vôtre — pas de DKIM aligné, pas de DMARC. Seuls 21,7% des 10 205 070 domaines envoyant via M365 appliquent DMARC (données au 2026-06-29), donc Microsoft applique des vérifications implicites à tous les autres, et le courrier légitime non authentifié les échoue aussi.

J’envoie moins de 5 000 e-mails par jour — puis-je ignorer cela ? Vous éviterez le 550 5.7.515, mais pas le dossier Indésirables : compauth s’applique à tout volume. Gmail joue la même partition — voir le guide Gmail 550 5.7.26. Les correctifs sont gratuits ; la barrière est le manque d’information, pas le coût.

Envoyez le rapport au propriétaire

Si vous corrigez l’e-mail pour quelqu’un d’autre — un client, votre patron, l’entreprise dont les factures rebondissaient — terminez le travail avec des preuves. Relancez le scan gratuit une fois le DNS stabilisé et transmettez le rapport noté. Il montre SPF, DKIM et DMARC passer au vert en langage clair, lisible par un chef d’entreprise, et c’est l’artefact dont il aura besoin la prochaine fois que le renouvellement de cyberassurance ou un questionnaire de sécurité client demande si son e-mail est authentifié. Corrigé, c’est bien ; prouvé corrigé, c’est ce qui vous fait payer et les couvre.

Vérifiez votre domaine gratuitement

Voyez quelle branche Microsoft vous fait échouer — SPF, DKIM, DMARC — en privé et réservé au propriétaire.

Vérifiez votre domaine → · Corriger DMARC → · DKIM passe mais DMARC échoue → · Comment nous notons → · Données agrégées uniquement. Données stockées et traitées dans l’UE.