Délivrabilité email SaaS : SPF, DKIM, DMARC et surveillance

Commencer par les identités d’expéditeur

Dans une application SaaS, l’email visible par le client peut partir de plusieurs systèmes : le serveur produit expédie les liens de connexion, l’outil de facturation envoie les reçus, le service de support répond aux tickets et la plateforme marketing diffuse les annonces. Avant de modifier le DNS, dressez l’inventaire de ces émetteurs. Pour chacun, notez le domaine d’envoi, le propriétaire technique, le type de message, la méthode d’authentification et la procédure à suivre si le fournisseur est remplacé. Ce relevé révèle souvent un ancien service de test ou une intégration oubliée qui publie encore une signature.

SPF indique quels serveurs sont autorisés à envoyer pour un domaine. Il se publie en TXT et doit rester cohérent avec tous les services actifs. Un domaine ne doit pas accumuler plusieurs politiques SPF concurrentes : regroupez les mécanismes demandés par vos fournisseurs dans l’enregistrement attendu, puis contrôlez les limites de consultation DNS définies par le protocole. Ne copiez pas une ligne trouvée dans un ancien ticket sans vérifier si elle correspond toujours au service réellement utilisé.

DKIM ajoute une signature au message. Le fournisseur donne généralement un sélecteur et une valeur DNS, parfois sous forme de clé publique. Publiez l’entrée exactement au nom demandé, attendez sa propagation, puis déclenchez un message de contrôle et examinez ses en-têtes. Une signature présente ne suffit pas si elle utilise une identité différente du domaine affiché au destinataire. Conservez les sélecteurs actifs et la date de rotation prévue dans votre documentation, afin que la personne qui renouvelle une clé sache quels flux dépendent d’elle.

DMARC relie ces mécanismes à l’adresse visible dans le champ « De ». Il vérifie l’alignement entre ce domaine et celui authentifié par SPF ou DKIM, et peut transmettre des rapports agrégés. Commencez par une politique d’observation qui permet d’identifier les expéditeurs légitimes. Examinez les rapports pour repérer les services connus, les erreurs de configuration et les sources inattendues. Une fois l’inventaire complet, l’équipe peut décider progressivement du traitement des messages non alignés. Passer directement à une politique de rejet peut interrompre des reçus ou alertes dont l’émetteur n’avait pas été recensé.

Un cas concret : votre produit utilise `app.exemple.fr`, les factures partent d’un prestataire et les campagnes depuis une autre plateforme. Les deux services peuvent signer correctement tout en présentant des domaines différents. Décidez quelle identité doit apparaître pour chaque catégorie, configurez les signatures prévues et vérifiez l’alignement sur les messages effectivement reçus. Faites valider les changements par les responsables de l’application et du DNS, surtout si ces équipes n’ont pas les mêmes droits de publication.

Après chaque changement, vérifiez le résultat depuis plusieurs points de vue : la valeur DNS publiée, l’état d’authentification indiqué par le fournisseur, puis les en-têtes d’un message arrivé chez un destinataire de contrôle. Gardez une trace des anciennes valeurs et de l’heure de bascule. Si une notification échoue ensuite, cette chronologie aide à distinguer une erreur de code d’un enregistrement supprimé trop tôt.

Séparer les flux et réchauffer sans improviser

Les messages transactionnels et les campagnes marketing n’ont pas les mêmes destinataires ni les mêmes conséquences en cas d’incident. Une réinitialisation de mot de passe doit rester disponible même si une campagne promotionnelle génère des plaintes. Attribuez donc des sous-domaines distincts aux usages, par exemple `notify.exemple.fr` pour les notifications produit et `news.exemple.fr` pour les campagnes. Ce découpage aide à lire les rapports et à attribuer un problème, mais ne remplace ni l’authentification, ni la qualité de la liste, ni une politique de suppression partagée.

Écrivez ces frontières dans une matrice : domaine, flux permis, fournisseur responsable, adresse de réponse, propriétaire et événement qui déclenche l’envoi. Définissez aussi les exceptions. Un email d’invitation à rejoindre un espace peut être transactionnel, tandis qu’une annonce d’une nouvelle fonction est une communication marketing, même si les deux proviennent du même produit. Si le classement varie d’une équipe à l’autre, la séparation technique ne sera pas fiable.

Pour un nouveau domaine ou une nouvelle adresse IP, évitez de basculer immédiatement tout le volume historique. Vérifiez d’abord que le service est configuré, que les enregistrements DNS sont publiés et que les messages de contrôle ont les signatures attendues. Ensuite, suivez un plan de montée en charge défini avec le fournisseur selon votre historique, votre volume réel et le profil des messages. Il n’existe pas de calendrier universel à appliquer à chaque SaaS : une base active qui reçoit régulièrement des alertes n’a pas le même profil qu’une campagne adressée à des contacts restés inactifs plusieurs mois.

