Guide délivrabilité

1. Contenu : ce que les filtres regardent vraiment

Première mise au point : la fameuse « liste de mots déclencheurs » (gratuit, urgent, gagner...) est un mythe datant des filtres à règles des années 2000. Depuis, les filtres de Gmail, Outlook et consorts sont des modèles de machine learning entraînés sur des milliards de messages. Un mot isolé ne déclenche plus rien : c'est l'ensemble des signaux qui compte.

Les vrais signaux pris en compte

• l'état de l'authentification (SPF/DKIM/DMARC et leur alignement) — le critère n°1 ;
• l'âge du domaine et son historique de réputation ;
• la réputation de l'IP et la courbe de volume d'envoi (une explosion soudaine est un signal) ;
• l'engagement du destinataire : ouverture, réponse, suppression sans lecture, signalement spam ;
• les caractéristiques structurelles : ratio HTML/texte, nombre de liens, ratio image/texte ;
• la similarité sémantique avec des patrons de spam connus (embeddings).

Ce qui nuit réellement au placement

• Densité de liens élevée : 3 liens ou plus dans un message court, surtout avec des raccourcisseurs (bit.ly, tinyurl, t.co).
• Contenu noyé : un message simple emballé dans des Ko de HTML avec CSS inline, ou un ratio image/texte inversé (80 % image / 20 % texte).
• Envois identiques en masse : le même corps envoyé à des milliers de destinataires dans une fenêtre de 24 h.
• Pièce jointe au premier contact : signal fort de phishing.
• Objets trompeurs : « Re: » ou « Fwd: » mensongers sur un vrai premier contact, « URGENT REQUEST », « Last Chance », le nom du destinataire dans le display name. Gmail le classe explicitement comme trompeur.
• Contenu masqué : texte caché en CSS (display:none, police de 1 px) — le masquage envoie en spam.
• « Répondez STOP pour vous désabonner » dans de l'outreach : classé comme marketing, donc soumis aux exigences de désinscription.

Les patterns résiduels « à l'ancienne » (MAJUSCULES, !!!, $$$, « 100 % gratuit », symboles monétaires dans l'objet) comptent encore, mais comme corrélation statistique, pas comme règle absolue.

Les règles d'or du contenu

• Ton factuel, identité claire : en-têtes exacts et non trompeurs, display name qui identifie l'expéditeur seul.
• Ratio texte/image : 60:40 texte/image pour une newsletter marketing, 95 %+ de texte pour l'outreach individuel. Un message doit rester compréhensible images coupées.
• Liens visibles et compréhensibles : ancres descriptives, pas de raccourcisseurs.
• Séparer les flux : une adresse From par catégorie de message, transactionnel et promotionnel sur des IP distinctes.
• Désinscription en un clic — exigence Gmail pour tout message marketing (RFC 8058) :

L'URI doit être en HTTPS et répondre à un simple POST, sans navigation. Un lien visible dans le corps est requis, et les demandes doivent être honorées sous 48 h. Les liens mailto ou une simple page de préférences ne suffisent pas. Les messages transactionnels (confirmation de réservation, réinitialisation de mot de passe) sont exclus de l'exigence one-click.

2. SPF, DKIM, DMARC, BIMI : l'authentification

Ces mécanismes prouvent au serveur de réception que votre email vient bien de vous. Ils sont vérifiés systématiquement, et Gmail les exige pour tout envoi de masse. Les RFC ci-dessous font foi — les chiffres cités en sont extraits.

2.1 SPF — RFC 7208

SPF publie, en TXT, la liste des IP autorisées à envoyer pour votre domaine. Mécanismes : ip4, ip6, a, mx, include, et le record se termine toujours par all.

• Limite des 10 lookups (RFC 7208 §4.6.4, citation exacte) : « SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation ». Les termes concernés : include, a, mx, ptr, exists, redirect. Au-delà : permerror, le record échoue chez de nombreux récepteurs.
• Le record doit tenir sous 512 octets (RFC 7208 §3.4) pour éviter la troncature DNS sans EDNS0.
• ptr est explicitement déconseillé (coût DNS élevé, résultat fragile) — et il compte dans les 10 lookups.
• ~all (softfail) en phase de transition, -all (hardfail) une fois la liste complète.
• Un seul record TXT par domaine, pas de concaténation. En cas de dépassement : aplatir (flattening) ou réduire les includes.

2.2 DKIM — RFC 6376 + RFC 8301

