Adresse expéditeur rejetée : correctifs d’authentification et de politique

décembre 9, 2025 • février 3, 2026 • Lecture : 31 min • Views: 6

Cet article vous a aidé ?

Vous appuyez sur « envoyer » et le serveur de messagerie vous répond : « Sender address rejected ». Pas de délai. Pas de mise en file.
Rejeté. Le genre de message qui tombe sur vous juste au moment où le directeur essaie d’écrire à un client, ou quand une application
envoie des réinitialisations de mot de passe dans le vide.

Cette erreur est rarement mystérieuse. Elle est généralement simplement impitoyable. Un MTA récepteur (ou un moteur de politique devant lui)
a décidé que l’identité de l’expéditeur ne tient pas la route : mauvais domaine, authentification cassée, vérification de l’expéditeur échouée, mauvaise réputation,
ou une règle locale qui n’aime pas ce qu’elle voit. Votre travail est de prouver qui vous êtes, de façon cohérente, aux endroits où SMTP s’en préoccupe réellement.

Ce que signifie vraiment « Sender address rejected »

« Sender address rejected » est une catégorie de rejets SMTP, pas une erreur unique. La plupart du temps vous la verrez
accompagnée d’un code d’état SMTP comme :

550 (échec permanent) : boîte indisponible ou rejet pour politique
553 (souvent adresse expéditeur invalide) : « sender address rejected: not owned by user » ou similaire
501/502 (syntaxe) : adresse mal formée, guillemets incorrects, caractères interdits
554 (transaction échouée) : veto d’un moteur de politique ou filtre de contenu

L’important est l’endroit de la conversation SMTP où cela se produit. Un rejet au moment de MAIL FROM signifie que le serveur n’a pas aimé
l’expéditeur d’enveloppe (Return-Path). Un rejet au moment de RCPT TO peut encore mentionner l’expéditeur, mais c’est souvent une
règle par destinataire. Un rejet après DATA indique généralement un filtrage de contenu, une application de DKIM/DMARC, ou un problème en aval.

Un piège étonnamment fréquent : vous avez « corrigé » l’en-tête From dans votre client mail, mais le rejet concerne l’expéditeur d’enveloppe
que votre MTA ou application a réellement utilisé. SMTP s’intéresse d’abord à l’enveloppe.

Une citation à garder sur un post-it

L’espoir n’est pas une stratégie. — James Cameron

La délivrabilité des mails est un problème système. Si vous ne mesurez pas, ne vérifiez pas et n’alignez pas les identités, vous espérez seulement.

Mode opératoire de diagnostic rapide (vérifier premier/deuxième/troisième)

Quand la production brûle, vous ne commencez pas par un débat philosophique sur les RFC. Vous commencez par l’ensemble le plus petit de vérifications
qui vous dit où le rejet se produit et quelle identité est rejetée.

Premier : identifier la réponse SMTP exacte et l’étape

Récupérez le texte complet du bounce (DSN) ou la transcription SMTP depuis les logs de votre MTA/application.
Notez le code numérique (550/553/554), le code d’état étendu (comme 5.7.1) et le message.
Confirmez s’il se produit à MAIL FROM, RCPT TO ou après DATA.

Deuxième : confirmer de quel « expéditeur » il s’agit

Expéditeur d’enveloppe (MAIL FROM / Return-Path) : utilisé pour les rebonds et SPF.
Header From : ce que voient les humains ; utilisé pour l’alignement DMARC.
Nom HELO/EHLO : parfois vérifié par rapport au reverse DNS et à la politique.

Troisième : réaliser des vérifications d’alignement d’authentification

SPF : l’IP envoyant apparaît-elle dans l’enregistrement SPF du domaine ?
DKIM : le message est-il signé et la signature se valide-t-elle ?
DMARC : est-ce que SPF ou DKIM réussit et s’aligne avec le Header From ?

Quatrième : vérifier la politique locale et la vérification d’annuaire

Vérification d’expéditeur activée côté récepteur (callout verification, verify_sender) ?
Le récepteur exige-t-il que l’adresse expéditeur existe localement (commun dans des organisations verrouillées) ?
Relayezez-vous via un smart host qui réécrit les expéditeurs de façon inattendue ?

Cette séquence trouve rapidement le goulot d’étranglement parce qu’elle sépare : (1) protocole/syntaxe, (2) décalage d’identité, (3) échec d’auth,
(4) application de la politique. Ne sautez pas à « c’est SPF » quand le serveur rejette une adresse syntaxiquement invalide. Oui, j’ai vu
user@@example.com en production. Les ordinateurs sont très littéraux et parfois mesquins.

Quelques faits et un peu d’histoire (pour comprendre les bizarreries)

Le courrier électronique n’a pas été conçu pour des environnements hostiles. Il a été conçu pour des chercheurs qui, généralement, n’essayaient pas de s’usurper mutuellement.
L’écosystème moderne du « sender rejected » est un tas de rétrofits, plus la peur des entreprises, plus le pragmatisme anti-abus.

