Email : relais authentifié vs envoi direct — choisissez l’approche qui ne vous fait pas bloquer

La décision : envoi direct vs relais authentifié

Envoi direct (votre MTA livre directement aux MX destinataires)

Dans un modèle d’envoi direct, votre serveur exécute un MTA (Postfix/Exim/etc.) et se connecte aux échangeurs de mail (MX) destinataires sur Internet. Vous contrôlez toute la session SMTP, la file, les nouvelles tentatives, la politique TLS et le débit. Vous héritez aussi de la charge complète de la réputation et de l’ingénierie de délivrabilité.

Utilisez l’envoi direct quand :

• Vous pouvez vous engager à exploiter le service mail en production (supervision, gestion des abus, gestion de la réputation).
• Vous avez besoin d’un contrôle élevé sur le routage, les nouvelles tentatives, les politiques personnalisées et le réglage par domaine.
• Vous avez un volume d’envoi stable et pouvez chauffer correctement les IP.
• Vous pouvez assigner une IP dédiée propre (ou un pool géré) avec rDNS correct.

Évitez l’envoi direct quand :

• Vous êtes sur des instances cloud avec IP qui changent fréquemment.
• Vous ne contrôlez pas rDNS/PTR (commun sur des VPS grand public et certains réseaux internes).
• Vous envoyez un faible volume mais avez besoin d’une haute délivrabilité (la réputation ne « se stabilise » jamais).
• Vous n’avez pas de plan pour les plaintes spam, les rebonds et les feedback loops.

Relais authentifié (votre serveur soumet le mail à un fournisseur)

Dans un modèle de relais authentifié, vos systèmes envoient le mail à un smarthost via la soumission SMTP (généralement port 587, parfois 465) avec authentification (SASL) et TLS. Le fournisseur de relais s’occupe ensuite de livrer aux MX destinataires. Ce fournisseur peut être un ESP (service d’e‑mail transactionnel), votre suite corporate (Microsoft 365 / Google Workspace) ou une couche de relais interne.

Utilisez le relais authentifié quand :

• Vous voulez de la délivrabilité sans devenir une entreprise de délivrabilité d’e‑mails.
• Vous avez besoin d’une connectivité sortante prévisible depuis des réseaux verrouillés (587 fonctionne quand 25 est bloqué).
• Vous voulez que la réputation soit gérée par une partie qui a du personnel dédié.
• Vous avez besoin d’audit consolidé, de limitation de débit, de détection d’abus et de traitement des rebonds.

Évitez le relais authentifié quand :

• Vous ne pouvez pas tolérer la dépendance à une infrastructure tierce d’envoi.
• Vous avez des contraintes strictes de résidence des données et le relais ne peut pas les respecter.
• Vous avez besoin de certains comportements SMTP que le relais n’autorisera pas (rare, mais ça arrive).

Mon biais opérationnel

Si vous exploitez un produit SaaS typique, des notifications d’application internes, des réinitialisations de mot de passe, des factures et des alertes : utilisez un relais authentifié. C’est ennuyeux. Ça réduit le rayon d’impact. Ça vous évite les listes noires quand le script d’un stagiaire décide de « tester » en envoyant la table entière des clients deux fois.

L’envoi direct est pour les équipes qui choisissent explicitement de posséder le mail comme infrastructure, y compris tous les cas limites pénibles. On peut le faire correctement. Mais si vous le traitez comme « un autre daemon », il traitera votre entreprise comme « un spammeur de plus ».

Faits et historique qui comptent encore en 2026

• SMTP a précédé le spam en tant que problème industriel. Le SMTP ancien supposait des pairs coopérants ; les filtres modernes supposent que vous pourriez mentir jusqu’à preuve du contraire.
• Le blocage de l’egress sur le port 25 est devenu courant quand les FAI ont lutté contre les botnets. Beaucoup de réseaux bloquent encore le 25 sortant ; les ports de soumission (587/465) sont la voie pragmatique.
• SPF est arrivé parce qu’usurper l’expéditeur d’enveloppe était trivial. C’est un pansement de l’ère DNS qui compte toujours parce que les récepteurs l’utilisent pour modéliser l’intention et la responsabilité.
• DKIM a été conçu pour protéger les en‑têtes contre les modifications et prouver la responsabilité du domaine. Ce n’est pas du chiffrement ; c’est une signature qui survit au renvoi (parfois).
• DMARC existe parce que SPF et DKIM seuls ne suffisaient pas. L’alignement et la politique permettent aux domaines de dire « rejetez ceci si ce n’est pas vraiment nous ».
• Les expéditeurs en masse ont poussé des systèmes de réputation sophistiqués. L’idée « l’IP est bonne/mauvaise » a évolué vers la réputation de domaine, la réputation du contenu, les signaux d’engagement et les taux de plainte.
• rDNS/PTR reste un filtre grossier mais efficace. Un PTR manquant ne vous bloquera pas toujours, mais il dégrade souvent la confiance et augmente la possibilité d’être mis en spam.
• TLS est devenu une attente, puis un signal. STARTTLS opportuniste est le minimum. Certains récepteurs vous notent pour des suites de chiffrement modernes et un comportement TLS stable.
• Le greylisting a entraîné les MTAs à réessayer correctement. Un comportement de retry négligent est toujours un signe d’infrastructure de faible qualité et peut nuire à la délivrabilité.

