Boîte à Outils Informatique
Guide

Comment résoudre SMTP 550 5.7.60 Send As

Ce guide montre comment résoudre SMTP 550 5.7.60 Send As à partir de vérifications ciblées et d’une validation explicite, sans multiplier les changements inutiles. L’utilisateur SMTP authentifié, le MAIL FROM et le header From: peuvent être trois identités différentes.

ThématiqueMicrosoft 365 →
⌚ Environ 3 min de lecture
Voir mes favoris
Microsoft 365 Intermédiaire 15-30 min

Ce guide montre comment résoudre SMTP 550 5.7.60 Send As à partir de vérifications ciblées et d’une validation explicite, sans multiplier les changements inutiles. L’utilisateur SMTP authentifié, le MAIL FROM et le header From: peuvent être trois identités différentes.

Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une sauvegarde ou un retour arrière lorsque l’action peut modifier la configuration.

Étapes à suivre

  1. 1

    Identifier les critères déterminants

    L’utilisateur SMTP authentifié, le MAIL FROM et le header From: peuvent être trois identités différentes.

  2. 2

    Recouper le contexte technique

    Une erreur Send As / sender mismatch apparaît quand le serveur autorise l’authentification mais refuse l’identité d’envoi demandée.

  3. 3

    Lecture d’un échec

    Conserver le code SMTP complet et comparer compte authentifié, adresse d’enveloppe et From visible.

  4. 4

    Écarter les erreurs de diagnostic

    Changer SPF/DKIM ne corrige pas une permission Send As manquante au niveau du serveur.

  5. 5

    Valider le résultat

    Le serveur accepte l’expéditeur attendu avec l’identité et la permission prévues. Les headers du message reçu correspondent au compte et au domaine attendus.

Commandes utiles

AUTH user@example.com
MAIL FROM:<sender@example.com>
From: Display <sender@example.com>

À retenir

  • Le Message-ID, Return-Path et Received permettent de reconstruire le chemin réel du message.
  • Tester avec une autre adresse sans conserver le code exact peut masquer le périmètre réel.
  • Les headers du message reçu correspondent au compte et au domaine attendus.
← Tous les guides
Complément technique

SMTP : distinguer authentification, enveloppe et identité visible

Repères techniques

  • L’utilisateur SMTP authentifié, le MAIL FROM et le header From: peuvent être trois identités différentes.
  • Une erreur Send As / sender mismatch apparaît quand le serveur autorise l’authentification mais refuse l’identité d’envoi demandée.
  • Le Message-ID, Return-Path et Received permettent de reconstruire le chemin réel du message.

Lecture d’un échec

Conserver le code SMTP complet et comparer compte authentifié, adresse d’enveloppe et From visible.

AUTH user@example.com
MAIL FROM:<sender@example.com>
From: Display <sender@example.com>

Pièges spécifiques

  • Changer SPF/DKIM ne corrige pas une permission Send As manquante au niveau du serveur.
  • Tester avec une autre adresse sans conserver le code exact peut masquer le périmètre réel.

Comment valider

  • Le serveur accepte l’expéditeur attendu avec l’identité et la permission prévues.
  • Les headers du message reçu correspondent au compte et au domaine attendus.

Preuves et vérifications

L’utilisateur SMTP authentifié, le MAIL FROM et le header From: peuvent être trois identités différentes. Une erreur Send As / sender mismatch apparaît quand le serveur autorise l’authentification mais refuse l’identité d’envoi demandée.

Contrôle de résultat

Le serveur accepte l’expéditeur attendu avec l’identité et la permission prévues. Les headers du message reçu correspondent au compte et au domaine attendus.

Point d’attention

Changer SPF/DKIM ne corrige pas une permission Send As manquante au niveau du serveur. Le Message-ID, Return-Path et Received permettent de reconstruire le chemin réel du message.

Concepts liés

Référence primaire : RFC 5321 — SMTP.

♡ 0