SPF a commencé au début des années 2000 comme moyen de lier des IPs d’envoi à des domaines. Il n’a jamais authentifié « la personne », seulement le chemin.
DKIM est arrivé plus tard, largement déployé vers 2007–2009, pour signer les en-têtes/corps afin que les intermédiaires ne puissent pas facilement falsifier l’identité.
DMARC (vers 2012) a lié SPF et DKIM au domaine Header From, parce que les utilisateurs ne lisent pas Return-Path et les attaquants le savent.
Split RFC 5321 vs RFC 5322 : les adresses d’enveloppe SMTP relèvent d’une spécification ; les en-têtes de message d’une autre. Beaucoup de problèmes « sender rejected » viennent de ce décalage.
Codes d’état étendus (RFC 3463) comme 5.7.1 existent pour que les humains arrêtent de deviner. Malheureusement, les fournisseurs écrivent encore de la poésie dans la partie texte.
Le backscatter est devenu un gros sujet quand les serveurs ont arrêté d’accepter les mails qu’ils ne peuvent pas livrer. Rejeter tôt est maintenant considéré comme poli et plus sûr.
Les changements de politique de Yahoo et AOL ont plusieurs fois fait évoluer l’industrie en imposant l’authentification et le throttling ; les gros fournisseurs de boîtes ont défini des standards de facto.
Les forwarders cassent SPF par conception parce qu’ils changent l’IP d’envoi. C’est pourquoi DKIM et ARC existent, et pourquoi « sender rejected » est courant dans les chaînes de forwarding.
DMARC strict est devenu courant quand le phishing s’est industrialisé. Beaucoup de domaines publient maintenant p=reject ; les échecs ne sont plus de simples « avertissements doux ».

Blague #1 : La sécurité des e-mails, c’est comme un videur de boîte — si votre pièce d’identité est floue, vous n’entrerez pas, même si vous êtes sur la pochette de l’album du groupe.

Taxonomie des rejets : quelle couche dit « non »

1) Syntaxe et validité d’adresse

Ce sont les échecs les plus nets. Le récepteur rejette parce que l’adresse expéditeur est mal formée ou viole les règles locales de syntaxe.
Cas courants : double @, caractères illégaux, nom de domaine manquant, point final, espaces non cités, ou un domaine qui ne résout pas.

2) Autorisation locale d’expéditeur (« vous ne pouvez pas envoyer en tant que ça »)

Certains récepteurs n’acceptent que des MAIL FROM correspondant à un utilisateur local existant, ou exigent une soumission authentifiée pour utiliser un domaine.
Cela apparaît sous la forme 553 5.7.1 Sender address rejected: not owned by user ou similaire.

3) Vérification d’expéditeur / contrôles par callout

Le récepteur essaie de vérifier votre adresse d’expéditeur en se connectant au MX de votre domaine et en vérifiant si l’adresse existe.
C’est fragile, lent et parfois faux (greylisting, tarpitting, échecs temporaires). Mais c’est encore utilisé.

4) Politique d’authentification (SPF/DKIM/DMARC)

Le récepteur n’aime pas vos résultats d’authentification, ou les résultats ne s’alignent pas avec ce que l’utilisateur voit dans From.
Cela peut rejeter au moment SMTP, ou accepter puis supprimer/quarantaine selon la politique.

5) Réputation et garde-fous anti-abus

« Sender address rejected » est parfois un masque poli pour « votre IP est en feu » ou « votre domaine a une mauvaise réputation ».
Certains systèmes regroupent plusieurs refus de politique sous la même raison générique.

6) Réécriture par un relais interne / smart-host

Votre application envoie à votre relais ; votre relais réécrit l’expéditeur d’enveloppe ; l’amont rejette l’adresse réécrite.
Vous déboguez l’application pendant des heures, mais le bug est dans la tuyauterie mail.

Tâches pratiques : commandes, sorties, décisions (12+)

Ci-dessous des tâches pratiques que j’exécute réellement. Chacune inclut (a) une commande, (b) une sortie réaliste, et (c) quelle décision prendre.
Exécutez-les depuis l’hôte d’envoi, le relais, ou une machine de diagnostic. Le but est de remplacer les suppositions par des preuves.

Tâche 1 : Capturer le rejet SMTP depuis les logs Postfix

cr0x@server:~$ sudo grep -E "reject:|Sender address rejected" /var/log/mail.log | tail -n 5
Jan 04 10:12:11 mailgw postfix/smtpd[18422]: NOQUEUE: reject: RCPT from app01[10.20.30.41]: 553 5.7.1 Sender address rejected: not owned by user; from=<alerts@corp.example> to=<user@partner.example> proto=ESMTP helo=<app01>
Jan 04 10:12:42 mailgw postfix/smtpd[18422]: NOQUEUE: reject: MAIL FROM<bounce@corp.example>: 550 5.1.8 Sender address rejected: Domain not found; from=<bounce@corp.example> proto=ESMTP helo=<mailgw>

Ce que cela signifie : Le premier est un rejet par politique au moment de RCPT ; le second rejette au moment de MAIL FROM en raison de la résolution du domaine.
Décision : Si c’est « not owned by user », concentrez-vous sur l’autorisation locale d’expéditeur/soumission authentifiée. Si c’est « Domain not found », corrigez le DNS du domaine expéditeur.

Tâche 2 : Reproduire avec une session SMTP manuelle (voir l’étape exacte)

cr0x@server:~$ nc -nv mx.partner.example 25
(UNKNOWN) [203.0.113.55] 25 (smtp) open
220 mx.partner.example ESMTP
EHLO mailgw.corp.example
250-mx.partner.example
250 PIPELINING
MAIL FROM:<alerts@corp.example>
553 5.7.1 Sender address rejected: not owned by user
QUIT
221 2.0.0 Bye

