Envoyer des e-mails depuis vos applications auto-hébergées

Applications auto-hébergées : quels besoins pour envoyer des e-mails

Pour envoyer des e-mails depuis des applications auto-hébergées, vous n’avez pas besoin d’un serveur de messagerie. Vous avez besoin d’un relais : un compte SMTP authentifié, configuré une seule fois sur l’hôte, auquel toutes les applications de la machine remettent leurs e-mails sortants. Héberger des boîtes aux lettres est le problème difficile, et c’est un autre sujet.

Recevoir des e-mails signifie accepter des connexions depuis tout Internet sur le port 25, filtrer le spam, stocker et sauvegarder les boîtes aux lettres, puis défendre la réputation d’une adresse IP pendant toute la durée de vie du serveur. Cette tâche est devenue réellement plus difficile. Envoyer des e-mails signifie transmettre le lien de réinitialisation du mot de passe, la confirmation d’inscription, l’alerte « sauvegarde échouée » ou la notification de réponse sur un forum. Ces messages sont courts, peu nombreux et envoyés un par un. Un relais les prend en charge, et sa configuration demande une après-midi.

Déterminez lequel de ces deux problèmes vous cherchez réellement à résoudre. Déterminer s’il vaut encore la peine d’héberger sa propre boîte aux lettres est une vraie question, avec une vraie réponse. Pour la plupart des utilisateurs, la réponse est non. Si votre réponse est oui, un serveur de messagerie Mailcow complet sur un VPS est la voie la plus honnête. L’envoi est l’autre partie du problème : c’est ce dont presque tout le monde a besoin, mais que presque personne ne planifie.

Commençons par deux termes. SMTP (simple mail transfer protocol) est le protocole utilisé par tous les composants concernés. Un relais, également appelé smarthost, est un serveur qui accepte vos e-mails authentifiés et les distribue ensuite en utilisant ses propres adresses et sa propre réputation.

Pourquoi votre VPS ne peut pas envoyer de messages sur le port 25

Presque tous les fournisseurs de VPS bloquent par défaut le port TCP sortant 25. Le port 25 est utilisé par les serveurs de messagerie pour communiquer entre eux. Un VPS compromis dont le port 25 sortant est ouvert peut donc envoyer directement du spam à tous les serveurs de messagerie destinataires. Les fournisseurs abandonnent ces paquets au lieu de rejeter la connexion. C’est pourquoi le symptôme est une connexion qui reste bloquée, puis expire, plutôt qu’une erreur.

Testez-le depuis le serveur :

sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 gmail-smtp-in.l.google.com 25
nc -vz -w 5 smtp.relay.example 587

Si la première commande reste bloquée pendant les cinq secondes complètes alors que la seconde répond immédiatement, le blocage est confirmé. Certains fournisseurs le lèvent après un examen du compte. La plupart ne le font pas.

Le blocage n’est pas la raison principale d’utiliser un relay. Même lorsque le port 25 est ouvert, les messages envoyés directement depuis l’adresse d’un VPS récent arrivent dans les spams ou sont refusés, car cette adresse n’a aucun historique d’envoi et appartient à une plage que les serveurs destinataires associent à l’hébergement. Les recommandations de Google concernant les expéditeurs exigent un DNS direct et inverse valide pour l’IP d’envoi. De nombreuses adresses de VPS utilisent un enregistrement PTR (pointer) générique que vous ne pouvez pas modifier. Un relay vous fournit des adresses qui disposent déjà d’un historique.

Les ports de submission permettent de contourner ce problème. Le port 587 utilise STARTTLS : la session commence en clair, puis passe en mode chiffré. Le port 465 utilise TLS implicite (transport layer security) : la session est chiffrée dès le premier octet. Les deux ports sont destinés aux clients authentifiés, les deux sont ouverts sur les réseaux de VPS, et votre relay en prend en charge au moins un.

Choisir un relais et un sous-domaine d’envoi

Il existe de nombreux fournisseurs de messagerie transactionnelle, et ils remplissent tous la même fonction. Évaluez-les selon quatre critères :

