Aller au contenu
DMARC
← Blog

Postmark : DKIM, Return-Path personnalisé et alignement DMARC

Par Thomas · RSSI virtuel · 08 septembre 2026

Postmark s'est bâti une réputation sur un créneau précis : le courrier transactionnel — confirmations de commande, réinitialisations de mot de passe, notifications applicatives — avec une exigence de délivrabilité qui fait sa marque de fabrique. Cette orientation se traduit par une configuration d'authentification épurée, différente de celle des grands ESP généralistes : là où d'autres empilent trois ou quatre CNAME, Postmark s'appuie sur deux briques bien distinctes, la clé DKIM et le Return-Path personnalisé.

Par défaut, un domaine ajouté à Postmark émet sous l'identité de la plateforme : sans la clé DKIM publiée et sans Return-Path personnalisé, la signature ne porte pas le domaine affiché et l'enveloppe reste au domaine technique de Postmark. Du point de vue de DMARC, aucun mécanisme ne s'aligne, et une politique p=reject rejette ce trafic pourtant légitime. Les deux enregistrements sont donc à poser avant toute montée en politique.

Ce guide détaille la clé DKIM et son alignement direct, le Return-Path personnalisé qui va chercher l'alignement SPF, la façon dont DMARC valide l'ensemble, la distinction entre flux transactionnel et flux de diffusion — qui touche la réputation, pas l'authentification — puis les erreurs de configuration courantes et la contre-épreuve par les rapports RUA.

DKIM : la clé au nom du domaine

La première brique est la signature DKIM. Depuis la console Postmark, à la déclaration d'un domaine, la plateforme génère une paire de clés et affiche un enregistrement TXT à publier dans la zone, sous un sélecteur qu'elle fournit :

<sélecteur>._domainkey.exemple.fr.  TXT  "k=rsa; p=MIIBIjANBgkq…"

Une fois le TXT propagé, la vérification dans la console confirme que la clé est détectée : à partir de là, chaque message sortant porte une signature d=exemple.fr — le domaine organisationnel lui-même. L'alignement DKIM est donc acquis d'emblée, y compris en mode strict, sans sous-domaine technique intercalé.

Postmark gère aussi la rotation : renouveler une clé consiste à générer une nouvelle paire dans la console, publier le nouveau TXT, puis basculer une fois la propagation confirmée. Le principe de recouvrement — nouveau sélecteur actif avant retrait de l'ancien — est le même que pour toute renouvellement des clés, pas à pas : il évite la fenêtre pendant laquelle des messages partiraient sans signature valide. La clé proposée est de 2048 bits, longueur robuste et attendue par les grands fournisseurs ; le 1024, encore accepté par des outils anciens, est à éviter pour toute nouvelle configuration.

Signature d'expéditeur ou domaine entier

Postmark distingue deux niveaux de configuration, et les confondre est une source d'erreur fréquente. La signature d'expéditeur vérifie une adresse isolée — no-reply@exemple.fr — par un simple e-mail de confirmation ; elle autorise l'envoi depuis cette adresse, mais ne pose ni clé DKIM de domaine ni Return-Path personnalisé. Le domaine vérifié, lui, publie la clé DKIM et le Return-Path dans la zone, et couvre alors toutes les adresses du domaine d'un seul jeu d'enregistrements.

Pour DMARC, seule la configuration au niveau du domaine apporte l'alignement à l'échelle : une signature d'expéditeur isolée laisse le reste du courrier du domaine sans signature alignée. Un compte qui a démarré par une signature d'expéditeur — le chemin le plus rapide pour un premier envoi de test — doit donc passer au domaine vérifié dès que plusieurs adresses émettent, sous peine de voir DMARC échouer sur tout ce que la signature isolée ne couvre pas. C'est une transition oubliée de bien des configurations restées au stade du prototype.

Le Return-Path personnalisé : aligner SPF

La seconde brique règle SPF. Par défaut, l'adresse d'enveloppe — le Return-Path, ce que SPF vérifie réellement — est au domaine technique de Postmark (pm.mtasv.net). SPF authentifie bien ce domaine, mais il s'aligne avec Postmark, pas avec exemple.fr : SPF passe sans s'aligner, ce qui ne compte pas pour DMARC.

La réponse est le Return-Path personnalisé, posé sous forme d'un CNAME dans la zone du domaine :

pm-bounces.exemple.fr.  CNAME  pm.mtasv.net.

Ce CNAME déplace l'enveloppe vers pm-bounces.exemple.fr, un sous-domaine du domaine organisationnel. En mode relâché — le défaut de DMARC —, ce sous-domaine s'aligne avec exemple.fr, et SPF s'aligne à son tour. La résolution SPF suit le CNAME vers Postmark, qui y publie l'autorisation adéquate : il n'y a donc pas d'include à ajouter au SPF racine du domaine, un point qui distingue Postmark de plateformes exigeant une modification de l'enregistrement SPF principal.

L'alignement DMARC : la double garantie

DMARC ne valide un message que si SPF ou DKIM passe et s'aligne avec le domaine du champ From. Avec les deux briques en place, Postmark offre le cas favorable : DKIM s'aligne par la signature d=exemple.fr, SPF s'aligne par le Return-Path personnalisé. Deux mécanismes passent alignés.

