Ce que signifie le message
Le retour de Microsoft ressemble à ceci :
550 5.7.515 Access denied, sending domain example.com does not meet the required authentication level.En clair : accès refusé, le domaine expéditeur n'atteint pas le niveau d'authentification exigé. Le code 550 indique une erreur définitive. L'e-mail n'a pas été remis et votre serveur ne fera pas de nouvelle tentative.
Le domaine visé est celui de l'adresse d'expéditeur visible, c'est-à-dire ce qui suit le @ dans le champ «De». L'erreur ne dit rien sur le contenu de votre message. Elle signifie seulement que Microsoft n'a pas pu confirmer suffisamment que l'e-mail vient bien de votre domaine.
Trois notions reviennent sans cesse :
- SPF : une entrée DNS qui liste les serveurs autorisés à envoyer des e-mails pour votre domaine.
- DKIM : une signature numérique que votre système de messagerie ajoute à chaque e-mail. La clé correspondante se trouve dans votre DNS.
- DMARC : une entrée DNS qui relie SPF et DKIM à l'adresse d'expéditeur et définit ce qu'il advient des e-mails qui échouent.
Qui est concerné
En avril 2025, Microsoft a annoncé de nouvelles règles pour les expéditeurs à gros volume. Elles s'appliquent depuis mai 2025 aux services de messagerie grand public : Outlook.com, Hotmail, Live.com et MSN. Au départ, Microsoft voulait d'abord classer ces e-mails dans le dossier Courrier indésirable. Peu avant le lancement, Microsoft a décidé de les refuser avec le code 5.7.515.
Dans son blog, Microsoft qualifie de gros expéditeurs les domaines qui envoient plus de 5000 e-mails par jour. L'article d'aide sur l'erreur parle de 5000 messages ou plus vers les services grand public, tous avec le même domaine dans l'adresse d'expéditeur. C'est donc votre domaine qui compte, pas le logiciel. Newsletter, boutique en ligne et comptabilité s'additionnent si tous envoient avec @example.com.
Beaucoup de PME restent sous ce seuil. La correction vaut quand même la peine : Microsoft recommande expressément les mêmes réglages à tous les expéditeurs, et Google impose des exigences comparables pour Gmail depuis février 2024.
Ce que Microsoft exige précisément
Selon Microsoft, les e-mails des gros expéditeurs doivent remplir tous ces points :
- SPF réussit : le serveur d'envoi est autorisé dans l'entrée SPF.
- DKIM réussit : l'e-mail porte une signature valide.
- DMARC est publié : au minimum avec la règle
p=none, donc «observer seulement». - DMARC réussit : SPF ou DKIM, idéalement les deux, sont alignés sur l'adresse d'expéditeur.
L'alignement signifie que le domaine confirmé par SPF ou DKIM doit correspondre au domaine de l'adresse d'expéditeur. Un sous-domaine comme news.example.com est accepté. Un exemple : vous envoyez depuis info@example.com. Si votre outil de newsletter signe avec d=example.com, DKIM est aligné. S'il signe avec son propre domaine, DKIM réussit techniquement, mais n'aide pas pour DMARC.
Important : p=none suffit comme règle. Le contrôle lui-même doit toutefois réussir. Une entrée DMARC seule ne corrige donc pas l'erreur si SPF ou DKIM ne sont pas en ordre.
La solution pas à pas
- Lire le retour : notez de quel système provenait l'e-mail refusé, par exemple l'outil de newsletter, la boutique ou la comptabilité. Certains retours indiquent aussi les résultats des contrôles, comme
Spf=FailouDkim=Fail. - Contrôler le domaine : saisissez votre domaine dans le test de domaine gratuit. Vous voyez d'un coup d'œil si SPF, DKIM et DMARC existent et sont valides.
- Compléter SPF : il ne doit exister qu'une seule entrée TXT avec
v=spf1, et elle doit contenir toutes les voies d'envoi. Exemple pour Microsoft 365 et un outil de newsletter :v=spf1 include:spf.protection.outlook.com include:[valeur de votre outil de newsletter] -all. Attention à la limite de dix requêtes DNS : Erreur SPF «too many DNS lookups» : pourquoi dix requêtes doivent suffire. - Activer DKIM dans chaque système : dans Microsoft 365, vous ajoutez deux entrées CNAME comme
selector1._domainkey.example.com, puis vous activez la signature. Le guide correspondant : Microsoft 365 : les e-mails arrivent en spam, DKIM est souvent désactivé. Dans les outils de newsletter et les boutiques, la fonction s'appelle souvent «authentifier votre propre domaine». Le service vous fournit les entrées DNS. - Créer DMARC : ajoutez une entrée TXT nommée
_dmarc, par exemple avec la valeurv=DMARC1; p=none; rua=mailto:rapports-dmarc@example.com. L'adresse aprèsrua=reçoit les rapports des destinataires. Il ne doit exister qu'une seule entrée de ce type. - Tester l'effet : depuis chaque système, envoyez un e-mail vers une boîte Outlook.com à vous. Affichez-y la source du message ou ses en-têtes. Dans la ligne
Authentication-Results, vous devriez voirspf=pass,dkim=passetdmarc=pass, ainsi queheader.d=example.com. - Renvoyer les e-mails refusés : Microsoft ne les remet pas après coup. Attendez que la modification DNS soit active. Selon le réglage, cela prend de quelques minutes à quelques heures.
Contrôle de domaine gratuit
Votre adresse d’entreprise est-elle protégée ?
Saisissez votre domaine ou votre adresse e-mail. Le résultat s’affiche aussitôt ici, avec un feu tricolore et une note de A à F.
Vous avez ouvert un lien vers un résultat. La vérification ne démarre qu’avec votre clic, toujours avec l’état actuel.
Protection des données : si vous saisissez une adresse e-mail, nous ne transmettons que le domaine ; la partie avant le @ ne quitte pas votre navigateur. Nous utilisons le domaine uniquement pour ce contrôle d’entrées DNS publiques et ne l’enregistrons pas en clair ; nous n’enregistrons pas le résultat. Nous n’enregistrons votre adresse IP que sous forme d’empreinte et au maximum un jour, pour freiner les abus.
Le contrôle rapide repose sur les données DNS publiques au moment de la requête et ne remplace pas un contrôle complet ; sans garantie.
Garder un œil en continu plutôt que vérifier une fois :
Réserver un entretien gratuitSurveiller 14 jours gratuitementPlutôt avec de l’aide ? Demander la mise en place par nos soins- Sans engagement
- Sans carte de crédit
- Se termine de lui-même après 14 jours
Demande sans engagement par e-mail · prix sur demande
La suite
- Votre programme de messagerie ouvre une demande préparée avec votre domaine. Ajoutez votre nom et envoyez-la.
- Nous vous recontactons et discutons avec vous ou votre partenaire informatique des entrées nécessaires (SPF, DKIM, DMARC) et du prix de la mise en place.
- La mise en place nécessite un accès à la gestion DNS de votre domaine. Nous convenons avec vous de la transmission – merci de ne jamais nous envoyer de mots de passe par e-mail.
- Si vous le souhaitez, DomainRadar surveille ensuite votre domaine en continu et vous prévient lorsque quelque chose change.
Aucun programme de messagerie ne s’ouvre ? Écrivez-nous en indiquant votre domaine à info@domainradar.ch.
Bon à savoir : la protection empêche qu’on usurpe exactement votre domaine. Contre les adresses qui ressemblent à la vôtre, confirmez toujours par téléphone les changements de paiement.
Tous les contrôles
Contrôle rapide à partir des entrées DNS publiques. La surveillance continue vérifie en plus les certificats, les listes de blocage et vos rapports DMARC.
Votre résultat en PDF
Sous forme de rapport, à conserver ou à transmettre à votre informatique.
Gratuit et sans compte : vous confirmez votre adresse par e-mail, puis vous pouvez vous désinscrire à tout moment.
Erreurs typiques
- Aucune entrée DMARC : SPF et DKIM sont en ordre, mais
_dmarcmanque. Pour Microsoft, cela ne suffit pas. - DMARC au mauvais endroit : certains éditeurs DNS ajoutent automatiquement le domaine. Si vous saisissez
_dmarc.example.com, vous obtenez alors_dmarc.example.com.example.com. Saisissez seulement_dmarc. - Deux entrées SPF ou deux entrées DMARC : dans les deux cas, le contrôle devient invalide. Fusionnez-les en une seule.
- Outil de newsletter sans domaine propre : l'outil signe avec son domaine. DKIM réussit, mais n'est pas aligné, et SPF contrôle alors aussi le domaine de l'outil.
- Nouveau système oublié : un nouveau CRM ou système de tickets envoie avec votre adresse, mais ne figure pas dans SPF et n'a pas de DKIM.
- Transferts : quand un e-mail est transféré par un autre serveur, SPF échoue souvent. DKIM survit en général au transfert. Une raison de plus d'activer DKIM partout.
À ne pas confondre avec d'autres erreurs
- 550 5.7.26 chez Gmail : Gmail refuse parce que ni SPF ni DKIM ne réussissent. Cause et solution sont proches : Erreur 550 5.7.26 «unauthenticated email» : signification et solution.
- 550 5.7.509 chez Microsoft : l'e-mail échoue à DMARC et votre propre entrée indique
p=reject. C'est votre propre règle qui bloque, pas la règle pour les gros expéditeurs : «Rejected due to DMARC policy» : votre propre domaine bloque vos propres e-mails. - Messages avec adresse IP et liste noire : il s'agit alors de la réputation du serveur d'envoi, pas des entrées de votre domaine.
- L'e-mail arrive, mais dans le Courrier indésirable : ce n'est pas un retour. La cause tient le plus souvent à la réputation, au contenu ou à l'absence de lien de désinscription.
Une fois SPF, DKIM et DMARC stables, vous pourrez durcir DMARC plus tard. La marche à suivre : DMARC de p=none à quarantine et reject : quand est-ce sûr ?.
Ce que DomainRadar fait contre l'erreur 5.7.515
DomainRadar contrôle en continu SPF, DKIM et DMARC de votre domaine et reçoit les rapports DMARC via sa propre adresse de rapport. Outlook.com envoie lui aussi de tels rapports. Vous voyez pour chaque système d'envoi s'il réussit et s'il est aligné, et vous recevez une alerte si le taux d'e-mails conformes chute ou si une source inconnue apparaît. Vous pouvez tester DomainRadar gratuitement pendant 14 jours.
Questions fréquentes
Que signifie l'erreur 550 5.7.515 chez Outlook ?
Microsoft a refusé votre e-mail parce que le domaine expéditeur ne remplit pas les exigences en matière de SPF, DKIM et DMARC. La règle vise les expéditeurs à gros volume vers Outlook.com, Hotmail, Live.com et MSN. L'e-mail n'a pas été remis.
Nous envoyons moins de 5000 e-mails par jour. Devons-nous quand même agir ?
Selon Microsoft, le refus avec 5.7.515 vise les gros expéditeurs. Microsoft recommande toutefois les mêmes réglages à tous. Avec SPF, DKIM et DMARC fonctionnels, vos e-mails arrivent aussi plus sûrement chez Gmail et d'autres fournisseurs.
DMARC avec p=none suffit-il ?
Comme règle, oui : Microsoft exige au minimum p=none. Le contrôle DMARC doit cependant réussir, donc SPF ou DKIM doivent correspondre à l'adresse d'expéditeur. Une entrée seule, sans SPF ni DKIM fonctionnels, ne suffit pas.
Cela aide-t-il si le destinataire nous ajoute aux expéditeurs approuvés ?
Non. Microsoft précise expressément que la liste des expéditeurs approuvés ne lève pas ce contrôle. La solution se trouve du côté du domaine expéditeur.
En combien de temps la correction fait-elle effet ?
Dès que les entrées DNS modifiées sont consultables, en général après quelques minutes à quelques heures. Vérifiez avec un e-mail de test vers une boîte Outlook.com que SPF, DKIM et DMARC affichent «pass». Les e-mails refusés doivent ensuite être renvoyés.
Cela concerne-t-il aussi les e-mails vers des entreprises sous Microsoft 365 ?
Microsoft cite la règle pour les gros expéditeurs pour les services grand public comme Outlook.com et Hotmail. Les boîtes d'entreprise peuvent refuser pour d'autres raisons, par exemple avec 5.7.509 en cas de règle DMARC p=reject. Des entrées propres aident dans tous les cas.
Comment DomainRadar vous aide
DomainRadar vérifie en continu SPF, DKIM et DMARC de vos domaines, analyse automatiquement les rapports DMARC et vous dit clairement quel canal d’envoi manque et ce qu’il faut faire.
Le test de domaine gratuit vous montre en une minute où en est votre domaine aujourd’hui.
Le contrôle de domaine reste gratuit. Ensuite, vous testez DomainRadar avec toutes les fonctions pendant 14 jours – sans carte de crédit, l’essai se termine de lui-même.