DKIM signe cryptographiquement certains en-têtes et le corps ; la clé publique est publiée en TXT sur sélecteur._domainkey.votredomaine.com.

• Longueur de clé (RFC 8301) : RSA d'au moins 1024 bits obligatoire pour signer, 2048 bits recommandé. Gmail exige 1024 bits minimum et recommande 2048.
• Algorithme : rsa-sha1 interdit, rsa-sha256 obligatoire.
• Rotation : publier une nouvelle clé sur un nouveau sélecteur, garder les deux en DNS pendant la transition, supprimer l'ancienne après 1-2 ans.
• Piège DNS : une clé RSA 2048 bits dépasse 255 caractères — il faut découper la valeur TXT en plusieurs chaînes (autorisé par le standard DNS).

2.3 DMARC — RFC 7489

DMARC, publié sur _dmarc.votredomaine.com, dit au récepteur quoi faire des messages qui échouent SPF/DKIM : none, quarantine ou reject.

• L'alignement (RFC 7489 §3.1) : relâché = le domaine organisationnel doit correspondre (d=exemple.com aligné avec From news.exemple.com) ; strict = correspondance exacte du FQDN. Un pass sur SPF OU DKIM suffit pour passer DMARC — Gmail recommande l'alignement double et l'annonce comme futur obligatoire.
• Déploiement recommandé : p=none avec rua= pour observer (les rapports agrégés arrivent de Gmail et Microsoft), corriger les sources non alignées, puis durcir vers quarantine puis reject.
• Gmail : DMARC obligatoire pour les bulk senders, p=none minimum. Microsoft : idem au-delà de 5 000 messages/jour, avec rejet possible (code 550 5.7.515) si absent.

2.4 BIMI — à connaître, pas à brûler

BIMI affiche votre logo à côté de vos emails. Point de rigueur : c'est un Internet-Draft IETF (pas un RFC), et il n'améliore pas directement le placement — c'est un indicateur de confiance visuelle.

• Conditions : DMARC en quarantine ou reject (p=none exclu), logo en SVG Tiny PS servi en HTTPS, enregistrement sur default._bimi.votredomaine.com.
• Gmail exige un VMC (Verified Mark Certificate) : délivré uniquement par DigiCert ou Entrust, environ 1 500 USD/an, exige une marque déposée. Apple, Yahoo, Fastmail l'affichent sans VMC ; Outlook ne le supporte pas.

3. Monter son serveur SMTP sur VPS (Postfix + OpenDKIM)

Un SMTP maison donne un contrôle total, mais l'infrastructure est exigeante : PTR, SPF/DKIM/DMARC, TLS, et un chauffage d'IP progressif. Sans cela, votre IP sera blacklistée en quelques jours.

Étape 1 — Installer

opendkim-tools fournit opendkim-genkey — piège classique : « command not found » sans ce paquet.

Étape 2 — Configurer OpenDKIM

Étape 3 — Générer les clés

-b 2048 : conforme RFC 8301 et recommandation Google. Publiez ensuite la valeur du fichier mail.txt généré dans le record TXT mail._domainkey (découpée en plusieurs chaînes si > 255 caractères).

Étape 4 — Brancher Postfix

Étape 5 — Le PTR, prérequis absolu

Google l'exige pour TOUS les expéditeurs : « The sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record ». Le hostname doit aussi avoir un A/AAAA qui pointe vers la même IP (forward DNS). L'absence ou l'incohérence produit des erreurs 4.7.23/5.7.25 chez Gmail. Le PTR se configure dans le panneau de votre hébergeur (OVH, Hetzner, Scaleway...), pas dans votre DNS.

Étape 6 — TLS et port 25

• TLS obligatoire pour transmettre vers Gmail (erreurs 4.7.29/5.7.29 sinon).
• Le port 25 est le port de relais entre serveurs. Beaucoup de FAI et clouds le restreignent par défaut (AWS le throttle sur EC2, demande de déblocage nécessaire).
• Pour la soumission depuis un client, on utilise 587 (STARTTLS) ou 465 (TLS implicite).
• Pare-feu réseau de l'hébergeur : ufw ne suffit pas toujours — vérifiez aussi le firewall applicatif de l'hébergeur.

Étape 7 — Chauffer et surveiller

