Auto-héberger son serveur mail en 2026

Survivre aux règles de Gmail, Outlook et consorts

Contexte — Cet article de Clubic (lien) rappelle une vérité technique : SMTP date de 1982, n'a aucune sécurité native, et toutes les "rustines" (SPF, DKIM, DMARC, MTA-STS, DANE) ont été conçues par Yahoo, Cisco, Microsoft, Google. Depuis février 2024 (Google) et mai 2025 (Microsoft), tout expéditeur dépassant 5000 mails/jour vers Gmail/Outlook doit configurer SPF + DKIM + DMARC, maintenir un taux de spam < 0,1 %, et fournir un lien de désinscription en un clic.

Mais même en dessous de 5000/jour, ces règles s'appliquent en pratique : sans elles, ton mail finit en spam ou est rejeté. Ce dossier décrit comment monter son propre serveur mail tout en passant à travers ces filtres.

Sommaire

1. Avant de commencer : est-ce vraiment une bonne idée ?
2. Prérequis techniques
3. Architecture cible
4. Choix du fournisseur et de l'IP
5. Configuration DNS complète
6. Installation du stack mail
7. SPF, DKIM, DMARC : les rustines obligatoires
8. MTA-STS, TLS-RPT, DANE : aller plus loin
9. PTR (reverse DNS) et HELO
10. Warmup d'IP : la phase la plus délicate
11. Postmaster Tools, SNDS, FBL
12. Liste de désinscription en un clic (RFC 8058)
13. Anti-spam entrant et hygiène
14. Monitoring, logs, alertes
15. Que faire quand Gmail rejette quand même ?
16. Checklist finale avant mise en prod
17. Annexes : commandes utiles

1. Avant de commencer : est-ce vraiment une bonne idée ?

L'auto-hébergement mail est techniquement possible, mais c'est probablement le service le plus pénible à maintenir en 2026. Avant de te lancer, lis ça :

Ce qui marche bien en auto-hébergé :

• Recevoir du mail (presque tout le monde te livre).
• Envoyer vers d'autres serveurs auto-hébergés ou pros bien configurés.
• Garder le contrôle sur tes données, tes alias, tes domaines.

Ce qui est dur :

• Envoyer vers Gmail / Outlook / Yahoo / iCloud sans atterrir en spam.
• Sortir d'une blacklist une fois dedans.
• Maintenir un score de réputation IP correct sur la durée.
• Survivre à un changement unilatéral des règles côté gros acteurs (cf. février 2024 et mai 2025).

Stratégie réaliste recommandée :

• Réception entrante : auto-hébergée à 100 %. Aucun risque, full contrôle.
• Envoi sortant : deux options, selon ton volume et ton tolérance au risque.
  • Option A — Pure auto-hébergée : tu envoies directement depuis ton serveur. Faisable, mais demande un warmup, une IP propre, et un suivi continu.
  • Option B — Smart host sortant : tu envoies via un relais réputé (un autre de tes serveurs avec une IP qui a déjà sa réputation, ou un service type Mailjet/Sendgrid/SMTP2GO en bas volume gratuit). Tes mails sortent depuis l'IP du relais, qui a déjà sa réputation faite. C'est un compromis : tu perds une partie de la souveraineté technique, mais tu gagnes énormément en délivrabilité.

Le reste du dossier suit l'option A — tout en t'expliquant comment basculer en B si nécessaire.

2. Prérequis techniques

Compétences attendues : Linux en ligne de commande, DNS (champs A/AAAA/MX/TXT/SRV/CAA/TLSA), notion de TLS, lecture de logs journalctl et /var/log/mail.log.

3. Architecture cible

Un stack standard, éprouvé, en logiciels libres :

                 ┌─────────────────────────────────────┐
                 │  Internet (mails entrants/sortants) │
                 └─────────────────────────────────────┘
                                  │
                                  ▼ port 25
                         ┌────────────────┐
                         │    Postfix     │  ← MTA (envoi/réception SMTP)
                         │ (SMTP / 25/587)│
                         └────────────────┘
                          │      │      │
                          ▼      ▼      ▼
                    ┌─────────┐ ┌─────────┐ ┌──────────┐
                    │ Rspamd  │ │OpenDKIM │ │ Dovecot  │  ← IMAP/POP + LMTP
                    │(spam,   │ │ (signe  │ │ (livrai- │
                    │ DKIM    │ │ DKIM)   │ │  son aux │
                    │ verif,  │ └─────────┘ │  boîtes) │
                    │ DMARC)  │             └──────────┘
                    └─────────┘                  │
                                                 ▼
                                            Maildir / utilisateurs