• un port de soumission, 587 ou 465, avec SMTP AUTH
• la signature DKIM avec votre propre domaine et votre propre selector, et pas uniquement avec celui du fournisseur
• des données sur les bounces et les réclamations, consultables dans un dashboard ou via un webhook
• une offre adaptée à votre volume. En août 2026, plusieurs fournisseurs incluent encore gratuitement quelques milliers de messages par mois. Ces conditions changent souvent : consultez donc la page tarifaire actuelle plutôt qu’un article de blog

Envoyez les e-mails des applications depuis un sous-domaine. Utilisez par exemple notify.example.com au lieu de example.com. Les destinataires évaluent la réputation de chaque domaine. Un mauvais envoi depuis vos applications reste ainsi séparé du domaine utilisé pour vos factures et les e-mails de votre équipe. Soyez toutefois conscient de la limite : certains destinataires reportent les signaux des sous-domaines sur le domaine organisationnel. Un sous-domaine limite donc les dégâts, sans les isoler complètement.

Configurer le relais une seule fois pour chaque application auto-hébergée

L’approche la plus évidente consiste à ouvrir la page de configuration de chaque application et à y saisir l’hôte SMTP, le nom d’utilisateur et le mot de passe. Nextcloud, le forum, Grafana, Vaultwarden et le moniteur de disponibilité proposent tous ce formulaire. La même information se retrouve alors à six endroits, dans six formats différents, dont plusieurs dans une base de données que vous sauvegardez comme des données et non comme de la configuration. Lorsque vous changez le mot de passe, vous en mettez cinq à jour. La sixième application cesse d’envoyer des messages, sans avertissement, car la plupart des applications enregistrent l’erreur SMTP côté serveur tout en affichant une page de succès à l’utilisateur.

Configurez plutôt le relais une seule fois sur l’hôte et laissez les applications soumettre leurs messages localement. Deux outils conviennent bien à cet usage. Le choix entre les deux dépend de la mise en file d’attente.

msmtp est un client compatible sendmail, sans daemon. Il se connecte, envoie le message, puis se termine. Il ne met pas les messages en file d’attente. Si le relais est inaccessible, le message est perdu et l’application appelante reçoit un code de sortie différent de zéro.

Postfix configuré comme satellite est un agent de transfert de courrier complet, avec une véritable file d’attente. Il accepte immédiatement le message, réessaie pendant plusieurs jours en cas d’échec et conserve l’identifiant du relais dans un fichier accessible uniquement à root. Utilisez-le lorsqu’il est important de ne pas perdre une alerte pendant une panne du relais, ou lorsque plusieurs applications s’exécutent avec des utilisateurs système différents.

msmtp, l’option légère

sudo apt update
sudo apt install -y msmtp msmtp-mta ca-certificates

msmtp-mta installe le lien symbolique /usr/sbin/sendmail. Ainsi, tout programme qui appelle sendmail utilise msmtp sans savoir qu’il est présent.

Écrivez /etc/msmtprc :

defaults
auth            on
tls             on
tls_trust_file  /etc/ssl/certs/ca-certificates.crt
syslog          on

account         relay
host            smtp.relay.example
port            587
from            apps@notify.example.com
set_from_header on
user            <relay username>
password        <relay password>

account default : relay

set_from_header on définit toujours un en-tête From et remplace celui qui existe déjà. Il remplace donc la valeur produite par l’application par l’adresse indiquée dans from. Sans cette option, une tâche cron envoie le message avec root@your-hostname. Le relais le refuse, car cette adresse n’a pas été vérifiée. syslog on envoie le journal à syslog. Vous pouvez donc le consulter avec journalctl -t msmtp. Un chemin logfile partagé constitue l’autre possibilité. Il doit être accessible en écriture par chaque utilisateur qui envoie des messages. C’est un piège sur un serveur multi-utilisateur.

Définissez vous-même les permissions. msmtp contrôle les permissions d’une configuration par utilisateur (~/.msmtprc) et refuse de s’exécuter avec contains secrets and therefore must have no more than user read/write permissions. Il n’effectue aucun contrôle sur /etc/msmtprc, car il charge simplement ce fichier s’il est lisible.