• Une IP neuve part de zéro en réputation, et le domaine a SA propre réputation (surtout chez Gmail). Un warmup typique monte progressivement sur 4-6 semaines, en ciblant d'abord les destinataires les plus engagés. Volume massif le premier jour = throttling, greylisting ou blocage.
• Blacklists Spamhaus : SBL (spam/malware), PBL (IP qui ne devraient pas envoyer), XBL (machines compromises), DBL (domaines de spam), ZEN (SBL+PBL+XBL). Une IP listée est quasi systématiquement rejetée.
• Taux de bounce : hard bounce < 1 % sur liste saine (moyenne observée ~0,2 %), soft bounce répété sur 3 campagnes = à traiter comme un hard bounce. Au-delà de 5 % : problème actif de qualité de liste.
• Taux de plaintes : < 0,1 % chez Gmail, < 0,3 % chez Yahoo. Le double opt-in est le meilleur garde-fou.
• Surveillance : Google Postmaster Tools (réputation IP + domaine, taux de spam), SNDS et JMRP chez Microsoft.

4. Monter son serveur SMTP avec AWS SES

Amazon SES (Simple Email Service) délègue l'infrastructure : pas de serveur à maintenir, une réputation gérée par AWS, et un coût à l'envoi (0,10 $ pour 1 000 emails). Le revers : quotas à faire monter, identités à vérifier, et des règles strictes de consentement.

Étape 1 — Le sandbox, puis la production

• Tout nouveau compte SES est en sandbox (par région) : 200 messages/24 h maximum, 1 message/seconde, uniquement vers des adresses vérifiées ou le mailbox simulator.
• Passage en production : vérifier d'abord une identité (de préférence un domaine — cela accélère l'approbation), puis console → Account dashboard → Request production access, en déclarant le type de trafic (marketing ou transactionnel) et l'URL du site. Réponse du support AWS sous 24 h.
• Via CLI : aws sesv2 put-account-details --production-access-enabled --mail-type TRANSACTIONAL --website-url https://votresite.com --additional-contact-email-addresses contact@votresite.com --contact-language FR

Étape 2 — Vérifier le domaine

SES vous donne les enregistrements à publier chez votre registraire : 3 records DKIM (CNAME) gérés automatiquement, 1 MX (retours), 1 TXT SPF. Le SPF et le DKIM sont donc gérés pour vous — l'avantage majeur par rapport au VPS maison. Toutes les identités utilisées en From/Source/Sender/Return-Path doivent rester vérifiées, y compris en production.

Étape 3 — Les identifiants SMTP

Étape 4 — Quotas et bonnes pratiques

• Hors sandbox : quota initial commun de 50 000 messages/24 h, ajustable selon l'usage déclaré. 50 destinataires max par message (To/CC/BCC cumulés), 10 Mo par message via API v1, 40 Mo via API v2 ou SMTP.
• Configuration sets + event publishing (SNS/EventBridge) pour surveiller bounces et plaintes, et supprimer immédiatement les hard bounces. Taux de plainte à garder sous 0,1 %.
• Augmenter le volume progressivement, en cohérence avec les règles de croissance de volume de Gmail.
• Piège EC2 : si l'envoi passe par une instance EC2, il faut demander le déblocage du throttle du port 25 de l'instance.
• La demande de production access exige de déclarer qu'on ne cible que des destinataires consentants — c'est le filtre anti-spam d'AWS.

VPS ou AWS : le choix

5. La checklist « prêt à envoyer »

1. SPF publié, sous 10 lookups, terminant par ~all ou -all (RFC 7208).
2. DKIM signé en rsa-sha256, clé ≥ 1024 bits (2048 recommandé), sélecteur publié et testable (RFC 6376 + 8301).
3. DMARC publié avec rua=, p=none au minimum ; alignement SPF ou DKIM vérifié ; objectif p=quarantine puis p=reject (RFC 7489).
4. PTR valide et cohérent avec le forward DNS (exigence Gmail pour tous).
5. TLS forcé sur la transmission.
6. Format RFC 5322 : Message-ID présent, en-têtes uniques, From simple.
7. Désinscription one-click RFC 8058 pour tout marketing, honorée sous 48 h, lien visible dans le corps.
8. Taux de plaintes < 0,1 % (Gmail), < 0,3 % (Yahoo) ; bounce < 2 % (hard < 1 %) ; nettoyage trimestriel des listes.
9. Volume progressif : warmup IP + domaine sur 4-6 semaines en ciblant les engagés.
10. Contenu simple : 60:40 texte/image max, liens peu nombreux et clairs, zéro pattern trompeur (Re:/Fwd: mensongers, contenu masqué).
11. Surveillance : Postmaster Tools (Google), SNDS/JMRP (Microsoft), blacklists Spamhaus.