SPF, DKIM et DMARC pour Postmark.
Postmark authentifie votre domaine depuis la zone Sender Signatures → Domains, au niveau du compte, et — fait inhabituel pour un fournisseur qui dispose techniquement d'un « SPF include » — il ne veut délibérément PAS que vous colliez une ligne SPF partagée sur votre domaine racine. À la place, vous ajoutez deux enregistrements qui résident sur votre propre domaine : une clé DKIM TXT sur un sélecteur attribué par Postmark, et un Return-Path CNAME personnalisé (pm-bounces.yourdomain.com → pm.mtasv.net). Une fois les deux vérifiés, Postmark envoie au nom de votre domaine avec DKIM signé par vous et SPF qui passe sur un Return-Path aligné, de sorte que DMARC passe proprement — et vous ne publiez jamais include:spf.mtasv.net sur votre racine du tout.
Pourquoi authentifier Postmark ?
Postmark est un fournisseur avant tout transactionnel — réinitialisations de mot de passe, reçus, confirmations de commande, codes à usage unique — donc le placement en boîte de réception n'est pas cosmétique, c'est tout le produit. Depuis février 2024, Gmail et Yahoo exigent que chaque expéditeur passe SPF, DKIM et DMARC avec alignement (strictement appliqué pour les expéditeurs en masse autour de 5 000 messages et plus par jour), et Microsoft a commencé à rejeter le courrier non conforme en 2025. Si vous envoyez via Postmark sans vérifier votre domaine, Postmark peut tout de même remettre le courrier, mais les messages sont signés DKIM par le domaine de Postmark lui-même et transitent par un Return-Path sur pm.mtasv.net, de sorte que ni DKIM ni SPF ne s'aligne sur votre adresse From. C'est toléré à DMARC p=none, mais dès que vous (ou quiconque sur un domaine parent partagé) passez à p=quarantine ou p=reject, le courrier Postmark non aligné se retrouve en quarantaine ou rejeté. Vérifier le domaine règle cela en deux enregistrements : DKIM s'aligne sur votre domaine, le Return-Path personnalisé aligne aussi SPF, DMARC passe sur les deux, et la réputation d'envoi que vous construisez s'accumule sur votre domaine plutôt que sur l'infrastructure partagée de Postmark.
La réalité SPF pour Postmark
Postmark dispose bien d'un SPF include partagé — l'hôte est include:spf.mtasv.net (mtasv est le domaine d'infrastructure de transfert de courrier de Postmark) — mais Postmark a délibérément cessé de demander aux clients de l'ajouter à leur racine, et pour presque tout le monde c'est le bon choix. Voici pourquoi : SPF est validé par rapport au Return-Path (l'enveloppe MAIL FROM), pas votre adresse From visible. Par défaut, le Return-Path de Postmark réside sur son propre domaine (pm.mtasv.net), donc SPF passe déjà — mais il passe pour le domaine de Postmark, qui ne s'aligne PAS avec votre domaine From, il ne peut donc pas aider DMARC. Ajouter include:spf.mtasv.net à votre SPF RACINE n'y change rien, car votre domaine racine n'est pas ce qui apparaît dans le Return-Path ; l'include ne ferait que rester là à consommer une résolution sans bénéfice. La bonne démarche est un Return-Path personnalisé : ajoutez un CNAME sur pm-bounces.yourdomain.com pointant vers pm.mtasv.net. Ce sous-domaine hérite du SPF publié par Postmark lui-même (une résolution en direct confirme que pm.mtasv.net publie v=spf1 include:spf.mtasv.net -all) ainsi que des enregistrements MX de rebond, de sorte que SPF passe là ET que le Return-Path est désormais sur votre domaine organisationnel — ce qui signifie que SPF s'aligne pour DMARC. En résumé : l'include partagé (spf.mtasv.net) existe, mais la configuration Postmark moderne et recommandée est un CNAME Return-Path personnalisé plus une clé DKIM TXT, sans rien ajouter à votre SPF racine. L'include ne vaut la peine d'être touché que dans le cas rare où vous envoyez spécifiquement depuis votre apex via Postmark et souhaitez une autorisation explicite là — et même dans ce cas Postmark indique qu'il n'est pas requis.
Deux façons de le configurer
CNAME Return-Path personnalisé + DKIM (recommandé)
- Ajoutez une clé DKIM TXT et un CNAME pm-bounces → pm.mtasv.net ; rien ne va sur votre SPF racine
- SPF passe ET s'aligne parce que le Return-Path est désormais sur votre propre domaine, donc DMARC passe à la fois sur SPF et DKIM
- N'ajoute aucune résolution DNS à votre enregistrement SPF racine — il n'y a rien à y fusionner
- C'est exactement ce que le tableau de bord de Postmark vous invite à faire ; c'est la voie prise en charge
Ajouter include:spf.mtasv.net à votre SPF racine (inutile)
- Vous colleriez vous-même v=spf1 a mx include:spf.mtasv.net ~all sur votre apex
- Postmark indique explicitement que ce n'est PAS requis — et cela ne fait rien pour l'alignement
- Sur votre racine, cela ne peut pas aider DMARC, car votre racine n'est pas le Return-Path qu'utilise Postmark
- Concevablement pertinent seulement si vous envoyez depuis votre apex nu via Postmark ; coûte une résolution sans gain sinon
Étape par étape
- 1
Ouvrez Sender Signatures → Domains
Connectez-vous sur account.postmarkapp.com, ouvrez Sender Signatures depuis le menu du compte, puis passez à l'onglet Domains. Vérifier le domaine entier (pas seulement un unique expéditeur confirmé) est ce qui donne à chaque adresse de votre domaine l'alignement SPF/DKIM.
- 2
Ajoutez votre domaine
Cliquez sur Add Domain et saisissez yourdomain.com. Postmark crée l'ensemble d'enregistrements et ouvre la page DNS Settings du domaine, où les lignes DKIM et Return-Path attendent d'être vérifiées.
- 3
Copiez l'enregistrement DKIM
Sur la page DNS Settings, notez la ligne DKIM : un enregistrement TXT dont le Hostname est un sélecteur attribué par Postmark se terminant par pm._domainkey (par exemple 20260727pm._domainkey) et dont la Value est une longue clé v=DKIM1; k=rsa; p=…. Ce sélecteur et cette clé sont propres à votre domaine.
- 4
Copiez l'enregistrement Return-Path
Dans la section Return-Path, notez le CNAME : le Hostname par défaut est pm-bounces (c.-à-d. pm-bounces.yourdomain.com) et la Value est pm.mtasv.net. C'est l'enregistrement qui aligne SPF sur votre domaine. Vous pouvez changer le libellé pm-bounces, mais il doit rester un CNAME vers pm.mtasv.net.
- 5
Ajoutez l'enregistrement DKIM TXT
Chez votre hébergeur DNS, créez un enregistrement TXT. Host = le sélecteur que Postmark affiche (p. ex. 20260727pm._domainkey), Value = la chaîne complète v=DKIM1;…, collée exactement. Postmark émet des clés 2048 bits, la valeur est donc longue — voyez le piège concernant sa scission si votre panneau impose une limite de 255 caractères par chaîne.
- 6
Ajoutez le CNAME Return-Path
Créez un enregistrement CNAME : Host = pm-bounces, Value = pm.mtasv.net. N'ajoutez aucun autre enregistrement (ni TXT, ni A) sur le sous-domaine pm-bounces — un CNAME ne peut pas coexister avec d'autres types d'enregistrement sur le même nom.
- 7
Laissez votre SPF racine tranquille
N'ajoutez PAS include:spf.mtasv.net à votre SPF apex. Ce n'est pas requis et cela ne fait rien pour l'alignement. Si vous avez déjà un enregistrement SPF racine pour d'autres expéditeurs (Google Workspace, Microsoft 365, etc.), conservez-le tel quel — le CNAME pm-bounces gère le SPF de Postmark sur son propre sous-domaine.
- 8
Publiez ou conservez un seul enregistrement DMARC
Si vous n'avez pas encore de DMARC, ajoutez un enregistrement TXT sur _dmarc pointant vers v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Si vous en avez déjà un, laissez-le — vous ne conservez jamais qu'un seul enregistrement _dmarc pour tout le domaine.
- 9
Cliquez sur Verify dans Postmark
De retour sur la page DNS Settings du domaine, cliquez sur Verify à côté de DKIM et de Return-Path. La propagation ne prend généralement que quelques minutes mais peut aller jusqu'à 24–48 heures ; les deux lignes passent au vert lorsqu'elles se résolvent.
- 10
Envoyez un vrai test et affichez l'original
Une fois vérifié, envoyez un test depuis une adresse de votre domaine via Postmark, ouvrez-le dans Gmail, et utilisez ⋮ → Afficher l'original. Vous voulez voir SPF : PASS et DKIM : PASS affichant tous deux yourdomain.com (pas mtasv.net), plus DMARC : PASS.
Enregistrements à ajouter
Postmark génère les valeurs exactes dans son assistant de configuration — celles-ci illustrent la forme de ce que vous ajouterez chez votre hébergeur DNS.
| Type | Hôte | Valeur |
|---|---|---|
| TXT | 20260727pm._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC…Clé DKIM. Le sélecteur (le libellé YYYYMMDDpm._domainkey) et la clé sont propres à votre domaine — copiez les valeurs exactes depuis la page DNS Settings de Postmark. 2048 bits, elle peut donc nécessiter une scission en chaînes entre guillemets. |
| CNAME | pm-bounces | pm.mtasv.netReturn-Path personnalisé. C'est ce qui fait passer SPF (PASS) et ALIGNE SPF pour DMARC — il hérite du SPF de Postmark (vérifié en direct : pm.mtasv.net publie v=spf1 include:spf.mtasv.net -all) et du MX de rebond depuis pm.mtasv.net. Gardez-le en CNAME uniquement sur ce sous-domaine. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVotre politique DMARC — un seul enregistrement par domaine, distinct de Postmark. Commencez à p=none pour surveiller. |
| TXT | @ | v=spf1 a mx include:spf.mtasv.net ~allNON requis et non recommandé — ne l'ajoutez pas. Postmark a cessé de le demander ; sur votre racine, il ne fait rien pour l'alignement du Return-Path. Montré uniquement pour que vous reconnaissiez l'include hérité si vous le trouvez déjà en place. |
Conservez exactement un seul enregistrement SPF (v=spf1) TXT sur votre domaine racine — fusionnez-y tous vos expéditeurs. Avoir deux enregistrements SPF constitue en soi une erreur.
Le budget de 10 requêtes DNS
SPF est plafonné à une limite stricte de 10 requêtes DNS — dépassez-la et il renvoie une permerror et cesse de valider partout. Voici ce que coûte la configuration de Postmark sur ce budget.
La configuration recommandée de Postmark ajoute 0 requête — les 10 restent disponibles pour les expéditeurs qui, eux, ont besoin d'un include:.
DKIM
Chez Postmark, DKIM est un enregistrement TXT que vous publiez vous-même — pas une délégation CNAME comme chez SendGrid ou Mailchimp. Postmark vous attribue un sélecteur basé sur une date se terminant par pm._domainkey (par exemple 20260727pm._domainkey) et génère une clé RSA 2048 bits ; vous créez un enregistrement TXT avec ce Hostname et collez la valeur complète v=DKIM1; k=rsa; p=… exactement telle qu'affichée sur la page DNS Settings. Comme il s'agit d'un enregistrement TXT contenant la clé publique (Postmark conserve la clé privée), Postmark ne peut pas la faire tourner silencieusement comme le peut un fournisseur qui délègue par CNAME — à la place, Postmark propose une action manuelle Rotate DKIM Key qui génère une nouvelle clé sous un nouveau sélecteur et vous montre un enregistrement en attente à publier ; une fois le nouveau TXT vérifié, Postmark bascule la signature et vous pouvez retirer l'ancien. Une rotation périodique (deux fois par an est une cadence raisonnable) est une bonne hygiène. Point important : une clé DKIM vérifiée suffit à elle seule à faire passer le courrier Postmark à DMARC, car DKIM s'aligne sur votre domaine — le Return-Path personnalisé est ce qui vous donne en plus l'alignement SPF.
DMARC
DMARC est un enregistrement de politique distinct sur votre domaine racine — ce n'est pas l'un des enregistrements Postmark, et vous conservez exactement un seul _dmarc TXT pour tout le domaine, quel que soit le nombre d'expéditeurs que vous utilisez. Publiez-le sur _dmarc.yourdomain.com en commençant par v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est en mode surveillance uniquement, il n'affectera donc pas la remise pendant que vous confirmez que le courrier Postmark passe. Surveillez les rapports agrégés (rua) pendant une semaine ou deux : avec DKIM vérifié, vous verrez Postmark listé comme aligné DKIM et passant, et une fois le Return-Path personnalisé pm-bounces en place, SPF s'affichera également comme aligné. Ce n'est qu'après que Postmark (et tout autre expéditeur légitime) passe en aligné que vous devriez resserrer vers p=quarantine puis, à terme, p=reject. Notez l'interaction que Postmark lui-même signale : si votre domaine est à p=quarantine/reject et que vous omettez le Return-Path personnalisé, SPF ne s'alignera pas — vous vous appuieriez sur l'alignement DKIM seul, ce qui fonctionne mais ne vous laisse aucun recours SPF ; ajoutez donc le CNAME pm-bounces.
Vérifiez que tout fonctionne réellement
Ne vous fiez pas aux seuls badges verts « Verified » — confirmez-le sur un vrai message. Envoyez-vous un test depuis une adresse de votre domaine via Postmark, ouvrez-le dans Gmail, et choisissez ⋮ → Afficher l'original : vous voulez voir SPF : PASS et DKIM : PASS affichant tous deux yourdomain.com (pas mtasv.net), plus DMARC : PASS. Vérifiez la ligne Return-Path / mailed-by — elle devrait indiquer pm-bounces.yourdomain.com, ce qui prouve que votre Return-Path personnalisé fait son travail. Vous préférez un bilan récapitulatif ? Passez le domaine dans le contrôle de santé de domaine de Qualisend pour confirmer que le DKIM TXT et le CNAME pm-bounces se résolvent, utilisez le vérificateur SPF/DKIM/DMARC pour une lecture rapide des enregistrements, et une fois que les rapports agrégés DMARC commencent à arriver, déposez-en un dans l'analyseur de rapports DMARC — Postmark devrait y apparaître comme une source alignée et passante.
Pièges courants
- Casse l'authentification
N'ajoutez pas include:spf.mtasv.net à votre SPF racine. Postmark a délibérément cessé de le demander — sur votre apex, il ne fait rien pour l'alignement car votre domaine racine n'est pas le Return-Path qu'utilise Postmark. Ajoutez plutôt le CNAME Return-Path personnalisé pm-bounces.
- Couverture
L'hôte de l'include est spf.mtasv.net, pas postmarkapp.com. MTASV est le domaine d'infrastructure de transfert de courrier de Postmark ; la cible du Return-Path (pm.mtasv.net) et son MX de rebond y résident aussi.
- Configuration DNS
Le sous-domaine pm-bounces doit être un CNAME uniquement. Le DNS n'autorise pas un CNAME à coexister avec un autre type d'enregistrement sur le même nom, donc ne placez pas non plus de TXT ou de A sur pm-bounces.yourdomain.com, sinon la vérification échouera.
- Configuration DNS
Les valeurs DKIM 2048 bits sont longues. Certains panneaux DNS plafonnent une chaîne TXT à 255 caractères et vous obligent à scinder la clé en plusieurs chaînes entre guillemets — scindez-la, ne supprimez aucun caractère, et n'introduisez pas d'espaces parasites dans la valeur p=.
- Configuration DNS
Sur Cloudflare, réglez le CNAME pm-bounces sur DNS only (nuage gris). Un enregistrement proxifié en nuage orange ne se résoudra pas vers pm.mtasv.net et la vérification du Return-Path échouera.
- Configuration DNS
Doublement du champ Host : de nombreux registrars ajoutent automatiquement votre domaine, donc saisir 20260727pm._domainkey.yourdomain.com devient …yourdomain.com.yourdomain.com. Saisissez uniquement le libellé (le sélecteur, ou pm-bounces) si le panneau ajoute le domaine pour vous.
- Couverture
Une seule Sender Signature confirmée n'est pas une authentification de domaine — elle vérifie une adresse From mais ne vous donne pas l'alignement DKIM/SPF sur l'ensemble du domaine. Vérifiez le domaine entier (DKIM + Return-Path) sous l'onglet Domains.
- Casse l'authentification
Conservez exactement un seul SPF TXT et un seul _dmarc TXT sur votre racine. Si vous envoyez aussi depuis d'autres fournisseurs, fusionnez leurs mécanismes dans un unique enregistrement v=spf1 — deux enregistrements SPF constituent en soi une PermError.
Construisez votre enregistrement SPF
Postmark n'a pas besoin d'un include: SPF sur votre domaine racine — utilisez le générateur pour assembler un enregistrement propre et unique pour vos autres expéditeurs, en le limitant à une seule ligne.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF Postmark — FAQ
Lectures complémentaires
Une fois publié, confirmez que tout se résout correctement avec la vérification de l'état du domaine, puis identifiez qui envoie en votre nom grâce à l'analyseur de rapports DMARC. Parcourez toutes les sources d'envoi dans le générateur. L'authentification ne représente toutefois que la moitié de la délivrabilité — une IP ou un domaine d'envoi inscrit sur une liste vous fait toujours atterrir dans les spams, quelle que soit la propreté de votre SPF ; il vaut donc la peine de surveiller les listes noires avec la surveillance des listes noires.
Authentifié — maintenant, gardez votre liste propre
Réussir SPF, DKIM et DMARC vous mène jusqu'à la boîte de réception ; une liste propre vous y maintient. Vérifiez la vôtre — commencez gratuitement avec 100 crédits, sans carte bancaire.