Modèles de délivrance et où chacun échoue

Modèle A : App → MTA local → direct vers MX destinataire

C’est le classique. Votre application parle SMTP à localhost, Postfix met en file, Postfix fait des requêtes DNS pour MX, puis livre vers l’extérieur. Les points de rupture incluent DNS, connectivité sortante, réputation, rDNS, négociation TLS et limites de débit chez le destinataire.

Mode d’échec reconnaissable : ça marche pour les petits domaines, échoue pour les gros. Les grands fournisseurs ont les systèmes de réputation les plus stricts et la meilleure télémétrie.

Modèle B : App → MTA local → relais smarthost authentifié

Votre appli parle toujours SMTP localement, mais Postfix relaie tout à un fournisseur avec AUTH et TLS. Les points de rupture passent de « peut‑on atteindre chaque MX sur terre ? » à « pouvons‑nous nous authentifier, respecter les limites du fournisseur, et aligner l’identité ? »

L’échec sournois : le mail est accepté par le relais mais n’arrive jamais. C’est là que vous devez comprendre que « accepté » n’est pas « livré ». C’est « mis en file ailleurs ». Il vous faut des IDs de message et un moyen de corréler les événements.

Modèle C : App → API du fournisseur (HTTP) → le fournisseur livre

Ce n’est pas le sujet principal, mais c’est important car les équipes y dérivent souvent. L’envoi via API supprime votre MTA local mais augmente le couplage fournisseur. Ça peut être excellent. Ça peut aussi casser de manière étrange quand votre appli déploie un nouveau modèle qui déclenche des filtres de contenu.

Réalité hybride

La plupart des entreprises finissent hybrides :

• Courrier transactionnel via relais authentifié (réinitialisations, reçus).
• Alertes internes via envoi direct vers MX corporate (ou relais interne).
• Mail marketing via une pipeline ESP dédiée.

Cette séparation est saine. Elle signifie aussi que vous devez être explicite sur le chemin utilisé par chaque message. Sinon vous routiez accidentellement les réinitialisations par le pool IP marketing et découvrez de nouvelles définitions du mot « incident ».

Identité : SPF, DKIM, DMARC, alignement, et pourquoi « pass » peut quand même échouer

SPF : autorisation pour l’expéditeur d’enveloppe

SPF vérifie si l’IP d’envoi est autorisée à envoyer au nom du domaine dans le RFC5321.MailFrom (envelope‑from). Il est évalué via des enregistrements TXT DNS.

Ce que SPF fait bien : empêche l’usurpation occasionnelle et donne aux récepteurs un signal propre quand votre infrastructure est stable.

Ce que SPF fait mal : le renvoi. Si un message est retransmis par un autre serveur, SPF peut échouer parce que l’IP du relais n’est pas dans votre enregistrement SPF.

DKIM : signature pour en‑têtes/corps

DKIM signe des en‑têtes sélectionnés et le corps avec une clé privée ; les récepteurs vérifient via une clé publique dans DNS. Il survit mieux au renvoi que SPF parce que la signature reste vérifiable—sauf si le message est modifié.

Piège opérationnel courant : un système en aval modifie le message (injection de pied de page, repli de lignes, conversion MIME), cassant la signature DKIM. Le récepteur voit « DKIM fail », et votre histoire d’alignement DMARC devient moche.

DMARC : alignement et politique

DMARC pose la question : le domaine dans le From visible s’aligne‑t‑il avec SPF ou DKIM (ou les deux), et que faire si ce n’est pas le cas ? La politique s’exprime en none/quarantine/reject.

L’alignement surprend souvent les équipes. Vous pouvez avoir SPF pass et DKIM pass, et quand même échouer DMARC si ils ne sont pas alignés avec le domaine From. Ce n’est pas que le récepteur soit méchant. C’est votre configuration qui est incohérente.

Le relais authentifié change qui « possède » l’IP d’envoi

Avec l’envoi direct, l’IP de votre serveur est évaluée par rapport au SPF de votre domaine. Avec un relais authentifié, les IPs du fournisseur de relais comptent, et votre SPF doit les autoriser. DKIM peut être signé par vous (préférable) ou par le fournisseur (acceptable si correctement aligné).

Une citation à garder sur un post‑it

« L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

La délivrabilité des mails est l’endroit type où cela s’applique. Si vous « espérez » que votre IP cloud sera digne de confiance, vous choisissez des interruptions via dossier spam.

Réalité d’infrastructure : réputation d’IP, rDNS, TLS, files, limites de débit

La réputation d’IP n’est pas un jugement moral, c’est un modèle statistique

Les récepteurs notent votre IP (et votre domaine) en fonction des taux de plainte, des taux de rebond, des hits sur pièges à spam, des patterns d’envoi et des signaux de contenu. L’envoi direct signifie que vous portez cette note. Le relais authentifié signifie que vous empruntez le modèle de note de quelqu’un d’autre—et leurs contraintes.