Ce que cela signifie : Le rejet a lieu à MAIL FROM. Ce n’est pas DMARC après DATA ; c’est une politique au niveau de l’enveloppe.
Décision : Arrêtez de bidouiller les en-têtes DKIM. Corrigez l’autorisation de l’expéditeur d’enveloppe ou utilisez une soumission authentifiée si nécessaire.

Tâche 3 : Vérifier les enregistrements MX et A/AAAA pour le domaine expéditeur

cr0x@server:~$ dig +short MX corp.example
10 mx1.corp.example.
20 mx2.corp.example.
cr0x@server:~$ dig +short A mx1.corp.example
192.0.2.10

Ce que cela signifie : Le domaine résout et possède des MX. Si c’était vide, certains récepteurs rejettent « Domain not found » ou échouent la vérification d’expéditeur.
Décision : Si MX/A sont manquants ou incorrects, corrigez le DNS avant de toucher la config mail.

Tâche 4 : Valider le reverse DNS pour l’IP d’envoi (contrôle de politique courant)

cr0x@server:~$ dig +short -x 192.0.2.25
mailgw.corp.example.
cr0x@server:~$ dig +short A mailgw.corp.example
192.0.2.25

Ce que cela signifie : Reverse DNS forward-confirmed (FCrDNS) correspond. Beaucoup de récepteurs n’iront pas jusqu’à rejeter sans cela, mais certains le feront.
Décision : Si le reverse DNS manque ou est en discordance, corrigez PTR/A pour l’aligner. C’est une crédibilité pas chère.

Tâche 5 : Inspecter l’enregistrement SPF du domaine utilisé dans MAIL FROM

cr0x@server:~$ dig +short TXT corp.example
"v=spf1 ip4:192.0.2.0/24 include:_spf.relayvendor.example -all"

Ce que cela signifie : SPF est présent et strict (-all). Bien—sauf si votre IP d’envoi n’est pas couverte.
Décision : Si votre IP de sortie ou votre fournisseur de relais n’est pas inclus, mettez à jour SPF ou envoyez via un relais autorisé.

Tâche 6 : Évaluer SPF pour une IP spécifique avec un outil local

cr0x@server:~$ sudo apt-get -y install spfquery >/dev/null
cr0x@server:~$ spfquery -ip 192.0.2.25 -sender alerts@corp.example -helo mailgw.corp.example
pass SPF check for alerts@corp.example: 192.0.2.25 is authorized to use 'corp.example'

Ce que cela signifie : SPF passe pour le domaine de l’expéditeur d’enveloppe.
Décision : Si SPF échoue, soit (a) corriger SPF, (b) changer le domaine MAIL FROM pour un domaine qui autorise l’expéditeur, ou (c) envoyer via le relais approprié.

Tâche 7 : Confirmer quel expéditeur d’enveloppe est réellement utilisé (inspection de la file)

cr0x@server:~$ mailq | head -n 12
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
7C8F21A03B      2142 Fri Jan  4 10:20:01  alerts@corp.example
                                         user@partner.example

Ce que cela signifie : La file montre l’expéditeur d’enveloppe. Si vous attendiez no-reply@corp.example mais voyez autre chose, vous avez trouvé la divergence.
Décision : Corrigez le paramètre MAIL FROM de l’application ou les règles de réécriture d’expéditeur de votre MTA.

Tâche 8 : Vérifier la réécriture d’expéditeur Postfix qui pourrait vous saboter

cr0x@server:~$ sudo postconf | grep -E "sender_canonical|smtp_generic_maps|masquerade|canonical_maps"
sender_canonical_maps = hash:/etc/postfix/sender_canonical
smtp_generic_maps = hash:/etc/postfix/generic
masquerade_domains = corp.example

Ce que cela signifie : Les maps canonical et generic peuvent réécrire les expéditeurs. La mascarade peut aussi changer les domaines.
Décision : Si la réécriture d’expéditeur pointe vers un domaine sans DNS/auth correct, soit mettez à jour l’auth/DNS soit arrêtez la réécriture.

Tâche 9 : Inspecter le contenu de la map canonical (attraper la réécriture « utile »)

cr0x@server:~$ sudo postmap -q alerts@corp.example /etc/postfix/sender_canonical
alerts@corp.mail.invalid

Ce que cela signifie : Vous réécrivez vers un domaine qui sent le « quelqu’un a fait ça lors d’une migration ».
Décision : Supprimez/ajustez la correspondance. Puis recompiles les maps et rechargez Postfix.

Tâche 10 : Recharger Postfix en toute sécurité après des modifications de maps

cr0x@server:~$ sudo postmap /etc/postfix/sender_canonical
cr0x@server:~$ sudo postfix check
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ systemctl is-active postfix
active

Ce que cela signifie : Maps compilées, sanity check de la config, service rechargé sans redémarrage.
Décision : Si postfix check se plaint, arrêtez et corrigez avant de recharger. Un reload MTA cassé pendant un incident est une tragédie évitable.

Tâche 11 : Vérifier que DKIM signe (exemple OpenDKIM)

cr0x@server:~$ sudo journalctl -u opendkim --since "10 minutes ago" | tail -n 5
Jan 04 10:25:10 mailgw opendkim[912]: 7C8F21A03B: DKIM-Signature field added (s=mail, d=corp.example)
Jan 04 10:25:10 mailgw opendkim[912]: 7C8F21A03B: signed message

Ce que cela signifie : Les messages sont signés pour d=corp.example avec le sélecteur s=mail.
Décision : Si vous ne voyez pas de signature, corrigez le wiring du milter ou la configuration des clés/tables avant d’accuser DMARC.