Composants :

• Postfix : MTA. Reçoit, route, envoie le SMTP.
• Dovecot : serveur IMAP/POP3, livraison locale (LMTP), authentification SASL pour Postfix, gestion Sieve (filtres).
• Rspamd : antispam moderne, fait aussi la vérification SPF/DKIM/DMARC entrante, le greylisting, et — option recommandée — la signature DKIM sortante (en remplacement d'OpenDKIM).
• Let's Encrypt (certbot) : TLS.
• (Optionnel) Roundcube ou SnappyMail : webmail.

Alternative tout-en-un : Mailcow ou Mailu, basés sur Docker, qui empaquètent tout ça avec une interface admin. Si tu préfères ne pas tout configurer à la main, c'est légitime — la majorité des règles DNS et de délivrabilité de ce dossier restent identiques.

4. Choix du fournisseur et de l'IP

Le choix de l'hébergeur conditionne la moitié de ta délivrabilité. Avant de prendre un VPS :

1. Le port 25 sortant est-il ouvert ? Beaucoup d'hébergeurs le bloquent par défaut pour limiter le spam (Hetzner l'ouvre sur demande, OVH l'ouvre selon le produit, Scaleway l'ouvre selon le compte). Pose la question au support avant de payer.

2. Le PTR est-il configurable ? Si non, change.

3. L'IP a-t-elle été utilisée par un spammeur ? Avant d'acheter le VPS, demande l'IP qu'on te donnera. Vérifie sur :

   • mxtoolbox.com/blacklists.aspx
   • multirbl.valli.org
   • talosintelligence.com (Cisco)
   • senderscore.org

   Si l'IP est listée sur Spamhaus, Barracuda, SORBS, SpamCop, demande à l'hébergeur de te l'échanger ou prends un autre VPS. Une fois listée, tu vas y passer des semaines.

4. Réputation du subnet (/24). Même si ton IP est propre, si le /24 est pourri (beaucoup de spammeurs voisins), Gmail va te traiter avec méfiance. Vérifie sur senderscore.org en saisissant ton IP — le score du subnet apparaît.

Hébergeurs réputés corrects pour le mail : Hetzner, OVH (gamme dédiée, pas SoYouStart), Scaleway, Infomaniak (en VPS), Netcup. À éviter pour de l'envoi : DigitalOcean (subnets souvent grillés), Linode/Akamai (idem), AWS EC2 (le port 25 est limité par défaut, et la rate-limit est costaude).

5. Configuration DNS complète

Pour un domaine exemple.fr avec un serveur mail sur mail.exemple.fr à l'IP 203.0.113.10 (et 2001:db8::10 en v6) :

;; Enregistrement du serveur mail lui-même
mail.exemple.fr.        IN  A     203.0.113.10
mail.exemple.fr.        IN  AAAA  2001:db8::10

;; MX : qui reçoit les mails du domaine
exemple.fr.             IN  MX  10 mail.exemple.fr.

;; SPF : qui a le droit d'envoyer pour ce domaine
exemple.fr.             IN  TXT "v=spf1 mx -all"

;; DKIM (clé publique, le sélecteur ici est "mail")
mail._domainkey.exemple.fr.  IN  TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

;; DMARC
_dmarc.exemple.fr.      IN  TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.fr; ruf=mailto:dmarc@exemple.fr; fo=1; adkim=s; aspf=s; pct=100"

;; MTA-STS (cf. §8)
_mta-sts.exemple.fr.    IN  TXT "v=STSv1; id=20260509T000000;"
mta-sts.exemple.fr.     IN  A   203.0.113.10

