« Outlook » peut désigner une application de bureau, une boîte aux lettres grand public ou l'environnement Microsoft 365 d'une organisation. Ce ne sont pas des champs d’application politiques interchangeables. Commencez par le service de réception et le diagnostic réels avant d'utiliser une liste de contrôle à volume élevé pour expliquer un message ayant échoué.
Identifier le service consommateur et ses exigences actuelles
L'article de support actuel de Microsoft pour 550 5.7.515 décrit Outlook .com et les services grand public associés, notamment Hotmail, Live.com et MSN. Il identifie un expéditeur de gros volumes comme envoyant 5 000 messages ou plus à ces services en utilisant le même domaine dans le visible. 5322.De adresse. Son texte de support indique que les deux SPF et DKIM doit réussir, et qu'un publié DMARC politique d'au moins p=none et un pass DMARC sont requis. Conseils pour Microsoft 550 5.7.515.
L'annonce mise à jour prévoit que l'application du rejet commencera le 5 mai 2025. Son plan initial réservé aux courriers indésirables est supprimé ; ne considérez pas ce paragraphe remplacé comme la politique de réponse actuelle. Annonce mise à jour par Microsoft.
L’annonce précédente décrivait le volume quotidien et en utilisait « plus de 5 000 ». Ne construisez pas d’exemption autour du libellé des limites : les directives de soutien actuelles en utilisent 5 000 ou plus. Vous ne devez pas non plus inventer une période de réinitialisation ou une règle de classification permanente à partir de cette page d'assistance. Enregistrez la version et le diagnostic de réception réel lors de l’interprétation d’un cas.
Séparer le succès du protocole de la porte du fournisseur
Références : RFC 9989 §4.4, RFC 9989 §5.3.5.
DMARC peut passer par un succès aligné Signature DKIM même lorsque SPF échoue. Ce résultat de protocole ne satisfait pas à une exigence distincte selon laquelle les deux mécanismes sous-jacents doivent être satisfaits. À l’inverse, SPF et DKIM peuvent tous deux passer pour des domaines sans rapport avec le visible From et laisser DMARC échouer. Conservez les trois résultats et les identités derrière eux.
Pour un message direct généré par le service, enregistrez l'adresse IP d'envoi, expéditeur d'enveloppe domaine, Du domaine, DKIM d= domaine et sélecteur. Vérifiez le DNS actuel et le message final signé, pas seulement un écran de configuration. Utilisez les noms de protocole réels : SMTP MAIL FROM est l'identité de l'enveloppe RFC 5321 , tandis que le From visible appartient à RFC 5322 .
Lisez le rejet comme preuve, pas comme script de réparation
Références : RFC 8601 §5.
Un rejet 550 5.7.515 indique que le domaine de l'expéditeur ne répond pas au niveau d'authentification requis. Conservez l’intégralité des identifiants de diagnostic, d’heure, de destinataire concerné et de message. Ne répondez pas en ajoutant tous les fournisseurs disponibles au SPF ou en désactivant Application DMARC sans comprendre l’identité défaillante.
Comparez les flux concernés et non affectés. Un service de facturation peut disposer d'une configuration de signature personnalisée correcte, tandis qu'un service de campagne signe toujours uniquement avec son propre domaine. S'il s'agit d'un transitaire ou d'un autre intermédiaire, conserver l'itinéraire et les transformations. Les hypothèses du publipostage peuvent ne pas expliquer un chemin indirect, et une copie Authentication-Results la ligne ne remplace pas la preuve d’un destinataire fiable.
Travailler sur un diagnostic synthétique
Références : RFC 9989 §5.3.5.
Imaginez un message contrôlé dont le résultat SPF est échec, dont le résultat DKIM est réussite avec alignement, et dont le résultat DMARC est réussi. Le résultat DMARC est cohérent en interne. Conformément aux exigences de volume élevé déclarées par Microsoft, la défaillance SPF doit encore être réparée. Il s’agit d’un exemple logique, et non d’un rejet de Microsoft.
L'action suivante consiste à déterminer si l'expéditeur de l'enveloppe évalué a autorisé l'adresse IP de connexion réelle. Après une correction approuvée, testez à nouveau par le même itinéraire prévu et conservez le nouveau résultat. Ne réutilisez pas l’ancien pass comme preuve d’un changement de message ou d’itinéraire.
Gardez les dossiers d'entreprise sur leur propre chemin de preuve
Un locataire Microsoft 365 peut appliquer ses propres stratégies et connecteurs entrants. Un destinataire utilisant l'application Outlook ne soumet pas son organisation au portail exact de l'article consommateur. Pour les cas d'entreprise, collectez le contexte de diagnostic et de stratégie du locataire au lieu de supposer que 5.7.515 explique chaque réponse 5.7.x.
Terminez avec le service concerné, le domaine de l'expéditeur, les résultats du mécanisme observé et l'itinéraire corrigé. Aucun test de boîte aux lettres Microsoft en direct n'est revendiqué ici, et la conformité de l'authentification reste distincte du placement dans la boîte de réception.