sudo chown root:root /etc/msmtprc
sudo chmod 600 /etc/msmtprc
printf 'Subject: relay test\n\nsent from the host\n' | sudo sendmail -v you@example.com

-v affiche toute la conversation SMTP. Vous voyez ainsi chaque réponse du relais. Un envoi réussi se termine par une réponse 250, qui indique que le message est accepté. Une ligne authentication failed signifie que le nom d’utilisateur ou le mot de passe est incorrect, ou que le relais attend une clé d’API à la place du mot de passe du compte.

Voici le problème, et c’est la raison pour laquelle beaucoup passent à Postfix. Avec le mode 600 et root comme propriétaire, seul root peut envoyer des messages. Une application exécutée sous www-data ne peut pas lire le fichier. msmtp l’ignore alors et l’application échoue avec une erreur indiquant que le compte par défaut est introuvable. La solution consiste à utiliser un groupe :

sudo chgrp mail /etc/msmtprc
sudo chmod 640 /etc/msmtprc
sudo usermod -aG mail www-data

Cela signifie clairement que chaque membre du groupe mail peut lire le mot de passe du relais et envoyer des messages comme votre domaine depuis cette machine. Sur un VPS que vous administrez seul, c’est acceptable. Si plusieurs applications que vous n’avez pas écrites s’exécutent avec des utilisateurs différents, ce n’est pas acceptable. Postfix constitue alors une meilleure solution, car ces applications n’accèdent jamais à l’identifiant du relais.

Postfix comme satellite

sudo debconf-set-selections <<'EOF'
postfix postfix/main_mailer_type select Satellite system
postfix postfix/mailname string notify.example.com
postfix postfix/relayhost string [smtp.relay.example]:587
EOF
sudo DEBIAN_FRONTEND=noninteractive apt install -y postfix libsasl2-modules

libsasl2-modules est obligatoire. Sans ce paquet, Postfix journalise warning: SASL authentication failure: No worthy mechs found, car les bibliothèques des mécanismes PLAIN et LOGIN ne sont pas installées sous /usr/lib/sasl2.

Configurez le reste avec postconf -e. Cette commande modifie /etc/postfix/main.cf directement :

sudo postconf -e 'relayhost = [smtp.relay.example]:587'
sudo postconf -e 'smtp_sasl_auth_enable = yes'
sudo postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
sudo postconf -e 'smtp_sasl_security_options = noanonymous'
sudo postconf -e 'smtp_tls_security_level = encrypt'
sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'
sudo postconf -e 'inet_interfaces = loopback-only'

Les crochets autour du nom d’hôte du relais empêchent Postfix de rechercher un enregistrement MX pour ce nom. Postfix se connecte directement à ce nom. Certains noms d’hôte de relais publient un enregistrement MX qui pointe vers un autre serveur. Sans les crochets, vos messages suivent cet enregistrement et arrivent sur le mauvais serveur.

smtp_tls_security_level = encrypt rend TLS obligatoire. Le message n’est donc jamais envoyé en clair. Cette option ne vérifie pas le certificat. La documentation de Postfix le précise explicitement : à ce niveau, la livraison continue même si le certificat du serveur n’est pas approuvé ou si son nom est incorrect. Pour vérifier le certificat, utilisez verify ou secure et laissez smtp_tls_CAfile activé.

L’identifiant se place dans un fichier accessible uniquement à root :

echo '[smtp.relay.example]:587 relay-username:relay-password' | sudo tee /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap hash:/etc/postfix/sasl_passwd
sudo systemctl restart postfix

postmap construit la copie indexée que Postfix lit réellement. Si vous modifiez ensuite le fichier texte et oubliez postmap, Postfix continue d’utiliser l’ancienne base de données. Rien dans le journal ne vous l’indique. Dans Postfix 3.9 et les versions ultérieures, le type de map par défaut est lmdb. Si vous préférez ce type, écrivez lmdb: à la fois dans le paramètre et dans l’argument postmap. Indiquer le type sur les deux lignes permet de les maintenir synchronisées.