L’envoi direct signifie aussi que vous héritez des péchés du passé de votre IP. Dans les environnements cloud, la réutilisation d’IP est réelle. Vous pouvez obtenir une IP avec un historique, et votre premier e‑mail sera traité comme un invité revenu qui avait cassé le mobilier la fois précédente.

Reverse DNS (PTR) est de l’hygiène basique

Beaucoup de récepteurs attendent qu’une IP ait un enregistrement PTR qui correspond à un enregistrement DNS direct (A/AAAA) et qui semble raisonnable. Ce n’a pas besoin d’être poétique. Ça doit être cohérent et sous contrôle.

TLS : pas besoin de perfection, besoin de cohérence

Le TLS opportuniste est la base. Certains récepteurs pénalisent un « TLS étrange », comme des chaînes cassées, des hostnames non concordants ou des suites de chiffrement faibles. En utilisant un relais authentifié, vous obtenez généralement un TLS moderne par défaut et moins de raisons de déboguer OpenSSL à 3h du matin.

Files et retries font partie de la livraison

Un MTA qui réessaie correctement et décroît intelligemment ressemble à une infrastructure légitime. Un MTA qui réessaie agressivement ressemble à un botnet. L’un est livré. L’autre est bloqué.

Les limites de débit ne sont pas personnelles

Les gros fournisseurs limitent le débit des nouveaux expéditeurs ou des expéditeurs à faible réputation. Votre travail n’est pas de « combattre » ces limites ; c’est de concevoir autour :

• Filez et réessayez gracieusement.
• Envoyez d’abord les mails critiques (réinitialisations, alertes de connexion).
• Chauffez les IPs et domaines au lieu de déverser tout le volume d’un coup.

Blague courte #1 : La délivrabilité des e‑mails, c’est comme les rencontres—si vous arrivez à l’improviste depuis une adresse louche, ne soyez pas surpris d’être ignoré.

Trois mini‑histoires d’entreprise (réalistes, anonymisées, douloureuses)

Mini‑histoire 1 : L’incident causé par une fausse hypothèse

L’équipe exploitait une petite flotte de serveurs applicatifs et a décidé de « faire simple » : Postfix sur chaque nœud, envoi direct vers Internet, même configuration partout. Ils utilisaient les IPs sortantes par défaut du cloud. Personne ne gérait le rDNS. Personne ne gérait la réputation. Mais les e‑mails de staging arrivaient, et la première semaine de production aussi, donc tout semblait correct.

Puis un événement de montée en charge a remplacé un groupe de nœuds. Ces remplacements ont apporté des IPs différentes. Du jour au lendemain, les e‑mails de réinitialisation ont commencé à rebondir pour les grands fournisseurs avec des déferrals 4xx vagues et des rejets 5xx occasionnels. Le support a vu un pic : les utilisateurs ne pouvaient pas se connecter, ne pouvaient pas réinitialiser leurs mots de passe, et ont blâmé « l’appli ». L’appli était innocente. Le chemin mail ne l’était pas.

L’hypothèse erronée était subtile : « une IP est une IP. » En mail, une IP est un objet de réputation avec un historique. Les nouvelles IPs signifiaient une nouvelle réputation, et la réputation était froide ou mauvaise. Le comportement d’envoi de la flotte est passé de stable à chaotique, et les systèmes récepteurs ont réagi comme toujours : protéger d’abord les utilisateurs.

La correction a été opérationnelle, pas héroïque. Ils sont passés à un relais authentifié avec des IPs stables, ont ajouté l’autorisation SPF pour le relais, activé la signature DKIM alignée sur le domaine From, et ont arrêté de prétendre que l’autoscaling cloud est compatible avec la délivrabilité DIY par défaut. L’envoi direct aurait pu fonctionner, mais il aurait exigé des IPs de sortie dédiées, le contrôle du rDNS, du warming, de la supervision, et une personne responsable. Ils n’avaient pas cela, donc ils n’auraient pas dû choisir ce modèle.

Mini‑histoire 2 : L’optimisation qui a mal tourné

Une autre société utilisait un relais authentifié, mais voulait réduire la latence de leur pipeline de notifications. Quelqu’un a remarqué que chaque serveur applicatif établissait fréquemment de nouvelles sessions TLS vers le relais. Ils ont donc « optimisé » en réutilisant davantage les connexions, en augmentant la concurrence et en batchant plus d’e‑mails par connexion.

Cela a fonctionné—jusqu’à ce que ça ne fonctionne plus. Le fournisseur de relais a commencé à brider. Pas parce que le volume global était plus élevé, mais parce que le pattern d’envoi a changé : rafales, pics et comportements de connexion qui ressemblaient à de l’automatisation abusive. Certains messages ont commencé à se mettre en file côté fournisseur, puis à être livrés en retard. L’appli retournait toujours « sent » parce que le relais avait accepté la soumission. Les utilisateurs ont subi des retards et des doublons quand l’appli a relancé au mauvais niveau.

