La plupart des équipes SaaS découvrent la délivrabilité de la même façon : un client écrit « je n'ai jamais reçu l'e-mail de réinitialisation du mot de passe », quelqu'un va vérifier, et on se rend compte que les e-mails de bienvenue partent en spam depuis un mois.

Les règles ont beaucoup bougé ces deux dernières années. Gmail et Yahoo ont introduit leurs exigences pour les expéditeurs en masse en février 2024, Microsoft a suivi pour Outlook.com en mai 2025, et les trois sont passés du « on vous range dans les spams » au rejet pur et simple des messages. La bonne nouvelle, c'est que les exigences sont concrètes. Si vous déroulez cette liste une fois, vous évitez la plupart des problèmes.

Qui est concerné par les règles « bulk sender »

Le seuil dont tout le monde parle, c'est environ 5 000 messages par jour vers les boîtes grand public d'un même fournisseur (adresses personnelles Gmail, Yahoo ou Outlook.com/Hotmail). Google a indiqué qu'une fois ce seuil franchi, vous êtes considéré comme expéditeur en masse de façon définitive.

Beaucoup de SaaS en early stage sont en dessous. Faites la checklist quand même : les fournisseurs appliquent les mêmes signaux à tout le monde, les seuils décident seulement du niveau de sévérité, et un lancement produit ou une grosse newsletter peut vous faire passer au-dessus en une journée.

1. Envoyer depuis votre propre domaine

Les domaines d'envoi partagés (l'adresse par défaut en @yourprovider-mail.com de beaucoup d'outils) sont bons pour les tests, et pour rien d'autre. Votre réputation est mélangée à celle de tous les autres clients, et vous ne pouvez pas passer l'alignement DMARC sur un domaine que vous ne contrôlez pas.

Utilisez un sous-domaine dédié à l'envoi, par exemple mail.example.com ou updates.example.com. Le flux d'envoi a ainsi sa propre réputation, et une erreur à ce niveau n'abîmera pas le domaine racine que votre équipe utilise pour ses e-mails du quotidien.

2. SPF

SPF liste les serveurs autorisés à envoyer des e-mails pour un domaine. C'est un enregistrement DNS TXT posé sur le domaine de l'expéditeur d'enveloppe (le Return-Path), qui chez la plupart des fournisseurs est un sous-domaine qu'ils vous demandent de configurer.

example.com. TXT "v=spf1 include:_spf.google.com include:spf.yourprovider.com ~all"

Les erreurs classiques :

  • Plus de 10 requêtes DNS. Chaque include: compte, et les includes qu'il contient aussi. Au-delà de 10, le résultat est un permerror, et pour les serveurs de réception c'est comme si vous n'aviez pas de SPF du tout. C'est l'échec SPF que je vois le plus souvent en pratique. Supprimez les outils que vous n'utilisez plus, ou donnez à chaque fournisseur d'envoi son propre sous-domaine.
  • Deux enregistrements SPF sur le même nom. Un seul enregistrement TXT v=spf1 est autorisé. Fusionnez-les.
  • Utiliser +all. Ça autorise tout Internet à envoyer pour vous.

3. DKIM

DKIM signe chaque message avec une clé privée. Les serveurs de réception vérifient la signature avec la clé publique publiée dans le DNS. Votre fournisseur d'e-mail génère la paire de clés et vous donne un ou plusieurs enregistrements CNAME ou TXT :

s1._domainkey.example.com. CNAME s1.domainkey.yourprovider.com.

Utilisez des clés de 2048 bits quand votre fournisseur le permet, et vérifiez que chaque outil qui envoie au nom de votre domaine signe bien avec votre domaine : votre fournisseur transactionnel, votre outil marketing, votre helpdesk, les reçus envoyés par votre outil de facturation. Les outils oubliés sont la raison habituelle des échecs dans les rapports DMARC.

4. DMARC, avec l'alignement

DMARC relie SPF et DKIM au domaine que le destinataire voit réellement dans l'en-tête From:. Un message passe DMARC quand SPF ou DKIM passe et que le domaine validé correspond au domaine du From (on dit qu'il est « aligné »).

Commencez en mode surveillance :

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

p=none suffit pour respecter les exigences de Gmail, Yahoo et Outlook.com. L'adresse rua reçoit chaque jour des rapports agrégés envoyés par les serveurs de réception. Ils sont en XML, donc branchez-les sur un outil de lecture de rapports DMARC gratuit ou pas cher plutôt que de les lire à la main.

Quand les rapports montrent que tout votre trafic légitime passe, passez à p=quarantine, puis plus tard à p=reject. C'est ce qui protège vraiment votre domaine contre l'usurpation. Ne sautez pas directement à reject : vous découvrirez l'outil de facturation oublié le jour où vos clients ne recevront plus leurs factures.

L'alignement, c'est là que beaucoup de gens se font piéger. Si votre fournisseur signe DKIM avec d=yourprovider.com et que le Return-Path est bounces.yourprovider.com, SPF et DKIM peuvent tous les deux être « pass » alors que DMARC échoue, parce qu'aucun des deux domaines ne correspond à example.com. Configurer un domaine DKIM personnalisé (étape 3) règle le problème.

Microsoft est le plus strict sur ce point. Depuis le 5 mai 2025, Outlook.com rejette les envois à fort volume qui échouent à ces vérifications avec 550 5.7.515 Access denied, sending domain does not meet the required authentication level. Si vous voyez ce bounce, vérifiez vos trois enregistrements DNS avant de toucher au contenu de l'e-mail.