Les applications utilisent toujours root@hostname comme adresse d’envoi. Réécrivez l’expéditeur :

echo '/.+/    apps@notify.example.com' | sudo tee /etc/postfix/sender_canonical
sudo postconf -e 'sender_canonical_classes = envelope_sender, header_sender'
sudo postconf -e 'sender_canonical_maps = regexp:/etc/postfix/sender_canonical'
sudo systemctl reload postfix

Une table regexp: est lue directement. Elle ne nécessite donc aucun postmap. Tous les messages partent désormais avec le même expéditeur d’enveloppe et le même en-tête From, comme le demande le relais. En contrepartie, toutes les réponses arrivent au même endroit. Définissez donc un en-tête Reply-To dans chaque application lorsque les réponses doivent parvenir à une personne.

Envoyez un test et consultez le journal :

printf 'Subject: postfix relay test\n\nsent through the queue\n' | sendmail you@example.com
sudo tail -n 20 /var/log/mail.log

Un message livré produit une entrée status=sent, suivie de la réponse du relais entre crochets. Toute autre réponse indique la cause. status=deferred avec Connection timed out signifie qu’un élément utilise encore le port 25. Host or domain name not found. Name service error for name=smtp.relay.example type=A signifie que le nom d’hôte du relais est incorrect ou que le DNS ne fonctionne pas sur la machine. mailq affiche les messages bloqués et sudo postqueue -f les réessaie immédiatement.

Accéder au relais de l’hôte depuis les conteneurs Docker

Un conteneur ne peut pas appeler le sendmail de l’hôte, car le binaire n’est pas présent dans l’image et la file d’attente n’est pas partagée. Fournissez plutôt aux conteneurs une cible réseau. Postfix peut écouter sur l’adresse du bridge Docker.

ip -4 addr show docker0
sudo postconf -e 'inet_interfaces = 127.0.0.1, 172.17.0.1'
sudo postconf -e 'mynetworks = 127.0.0.0/8 172.17.0.0/16'
sudo systemctl restart postfix

Relevez votre propre adresse de bridge avec la première commande au lieu de copier celle-ci, car un projet Compose crée son propre réseau avec un autre sous-réseau, et docker network inspect <name> l’affiche. Utilisez restart ici, et non reload : la documentation de Postfix indique qu’il faut arrêter puis démarrer le service après la modification de inet_interfaces, car un reload ne prend pas cette modification en compte. Chaque application utilise ensuite 172.17.0.1 comme hôte SMTP, le port 25, sans authentification ni TLS, car ce trafic ne quitte jamais l’hôte. Si vos services se trouvent sur un réseau Compose, exécuter Docker Compose sur un VPS explique d’où vient ce sous-réseau.

C’est l’étape qui peut vous poser de graves problèmes. Un Postfix qui écoute sur une adresse publique avec un mynetworks trop permissif est un relais ouvert : des tiers envoient leurs messages via votre compte de relais, le fournisseur le suspend et la réputation de votre domaine est dégradée pendant des mois. Vérifiez les deux côtés après chaque modification.

ss -tlnp | grep ':25'

La sortie doit afficher uniquement l’adresse de loopback et l’adresse du bridge. Depuis une autre machine, nc -vz your.server.ip 25 doit échouer.

SPF, DKIM et DMARC pour le domaine d’envoi

Publiez les trois enregistrements avant le premier envoi réel. Ils sont gratuits, relèvent du DNS et font partie des premiers éléments vérifiés par les serveurs destinataires.

SPF (Sender Policy Framework) indique qui peut placer votre domaine dans l’expéditeur d’enveloppe. Publiez-le sur le sous-domaine d’envoi :

notify.example.com.  IN  TXT  "v=spf1 include:_spf.relay.example -all"

Copiez la valeur include: depuis la page de configuration de votre relay. Un include qui ne se résout pas produit une erreur permanente au lieu d’un pass. L’évaluation SPF s’arrête après dix mécanismes qui interrogent le DNS et renvoie permerror. Les serveurs destinataires le traitent comme un échec. Limitez donc le nombre d’include. Publiez exactement un enregistrement v=spf1 par nom. En publier deux constitue également un permerror.