Le retour de bâton est classique : optimisation pour la micro‑latence sans comprendre le contrat macro du système. La soumission SMTP n’est pas un RPC basse‑latence. C’est un pipeline store‑and‑forward avec des politiques et des contrôles de réputation. Le sur‑réglage du comportement de connexion a modifié l’empreinte de l’expéditeur et déclenché des garde‑fous.

La récupération a impliqué de réduire la concurrence selon les recommandations du fournisseur, d’ajouter des sémantiques de retry correctes (ne pas relancer si vous avez déjà reçu un 250 + ID de file), et d’implémenter l’idempotence au niveau applicatif pour que le même événement ne puisse pas se transformer en plusieurs e‑mails pendant une période de throttling transitoire.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation orientée finance envoyait des factures et des notifications de compte. Ils utilisaient un relais authentifié pour le mail sortant, mais faisaient aussi tourner une petite instance Postfix interne comme passerelle de soumission pour les applications. La passerelle faisait une chose peu sexy mais extrêmement bien : elle estampillait chaque message avec un en‑tête de corrélation et consignait la correspondance entre l’ID de requête applicative, l’ID de file SMTP et l’ID de message du fournisseur de relais.

Un mardi, un grand fournisseur de boîtes mail a commencé à différer le mail issu du pool partagé de leur fournisseur de relais en raison d’un problème de réputation localisé affectant de nombreux clients. Ce n’était pas la faute de l’organisation, et ils ne pouvaient pas le corriger. Mais ils pouvaient l’expliquer. En quelques minutes, l’astreinte a extrait la liste des IDs de message affectés, récupéré les codes de réponse SMTP, et produit une mise à jour client précise : « Messages soumis entre l’heure A et l’heure B retardés en raison de déferrals 4xx ; pas de perte de données ; nouvelles tentatives en cours. »

Le support a arrêté de deviner. Le Produit a arrêté d’accuser « les e‑mails qui sont instables ». La direction n’a pas demandé des changements de config au hasard. Le fournisseur a résolu le problème de réputation, et la livraison a repris. La raison pour laquelle tout est resté calme est que l’organisation traitait le mail comme un pipeline de production : traçabilité, logs et limites de retry claires.

Blague courte #2 : Rien ne construit la confiance comme une file bien étiquetée—sans cela, vous criez juste dans le vide SMTP.

Tâches pratiques avec commandes : vérifier, prouver, décider

Ce sont des tâches que j’exécute réellement pendant les incidents. Chacune inclut : une commande, un extrait de sortie réaliste, ce que ça signifie, et la décision suivante.

Task 1: Confirm which path you’re using (direct vs relay)

cr0x@server:~$ postconf -n | egrep '^(relayhost|smtp_sasl_auth_enable|myhostname|myorigin|mydestination)'
relayhost = [smtp.relay.example]:587
smtp_sasl_auth_enable = yes
myhostname = app-01.prod.example.net
myorigin = /etc/mailname
mydestination = localhost

Meaning: relayhost is set to a submission endpoint on 587 and SASL auth is enabled. You are relaying, not delivering direct.

Decision: Troubleshoot provider-side throttling/auth/TLS and identity alignment, not outbound port 25 to arbitrary MX.

Task 2: If direct send, confirm outbound port 25 is not blocked

cr0x@server:~$ nc -vz gmail-smtp-in.l.google.com 25
Connection to gmail-smtp-in.l.google.com 25 port [tcp/smtp] succeeded!

Meaning: Network allows outbound TCP/25 to at least one major MX.

Decision: If delivery still fails, pivot to reputation/TLS/rDNS/content rather than basic connectivity.

Task 3: Test submission to the relay with STARTTLS and AUTH capability

cr0x@server:~$ openssl s_client -starttls smtp -connect smtp.relay.example:587 -servername smtp.relay.example -crlf
...
250-smtp.relay.example
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-AUTH PLAIN LOGIN
250 HELP

Meaning: The relay supports STARTTLS and AUTH methods. Good baseline.

Decision: If Postfix can’t authenticate, it’s likely credentials/SASL config, not the relay being down.

Task 4: Check DNS for SPF on the From domain

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.relay.example -all"
"google-site-verification=..."

Meaning: SPF authorizes the relay provider via include and uses -all (hard fail for unauthorized IPs).

Decision: If you’re direct-sending from your own IPs, this SPF is wrong; add your IPs or switch to relay intentionally.

Task 5: Validate DKIM public key record exists

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtu6..."

Meaning: DKIM selector s1 is published.

Decision: If receivers show DKIM=fail, check whether the signing system is using the same selector and domain, and whether any middleware is modifying the message.

Task 6: Inspect DMARC policy and alignment mode

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=r; pct=100"

Meaning: DMARC is enforcing quarantine. DKIM alignment is strict (adkim=s), SPF alignment relaxed (aspf=r).

Decision: Strict DKIM alignment means the DKIM d= domain must match the From domain exactly. If your relay signs with a different d=, you will fail DMARC.

Task 7: Verify reverse DNS (PTR) of your sending IP (direct send path)