Tâche 12 : Vérifier l’enregistrement DKIM dans le DNS pour le sélecteur

cr0x@server:~$ dig +short TXT mail._domainkey.corp.example
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Ce que cela signifie : Le sélecteur existe en DNS. S’il manque, les récepteurs échoueront DKIM.
Décision : Publiez la bonne clé publique, confirmez qu’il n’y a pas de surprises de DNS split-horizon, et attendez le TTL si nécessaire.

Tâche 13 : Vérifier la politique DMARC et les attentes d’alignement

cr0x@server:~$ dig +short TXT _dmarc.corp.example
"v=DMARC1; p=reject; rua=mailto:dmarc@corp.example; aspf=s; adkim=s"

Ce que cela signifie : Alignement strict pour SPF et DKIM, et politique de rejet. Les récepteurs seront sévères quand l’alignement échoue.
Décision : Si vous utilisez des émetteurs tiers, assurez-vous qu’ils signent avec votre domaine (ou un sous-domaine aligné) ou utilisez des domaines d’enveloppe alignés.

Tâche 14 : Confirmer que le côté récepteur réalise une vérification d’expéditeur (Postfix côté récepteur)

cr0x@server:~$ sudo postconf | grep -E "reject_unknown_sender_domain|reject_unverified_sender|verify_sender"
smtpd_sender_restrictions = reject_unknown_sender_domain, reject_unverified_sender
address_verify_map = btree:/var/lib/postfix/verify

Ce que cela signifie : reject_unverified_sender déclenche la vérification par callout/caching. Cela peut rejeter des expéditeurs légitimes lors de problèmes DNS/MX transitoires.
Décision : Si vous administrez le récepteur et voyez des faux positifs, envisagez de supprimer reject_unverified_sender ou de le restreindre finement.

Tâche 15 : Inspecter le comportement du cache de vérification d’adresse (diagnostiquer les faux rejets)

cr0x@server:~$ sudo postmap -s /var/lib/postfix/verify | head
sender@corp.example OK
bounce@corp.example DEFER
missing@corp.example REJECT

Ce que cela signifie : Le cache mémorise les résultats. « DEFER » peut devenir « REJECT » selon la politique et la logique de retry.
Décision : Si vous voyez beaucoup de DEFER/REJECT pour des domaines valides lors de pannes, diminuez la vérification ou augmentez les timeouts avec précaution.

Tâche 16 : Vérifier si vous êtes rejeté à cause de la politique sur le nom HELO/EHLO

cr0x@server:~$ sudo postconf | grep -E "smtpd_helo_restrictions|reject_invalid_helo_hostname|reject_unknown_helo_hostname"
smtpd_helo_restrictions = reject_invalid_helo_hostname, reject_unknown_helo_hostname

Ce que cela signifie : Les récepteurs font parfois respecter la cohérence du HELO. Si votre application dit EHLO localhost depuis une IP publique, vous ressemblerez à du spam.
Décision : Définissez un hostname correct dans votre MTA et dans la bibliothèque SMTP de votre application si celle-ci contrôle le HELO.

Correctifs d’authentification : SPF, DKIM, DMARC, alignement

Commencez par le modèle d’identité : « Quel domaine affirmons-nous ? »

Votre mail a au moins trois identités qui comptent opérationnellement :

Domaine d’enveloppe (MAIL FROM) : utilisé par SPF et pour les rebonds.
Domaine Header From : utilisé par l’alignement DMARC, et c’est ce que voient les utilisateurs.
Domaine d= DKIM : le domaine de signature, que DMARC peut aligner avec Header From.

« Sender address rejected » vient souvent du fait que ces éléments ne sont pas synchronisés. Le schéma propre est :

MAIL FROM utilise bounce@corp.example ou bounces.mail.corp.example avec un SPF incluant votre infrastructure d’envoi.
Header From est corp.example (ou une politique de sous-domaine cohérente).
DKIM signe avec d=corp.example (ou sous-domaine aligné) et un sélecteur stable.

SPF : faites-le correct, gardez-le petit, et évitez les jeux d’includes

SPF vérifie l’IP connectante par rapport à l’enregistrement SPF du domaine MAIL FROM (ou du domaine HELO dans certains cas).
Le récepteur demande : « Cette IP est-elle autorisée à envoyer pour ce domaine ? »

Conseils pratiques :

Privilégiez des domaines d’enveloppe dédiés pour le bulk/l’email applicatif (ex. bounce.mail.corp.example) afin de pouvoir changer l’infra sans toucher l’apex corporate.
Gardez le nombre de requêtes DNS bas. SPF impose une limite de 10 lookups pour les mécanismes qui causent des requêtes DNS (include, a, mx, etc.). La dépasser entraîne un permerror, que beaucoup de récepteurs traitent comme un échec.
N’utilisez -all que si vous le pensez. Si vous publiez -all et oubliez un expéditeur, vous venez de créer votre propre panne.

DKIM : signez ce que vous envoyez, et empêchez les middleboxes de le modifier

DKIM vérifie que certains en-têtes et le corps ont été signés par un domaine ayant publié la clé publique en DNS.
Il survit mieux au forwarding que SPF, car le forwarding change les IPs mais pas nécessairement le contenu.

Ce qui casse DKIM en pratique :