DKIM (DomainKeys Identified Mail) signe chaque message avec une clé privée détenue par le relay. Les serveurs destinataires récupèrent la clé publique correspondante dans le DNS. Votre relay vous fournit un sélecteur et soit un enregistrement TXT, soit un CNAME à publier :

sel1._domainkey.notify.example.com.  IN  CNAME  sel1.dkim.relay.example.

DKIM est plus important que SPF, car il résiste au forwarding. Lorsqu’une liste de diffusion ou une règle .forward transmet votre message, celui-ci arrive depuis l’adresse IP du forwarder. SPF échoue alors que la signature reste valide.

DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) indique aux serveurs destinataires quoi faire lorsque les deux contrôles ne sont pas alignés et leur demande de vous transmettre des rapports. Publiez-le sur le domaine organisationnel :

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Commencez par p=none et consultez les rapports pendant deux semaines. p=none ne change rien à la distribution. Il active uniquement les rapports. C’est ainsi que vous repérez les systèmes dont vous aviez oublié qu’ils envoyaient avec votre domaine. Passez ensuite à p=quarantine, puis à p=reject. Publier p=reject dès le premier jour permet de découvrir que votre système de facturation envoyait avec le domaine, lorsqu’un client signale qu’il n’a jamais reçu sa facture.

Vérifiez ce que voit Internet, et non ce qu’affiche votre panneau DNS :

dig +short TXT notify.example.com
dig +short TXT sel1._domainkey.notify.example.com
dig +short TXT _dmarc.example.com

Une sortie vide signifie que l’enregistrement n’est pas encore propagé ou que le nom est incorrect. Un enregistrement corrigé il y a cinq minutes peut rester incorrect dans les caches pendant toute la durée de son ancien TTL (time to live). Vérifiez donc le TTL avant de tirer une conclusion.

Alignez From et Return-Path

Chaque message contient deux adresses d’expéditeur, qui sont vérifiées différemment. L’expéditeur d’enveloppe est indiqué dans la commande SMTP MAIL FROM et apparaît dans le message distribué sous la forme Return-Path. L’en-tête From correspond à l’adresse affichée au lecteur.

SPF vérifie le domaine de l’expéditeur d’enveloppe par rapport à l’adresse IP qui se connecte. DKIM indique le domaine qui a signé le message, sous la forme d=. DMARC réussit uniquement si au moins un de ces deux domaines est aligné sur le domaine de l’en-tête From. Avec un alignement relâché (adkim=r, aspf=r, qui est la valeur par défaut), un sous-domaine est accepté. Ainsi, un expéditeur d’enveloppe sur notify.example.com est aligné sur un en-tête From sur example.com. Avec un alignement strict, ce n’est pas le cas.

La règle pratique est simple : utilisez le même domaine pour l’en-tête From et l’expéditeur d’enveloppe. La question ne se pose alors plus. C’est exactement ce que set_from_header on fait dans msmtp et ce que sender_canonical_maps fait dans Postfix.

Consultez le verdict dans un message distribué. Dans Gmail, « Show original » affiche l’en-tête ajouté par le serveur destinataire :

Authentication-Results: mx.google.com;
       dkim=pass header.i=@notify.example.com;
       spf=pass (google.com: domain of apps@notify.example.com designates 198.51.100.25 as permitted sender) smtp.mailfrom=apps@notify.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Les trois vérifications réussissent dans cet exemple. Dans les autres cas, le résultat indique la vérification qui a échoué et généralement la raison. C’est l’information de débogage la plus rapide à obtenir sur ce sujet.

Rebonds et plaintes avant que le volume n’augmente

Un rebond signifie que le destinataire refuse votre message. Un hard bounce est définitif, et Gmail le formule 550 5.1.1 The email account that you tried to reach does not exist. Un soft bounce est temporaire, avec un code 4xx pour une boîte aux lettres pleine ou pour un greylisting ; le relay réessaie automatiquement.