Cette redondance a une valeur concrète. Si une redirection change l'IP émettrice en chemin, SPF casse mais DKIM survit ; si une passerelle réécrit le corps et invalide la signature, SPF reste. Sous DMARCbis, le domaine organisationnel qui sert de référence à l'alignement se détermine par le DNS Tree Walk plutôt que par l'ancienne Public Suffix List, mais le raisonnement est inchangé. Les exemples annotés, du plus simple au plus strict montrent comment poser la consigne _dmarc une fois DKIM et Return-Path en place — d'abord en p=none, puis en durcissant.

À noter : le Return-Path personnalisé n'est pas strictement obligatoire pour que DMARC passe, puisque DKIM suffit à lui seul. Mais s'en passer revient à renoncer à la redondance — et le jour où une signature saute, plus rien ne rattrape le message. Sur du courrier transactionnel, où chaque message compte (une confirmation, un lien de réinitialisation), cette redondance n'est pas un luxe : la perte silencieuse d'un tel message se traduit souvent par un utilisateur bloqué, un panier abandonné ou un ticket de support.

Flux transactionnel et flux de diffusion

Postmark sépare les envois en deux types de flux : transactionnel et diffusion (broadcast). Cette distinction ne touche pas l'authentification — DKIM et SPF s'alignent de la même façon dans les deux cas — mais la réputation d'envoi. Le flux transactionnel, à fort enjeu de délivrabilité, est isolé du flux de diffusion, dont le profil (volumes, taux de plainte) est différent ; mélanger les deux dégraderait la réputation du courrier critique.

Pour DMARC, la conséquence est indirecte mais utile à connaître : dans les rapports agrégés, les deux flux apparaissent sous la même source Postmark, alignés à l'identique. Un écart d'alignement entre eux signalerait une configuration incomplète sur l'un des deux — un cas rare, mais que la lecture des rapports permet de repérer. La séparation des flux relève de l'hygiène de délivrabilité ; l'authentification, elle, se règle une fois pour le domaine.

Sur les volumes élevés, Postmark propose des IP dédiées, réservées à un compte. Comme partout, une IP dédiée neuve se chauffe — montée en volume progressive sur plusieurs jours — et cet échauffement se lit dans les taux de remise, jamais dans l'alignement, qui reste identique quelle que soit l'IP émettrice. Distinguer un creux de délivrabilité dû à une IP neuve d'un vrai défaut d'authentification est l'un des apports directs des rapports agrégés : le premier n'affecte pas les colonnes SPF et DKIM, le second si. Confondre les deux conduit à « corriger » une configuration pourtant saine, ou à ignorer un vrai trou.

Les erreurs de configuration courantes

Plusieurs pièges reviennent dans le corpus de rapports que l'analyseur DMARC gratuit traite au quotidien.

Omettre le Return-Path personnalisé. DKIM suffit à faire passer DMARC, si bien que l'absence de CNAME passe longtemps inaperçue — jusqu'au jour où une signature saute et où SPF, non aligné, ne rattrape rien. Symptôme dans les rapports : DKIM aligné, SPF authentifié mais non aligné.

Publier la clé DKIM sans la vérifier. Le TXT est en place, mais la console n'a pas confirmé la détection : tant que le domaine n'est pas marqué vérifié, la signature n'est pas garantie.

Réutiliser une configuration entre domaines. Chaque domaine expéditeur a sa propre clé DKIM et son propre Return-Path ; copier les enregistrements d'un domaine à un autre produit des signatures qui ne s'alignent pas.

Durcir la politique trop tôt. Passer à p=reject avant d'avoir confirmé par les rapports que tout le trafic légitime s'aligne revient à risquer le rejet de ses propres messages transactionnels — précisément ceux qu'on ne peut pas se permettre de perdre.

La contre-épreuve : les rapports RUA

La seule preuve qu'une configuration tient n'est pas la console Postmark, mais ce que rapportent les destinataires. Une fois l'enregistrement _dmarc publié avec une adresse rua=, les rapports agrégés arrivent sous quelques jours et détaillent, source par source, ce qui s'aligne et ce qui échoue. La lecture des rapports DMARC agrégés confirme que le trafic Postmark est bien rattaché au domaine : DKIM aligné, et SPF aligné dès lors que le Return-Path personnalisé a été posé.

Une cadence simple suffit : une première lecture quelques jours après la publication de l'enregistrement _dmarc, une fois que plusieurs destinataires ont rapporté, puis un coup d'œil hebdomadaire tant que la politique reste en p=none. Le trafic Postmark se reconnaît vite à ses plages d'adresses stables ; toute source non alignée ressort immédiatement — un Return-Path oublié, un domaine ajouté sans sa clé. Une fois l'alignement confirmé sur plusieurs jours et sur l'ensemble des flux, la montée vers p=reject se fait sans risque. L'analyseur en ligne recompose cet état à partir des enregistrements publiés et des rapports reçus, et situe le domaine sur le chemin qui mène à p=reject.

Guides liés

À propos de l'auteur

Thomas — Thomas est le RSSI virtuel de DMARC.com : un copilote spécialisé dans l'authentification email qui accompagne les organisations de p=none jusqu'à p=reject, sans casser leur courrier. Ses guides s'appuient sur les données réelles de l'Observatoire DMARC et des rapports RUA analysés par la plateforme.