cr0x@server:~$ dig +short -x 203.0.113.10
mailout-01.example.net.

Meaning: PTR exists and points to a hostname.

Decision: Confirm forward DNS of that hostname resolves back to the same IP; if not, fix the mismatch or expect deliverability penalties.

Task 8: Verify forward DNS matches PTR (basic sanity)

cr0x@server:~$ dig +short mailout-01.example.net A
203.0.113.10

Meaning: Forward-confirmed reverse DNS (FCrDNS) passes.

Decision: If it doesn’t match, fix DNS before you debate anything else. This is table stakes for direct send.

Task 9: Check if your IP is listed on common DNS-based blocklists (signal, not gospel)

cr0x@server:~$ for z in zen.spamhaus.org bl.spamcop.net b.barracudacentral.org; do ip=203.0.113.10; rev=$(echo $ip | awk -F. '{print $4"."$3"."$2"."$1}'); echo "Query $z:"; dig +short ${rev}.${z} A; done
Query zen.spamhaus.org:
Query bl.spamcop.net:
Query b.barracudacentral.org:

Meaning: No A record returned, so not listed on these three at query time.

Decision: If listed, stop sending direct from that IP until you understand why; switch to authenticated relay or a clean IP while remediating.

Task 10: Inspect Postfix queue depth (are you stuck locally?)

cr0x@server:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5     1823 Mon Jan  4 09:12:10  alerts@example.com
                                         user@gmail.com
                                         (connect to gmail-smtp-in.l.google.com[142.250.102.27]:25: Connection timed out)

Meaning: Mail is queued locally due to connection timeouts to recipient MX.

Decision: Check outbound firewall, routing, and whether the recipient is deferring via tarpitting. If this is widespread, suspect outbound 25 block or network ACL changes.

Task 11: Trace a specific message through logs (find the SMTP response)

cr0x@server:~$ grep -R "A1B2C3D4E5" /var/log/mail.log | tail -n 5
Jan  4 09:12:10 app-01 postfix/qmgr[1187]: A1B2C3D4E5: from=<alerts@example.com>, size=1823, nrcpt=1 (queue active)
Jan  4 09:12:12 app-01 postfix/smtp[2214]: A1B2C3D4E5: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, delay=2.1, delays=0.1/0/2/0, dsn=4.4.1, status=deferred (connect to gmail-smtp-in.l.google.com[142.250.102.27]:25: Connection timed out)

Meaning: DSN 4.4.1 indicates a temporary network failure; Postfix will retry.

Decision: If the DSN is 5.x.x (permanent), stop retrying and fix identity/content/reputation. If it’s 4.x.x, fix connectivity or wait out rate limits depending on message text.

Task 12: Verify Postfix is using the relay and not leaking direct sends

cr0x@server:~$ grep -E "relay=" /var/log/mail.log | tail -n 3
Jan  4 10:02:41 app-01 postfix/smtp[4021]: 9F8E7D6C5B: to=<user@outlook.com>, relay=smtp.relay.example[198.51.100.20]:587, delay=1.2, dsn=2.0.0, status=sent (250 2.0.0 queued as 7c9f1a2b-1234-5678-9012-acdeffedcba0)
Jan  4 10:02:42 app-01 postfix/smtp[4021]: 1A2B3C4D5E: to=<user@gmail.com>, relay=smtp.relay.example[198.51.100.20]:587, delay=0.9, dsn=2.0.0, status=sent (250 2.0.0 queued as 0d1e2f3a-aaaa-bbbb-cccc-112233445566)

Meaning: Messages are leaving via relayhost on 587 and being queued by the provider (you have provider queue IDs).

Decision: If some lines show relay=recipient-mx:25, you have split paths. Fix transport maps or relay restrictions before you debug deliverability—you can’t debug two systems at once.

Task 13: Check TLS policy and whether you’re failing TLS negotiation

cr0x@server:~$ postconf -n | egrep '^(smtp_tls_security_level|smtp_tls_CAfile|smtp_tls_loglevel|smtp_tls_policy_maps)'
smtp_tls_security_level = may
smtp_tls_loglevel = 1

Meaning: Opportunistic TLS is enabled (may). Log level is low but present.

Decision: If you see TLS failures in logs, temporarily increase smtp_tls_loglevel to debug. If you require TLS (encrypt), set security_level=encrypt only if you know recipients support it or you have policy maps.

Task 14: Prove what the message actually looked like on the wire (headers)

cr0x@server:~$ sed -n '1,60p' /var/spool/postfix/deferred/A/A1B2C3D4E5
From: "Example Alerts" <alerts@example.com>
To: user@gmail.com
Subject: Your login code
Date: Mon, 04 Jan 2026 09:12:09 +0000
Message-ID: <20260104091209.12345@app-01.prod.example.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

Meaning: This shows the stored message headers (not the final received headers). Useful for verifying From domain, Message-ID domain, and content type.

Decision: If DMARC alignment is strict and you see From: uses one domain but DKIM signs another (or Message-ID domain confuses receivers), standardize header domains.

Task 15: Confirm your app is not bypassing the MTA and using random SMTP libraries directly