Les relays mesurent votre taux de hard bounce et suspendent les comptes qui continuent d’envoyer des messages à des adresses inexistantes, car ce comportement ressemble à celui d’une liste achetée. Les plaintes sont plus importantes. Une plainte survient lorsqu’une personne clique sur le bouton de signalement comme spam. Les recommandations de Google concernant les expéditeurs (vérifiées en août 2026) demandent de rester sous un taux de spam de 0.30 % dans Postmaster Tools et recommandent de rester sous 0.10 %.

Quatre éléments doivent être en place avant que le volume n’augmente :

• un webhook, ou une consultation hebdomadaire de la suppression list du relay, pour détecter les rebonds
• une adresse From correspondant à une véritable boîte aux lettres que quelqu’un consulte, avec Reply-To configuré à l’endroit où les réponses doivent arriver
• une confirmation avant d’ajouter une adresse à quoi que ce soit, afin de ne jamais envoyer de message à une adresse que son propriétaire n’a pas saisie
• une rate limit sur tout formulaire qui déclenche l’envoi de messages

Ce sont les deux derniers points qui posent d’abord problème dans les applications auto-hébergées. Un formulaire d’inscription non protégé permet à n’importe qui de saisir l’adresse d’un tiers. Votre serveur envoie la confirmation, puis ce tiers signale le message comme spam. Empêcher le subscription bombing sur votre formulaire d’inscription relève autant de la délivrabilité que de la lutte contre les abus.

Ne faites pas passer les envois en volume par ce circuit. Les newsletters nécessitent une gestion des listes et des en-têtes de désinscription absents des messages transactionnels. Utilisez donc une instance Listmonk auto-hébergée sur son propre sous-domaine, avec sa propre réputation. Les messages de notification provenant de un forum auto-hébergé se situent entre les deux : ils sont transactionnels par leur structure et volumineux par leur fréquence. Ils permettent généralement de vérifier en premier si votre configuration tient la charge.

À titre de référence, les règles de Gmail applicables aux expéditeurs en volume concernent les expéditeurs qui envoient plus de 5,000 messages par jour à des adresses Gmail. Elles exigent SPF, DKIM, DMARC et un lien de désinscription en un clic pour les messages marketing. La plupart des applications auto-hébergées n’atteignent jamais ce seuil. La partie authentification est désormais attendue de tous les expéditeurs, quelle que soit leur volumétrie.

Testez-le avant de lui faire confiance

swaks est l’outil adapté. Il parle SMTP et affiche toute la conversation, ce qui permet de voir à quelle étape l’échec se produit.

sudo apt install -y swaks
swaks --to you@example.com --from apps@notify.example.com --server smtp.relay.example --port 587 --tls --auth-user '<relay username>' --auth-password '<relay password>'

Cette commande teste directement les identifiants auprès du relay. Pour tester le chemin réellement utilisé par vos applications, indiquez plutôt le host relay :

swaks --to you@example.com --from apps@notify.example.com --server 127.0.0.1

Vérifiez ensuite le résultat de bout en bout, depuis le serveur, avec un vrai message. Les fichiers de configuration ne permettent pas de prouver tout cela. Faites donc le test vous-même :

• envoyez un message à un service de scoring tel que mail-tester.com, qui analyse vos enregistrements SPF, DKIM et DMARC ainsi que le contenu du message, puis explique les raisons du score
• envoyez un message à une boîte aux lettres chez chacun des deux fournisseurs réellement utilisés par vos utilisateurs, puis consultez Authentication-Results dans le message brut
• analysez un message avec learndmarc.com lorsque le résultat de l’alignement n’est pas évident
• déclenchez un envoi depuis l’application elle-même, et pas uniquement depuis la ligne de commande, car c’est l’application qui définit l’en-tête From

Pour terminer, voici un avertissement important. Un domaine entièrement nouveau, même avec les trois enregistrements corrects, arrive parfois dans les spams, car il n’a aucun historique et les destinataires se méfient des domaines apparus la semaine dernière. Commencez avec un faible volume et envoyez des messages attendus par leurs destinataires. La réputation se construit ensuite. Aucune configuration ne permet de contourner cette étape.

