Exigences d'Outlook pour les expéditeurs depuis mai 2025 et le rejet 550 5.7.515
Le message de rejet 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level signifie qu'Outlook.com a refusé votre message parce que votre domaine n'a pas passé les contrôles SPF, DKIM et DMARC que Microsoft exige des expéditeurs à gros volume. La correction se trouve dans votre DNS et dans la configuration des systèmes qui envoient vos e-mails, pas dans le contenu du message.
Microsoft a annoncé ces règles sur son blog Microsoft Defender for Office 365 en avril 2025, avec une application à partir du 5 mai 2025. Elles concernent Outlook.com, le service grand public de Microsoft, qui couvre les adresses outlook.com, hotmail.com et live.com.
Les exigences reprennent de près ce que Gmail et Yahoo ont introduit en 2024 : un domaine correctement configuré pour un fournisseur a donc généralement fait l'essentiel du chemin pour les autres.
Ce que Microsoft exige
Selon l'annonce, les domaines qui envoient plus de 5 000 e-mails par jour vers Outlook.com doivent remplir 3 conditions :
- SPF doit réussir pour le domaine d'envoi, avec un enregistrement DNS qui liste précisément les adresses IP et les hôtes autorisés.
- DKIM doit réussir, pour valider l'intégrité et l'authenticité du message.
- DMARC doit être publié avec au moins
p=noneet être aligné avec SPF ou DKIM (de préférence les deux, selon Microsoft).
Microsoft énumère aussi des bonnes pratiques d'hygiène pour les gros expéditeurs et se réserve le droit de filtrer ou de bloquer ceux qui les ignorent :
- Une adresse From ou Reply-To valide, qui correspond au vrai domaine d'envoi et peut recevoir des réponses.
- Une option de désabonnement claire et fonctionnelle pour les e-mails marketing et en masse.
- La suppression régulière des adresses invalides et le traitement des rebonds.
- Des objets exacts, aucun en-tête trompeur et des destinataires qui ont accepté de recevoir vos messages.
Dossier Courrier indésirable ou rejet
L'annonce initiale indiquait que les e-mails non conformes seraient d'abord envoyés dans le dossier Courrier indésirable. Microsoft a mis à jour la publication le 29 avril 2025 : les messages qui ne respectent pas les exigences d'authentification sont rejetés avec l'erreur 550 5.7.515, à compter du 5 mai 2025 comme prévu à l'origine (source).
En pratique, c'est utile : un rejet apparaît dans vos journaux d'envoi et vos rapports de rebonds, alors qu'un déplacement discret vers les indésirables peut passer inaperçu longtemps.
Pourquoi un domaine légitime reçoit 5.7.515
Les causes habituelles sont des lacunes de configuration, rien de malveillant :
Un outil d'envoi sans DKIM pour votre domaine. Les plateformes de newsletter, les CRM et les outils de facturation signent souvent avec leur propre domaine, sauf si vous ajoutez leurs enregistrements DKIM au vôtre.
SPF valide pour le prestataire, pas pour vous. Beaucoup de services utilisent leur propre adresse de retour, si bien que SPF réussit pour bounce.vendor.net. Sans DKIM aligné, DMARC échoue.
Aucun enregistrement DMARC. Microsoft exige au moins p=none. L'absence d'enregistrement _dmarc suffit à échouer.
SPF au-delà de sa limite de requêtes. SPF autorise au maximum 10 requêtes DNS (RFC 7208, section 4.6.4). Ajoutez un service de trop et SPF renvoie une erreur pour chaque message.
Un changement DNS récent. Une migration vers un nouveau fournisseur DNS ou un nouvel hébergeur de messagerie qui a oublié un sélecteur DKIM ou l'include SPF d'un service.
Comment trouver la cause
Commencez par votre DNS :
dig +short TXT yourcompany.com | grep spf1
dig +short TXT _dmarc.yourcompany.com
dig +short TXT selector1._domainkey.yourcompany.com
Identifiez ensuite le système qui a envoyé le message rejeté. Le rebond contient généralement les en-têtes d'origine. Envoyez alors un test depuis ce même système vers une adresse Outlook.com que vous contrôlez et examinez l'en-tête Authentication-Results. Microsoft explique comment le lire dans sa documentation sur les en-têtes de message. Vous cherchez :
spf=pass smtp.mailfrom=yourcompany.com
dkim=pass header.d=yourcompany.com
dmarc=pass header.from=yourcompany.com
Si smtp.mailfrom ou header.d affiche le domaine du prestataire au lieu du vôtre, le problème vient de l'alignement. Si vous voyez dkim=none, le système ne signe pas du tout.
Comment corriger
- Publiez un enregistrement DMARC si vous n'en avez pas :
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com. - Dans chaque outil d'envoi, configurez DKIM avec votre propre domaine (l'outil fournit les enregistrements CNAME ou TXT à ajouter).
- Lorsque l'outil permet une adresse de retour personnalisée, faites-la pointer vers l'un de vos sous-domaines pour que SPF soit aussi aligné.
- Fusionnez SPF en un seul enregistrement, retirez les services que vous n'utilisez plus et restez sous 10 requêtes.
- Renvoyez un test vers Outlook.com et vérifiez que les 3 contrôles réussissent.
- Lorsque les rapports DMARC montrent que tout le courrier légitime passe, évoluez vers
p=quarantinepuisp=reject.
Microsoft oriente les expéditeurs vers son portail d'assistance aux expéditeurs Outlook pour obtenir de l'aide. Notre guide SPF, DKIM et DMARC détaille chaque enregistrement.
Une courte liste de contrôle
- SPF valide, un seul enregistrement, moins de 10 requêtes.
- Signature DKIM avec votre domaine dans chaque système qui envoie des e-mails.
- DMARC publié, au moins
p=none, aligné avec SPF ou DKIM. - Journaux de rebonds vérifiés pour 5.7.515 après tout changement DNS ou de fournisseur.
- Un désabonnement fonctionnel et des listes propres pour les e-mails marketing.
La place de Datahorses
Datahorses surveille chaque jour depuis l'extérieur les enregistrements DNS liés à votre messagerie : un sélecteur DKIM supprimé, un enregistrement SPF cassé ou une politique DMARC affaiblie sont repérés avant de se transformer en rebonds. Un spécialiste examine chaque changement et envoie à votre développeur les enregistrements exacts à corriger. Découvrez ce que nous surveillons, comment nous traitons un constat ou le tableau de bord d'exemple.
Plus d’articles
Fichiers .env, .git et sauvegardes exposés : comment les secrets fuient des sites web
Un seul fichier oublié à la racine du site peut livrer des mots de passe de base de données et des clés d'API. Voici comment les fichiers .env, .git et de sauvegarde se retrouvent exposés et comment vérifier votre site.
Prise de contrôle de sous-domaine : comment un enregistrement DNS oublié devient le site de quelqu'un d'autre
Un sous-domaine qui pointe encore vers un service cloud supprimé peut être revendiqué par quiconque crée ce service. Voici comment cela arrive et comment vérifier votre DNS.
PHP2Shell : quelles versions de PHP sont corrigées et comment contrôler la vôtre
Le projet PHP a corrigé 2 failles critiques le 21 octobre 2026. Voici les versions qui contiennent le correctif, comment voir ce qu'annonce votre serveur et quoi demander à votre hébergeur.