Relais qui ajoutent des pieds de page ou réécrivent le contenu (mentions légales, pixels de tracking insérés par des gateways).
Mauvais wrapping de lignes ou normalisation de contenu par des « appliances » de sécurité.
Signer les mauvais en-têtes, ou en signer trop peu.
Rotation des clés sans publier le nouveau sélecteur suffisamment longtemps.

DMARC : l’alignement est où les rêves meurent

DMARC ne se contente pas que SPF passe pour un domaine quelconque et que DKIM passe pour un domaine quelconque.
Il exige qu’au moins l’un d’eux passe et s’aligne avec le domaine visible dans l’en-tête From.

Règles d’alignement :

Alignement relax : les sous-domaines peuvent s’aligner (ex. mail.corp.example s’aligne avec corp.example).
Alignement strict : doit correspondre exactement ; les sous-domaines ne s’alignent pas sauf s’ils sont identiques.

Si vous publiez aspf=s et adkim=s, vous optez pour une vie où chaque émetteur tiers doit être configuré très intentionnellement.
C’est acceptable. Faites juste attention à ne pas le faire un vendredi.

Quand les rejets se produisent au moment de MAIL FROM, DMARC n’est peut-être pas le coupable

Beaucoup de gens blâment DMARC parce que c’est l’acronyme le plus récent. Mais « Sender address rejected » au moment de MAIL FROM est souvent :

le domaine ne résout pas
le récepteur refuse l’utilisation non authentifiée d’un domaine
la vérification par callout dit que l’adresse expéditeur est invalide
une politique locale comme « n’accepter que les expéditeurs de notre liste de partenaires »

L’application de DMARC a lieu typiquement après la réception du message (après DATA), bien que certaines gateways pré-vérifient la réputation et la politique plus tôt.
Traduction : n’adaptez pas trop votre diagnostic à votre norme préférée.

Correctifs de politique : vérification d’expéditeur, allowlists, réécriture et limites de débit

Corrigez la réécriture de l’expéditeur d’enveloppe avec intention, pas de l’optimisme

La réécriture est puissante et dangereuse. C’est ainsi que l’on migre des domaines, standardise des adresses et route les rebonds.
C’est aussi la façon d’envoyer accidentellement du courrier en tant qu’un domaine que vous ne contrôlez plus.

Si vous devez réécrire :

Réécrivez vers un domaine que vous contrôlez, avec un DNS correct (MX/A/PTR quand pertinent).
Assurez-vous que SPF est rédigé pour le domaine MAIL FROM réécrit.
Assurez-vous que DKIM/DMARC restent cohérents avec le Header From.

Vérification d’expéditeur côté récepteur : ça sonne bien, puis ça vous ruine l’après-midi

« Vérifier que l’adresse expéditeur existe avant d’accepter le mail » est séduisant. Ça réduit les adresses usurpées et peut couper le spam.
Ça crée aussi des dépendances entre MTAs qui n’ont jamais été conçus pour être fiables en temps réel.

Modes de défaillance :

Votre MX est temporairement lent : le récepteur décide que votre expéditeur est invalide.
Greylisting : le récepteur interprète mal le refus temporaire comme « l’adresse n’existe pas ».
Limites de débit : les probes de vérification ressemblent à de l’abus et se font throttler.
Comportement catch-all : la vérification est inutile, mais ajoute latence et risque.

Allowlisting : utilisez-le chirurgicalement, documentez-le et supprimez-le quand c’est fini

Si la politique d’un partenaire est trop stricte et que vous devez rétablir le flux maintenant, une allowlist peut être un pansement pragmatique.
Mais les pansements prennent racine. Faites-les limités dans le temps et observables.

Soumission vs relais : cessez de laisser les apps parler au port 25 sur Internet

Pour les expéditeurs corporate, utilisez la soumission authentifiée (typiquement port 587 avec SMTP AUTH) vers un relais contrôlé.
Ce relais devrait être le seul à parler au monde extérieur. Cela simplifie la politique, réduit l’usurpation accidentelle,
et rend votre histoire SPF/DKIM cohérente.

Blague #2 : SMTP AUTH, c’est comme un lecteur de badge—sans ça, le bâtiment suppose que vous êtes un raton laveur avec un laptop.

Erreurs fréquentes (symptôme → cause → correction)

1) « 553 Sender address rejected: not owned by user »

Symptôme : Rejet immédiat au moment de MAIL FROM avec « not owned by user » ou « sender unknown ».
Cause : Le récepteur exige une soumission authentifiée pour utiliser ce From/domaine d’enveloppe, ou applique la propriété locale de l’expéditeur.
Correction : Utilisez le port 587 avec SMTP AUTH vers le récepteur (si c’est votre serveur), ou relayezez via le smart host authentifié de votre organisation. Si vous administrez le récepteur, assouplissez la politique « owned by user » pour les sources de confiance.

2) « 550 5.1.8 Sender address rejected: Domain not found »

Symptôme : Le domaine MAIL FROM est rejeté parce qu’il « n’existe pas ».
Cause : Le domaine de l’expéditeur d’enveloppe manque de DNS, a une délégation cassée, ou utilise un domaine retiré lors d’une migration.
Correction : Définissez MAIL FROM sur un domaine résoluble. Ajoutez A/MX selon le cas. N’utilisez pas de domaines internes uniquement sur l’internet public.

3) « 550 5.7.1 SPF fail / Sender rejected »