;; TLS-RPT (rapports d'erreurs TLS)
_smtp._tls.exemple.fr.  IN  TXT "v=TLSRPTv1; rua=mailto:tls-reports@exemple.fr"

;; CAA : restreindre qui peut émettre des certifs pour ton domaine
exemple.fr.             IN  CAA 0 issue "letsencrypt.org"

;; Autodiscover / autoconfig (pour les clients mail)
autoconfig.exemple.fr.  IN  CNAME mail.exemple.fr.
autodiscover.exemple.fr. IN CNAME mail.exemple.fr.

Détails dans les sections dédiées plus bas.

À ne pas oublier : l'enregistrement PTR (reverse DNS) se configure chez ton hébergeur, pas dans ta zone DNS. Il doit pointer 203.0.113.10 → mail.exemple.fr. C'est traité au §9.

6. Installation du stack mail

Sur Debian 12. Ce qui suit est volontairement condensé — pour une configuration ligne par ligne, suis le tutoriel de référence de Workaround.org qui est l'étalon depuis 20 ans.

# Mise à jour
apt update && apt upgrade -y

# Stack de base
apt install -y postfix postfix-mysql dovecot-core dovecot-imapd \
    dovecot-lmtpd dovecot-managesieved dovecot-sieve dovecot-mysql \
    rspamd redis-server mariadb-server certbot

# Certificat TLS
certbot certonly --standalone -d mail.exemple.fr \
    -d mta-sts.exemple.fr \
    -d autoconfig.exemple.fr -d autodiscover.exemple.fr

Postfix : configuration main.cf minimale-mais-saine

# /etc/postfix/main.cf
myhostname = mail.exemple.fr
mydomain = exemple.fr
myorigin = $mydomain
mydestination =                       # Vide : on utilise virtual_mailbox_domains
inet_interfaces = all
inet_protocols = all                  # IPv4 + IPv6

# TLS — chiffrement obligatoire
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.exemple.fr/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/mail.exemple.fr/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_security_level = may
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_dns_support_level = dnssec       # Indispensable pour DANE
smtp_tls_security_level = dane        # ou "may" si DANE pas encore prêt
smtp_host_lookup = dns

# Restrictions anti-relais ouvert
smtpd_relay_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination

smtpd_recipient_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination
    reject_unknown_recipient_domain
    reject_invalid_helo_hostname
    reject_non_fqdn_helo_hostname

# Limites raisonnables
message_size_limit = 52428800         # 50 Mo
mailbox_size_limit = 0
recipient_delimiter = +

# Intégration Rspamd
smtpd_milters = inet:localhost:11332
non_smtpd_milters = inet:localhost:11332
milter_protocol = 6
milter_default_action = accept
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}

# Livraison via Dovecot LMTP
virtual_transport = lmtp:unix:private/dovecot-lmtp

Dovecot, Rspamd

Ces composants demandent leurs propres fichiers de configuration. Renvoi explicite vers les tutos qui font autorité :

• Workaround.org / ISPmail : https://workaround.org/ispmail/ — référence francophone et anglophone, mise à jour à chaque version Debian.
• Rspamd quickstart : https://www.rspamd.com/doc/tutorials/quickstart.html
• Dovecot wiki : https://doc.dovecot.org/

Si tu veux gagner du temps, Mailcow (docker compose) est aujourd'hui la solution clé-en-main la plus fiable.

7. SPF, DKIM, DMARC : les rustines obligatoires

Sans ces trois enregistrements correctement configurés, Gmail et Outlook rejetteront ou marqueront en spam la majorité de tes messages — peu importe ton volume.

SPF (Sender Policy Framework)

Déclare qui a le droit d'envoyer du mail pour ton domaine.

exemple.fr.  IN  TXT "v=spf1 mx -all"

• mx : autorise les serveurs listés dans le MX du domaine.
• -all : rejet strict de tout le reste. Indispensable pour la réputation. Ne jamais utiliser ~all (softfail) en prod : Gmail aujourd'hui considère ~all comme un signal faible.

Si tu envoies aussi via un relais externe (smart host) : ajoute son include, ex. v=spf1 mx include:_spf.mailjet.com -all.

Limite : un enregistrement SPF doit tenir en 10 lookups DNS maximum. Au-delà, il est invalide. Vérifie avec https://www.kitterman.com/spf/validate.html.

DKIM (DomainKeys Identified Mail)

Signe chaque mail sortant avec une clé privée. Le destinataire vérifie la signature via la clé publique publiée en DNS.

Génération de la clé (Rspamd, sélecteur mail, clé 2048 bits) :

mkdir -p /var/lib/rspamd/dkim
rspamadm dkim_keygen -s mail -d exemple.fr -k /var/lib/rspamd/dkim/exemple.fr.mail.key \
    -b 2048 > /var/lib/rspamd/dkim/exemple.fr.mail.txt