cr0x@server:~$ ss -tpn | egrep ':25 |:587 ' | head
ESTAB 0 0 10.0.1.10:49822 198.51.100.20:587 users:(("master",pid=1123,fd=24))
ESTAB 0 0 10.0.1.10:50112 142.250.102.27:25 users:(("python3",pid=9981,fd=8))

Meaning: Postfix is using the relay on 587, but a python process is connecting directly to a recipient MX on 25.

Decision: Hunt that process. Mandate a single egress path. “Some mail direct, some via relay” is how you end up with half your domain reputation pinned to chaos.

Task 16: Check system time skew (DKIM and TLS can behave badly when clocks drift)

cr0x@server:~$ timedatectl
               Local time: Mon 2026-01-04 10:15:22 UTC
           Universal time: Mon 2026-01-04 10:15:22 UTC
                 RTC time: Mon 2026-01-04 10:15:21
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Meaning: Clock is synchronized; good.

Decision: If not synchronized, fix NTP. Some receivers are forgiving; others treat time-skewed signatures and TLS sessions as suspicious.

Playbook de diagnostic rapide

Ceci est la séquence « arrêtez de tourner en rond ». Exécutez‑la dans l’ordre. Vous cherchez à localiser le goulot d’étranglement : appli, MTA local, fournisseur de relais, destinataire, ou DNS/auth.

Premier : Déterminez où « sent » s’arrête

1. L’appli transmet‑elle le mail à quelque chose ? Cherchez dans les logs applicatifs des IDs de message ou des codes de réponse SMTP. Si l’appli n’a jamais transmis, c’est un bug applicatif, pas de la délivrabilité.
2. La file Postfix grossit‑elle ? mailq. Si la file locale augmente, votre système ne peut pas remettre le message (réseau, auth, DNS, panne de relais).
3. Les logs montrent‑ils 250 queued chez un relais ? Si oui, votre problème est en aval. Arrêtez de blâmer Postfix.

Second : Vérifiez l’identité et l’alignement, pas seulement les « pass »

1. Le record SPF existe et inclut le système d’envoi (votre IP ou le relais).
2. DKIM est présent et vérifiable ; le sélecteur existe en DNS.
3. La politique DMARC ne vous rejette pas ; l’alignement correspond au domaine From.

Troisième : Vérifiez la réputation et les signaux de confiance basiques

1. Si direct : PTR existe et correspond à l’A record (FCrDNS).
2. Si direct : vérifiez les blocklists et si l’IP est nouvelle/rotative.
3. Si relais : vérifiez l’état du fournisseur, les limites de débit et si vous avez dépassé des quotas.

Quatrième : Vérifiez le feedback côté destinataire (rebonds, déferrals, placement spam)

1. Parsez les codes de réponse SMTP depuis les logs ou les événements fournisseur.
2. Cherchez des motifs par domaine (gmail vs outlook vs yahoo).
3. Identifiez si c’est un rejet (5xx), un déferral (4xx), ou un placement en spam (accepté mais pas en boite de réception).

Erreurs courantes : symptôme → cause racine → correctif

1) « Ça marche en staging, échoue en production »

Symptôme : Les e‑mails de test arrivent ; les e‑mails de production vers les gros fournisseurs rebondissent ou disparaissent.

Cause racine : La production envoie depuis des IPs différentes (autoscaling, NAT, chemins d’egress multiples) avec une réputation froide/mauvaise et PTR manquant.

Fix : Utilisez un relais authentifié ou verrouillez des IPs de sortie dédiées avec rDNS contrôlé ; imposez un chemin d’egress unique ; chauffez progressivement.

2) « SMTP dit 250 OK mais les utilisateurs ne voient pas le mail »

Symptôme : Les logs montrent 250 queued chez le relais/fournisseur ; les destinataires prétendent n’avoir rien reçu.

Cause racine : Accepté dans la file du fournisseur ; ensuite drop/throttled ; ou livré en spam/quarantaine à cause du contenu/DMARC non aligné.

Fix : Corrélez les IDs de file fournisseur, inspectez les logs d’événements du fournisseur, et validez SPF/DKIM/DMARC. Implémentez le traitement des rebonds et la surveillance des plaintes.

3) « Pic soudain de rebonds après un déploiement »

Symptôme : Des rejets démarrent juste après le déploiement d’un template.

Cause racine : Les filtres de contenu se sont déclenchés (patterns d’URL, MIME cassé, absence de List‑Unsubscribe pour du bulk, encodage bizarre). Ou DKIM casse parce qu’un middleware modifie le corps.

Fix : Faites rollback du template, comparez le MIME brut, assurez‑vous que la canonicalisation DKIM correspond aux transformations, et évitez les patterns de contenu à risque.

4) « Certains destinataires reçoivent, d’autres non »

Symptôme : Gmail OK, Outlook bloqué (ou vice versa).

Cause racine : Notation spécifique au fournisseur ; mismatch TLS/cipher ; includes SPF inconsistants ; problèmes de chemin IPv6.

