Authentifier Mailjet : SPF, DKIM et alignement DMARC

exemple.fr.  IN TXT  "v=spf1 include:spf.mailjet.com ~all"

mailjet._domainkey.exemple.fr.  IN TXT  "k=rsa; p=MIGfMA0GCSqGSIb3DQEB…"

L'alignement : la signature DKIM porte la conformité

DMARC ne se contente pas d'un SPF ou d'un DKIM qui « passe » : il exige qu'au moins un des deux mécanismes valide un domaine aligné avec celui du champ From: — celui que le destinataire voit dans sa messagerie. C'est le concept central du standard, et c'est lui qui départage les ESP entre eux.

Chez Mailjet, la signature DKIM est apposée avec le domaine du client : un message envoyé avec From: contact@exemple.fr porte une signature d=exemple.fr. Domaine signataire et domaine visible sont identiques — l'alignement DKIM est acquis, en mode strict comme en mode relaxed. Résultat : DMARC passe, quelle que soit la politique publiée, p=none aujourd'hui comme p=reject demain.

C'est la propriété à retenir de tout cet article : chez Mailjet, la conformité DMARC repose sur DKIM. Tant que la clé mailjet._domainkey est en zone et la signature activée, le flux est conforme. L'include SPF, lui, sert la réputation et la délivrabilité, mais il n'est pas ce qui fait passer DMARC — la section suivante explique pourquoi.

Pour situer cette brique dans l'ensemble du dispositif — politique, adresses de rapport, balises —, le hub d'exemples d'enregistrements commentés, politique par politique sert de référence : l'enregistrement _dmarc y est décliné de la simple surveillance jusqu'au rejet.

Enveloppe et Return-Path : là où l'alignement SPF s'arrête

Reste à comprendre pourquoi SPF, de son côté, ne s'alignera pas — et pourquoi ce n'est pas grave.

SPF n'évalue pas le From: visible, mais l'adresse d'enveloppe : le MAIL FROM de la session SMTP, exposé après coup dans l'en-tête Return-Path. Or, comme la plupart des ESP, Mailjet place dans cette enveloppe un domaine technique qui lui appartient (de la forme bnc3.mailjet.com) : c'est ce qui lui permet de récupérer les rebonds et de traiter les désabonnements à la place du client. Conséquence mécanique : le serveur destinataire vérifie SPF contre le domaine de rebond de Mailjet. Le test réussit — les IP d'envoi figurent bien dans le SPF de ce domaine —, mais le domaine ainsi validé n'a aucun rapport avec exemple.fr : SPF passe sans s'aligner, et ne contribue pas au verdict DMARC.

Dans les rapports agrégés, ce comportement produit une lecture déroutante : spf=pass d'un côté, alignement SPF en échec de l'autre, et pourtant une évaluation DMARC positive grâce à DKIM. Cette gymnastique est décortiquée dans l'article consacré à ces verdicts en apparence contradictoires, qui apprend à lire ces lignes sans paniquer.

Certaines offres permettent d'aller plus loin : Mailjet propose, selon le plan souscrit, la personnalisation du Return-Path via un CNAME — bounce.exemple.fr pointant vers l'infrastructure de rebond de l'ESP. L'enveloppe devient alors un sous-domaine du domaine visible, et l'alignement SPF en mode relaxed devient atteignable. C'est un raffinement utile pour la réputation, pas un prérequis : DKIM aligné suffit à DMARC, et courir après le double alignement n'a de sens qu'une fois le reste du chantier terminé.

Un sous-domaine dédié à l'envoi : la bonne pratique

Rien n'oblige à faire partir les campagnes du domaine organisationnel lui-même. La pratique recommandée — chez Mailjet comme ailleurs — consiste à déléguer l'e-mailing à un sous-domaine dédié : news.exemple.fr pour le marketing, en gardant exemple.fr pour le courrier humain et, par exemple, facture.exemple.fr pour le transactionnel.

Les bénéfices sont concrets. D'abord, le cloisonnement de la réputation : un incident de campagne — plainte massive, liste mal nettoyée — dégrade la réputation du sous-domaine émetteur, pas celle du domaine principal dont dépendent les échanges du quotidien. Ensuite, la lisibilité des rapports : chaque sous-domaine raconte un flux, et une source inattendue s'y repère d'un coup d'œil. Enfin, la souplesse de politique : DMARC sait traiter les sous-domaines spécifiquement (balise sp=, complétée par np= pour les sous-domaines inexistants), et DMARCbis — le standard courant — découvre la politique applicable en remontant l'arbre DNS, le Tree Walk, sous-domaine par sous-domaine.

Concrètement, la démarche reste la même, un niveau plus bas : valider news.exemple.fr chez Mailjet, publier l'include SPF et la clé DKIM sur ce sous-domaine (mailjet._domainkey.news.exemple.fr), et laisser l'alignement relaxed — le mode par défaut — faire le lien avec le domaine organisationnel : un From: lettre@news.exemple.fr signé d=news.exemple.fr reste aligné avec exemple.fr.