Préparez le segment de départ à partir de personnes qui attendent clairement le message et dont l’adresse a été récemment confirmée. Écartez les anciennes importations sans provenance, les adresses supprimées et les contacts qui ont cessé de recevoir cette catégorie. Augmentez le rythme uniquement si les retours restent cohérents : erreurs temporaires, rebonds permanents, plaintes, désinscriptions et réponses des fournisseurs de boîtes. Si un signal se détériore, faites une pause et cherchez la cause avant d’ajouter une nouvelle tranche de volume.

La gestion des rebonds doit distinguer les échecs définitifs des incidents temporaires. Un rejet permanent ou une adresse inexistante doit alimenter la suppression afin que les prochains flux ne tentent pas le même envoi. Une réponse temporaire peut justifier une reprise limitée, suivant les règles du fournisseur, avec une durée maximale et une trace de l’issue. N’implémentez pas une boucle qui retente chaque échec sans limite : elle peut amplifier un refus ou générer des doublons après une panne réseau.

Les plaintes doivent également être converties en état exploitable. Dès qu’un fournisseur signale une plainte, bloquez les prochains messages marketing à cette adresse et transmettez l’information aux systèmes qui peuvent encore envoyer. Une désinscription en un clic doit être disponible dans les messages concernés et traitée sans délai par le service qui orchestre les campagnes. Conservez les préférences par catégorie : une personne peut vouloir arrêter les annonces produit tout en gardant les alertes indispensables au fonctionnement de son compte.

Enfin, testez les chemins d’arrêt, pas seulement le chemin nominal. Simulez une adresse invalide, une plainte, un clic de désinscription et un utilisateur qui ferme son compte. Vérifiez qu’aucune file d’attente ou intégration secondaire ne contourne la suppression centrale. Dans un SaaS, la logique de consentement peut se trouver dans le produit, tandis que l’envoi est confié à un prestataire ; les deux systèmes doivent partager une décision cohérente, avec une règle claire en cas d’indisponibilité de la synchronisation.

Surveiller les signaux utiles au diagnostic

Un tableau de bord de délivrabilité doit répondre à une question opérationnelle : quel flux échoue, depuis quand, pour quels destinataires et qui peut agir ? Regroupez les événements par fournisseur d’envoi, sous-domaine, catégorie et domaine de destination. Affichez le volume demandé par l’application, les acceptations par le prestataire, les retours de livraison, les rebonds, les plaintes et les désinscriptions. Ces étapes ne décrivent pas toutes le même résultat : une requête acceptée par votre API n’est pas nécessairement acceptée par le serveur destinataire, et une acceptation ne prouve pas que le message est visible dans la boîte principale.

Google Postmaster Tools peut fournir des informations sur la réputation et les erreurs observées pour les messages envoyés vers Gmail, lorsque le domaine et le volume répondent aux conditions de l’outil. Ajoutez-y les rapports DMARC agrégés, qui indiquent les sources déclarant envoyer au nom du domaine et les résultats d’authentification et d’alignement. Ils complètent les journaux du fournisseur d’envoi : les rapports DMARC ne remplacent pas les événements applicatifs et ne permettent pas à eux seuls de retrouver le parcours d’un message particulier.

Pour rendre les signaux comparables, conservez un identifiant de corrélation de votre application dans les journaux et reliez-le aux webhooks du fournisseur. Stockez les horodatages, la catégorie, l’identifiant du modèle et le statut final. Évitez de conserver le contenu intégral d’un message ou des données personnelles sans nécessité opérationnelle. Une équipe support doit pouvoir rechercher une notification avec un identifiant de compte ou d’envoi, tandis que l’accès aux adresses complètes et aux corps de message reste limité aux personnes qui en ont réellement besoin.

Créez des alertes sur les changements inhabituels plutôt que de reprendre des seuils prétendument universels. Votre historique et les recommandations de vos fournisseurs déterminent les limites adaptées. Une hausse de rebonds sur un seul domaine destinataire peut signaler une configuration locale ; une absence soudaine de webhooks peut indiquer une intégration interrompue ; des plaintes concentrées sur un modèle peuvent révéler un décalage de promesse. Chaque alerte doit nommer le propriétaire, les premières vérifications à faire et les conditions qui justifient une suspension du flux.

Lorsqu’un incident survient, rassemblez les changements récents : enregistrement DNS, clé DKIM, nouvelle adresse de départ, modification de volume, synchronisation des suppressions ou changement de modèle. Comparez un message affecté à un message qui fonctionne, puis vérifiez les en-têtes d’authentification et la réponse SMTP lorsque cette information est disponible. N’accumulez pas les changements correctifs pendant que l’incident est en cours : une seule modification testée à la fois permet de relier la cause au résultat et de revenir en arrière proprement.