Fix : Segmentez par domaine destinataire, vérifiez les transcriptions SMTP et les codes de réponse, désactivez l’envoi IPv6 si mal configuré, et ajustez les politiques par domaine si vous envoyez direct.

5) « Les rapports DMARC montrent des échecs mais on jure avoir configuré SPF et DKIM »

Symptôme : Les rapports agrégés montrent un fort taux d’échec DMARC.

Cause racine : Mismatch d’alignement : le domaine From diffère du DKIM d= ou du domaine MailFrom SPF. Ou des tiers envoient en votre nom sans autorisation.

Fix : Alignez le From avec le domaine signé DKIM ; utilisez un sous‑domaine dédié pour les expéditeurs tiers ; mettez à jour les includes SPF ; renforcez la politique DMARC à mesure que vous prenez confiance.

6) « On a ajouté des serveurs pour envoyer plus vite et la délivrabilité a empiré »

Symptôme : Débit plus élevé, moins d’inbox placement et plus de throttling.

Cause racine : Les rafales de volume et le changement de concurrence ont modifié l’empreinte de l’expéditeur ; la réputation par IP s’est diluée ; le taux de plainte a augmenté à cause de la vitesse et du manque de throttling.

Fix : Centralisez l’envoi via un relais authentifié ou un tier direct‑send contrôlé ; appliquez des limites de débit ; chauffez les IPs ; priorisez les messages.

7) « Les rebonds sont élevés et le support dit que les adresses sont valides »

Symptôme : Pics de 550 user unknown.

Cause racine : Problème d’hygiène de liste, données anciennes, fautes de frappe, ou abus d’inscription générant des adresses invalides.

Fix : Implémentez le traitement et la suppression automatique des rebonds ; validez les adresses lors de l’inscription sans être pénible pour les utilisateurs légitimes ; throttlez les sources d’inscription suspectes.

Listes de contrôle / plan pas à pas

Checklist A : Si vous choisissez le relais authentifié (recommandé pour la plupart des équipes)

1. Choisissez l’identité d’envoi : Décidez du domaine From et si vous utiliserez un sous‑domaine (ex. mail.example.com) pour séparation opérationnelle.
2. Publiez SPF : Autorisez le fournisseur de relais (include ou plages IP explicites). Gardez‑le sous 10 requêtes DNS.
3. Activez DKIM avec votre domaine : Préférez signer avec votre domaine From ou un sous‑domaine aligné. Faites tourner les clés périodiquement.
4. Publiez DMARC : Commencez par p=none pour observer, puis passez à quarantine/reject quand vous avez éliminé les expéditeurs non autorisés.
5. Configurez la soumission Postfix vers le relais : 587 avec STARTTLS et SASL auth. Utilisez des identifiants stables et la gestion secrète.
6. Définissez des limites de retry claires : Si le relais retourne 250 queued, ne relancez pas au niveau applicatif.
7. Implémentez le traitement des rebonds : Parsez les DSNs et événements fournisseur ; supprimez automatiquement les rebonds persistants.
8. Surveillez les signaux de délivrabilité : taux de déferrals, plaintes spam, rejets par domaine.

Checklist B : Si vous choisissez l’envoi direct (vous exploitez maintenant un système mail)

1. IPs de sortie stables : Pas d’IP rotative. Pas de surprises d’autoscaling. IPs dédiées si possible.
2. Contrôle rDNS/PTR : PTR existe, forward match, hostname sensé.
3. SPF autorise vos IPs : Gardez l’enregistrement serré ; ne vous cachez pas derrière un « ~all » ambigu.
4. Signature DKIM sur tout le sortant : Assurez‑vous que les systèmes intermédiaires ne cassent pas les signatures.
5. Politique DMARC : Alignez le From avec SPF/DKIM et avancez vers l’application.
6. Réglage des files et limites de débit : Limites de concurrence par domaine, backoff sensé, évitez les pics.
7. Gestion des abus : Plaintes, désabonnements, listes de suppression et un vrai processus humain.
8. Supervision : Profondeur de file, déferrals par domaine, codes de rebond, vérifs blocklist, erreurs TLS.
9. Plan de warming : Augmentez le volume progressivement ; commencez par des destinataires engagés et le trafic transactionnel critique.

Étapes pas à pas : migrer de l’envoi direct vers le relais authentifié sans chaos

1. Inventaire des expéditeurs : Trouvez chaque système qui envoie des e‑mails (applis, cron, imprimantes, serveurs legacy). Oui, même les imprimantes.
2. Centralisez la soumission : Obligez tous les expéditeurs à soumettre à un MTA local ou une passerelle de relais.
3. Configurez relayhost : Mettez à jour relayhost Postfix et les réglages SASL ; testez avec un flux de mail à faible risque.
4. Mettre à jour SPF/DKIM : Autorisez le relais et assurez‑vous que DKIM s’aligne avec le From visible.
5. Activez les rapports DMARC : Observez qui envoie encore direct ou vous usurpe.
6. Basculez par classe de message : Réinitialisations de mot de passe d’abord, puis notifications, puis bulk. Ne basculez pas tout d’un coup sauf si vous aimez l’adrénaline.
7. Supprimez l’egress direct : Bloquez le 25 sortant depuis les réseaux applicatifs pour empêcher les contournements.
8. Tracez les IDs de message de bout en bout : Corrélez app request ID → local queue ID → provider queue ID.