Symptôme : Le récepteur cite explicitement un échec SPF et rejette ou met en quarantaine.
Cause : L’IP connectante n’est pas autorisée dans SPF pour le domaine d’enveloppe ; ou SPF est en permerror à cause de trop de lookups.
Correction : Ajoutez les IPs/includes d’envoi corrects ; aplatissez SPF si nécessaire ; ou changez le domaine d’enveloppe pour un domaine qui correspond à l’infrastructure d’envoi.

4) « 550 5.7.1 DMARC policy reject »

Symptôme : Message rejeté après DATA ou accepté puis renvoyé, en citant DMARC.
Cause : Le domaine Header From a p=reject ; ni SPF ni DKIM ne passent avec alignement.
Correction : Assurez-vous que DKIM signe en alignement avec Header From, ou que SPF passe et s’aligne (domaine d’enveloppe aligné). Si un tiers envoie, configurez-le pour qu’il signe avec votre domaine ou utilisez un sous-domaine délégué aligné.

5) « Sender rejected » uniquement lorsqu’on envoie depuis une application, pas depuis un client mail

Symptôme : Outlook/Apple Mail fonctionne ; l’application échoue avec sender rejected.
Cause : L’application utilise un chemin SMTP différent, souvent direct-to-MX via le port 25 sans auth, mauvais HELO, et un expéditeur d’enveloppe étrange.
Correction : Forcez l’application à utiliser le même relais authentifié que les utilisateurs (587), définissez un HELO/hostname cohérent, et définissez un expéditeur d’enveloppe stable.

6) « Sender address rejected » apparaît après l’activation d’une gateway de sécurité ou d’un ajout de pied de page

Symptôme : DKIM commence à échouer et les rejets DMARC augmentent après le déploiement d’une gateway.
Cause : La gateway modifie les corps/en-têtes après la signature DKIM, invalidant la signature.
Correction : Déplacez la signature DKIM vers le dernier saut egress (après modification), ou configurez la gateway pour éviter de modifier le contenu signé.

7) Rejets sporadiques d’expéditeur pendant des pannes

Symptôme : Ça marche la plupart du temps ; échoue lors de problèmes DNS ou de pics de charge mail.
Cause : Le récepteur utilise la vérification par callout d’expéditeur ou des contrôles DNS stricts avec timeouts agressifs.
Correction : Si vous contrôlez le récepteur, ajustez ou retirez la vérification d’expéditeur. Si vous êtes l’expéditeur, assurez la résilience DNS et évitez les schémas qui déclenchent l’échec de vérification.

Listes de contrôle / plan pas à pas

Pas à pas : restaurer le flux mail en sécurité (mode incident)

Obtenir les preuves : capturez le code SMTP, l’étape et le texte depuis les logs ou un DSN.
Confirmer l’expéditeur d’enveloppe depuis les logs de file (pas ce que votre application affiche).
Confirmer l’existence DNS pour le domaine d’enveloppe : A/AAAA et/ou MX, et que les résolveurs y accèdent.
Confirmer l’IP de sortie et qu’elle correspond à votre egress prévu (pas de NAT surprise).
Vérifier SPF pour le domaine d’enveloppe et autoriser l’IP/relai de sortie.
Vérifier la signature DKIM sur le MTA d’egress et que le sélecteur existe en DNS.
Vérifier la politique DMARC sur le domaine Header From ; assurez-vous que la stratégie d’alignement convient à vos expéditeurs.
Corriger la réécriture d’expéditeur qui pointe vers des domaines retirés/invalide.
Rediriger temporairement via un relais connu bon si besoin pour stabiliser la production pendant que vous réparez DNS/auth proprement.
Valider avec un test contrôlé (un destinataire chez le domaine affecté) et surveiller les logs.
Documenter la cause racine et supprimer les allowlists/exceptions d’urgence.

Checklist de durcissement (pour éviter de revivre ça)

Un chemin de sortie sanctionné pour les applications (soumission à un relais), pas direct-to-MX.
Domaines d’enveloppe dédiés pour le bulk/l’email applicatif, avec SPF limité et DNS stable.
Signature DKIM au dernier saut egress, avec rotation de clés planifiée et gestion des sélecteurs.
Politique DMARC progressive (none → quarantine → reject) avec surveillance, surtout après acquisitions et intégration de fournisseurs.
Reverse DNS aligné avec le nom HELO ; HELO non défini sur « localhost » ou des IDs de conteneurs aléatoires.
Contrôle des changements pour toute règle de réécriture et maps de transport. Traitez-les comme de la configuration de routage, parce que c’en est.

Trois micro-histoires du monde de l’entreprise

Micro-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a migré d’un relais on-prem vers un service mail cloud. Le plan de migration couvrait les boîtes utilisateurs et les changements MX entrants.
Tout le monde s’est félicité. Les graphiques semblaient normaux. Puis le système d’alerte a cessé d’envoyer des mails aux équipes d’astreinte.

L’hypothèse erronée était simple : « Si Outlook marche, SMTP marche. » Outlook utilisait la soumission authentifiée vers le service cloud.
Le système d’alerte était une vieille application qui envoyait directement vers les MX des partenaires via le port 25, avec un expéditeur d’enveloppe dans l’ancien domaine on-prem.
Ce domaine existait encore dans la mémoire de quelqu’un, pas dans le DNS.

Les partenaires récepteurs rejetaient au moment de MAIL FROM avec « Domain not found ». Pendant ce temps, les utilisateurs internes ne remarquaient rien parce que le courrier interne n’utilisait pas ce chemin.
L’équipe applicative a changé l’en-tête From, l’a vu dans les logs, et a déclaré victoire—alors que l’expéditeur d’enveloppe restait cassé.