FAQ

Pourquoi le port sortant 25 est-il bloqué sur mon VPS ?

Presque tous les fournisseurs bloquent par défaut le port TCP sortant 25, car un serveur compromis auquel ce port est accessible peut envoyer directement du spam aux serveurs de messagerie destinataires. Les paquets sont supprimés plutôt que refusés. Le symptôme est donc une connexion qui reste bloquée puis expire, et non un message d’erreur. Vérifiez-le en exécutant nc -vz -w 5 gmail-smtp-in.l.google.com 25 puis nc -vz -w 5 smtp.relay.example 587 : la première commande reste bloquée, tandis que la seconde répond immédiatement. La solution n’est pas de demander la levée du blocage. Envoyez les messages via un relay sur le port de submission 587 ou 465. Ces ports restent ouverts et sont prévus pour les clients authentifiés.

Ai-je besoin de SPF, DKIM et DMARC pour envoyer seulement quelques notifications de mon application ?

Oui. Le volume ne change rien. Les serveurs destinataires appliquent les mêmes contrôles à un seul message de réinitialisation de mot de passe qu’à une campagne de cinquante mille messages. Sans SPF ni DKIM, vos messages ne sont pas authentifiés, et les recommandations actuelles de Google pour les expéditeurs exigent qu’au moins l’un des deux soit présent pour chaque expéditeur. Sans DMARC, vous ne recevez aucun rapport. Le premier signe d’un problème est alors qu’un utilisateur indique ne jamais avoir reçu le lien de réinitialisation. Les trois mécanismes reposent sur des enregistrements DNS, ne coûtent rien et leur publication prend environ dix minutes.

Dois-je utiliser msmtp ou Postfix comme client relay ?

Utilisez msmtp lorsqu’une seule personne administre le serveur et qu’il est acceptable de perdre un message pendant une panne du relay. Il se limite à un fichier de configuration et n’exécute aucun daemon. Comme il ne met pas les messages en queue, un relay inaccessible entraîne leur perte. Utilisez Postfix en mode satellite si vous voulez une queue qui effectue de nouvelles tentatives pendant plusieurs jours, ou si plusieurs applications s’exécutent avec des utilisateurs système différents. Postfix conserve le mot de passe du relay dans un fichier accessible uniquement à root, que les applications ne lisent jamais. Avec msmtp, le fichier de configuration doit être lisible par chaque utilisateur qui envoie des messages.

Pourquoi les messages de mon application sont-ils refusés parce qu’ils proviennent de root ?

Les tâches cron et de nombreuses applications construisent l’expéditeur à partir de l’utilisateur local et du nom d’hôte. Elles produisent alors une valeur semblable à root@srv1.localdomain. Il ne s’agit pas d’une adresse que vous avez validée auprès du relay. Celui-ci refuse donc le message avec une réponse 553 ou 554 qui indique l’adresse de l’expéditeur. Corrigez ce point au niveau de l’hôte plutôt que dans chaque application : set_from_header on avec une adresse from dans /etc/msmtprc, ou sender_canonical_maps avec sender_canonical_classes = envelope_sender, header_sender dans Postfix. Définissez Reply-To dans chaque application si les réponses doivent parvenir à une personne.

Un sous-domaine distinct pour les messages des applications protège-t-il réellement mon domaine principal ?

Partiellement, mais cela reste utile. Les serveurs destinataires suivent la réputation de chaque domaine. Les plaintes concernant notify.example.com restent donc en grande partie associées à notify.example.com, tandis que votre domaine principal continue de distribuer les messages. La limite est réelle : certains serveurs destinataires reportent les signaux des sous-domaines vers le domaine organisationnel. De plus, une stratégie DMARC publiée au niveau organisationnel s’applique aux sous-domaines, sauf si vous définissez séparément sp=. Considérez le sous-domaine comme une mesure de limitation des dommages, et non comme une garantie.