FAQ

1) Si j’utilise un relais authentifié, ai‑je encore besoin de SPF/DKIM/DMARC ?

Oui. Le relais résout l’infrastructure de transport et de réputation, pas l’identité. Les récepteurs évaluent toujours l’authentification et l’alignement de votre domaine. Sans cela, vous finirez en spam ou vous ferez rejeter sous des écosystèmes DMARC stricts.

2) L’envoi direct est‑il toujours pire pour la délivrabilité ?

Non. L’envoi direct peut être excellent si vous avez des IPs stables, DNS correct, envoi discipliné et supervision réelle. C’est simplement que beaucoup d’équipes le choisissent par accident et l’exploitent de façon casual, ce qui l’empire.

3) Pourquoi mes messages sont acceptés (250) mais n’apparaissent jamais ?

Parce que l’acceptation SMTP signifie « mis en file », pas « dans la boîte de réception ». Après l’acceptation, les filtres de contenu, la réputation et les politiques décident encore du placement. Il vous faut de la visibilité en aval (événements fournisseur ou rebonds côté destinataire) pour savoir ce qui s’est passé.

4) Dois‑je envoyer transactionnel et marketing depuis le même domaine/IP ?

Privilégiez la séparation. Utilisez des sous‑domaines ou des pools IP séparés. Le trafic marketing a une dynamique de plainte différente et peut tirer vers le bas la réputation du mail transactionnel, qui est le flux que vous ne pouvez pas vous permettre de perdre.

5) L’IPv6 aide ou nuit ?

Ça peut aider si correctement configuré (IPv6 stable, rDNS approprié, includes SPF, envoi cohérent). Ça peut nuire si vous commencez accidentellement à envoyer depuis une adresse IPv6 non routable ou sans réputation. Si vous n’êtes pas sûr, désactivez l’IPv6 sortant pour SMTP jusqu’à validation.

6) Puis‑je sauter le rDNS si j’utilise un relais ?

Généralement oui, parce que les récepteurs voient l’IP et le rDNS du relais, pas le vôtre. Mais votre environnement local a encore besoin d’un DNS sain pour son propre hostname et les opérations TLS ; ne fonctionnez pas avec un DNS cassé en espérant la stabilité.

7) Quelle politique DMARC devrais‑je commencer ?

Commencez par p=none pour collecter des rapports et découvrir qui envoie comme votre domaine. Passez à quarantine puis à reject une fois que vous avez aligné les expéditeurs légitimes et éliminé les non‑autorisés.

8) Quelle est la configuration la plus simple « ne pas se faire bloquer » pour une petite appli de production ?

Relais authentifié sur 587 avec TLS et AUTH, SPF autorisant le relais, DKIM signé aligné avec votre domaine From, et un enregistrement DMARC. Ajoutez la suppression des rebonds. Gardez votre domaine From stable et évitez de le changer chaque semaine.

9) Comment savoir si je suis limité par le débit ou bloqué ?

Regardez les codes de réponse SMTP. Les déferrals sont généralement des 4xx avec des indications de throttling ou de limites temporaires. Les blocages sont souvent des 5xx avec des indices de politique ou de réputation. Dans tous les cas, loggez et suivez par domaine destinataire.

10) Est‑ce que faire tourner Postfix localement reste utile si j’utilise un relais ?

Oui. Un MTA local vous donne de la mise en tampon, des retries et une interface de soumission propre pour les applis. Il vous donne aussi des logs que vous contrôlez. Gardez‑le simple : relayer tout ; n’autorisez pas les applis à « aller direct » à côté.

Conclusion : quoi faire ensuite, en termes de production

Si vous voulez l’approche qui ne vous fait pas bloquer, choisissez le relais authentifié sauf si vous avez une raison spécifique et des ressources pour faire de l’envoi direct. Ce n’est pas de la lâcheté ; c’est du contrôle des coûts. Le travail de délivrabilité est un vrai travail.

Étapes suivantes qui rapportent immédiatement :

1. Choisissez un chemin d’egress unique pour chaque classe d’e‑mail (transactionnel, bulk, interne) et appliquez‑le.
2. Rendez l’identité cohérente : SPF autorise l’expéditeur, DKIM signe comme le domaine From (ou un sous‑domaine aligné), la politique DMARC correspond à votre tolérance au risque.
3. Ajoutez de la traçabilité : corrélez les IDs de message app → MTA → fournisseur pour que « où est mon e‑mail ? » devienne une requête et non une séance spirite.
4. Surveillez les bons métriques : déferrals, rejets par domaine, profondeur de file et codes de rebond. Pas simplement « e‑mails envoyés ».
5. Arrêtez d’optimiser la mauvaise couche : ne combattez pas SMTP avec des retries applicatifs. Respectez la file.

Vous pourrez vous complexifier plus tard. D’abord, faites en sorte d’être livré.