La correction a été ennuyeuse et immédiate : routez l’application via le relais sanctionné sur le port 587 avec SMTP AUTH, et définissez un domaine d’enveloppe stable
qui avait DNS et SPF. La vraie correction a été culturelle : « le mail » n’est pas un système unique, ce sont plusieurs systèmes qui interagissent. Votre client n’est pas votre application.

Micro-histoire 2 : L’optimisation qui a mal tourné

Une équipe sécurité a activé la vérification par callout d’expéditeur sur leur gateway entrante. L’argument était propre : moins d’expéditeurs usurpés, moins de spam dans la file,
moins de backscatter. Ça a marché pendant une semaine. Puis le helpdesk a commencé à imiter une attaque par déni de service.

Des fournisseurs qui envoyaient des factures ont commencé à échouer sporadiquement. Certains jours tout allait bien ; d’autres jours, « Sender address rejected » partout.
La gateway vérifiait les expéditeurs en se connectant au MX de l’expéditeur et en émettant des RCPT TO—à l’échelle, avec des timeouts agressifs.

Beaucoup de MTA modernes se défendent contre le harvesting d’adresses en rejetant temporairement des destinataires inconnus, ou par greylisting au premier contact.
La gateway a interprété les échecs temporaires comme la preuve que l’adresse expéditeur était invalide et a mis en cache « REJECT ». Félicitations : vous vous êtes optimisé
en rejetant des mails commerciaux légitimes.

Le rollback a été douloureux mais nécessaire. L’approche finale a été plus moderne : se reposer sur SPF/DKIM/DMARC, la réputation et le scanning de contenu,
et réserver la vérification d’adresse à des cas restreints où vous contrôlez les deux extrémités. La vérification par sondage de l’internet n’est pas de la « sécurité » ; c’est de la devinette avec des sockets.

Micro-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande organisation avait un processus de changement strict pour les identités d’envoi : chaque nouveau SaaS devait utiliser un sous-domaine délégué
(comme notify.mail.corp.example) avec son propre SPF et clés DKIM sous le contrôle de l’entreprise. C’était ennuyeux. C’était de la paperasse.
Les gens se plaignaient, bien sûr.

Puis un fournisseur a eu un incident et a commencé à envoyer depuis des plages IP inattendues. Les récepteurs ont commencé à rejeter ces messages parce que SPF n’était plus valide.
Cela aurait pu devenir un vrai problème de marque et de support client. À la place, l’impact a été limité : seul le sous-domaine du fournisseur a été affecté.

Ils ont désactivé temporairement l’envoi de ce sous-domaine en resserrant SPF, tandis que le reste du courrier corporate continuait de circuler.
Parce que les identités étaient segmentées, ils n’ont pas eu à toucher l’enregistrement SPF de l’apex ou les clés DKIM, et n’ont pas risqué de casser le courrier des dirigeants.

La pratique ne semblait pas héroïque au moment de sa conception. Elle semblait bureaucratique. Pendant l’incident, elle ressemblait à des ceintures de sécurité.
Les meilleurs gains opérationnels sont souvent ceux que personne ne remarque jusqu’au jour où ils comptent vraiment.

Diagnostic approfondi : mapper les messages d’erreur à la bonne correction

Comprendre la différence : expéditeur d’enveloppe vs en-tête From

Si vous ne retenez qu’une chose : l’expéditeur d’enveloppe n’est pas le même que l’en-tête From.
L’expéditeur d’enveloppe fait partie de la transaction SMTP ; il est utilisé pour les rebonds et SPF. L’en-tête From fait partie du message ;
il est utilisé pour l’affichage utilisateur et l’alignement DMARC.

Beaucoup de systèmes vous laissent volontiers définir un joli en-tête From tout en gardant un expéditeur d’enveloppe absurde.
Les récepteurs qui appliquent des politiques d’expéditeur rejetteront l’absurdité. Et ils ont raison.

Les codes d’état étendus comptent

Si vous pouvez obtenir le code d’état étendu (la partie 5.X.Y), faites-le. Il vous dit la catégorie :

5.1.x : problèmes d’adressage/statut (domaine introuvable, mauvaise adresse)
5.7.x : problèmes de sécurité/politique/auth (SPF/DKIM/DMARC, relais refusé, expéditeur non autorisé)

Le texte fourni par les fournisseurs varie. Les codes sont la chose la plus proche d’une honnêteté que vous obtiendrez.

Correctifs pratiques par environnement (quoi changer, où)

Postfix : boutons courants qui causent « sender rejected »

smtpd_sender_restrictions : peut inclure reject_unknown_sender_domain, reject_unverified_sender, ou des services de politique personnalisés.
smtpd_recipient_restrictions : peut cacher des contrôles d’expéditeur dans des services de politique ou des access maps.
sender_canonical_maps / smtp_generic_maps / masquerading : peuvent réécrire les expéditeurs en domaines invalides.
smtpd_helo_restrictions : peut rejeter sur la validité du HELO ; certains logs l’expriment encore comme sender rejected.

Exchange / Microsoft 365 : schémas courants

Dans les écosystèmes Microsoft, « sender rejected » correspond souvent à :

