Configurer SPF, DKIM, DMARC : des e-mails qui arrivent
« Pourquoi mon propre e-mail professionnel part-il en spam ? » n'a rarement rien à voir avec ce que vous avez écrit. Ce sont trois enregistrements DNS que personne ne vous a dit de configurer : SPF, DKIM et DMARC. Avec eux, les fournisseurs de messagerie peuvent vérifier que votre courrier est vraiment le vôtre ; sans eux, un message parfaitement légitime est — pour un filtre automatisé — indiscernable de quelqu'un qui usurpe votre nom.
Trois enregistrements, trois rôles différents
SPF — qui peut envoyer en votre nom — un enregistrement TXT publié sur votre domaine listant les serveurs de messagerie autorisés à envoyer des e-mails se réclamant de vous. Un serveur destinataire vérifie l'origine réelle par rapport à cette liste ; une divergence est un signal fort — sans être à elle seule un rejet automatique — que le message pourrait ne pas vraiment être le vôtre.
DKIM — la preuve que rien n'a été altéré — le serveur expéditeur signe cryptographiquement chaque message avec une clé privée que lui seul détient ; la clé publique correspondante est publiée dans votre DNS. Une signature valide prouve à la fois qu'un détenteur de votre clé a envoyé le message et que rien n'a été modifié en transit après la signature.
DMARC — la politique qui relie les deux — indique si SPF et DKIM doivent s'aligner sur le domaine de l'adresse « De » visible, dit aux serveurs destinataires quoi faire quand un message échoue aux deux vérifications (rien, mise en quarantaine, ou rejet), et demande des rapports périodiques sur ce qui est envoyé sous votre nom, réussite ou échec.
D'où viennent réellement ces enregistrements
1
Sachez ce qui envoie réellement vos e-mails
Pas votre hébergeur de site — le service de messagerie ou d'envoi depuis lequel le message part réellement : Google Workspace, Microsoft 365, Zoho, Proton ou équivalent.
2
Publiez SPF pour cet expéditeur
Votre fournisseur de messagerie publie sa propre ligne SPF exacte dans sa documentation de configuration ; vous la collez dans le DNS de votre domaine, dans le même panneau que pour n'importe quel autre enregistrement DNS.
3
Activez la signature DKIM chez ce fournisseur
La plupart des fournisseurs génèrent la paire de clés pour vous et vous donnent l'enregistrement DNS exact à publier — la configuration DKIM est pilotée par le fournisseur, ce n'est pas quelque chose que vous construisez à la main.
4
Ajoutez un enregistrement DMARC, d'abord en surveillance seule
Rédigez vous-même un enregistrement TXT DMARC, en commençant par p=none, et ne le durcissez qu'une fois que les rapports confirment que tous vos véritables expéditeurs passent sans erreur.
Comment Olmira gère cela
Le SMTP par locataire est la réponse d'Olmira exactement à cela : connectez votre propre compte de messagerie pour chaque usage — transactionnel, marketing, support, facturation et plus — pour qu'un message parte réellement via un compte que vous contrôlez déjà, avec l'adresse « de » que vous définissez. Votre délivrabilité repose alors sur le SPF, DKIM et DMARC que le domaine de ce compte a déjà : connectez une vraie boîte professionnelle que vous utilisez déjà, et son authentification existante couvre aussi votre courrier envoyé depuis Olmira.
Une règle compte plus que toutes les autres : définissez l'adresse « de » d'un usage sur le même domaine que celui autorisé à envoyer via le compte connecté — faire correspondre les deux de travers est la cause la plus fréquente d'un échec qui ressemble à une usurpation, sur n'importe quelle plateforme. Un usage que vous laissez non configuré retombe simplement sur le relais d'Olmira plutôt que d'échouer à envoyer. Le reste de ce que couvrent les Intégrations : Intégrations.
À lire aussi
Connectez les enregistrements DNS du domaine : TXT, CNAME et l'attente — le même panneau DNS où se trouvent ces enregistrements, expliqué du point de vue du site web.
Certificat HTTPS automatique : pourquoi vous n'aurez plus jamais besoin d'en acheter un — l'autre élément pour bien configurer un domaine.
Techniquement, le message partira, mais le SPF et le DKIM d'un fournisseur de webmail grand public authentifient son domaine, pas celui que vous placez dans le champ « expéditeur » : un message qui prétend venir du domaine de votre entreprise mais qui est envoyé via les serveurs authentifiés de quelqu'un d'autre échoue généralement à l'alignement. Mieux vaut mettre en place une vraie boîte aux lettres sur votre propre domaine avant d'avoir besoin de paraître crédible à grande échelle.
SPF et DKIM sont désormais quasi obligatoires — plusieurs grands fournisseurs de messagerie en exigent déjà au moins un pour les expéditeurs de masse. DMARC est ce qui relie réellement les deux et indique aux destinataires quoi faire en cas d'échec ; l'omettre ne casse rien dans l'immédiat, mais c'est la pièce qui fait passer d'« authentifié » à « appliqué ».
L'authentification prouve que le message vient bien de vous ; elle ne l'exempte pas du filtrage antispam ordinaire. Le contenu, le volume d'envoi, l'engagement des destinataires et la réputation du domaine comptent toujours, en plus d'une authentification qui passe proprement.
Le même délai de propagation DNS que pour n'importe quel autre enregistrement — voyez connecter les enregistrements DNS du domaine pour comprendre ce qui se passe réellement pendant l'attente, et pourquoi « pas encore » n'est pas la même chose que « incorrect ».
Toute source d'envoi légitime — votre boîte mail quotidienne, une plateforme marketing, un formulaire de contact de site web — doit figurer dans le même enregistrement SPF et, lorsque le fournisseur le permet, disposer de sa propre signature DKIM. En oublier une est de loin la raison la plus fréquente pour laquelle un outil parfaitement légitime se met à échouer aux contrôles alors que tout « était déjà configuré ».