Le raisonnement vaut pour tous les routeurs, chacun avec ses particularités d'enveloppe et de sélecteurs : les guides consacrés à l'authentification chez Brevo et à la configuration côté SendGrid suivent le même canevas, et la comparaison des trois est instructive.

Les erreurs vues sur le terrain

Les zones DNS auditées après un « DKIM ne passe pas » racontent presque toujours l'une de ces quatre histoires.

• Le SPF dupliqué. L'assistant de l'hébergeur ou un copier-coller trop rapide crée un deuxième enregistrement v=spf1 à côté de l'existant, au lieu de fusionner les mécanismes dans un seul. Deux enregistrements SPF sur le même nom produisent un permerror : les destinataires ignorent les deux, et un mécanisme censé aider se transforme en échec systématique pour tous les flux du domaine, pas seulement pour Mailjet. La correction tient en une ligne : un seul v=spf1, tous les include dedans.
• L'enregistrement posé au mauvais niveau. Grand classique des interfaces DNS qui suffixent automatiquement le nom de zone : la clé se retrouve publiée à mailjet._domainkey.exemple.fr.exemple.fr — le domaine en double — parce que le nom complet fourni par Mailjet a été collé dans un champ qui attendait un nom relatif. Variante fréquente : l'include SPF ajouté sur exemple.fr alors que le domaine validé, et utilisé dans le From:, est news.exemple.fr — ou l'inverse, la clé DKIM posée sur la racine pendant que les envois partent du sous-domaine. Dans tous les cas, la vérification de Mailjet reste rouge, ou pire, passe au vert sur un périmètre qui n'est pas celui des envois réels.
• La clé tronquée. Une valeur p= amputée au collage — champ trop court, guillemets perdus, retour à la ligne parasite — produit une signature invérifiable. Un dig TXT mailjet._domainkey.exemple.fr permet de comparer caractère par caractère la valeur publiée à celle fournie par la plateforme.
• La signature jamais activée. L'enregistrement est bien en zone, mais la vérification finale côté Mailjet n'a jamais été relancée : les messages partent sans signature du domaine propre. Le DNS est correct, le flux ne l'est pas — le cas le plus frustrant, car invisible depuis la zone.

Aucune de ces erreurs n'est grave ; toutes coûtent des jours de délivrabilité dégradée quand personne ne regarde les bons signaux. D'où l'étape finale.

La vérification dans les rapports

La configuration ne se déclare pas terminée quand l'interface passe au vert : elle se vérifie dans les rapports agrégés. Avec un enregistrement DMARC publiant une adresse de collecte :

_dmarc.exemple.fr.  IN TXT  "v=DMARC1; p=none; rua=mailto:rapports@exemple.fr"

chaque grand destinataire — Gmail, Microsoft, Yahoo — envoie un bilan quotidien des messages reçus au nom du domaine, IP par IP, verdict par verdict.

Dans ces rapports, un flux Mailjet correctement configuré se reconnaît à trois signaux : les IP d'envoi de la plateforme apparaissent comme source identifiée ; DKIM affiche pass avec un domaine signataire égal au domaine du From: — l'alignement ; SPF affiche pass sur le domaine de rebond de Mailjet, sans alignement, ce qui est le comportement attendu et non une anomalie. Si DKIM échoue, ou si la signature porte un domaine Mailjet au lieu du domaine propre, l'une des erreurs de la section précédente est très probablement en cause.

Cette lecture est aussi le garde-fou du durcissement : passer de p=none à p=quarantine puis p=reject suppose plusieurs semaines de rapports où le flux Mailjet — et tous les autres émetteurs légitimes — restent alignés sans exception. DMARCbis fournit d'ailleurs un mode de test explicite (t=y) pour signaler une politique en rodage, là où l'ancienne balise pct a disparu du standard.

En résumé

Authentifier Mailjet suit un parcours court et bien balisé : validation du domaine — ou, mieux, du sous-domaine d'envoi dédié —, un include spf.mailjet.com fusionné dans l'enregistrement SPF existant, une clé DKIM publiée sous mailjet._domainkey, une signature activée puis contrôlée. La conformité DMARC repose sur DKIM, signé du domaine propre ; SPF passe sans s'aligner à cause du Return-Path technique de l'ESP, et c'est un comportement normal, éventuellement corrigible par un Return-Path personnalisé. Les échecs rencontrés sur le terrain viennent rarement du standard : ils viennent d'un SPF dupliqué, d'un enregistrement posé au mauvais niveau, d'une clé tronquée ou jamais activée — autant de diagnostics qui se lisent noir sur blanc dans les rapports agrégés.

Pour savoir où en est un domaine, avant ou après ce chantier, une analyse DMARC gratuite dresse en quelques secondes l'état des lieux : enregistrements publiés, include présents, politique en vigueur. Et pour suivre les rapports dans la durée, jusqu'à p=reject, l'ouverture d'un compte donne accès à la surveillance continue du domaine — flux Mailjet compris.