chown _rspamd:_rspamd /var/lib/rspamd/dkim/*

Le fichier .txt contient l'enregistrement DNS à publier :

mail._domainkey.exemple.fr.  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." )

Configuration Rspamd (/etc/rspamd/local.d/dkim_signing.conf) :

allow_username_mismatch = true;
domain {
    exemple.fr {
        path = "/var/lib/rspamd/dkim/exemple.fr.mail.key";
        selector = "mail";
    }
}

Recharge : systemctl restart rspamd.

Vérification : envoie un mail à check-auth@verifier.port25.com, tu reçois un rapport complet SPF/DKIM/DMARC en retour. Ou utilise https://www.mail-tester.com/ (note sur 10).

DMARC (Domain-based Message Authentication, Reporting and Conformance)

Dit aux serveurs distants quoi faire en cas d'échec SPF/DKIM, et te renvoie des rapports sur ce qui passe et ce qui rate.

_dmarc.exemple.fr.  IN  TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.fr; ruf=mailto:dmarc@exemple.fr; fo=1; adkim=s; aspf=s; pct=100"

• p=none : surveillance seule, à utiliser pendant 2-4 semaines en démarrage pour collecter les rapports sans pénaliser.
• p=quarantine : mise en spam des mails non authentifiés. Cible normale.
• p=reject : rejet pur. À atteindre en cible finale, après avoir vérifié 4 semaines de rapports propres.
• rua : adresse pour les rapports agrégés (quotidiens).
• ruf : rapports forensiques (par message). Optionnel.
• adkim=s aspf=s : alignement strict — le domaine de signature DKIM et le domaine SPF doivent exactement correspondre au domaine From:.

Lecture des rapports DMARC : ils arrivent en XML, illisibles. Utilise un parseur :

• Postmark DMARC Monitoring (gratuit, agrège les rapports dans une UI).
• parsedmarc (auto-hébergeable, envoie dans Elasticsearch/Splunk/Grafana).

8. MTA-STS, TLS-RPT, DANE : aller plus loin

Ces standards sécurisent le transport entre serveurs (chiffrement TLS forcé). Gmail les regarde, Microsoft aussi. Pas obligatoires, mais ils boostent ta réputation.

MTA-STS

Force les serveurs distants à utiliser TLS pour t'envoyer des mails. Trois éléments :

1. Enregistrement DNS TXT :

_mta-sts.exemple.fr.  IN  TXT "v=STSv1; id=20260509T000000;"

2. Sous-domaine mta-sts.exemple.fr servant un fichier en HTTPS à https://mta-sts.exemple.fr/.well-known/mta-sts.txt :

version: STSv1
mode: enforce
mx: mail.exemple.fr
max_age: 604800

mode: enforce est la cible. En démarrage, mets mode: testing pendant 1-2 semaines.

3. Certificat TLS valide sur ce sous-domaine (déjà fait via certbot au §6).

TLS-RPT

Demande aux serveurs distants de t'envoyer des rapports en cas d'échec TLS.

_smtp._tls.exemple.fr.  IN  TXT "v=TLSRPTv1; rua=mailto:tls-reports@exemple.fr"

DANE (DNS-based Authentication of Named Entities)

Encore plus solide que MTA-STS, mais nécessite DNSSEC activé sur ton domaine. Si ton registrar ne supporte pas DNSSEC, oublie DANE.

DANE publie un hash du certificat TLS dans un enregistrement TLSA :

# Générer l'enregistrement TLSA pour le port 25
posttls-finger -t30 -T180 -P /etc/ssl/certs/ -lsecure mail.exemple.fr

Ou plus simplement avec https://www.huque.com/bin/gen_tlsa :

_25._tcp.mail.exemple.fr.  IN  TLSA 3 1 1 ABC123...

Vérification globale de tout ton setup TLS+DANE : https://internet.nl/mail/ (excellent, recommandé).

9. PTR (reverse DNS) et HELO

Le PTR est probablement la cause la plus fréquente de rejet par Gmail/Outlook chez les nouveaux auto-hébergés.

Règle absolue : PTR(IP) == HELO == nom A/AAAA, et tout doit être un FQDN cohérent.

Configure le PTR dans le panneau de ton hébergeur (chez OVH : "IP" → "Reverse DNS") :

203.0.113.10  → mail.exemple.fr
2001:db8::10  → mail.exemple.fr

Vérifie :

dig -x 203.0.113.10 +short
# doit retourner : mail.exemple.fr.

dig mail.exemple.fr A +short
# doit retourner : 203.0.113.10

Dans Postfix, myhostname = mail.exemple.fr et c'est ce qui est annoncé en HELO. Cohérence garantie.

10. Warmup d'IP : la phase la plus délicate

Une IP neuve = pas de réputation = défiance maximale des gros acteurs. Tu ne peux pas envoyer 1000 mails le jour 1 sans te griller.

Plan de warmup sur 4 à 6 semaines

Règles d'or pendant le warmup :

• Pas de mailing list, pas de notifs automatiques en masse. Privilégie des mails 1-à-1 conversationnels.
• Demande aux destinataires de répondre — un mail avec réponse a 100x le poids d'un mail ouvert silencieusement.
• Aucun lien raccourci, aucun pixel de tracking, aucune image lourde.
• Stop net si ton score Senderscore baisse ou si Gmail Postmaster Tools (cf. §11) montre du rouge.

Si tu as un volume immédiat à envoyer

Bascule en option B (smart host) le temps du warmup, puis rapatrie progressivement en interne en répliquant les volumes ci-dessus.

11. Postmaster Tools, SNDS, FBL

Les gros acteurs te donnent des dashboards dédiés. Inscris-toi à tous, dès la création du domaine.

Configure les feedback loops (FBL) : quand un destinataire clique "spam", tu reçois une notification. Ça te permet de désinscrire l'utilisateur avant qu'il ne dégrade ta réputation.

12. Liste de désinscription en un clic (RFC 8058)

Exigence Google/Microsoft pour les expéditeurs en volume, mais à mettre en place dès le début même en bas volume.

Ajoute deux en-têtes à tous les mails non-strictement-personnels :

List-Unsubscribe: <https://exemple.fr/unsub?token=abc123>, <mailto:unsub@exemple.fr?subject=unsub-abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

L'URL HTTPS doit accepter une requête POST (pas seulement GET) avec List-Unsubscribe=One-Click dans le corps, et désinscrire immédiatement et silencieusement sans demander de confirmation.

13. Anti-spam entrant et hygiène

Un serveur mail mal configuré côté entrée devient vite un relais de spam ou une cible. Configuration Rspamd minimale :

# /etc/rspamd/local.d/actions.conf
reject = 15;
add_header = 6;
greylist = 4;

# /etc/rspamd/local.d/greylist.conf
expire = 1d;

Active aussi :

• Vérification SPF/DKIM/DMARC entrante (par défaut activée dans Rspamd).
• RBL (Realtime Blackhole Lists) : Spamhaus ZEN, Barracuda. Attention à ne pas multiplier — 2 ou 3 RBL fiables suffisent.
• Greylisting : refuse temporairement les premiers contacts, ce qui élimine 80% du spam basique. Ne pas activer sur un domaine à fort volume transactionnel (gêne les notifs).
• Bayes : laisse Rspamd apprendre via le dossier Junk de Dovecot (signal IsSpam / IsHam).

Mises à jour : unattended-upgrades activé, redémarrage planifié, lecture des annonces sécu Postfix/Dovecot.

14. Monitoring, logs, alertes

Sans monitoring, tu découvres les problèmes par les utilisateurs. À mettre en place :

• Lecture des logs : journalctl -u postfix -f, tail -f /var/log/mail.log, web UI de Rspamd sur localhost:11334.
• Métriques : exporter Postfix/Dovecot vers Prometheus + Grafana (postfix_exporter, dovecot_exporter).
• Alertes sur :
  • File d'attente Postfix > 50 messages (mailq | tail -1).
  • Score Senderscore qui chute.
  • Apparition sur une RBL : surveillance automatisée par https://multirbl.valli.org/ ou via un script qui interroge plusieurs DNSBL en cron.
  • Échec TLS-RPT (rapport entrant signalant une connexion non chiffrée).
• Rapports DMARC parsés régulièrement (cf. §7).

15. Que faire quand Gmail rejette quand même ?

Ça arrive. Diagnostic dans l'ordre :

1. Lis le code de rejet SMTP dans /var/log/mail.log. Gmail renvoie des codes très explicites :
   • 550-5.7.1 [203.0.113.10 19] Our system has detected that this message is likely unsolicited mail. → contenu jugé spammy. Revois le contenu, ajoute du texte conversationnel, retire les liens douteux.
   • 421-4.7.0 [203.0.113.10 15] Our system has detected an unusual rate of unsolicited mail. → tu as dépassé un seuil. Ralentis immédiatement, attends 24-48h, reprends doucement.
   • 550-5.7.26 ... DMARC ... → ton DMARC ne passe pas. Revérifie SPF/DKIM/alignement.
   • 550-5.7.1 ... blocked using Spamhaus. → tu es sur une RBL. Va sur spamhaus.org/lookup/ pour vérifier et demander la sortie.
2. Va dans Postmaster Tools (§11). Si "IP reputation" est rouge ou orange, regarde le contenu et le timing de tes envois récents.
3. Test mail-tester : envoie à une adresse fournie par mail-tester.com, obtiens une note sur 10. Vise 10/10. Toute case manquante doit être corrigée.
4. Sortie de blacklist : la plupart des RBL (Spamhaus, Barracuda) ont un formulaire de retrait. Spamhaus retire en quelques heures si tu corriges la cause. SORBS est plus lent. UCEPROTECT exige souvent de payer — ignore-la, peu de serveurs sérieux la consultent.
5. Si rien ne marche, change d'IP. C'est parfois la seule issue. Demande à ton hébergeur une IP fraîche, refais un warmup.

16. Checklist finale avant mise en prod

Avant d'envoyer le premier vrai mail :

• [ ] Domaine avec DNSSEC activé.
• [ ] IP testée sur 5+ blacklists, propre.
• [ ] Port 25 sortant ouvert et testé (telnet gmail-smtp-in.l.google.com 25).
• [ ] PTR configuré et cohérent avec le HELO.
• [ ] MX, A, AAAA, SPF, DKIM, DMARC publiés et validés via mxtoolbox.com.
• [ ] MTA-STS publié (mode testing au démarrage).
• [ ] TLS-RPT publié.
• [ ] DANE/TLSA publié (si DNSSEC OK).
• [ ] CAA publié.
• [ ] Test envoyé à check-auth@verifier.port25.com : tout en pass.
• [ ] Test mail-tester.com : 10/10.
• [ ] Test internet.nl/mail/ : 100%.
• [ ] Inscription Postmaster Tools, SNDS, JMRP, Yahoo CFL.
• [ ] DMARC p=none au démarrage, parser de rapports en place.
• [ ] List-Unsubscribe + List-Unsubscribe-Post implémentés.
• [ ] Plan de warmup affiché et respecté.
• [ ] Monitoring file d'attente + RBL en place.
• [ ] Backup chiffré des Maildir.

Au bout de 4 semaines de rapports DMARC propres : passage à p=quarantine. Au bout de 8-12 semaines : p=reject.

17. Annexes : commandes utiles

# Voir la file d'attente
mailq
postqueue -p

# Forcer la tentative de livraison
postqueue -f

# Vider la file (à utiliser avec précaution)
postsuper -d ALL

# Tester la délivrabilité d'un domaine cible (DANE / TLS)
posttls-finger -t30 -T180 -P /etc/ssl/certs/ -lsecure gmail-smtp-in.l.google.com

# Vérifier ses propres enregistrements
dig exemple.fr TXT +short
dig _dmarc.exemple.fr TXT +short
dig mail._domainkey.exemple.fr TXT +short
dig mail.exemple.fr MX +short
dig -x 203.0.113.10 +short

# Tester l'envoi en SMTP authentifié
swaks --to test@gmail.com --from moi@exemple.fr \
      --server mail.exemple.fr --auth --auth-user moi@exemple.fr \
      --tls --port 587

# Voir en temps réel ce qu'il se passe
journalctl -u postfix -u dovecot -u rspamd -f

Outils web à mettre en favoris

• https://www.mail-tester.com/ — score sur 10
• https://internet.nl/mail/ — audit complet
• https://mxtoolbox.com/SuperTool.aspx — DNS, blacklists
• https://dmarcian.com/dmarc-inspector/ — vérif DMARC
• https://www.kitterman.com/spf/validate.html — vérif SPF
• https://postmaster.google.com/ — Google Postmaster
• https://senderscore.org/ — réputation IP

Documentation de référence

• ISPmail / Workaround.org — https://workaround.org/ispmail/ — le tutoriel le plus complet et tenu à jour, par version Debian.
• Mailcow docs — https://docs.mailcow.email/ — pour la version conteneurisée clé-en-main.
• Postfix officiel — https://www.postfix.org/documentation.html
• Rspamd docs — https://www.rspamd.com/doc/
• RFCs essentielles : 5321 (SMTP moderne), 7208 (SPF), 6376 (DKIM), 7489 (DMARC), 8461 (MTA-STS), 8460 (TLS-RPT), 7672 (DANE-SMTP), 8058 (One-Click Unsubscribe).

L'auto-hébergement mail en 2026 reste possible, mais c'est devenu un sport : les règles changent, les gros acteurs durcissent leurs critères, et l'écosystème pousse vers la centralisation. Si tu réussis le warmup et tiens 6 mois sans incident, tu as gagné — mais ne baisse pas la garde, un changement unilatéral de Google peut survenir à tout moment, comme en février 2024.