Les rapports DMARC méritent une revue régulière et un propriétaire. Identifiez les expéditeurs inconnus, confirmez les services légitimes avec les équipes concernées et retirez les anciens mécanismes après avoir établi qu’aucun flux ne les utilise encore. Ne transformez pas une source inconnue en autorisation permanente par commodité. Si un service tiers est confirmé, demandez-lui la configuration d’authentification adaptée, documentez la décision et vérifiez les résultats dans les rapports suivants.

La surveillance n’a de valeur que si elle mène à une action compréhensible. Pour une notification de sécurité retardée, l’équipe produit peut proposer une voie de secours dans l’application. Pour une campagne présentant une hausse de plaintes, le responsable marketing peut suspendre le segment à l’origine du problème. Après résolution, consignez le symptôme, le flux concerné, la configuration modifiée et les vérifications faites. Cette fiche donne aux équipes SaaS une base de diagnostic réutilisable sans attribuer à un simple taux d’ouverture une signification qu’il ne peut pas prouver.

Comparer les fournisseurs d’envoi

Ces options couvrent des besoins d’envoi transactionnel ou d’intégration API. Les prix sont ceux des offres mensuelles affichées ; ils ne décrivent ni une garantie de placement en boîte de réception ni un résultat de délivrabilité. Comparez les fonctions d’événements, les suppressions et le niveau de contrôle qui correspondent à votre architecture.

Postmark et Mailgun affichent un tarif d’entrée au même niveau de volume, mais la décision dépend surtout de votre modèle d’intégration et des informations que l’équipe doit consulter pendant un incident. Resend et SendGrid présentent ici un palier incluant davantage d’emails ; vérifiez les options associées avant d’estimer le coût d’un flux combinant notifications et campagnes. Dans tous les cas, gardez la propriété des événements et de l’état de suppression dans une couche que votre équipe peut auditer.

Erreurs fréquentes à éviter

• Publier un deuxième SPF au lieu de réconcilier les émetteurs autorisés dans l’entrée existante.
• Passer DMARC à une politique stricte avant d’avoir identifié les services qui envoient légitimement.
• Utiliser le même sous-domaine pour les alertes essentielles et les campagnes sans propriétaires distincts.
• Confondre un message accepté par l’API et un message accepté par le serveur destinataire.
• Réessayer indéfiniment un rebond temporaire ou réactiver une adresse après une plainte.
• Considérer la désinscription comme une préférence locale à une seule plateforme au lieu de la synchroniser entre les systèmes.
• Interpréter les ouvertures comme une preuve d’arrivée en boîte principale.
• Modifier DNS, modèle, volume et segment en même temps, puis perdre la trace de la cause.

Choisir un plan de surveillance exploitable

Commencez par l’incident que l’équipe doit pouvoir diagnostiquer. Si les notifications de compte partent depuis plusieurs services, privilégiez un fournisseur qui expose des événements consultables et un moyen de les relier aux identifiants de l’application. Pour les campagnes, vérifiez comment les retours de plainte et les désinscriptions rejoignent votre registre de préférences. Un tableau de bord riche ne suffit pas si les personnes qui répondent aux tickets n’ont pas accès à l’information nécessaire.

Comparez également la conservation des événements à votre procédure de support. Une équipe qui investigue plusieurs jours après le signalement doit savoir si les détails restent disponibles et s’ils peuvent être exportés. Définissez quelles données peuvent être consultées par le support, lesquelles sont réservées aux administrateurs et combien de temps elles doivent être gardées. La durée utile dépend des processus internes et des obligations applicables à votre organisation.

Testez les retours de bout en bout dans un environnement contrôlé : une adresse invalide, un refus temporaire, une plainte simulée par les mécanismes proposés par le fournisseur et une désinscription. Vérifiez que chaque événement met à jour le bon compte et qu’un flux secondaire ne peut pas ignorer la décision. Documentez la personne à contacter lorsque la suppression ne se synchronise pas, ainsi que le moyen de mettre en pause les campagnes concernées.

Enfin, vérifiez la propriété du DNS et des identifiants d’API avant le renouvellement ou le départ d’un membre de l’équipe. Les accès d’administration doivent être attribués à des rôles durables, avec une procédure de rotation des secrets. Après un changement de prestataire, retirez les anciens enregistrements uniquement lorsque les flux qui en dépendent ont été déplacés et validés. Cette discipline réduit les erreurs de configuration sans faire du choix d’un outil une promesse de placement en boîte.