essayer d’envoyer en tant qu’une adresse pour laquelle vous n’avez pas la permission « Send As »
restrictions de connecteur qui exigent la soumission authentifiée ou des IPs spécifiques
application de DMARC en amont lors de l’utilisation d’un domaine personnalisé avec politique stricte

Opérationnellement, la correction est la même : identifiez quelle identité est rejetée (enveloppe vs header), puis alignez autorisations, connecteurs et authentification.

Fournisseurs de services mail et expéditeurs SaaS

Les plateformes SaaS aiment définir des en-têtes From qui ressemblent à votre domaine tout en utilisant leurs propres domaines d’enveloppe.
Cela peut marcher—jusqu’à ce que votre politique DMARC soit stricte, ou que le récepteur exige l’alignement ou que « le domaine doit exister ».

La démarche professionnelle : donnez à chaque fournisseur un sous-domaine délégué explicite avec SPF et DKIM contrôlés. Ne les laissez pas profiter gratuitement de votre domaine apex.

FAQ

1) « Sender address rejected » est-ce toujours un problème SPF/DKIM/DMARC ?

Non. Si cela se produit à MAIL FROM et mentionne « domain not found » ou « not owned by user », il peut s’agir de DNS ou d’autorisation locale.
L’authentification est courante, pas universelle.

2) Quelle est la façon la plus rapide de distinguer l’expéditeur d’enveloppe du Header From ?

L’expéditeur d’enveloppe apparaît dans la transcription SMTP (MAIL FROM) et dans les messages en file comme « Sender ». Header From est dans les en-têtes du message.
Si vous avez une copie reçue, regardez Return-Path (enveloppe) versus From: (en-tête).

3) Pourquoi un récepteur rejetterait-il l’adresse expéditeur avant de voir le contenu du message ?

Par politique. Certains systèmes bloquent tôt les domaines inconnus/mauvais pour économiser des ressources et réduire les abus. Ils peuvent aussi faire des callouts de vérification d’expéditeur.
Les rejets précoces sont normaux dans la conception anti-abus moderne.

4) Mon SPF passe, mais je suis toujours rejeté. Comment ?

SPF peut réussir pour le domaine d’enveloppe tandis que DMARC échoue si le Header From ne s’aligne pas. Aussi, les récepteurs peuvent rejeter pour réputation,
syntaxe, autorisation d’expéditeur, ou politique HELO/PTR même avec un SPF qui passe.

5) DKIM casse-t-il quand on ajoute un pied de page de disclaimer ?

Ça peut. Si le pied de page est inséré après la signature DKIM, la signature devient invalide. La correction est de signer après la modification
(egress final) ou d’arrêter de modifier le contenu signé.

6) Devons-nous activer la vérification par callout d’expéditeur sur notre gateway entrante ?

Généralement non. Cela crée des dépendances fragiles et des faux rejets, surtout avec le greylisting et les défenses anti-harvest.
Utilisez SPF/DKIM/DMARC plus la réputation et le scanning de contenu. Réservez la vérification pour des cas internes restreints.

7) Pourquoi le forwarding provoque-t-il des rejets d’expéditeur ?

Le forwarding change l’IP d’envoi, donc SPF peut échouer. DKIM peut survivre, sauf si le forwarder modifie le message.
DMARC peut échouer si ni SPF ni DKIM ne passent avec alignement. C’est pourquoi certains mails transférés se font rejeter sous des politiques strictes.

8) Peut-on régler ça en changeant seulement l’adresse From visible ?

Parfois, mais souvent non. Si le récepteur rejette au moment de MAIL FROM, changer l’en-tête From n’aidera pas.
Corrigez l’expéditeur d’enveloppe et l’authentification associée.

9) Et si le récepteur a tort et rejette des expéditeurs légitimes ?

Ça arrive. Fournissez-leur la transcription SMTP, vos preuves DNS/auth, et demandez quelle politique spécifique a déclenché (SPF/DMARC/sender verify).
Si vous contrôlez votre chemin d’envoi, vous pouvez généralement vous adapter plus vite que convaincre un partenaire de changer sa gateway.

10) Devons-nous utiliser un sous-domaine séparé pour les mails transactionnels ?

Oui, dans la plupart des organisations. Cela isole la réputation et la politique, simplifie SPF, et permet de changer de fournisseur sans toucher le domaine principal.
C’est un classique « ennuyeux mais correct ».

Conclusion : prochaines étapes à faire aujourd’hui

« Sender address rejected » est le signal que l’identité et la politique sont désalignées quelque part entre votre application,
votre relais, votre DNS et les règles du récepteur. Traitez-le comme un incident de routage : localisez le saut exact et l’identité exacte,
puis corrigez le plus petit contrat cassé.

Récupérez une transcription SMTP propre et déterminez l’étape du rejet.
Confirmez l’expéditeur d’enveloppe utilisé sur le fil (pas dans votre UI).
Corrigez d’abord les problèmes d’existence DNS (MX/A, PTR/HELO cohérence).
Alignez SPF pour le domaine d’enveloppe avec les IPs d’egress réelles.
Assurez-vous que DKIM signe au dernier egress et que les sélecteurs sont publiés en DNS.
Vérifiez la politique DMARC et l’alignement ; segmentez les fournisseurs en sous-domaines délégués.
Retirez la vérification d’expéditeur côté récepteur risquée sauf si vous en avez vraiment besoin.

Ensuite, notez-le. Pas en roman postmortem—juste assez pour que la prochaine personne n’« améliore » pas l’en-tête From et n’annonce pas l’incident résolu.