5. Reverse DNS et TLS

Si vous passez par un fournisseur d'e-mail (ESP), il s'en occupe. Si vous faites tourner votre propre MTA (Postfix, Haraka, une VM cloud), chaque IP d'envoi doit avoir un enregistrement PTR qui pointe vers un nom d'hôte, et ce nom d'hôte doit pointer à son tour vers la même IP (forward-confirmed reverse DNS). Envoyez en TLS. Gmail liste ces deux points comme obligatoires pour tout le monde, pas seulement pour les expéditeurs en masse.

6. Désinscription en un clic pour les e-mails marketing

Les messages marketing et promotionnels doivent proposer la désinscription en un clic de la RFC 8058, c'est-à-dire avec les deux en-têtes :

L'URL https doit accepter un POST et désinscrire le destinataire immédiatement, sans connexion et sans page de confirmation. Gmail et Yahoo attendent que la désinscription soit effective sous deux jours. Gardez aussi un lien de désinscription visible dans le corps de l'e-mail.

Les e-mails transactionnels (réinitialisation de mot de passe, reçus, alertes de sécurité) en sont dispensés. C'est une des raisons de séparer les deux flux (point suivant).

7. Séparer les flux transactionnel et marketing

Envoyez les réinitialisations de mot de passe et les newsletters depuis des sous-domaines différents, et idéalement depuis des pools d'IP différents :

Flux Exemple de From Exemple de domaine d'envoi
Transactionnel no-reply@example.com ou support@example.com tx.example.com
Marketing produit et lifecycle hello@example.com mail.example.com

Quand une campagne marketing fait grimper les plaintes, les dégâts restent sur ce flux et les réinitialisations de mot de passe continuent d'arriver. La plupart des fournisseurs qui gèrent les deux permettent de configurer un domaine d'envoi distinct par flux.

8. Garder un taux de plaintes pour spam bas

C'est l'exigence qu'on ne règle pas dans le DNS. Le seuil de Gmail est un taux de spam signalé par les utilisateurs de 0,3 %, et Google recommande de rester sous 0,1 %. Au-delà de 0,3 %, attendez-vous à du throttling, puis à un classement en spam, puis à des rejets.

Ce qui limite les plaintes dans un contexte SaaS :

  • N'écrivez qu'aux gens qui s'y attendent. Les confirmations d'inscription et l'onboarding sont attendus ; une newsletter envoyée à tous les utilisateurs en essai d'il y a deux ans ne l'est pas.
  • Arrêtez d'écrire aux contacts inactifs. Arrêtez le marketing vers les personnes qui n'ont ni ouvert ni cliqué depuis 90 à 180 jours (Apple Mail Privacy Protection gonfle les ouvertures, donc donnez plus de poids aux clics).
  • Rendez la désinscription plus simple que le signalement en spam. Si se désinscrire est compliqué, les gens cliquent sur le bouton spam à la place.
  • Supprimez les hard bounces immédiatement, et mettez en liste de suppression les adresses qui se sont plaintes.

9. Surveiller

Mettez ces outils en place une fois et consultez-les chaque semaine :

  • Google Postmaster Tools : taux de spam et statut de conformité pour les destinataires Gmail. Vérifiez-y votre domaine d'envoi, c'est gratuit.
  • Microsoft SNDS : données de réputation de vos IP d'envoi chez Outlook.com (utile si vous avez des IP dédiées).
  • Rapports agrégés DMARC : quelles sources envoient au nom de votre domaine, et si elles passent.
  • Les codes de bounce dans les logs de votre fournisseur. 5.7.26 chez Gmail et 5.7.515 chez Outlook signalent des problèmes d'authentification ; les reports en 4.7.x veulent généralement dire que vous êtes limité en débit.

10. Chauffer les nouveaux domaines et les nouvelles IP

Un nouveau domaine d'envoi ou une nouvelle IP dédiée n'a aucune réputation. N'envoyez pas 50 000 e-mails avec dès le premier jour. Commencez par vos destinataires les plus engagés (inscrits récents, utilisateurs actifs), augmentez le volume sur deux à quatre semaines, et surveillez le taux de plaintes et les reports au fur et à mesure. Si vous êtes sur un pool d'IP partagé chez un fournisseur réputé, le domaine a quand même besoin d'une montée en charge progressive, mais la partie IP est gérée pour vous.

Checklist express

  • [ ] Envoi depuis votre propre (sous-)domaine
  • [ ] Un seul enregistrement SPF, sous les 10 requêtes DNS
  • [ ] DKIM signé avec votre domaine, par chaque outil qui envoie en votre nom
  • [ ] DMARC publié avec les rapports rua, aligné, en route vers quarantine/reject
  • [ ] PTR et TLS (gérés par votre fournisseur si vous en utilisez un)
  • [ ] Désinscription en un clic RFC 8058 sur les e-mails marketing
  • [ ] Transactionnel et marketing sur des sous-domaines séparés
  • [ ] Taux de spam sous 0,1 %, contacts inactifs écartés
  • [ ] Postmaster Tools et rapports DMARC consultés chaque semaine
  • [ ] Montée en charge progressive pour les nouveaux domaines et IP

Si vous voulez que l'essentiel de tout ça soit géré pour vous, Sequenzy ajoute les en-têtes de désinscription en un clic, vous donne les enregistrements DNS exacts à publier, et vous permet d'envoyer chaque flux depuis son propre sous-domaine (la structure que nous recommandons), mais la checklist s'applique quel que soit l'outil avec lequel vous envoyez.