Dois-je ajouter include:sparkpostmail.com à mon enregistrement SPF ?

Pas pour DMARC. SparkPost possède l'enveloppe/Return-Path (le bounce domain par défaut est sparkpostmail.com), si bien qu'un include SPF racine n'est jamais évalué pour votre domaine et ne peut pas s'aligner. Configurez plutôt l'enregistrement TXT DKIM scph et un bounce domain personnalisé — c'est ce qui fait réellement réussir DMARC. L'include existe toujours et se résout, mais il est hérité et optionnel, et si vous l'ajoutiez, il coûterait deux de vos dix lookups SPF pour rien (l'include plus la macro exists dans l'enregistrement de SparkPost).

Pourquoi mon courrier SparkPost réussit-il SPF mais échoue-t-il quand même à DMARC ?

Parce que la validation SPF n'est pas alignée. Avec le bounce domain par défaut de SparkPost, le Return-Path est sparkpostmail.com, si bien que SPF réussit sur le domaine de SparkPost, pas le vôtre — et DMARC ne comptabilise SPF que lorsqu'il est aligné sur votre domaine From. Ajoutez un Bounce Domain personnalisé (un sous-domaine en CNAME vers sparkpostmail.com) pour que l'enveloppe soit sur votre domaine, et assurez-vous que votre enregistrement DKIM scph est vérifié afin que DKIM s'aligne lui aussi.

Le DKIM de SparkPost est-il un CNAME ou un enregistrement TXT ?

Un enregistrement TXT. SparkPost génère une clé RSA et vous fournit un TXT à scphNNNN._domainkey.yourdomain.com avec une valeur v=DKIM1; k=rsa; h=sha256; p=…. Contrairement aux fournisseurs à délégation CNAME, vous publiez la clé réelle, donc conservez le type d'enregistrement TXT et effectuez la rotation manuellement si nécessaire. Parce que la clé par défaut est de 2048 bits, la valeur peut nécessiter d'être scindée en plusieurs chaînes entre guillemets sur certains panneaux DNS.

Quelle est la différence entre l'alignement de bounce strict et relâché ?

L'alignement relâché (le défaut de DMARC) utilise un sous-domaine apparenté — par ex. bounces.yourdomain.com ou mail.yourdomain.com comme Return-Path alors que votre From est sur yourdomain.com. Il réussit tant que le sous-domaine de bounce et votre From partagent le même domaine organisationnel, c'est donc le choix pratique pour la plupart des expéditeurs. L'alignement strict exige que le domaine du Return-Path corresponde exactement à votre domaine From — avec SparkPost, vous l'obtenez en utilisant votre sous-domaine d'envoi exact (par ex. mail.yourdomain.com) à la fois comme domaine d'envoi et comme bounce domain. Laissez DMARC en relâché (aspf=r) sauf si vous avez une raison spécifique d'imposer le mode strict.

Comment configurer SparkPost dans la région UE ?

SparkPost EU est une pile totalement distincte. Connectez-vous sur app.eu.sparkpost.com, envoyez via smtp.eu.sparkpostmail.com / api.eu.sparkpost.com, et pointez votre CNAME de bounce domain personnalisé vers eu.sparkpostmail.com au lieu de sparkpostmail.com. Le TXT DKIM scph et l'enregistrement DMARC fonctionnent de la même manière, mais le même domaine enregistré sur US et EU correspond à deux comptes indépendants avec leurs propres enregistrements DNS — publiez les enregistrements que le tableau de bord UE vous affiche, pas ceux des US.

SparkPost effectue-t-il la rotation de ma clé DKIM automatiquement ?

Non. Parce que le DKIM de SparkPost est un enregistrement TXT que vous publiez (et non un CNAME délégué vers SparkPost), vous détenez la clé publique publiée et il n'y a pas de rotation silencieuse. Pour effectuer une rotation, générez une nouvelle clé dans Configuration → Sending Domains, publiez le nouveau TXT scph, vérifiez-le, puis supprimez l'ancien enregistrement une fois la signature basculée. Effectuer une rotation de temps en temps est une bonne hygiène, mais c'est une étape manuelle.

Mon domaine SparkPost ou mon bounce domain ne se vérifie pas — quel est le problème ?

En général l'une de ces quelques causes : le DNS n'a pas encore propagé (accordez-lui jusqu'à 24–48 heures) ; votre registrar a dédoublé l'hôte (scph0421._domainkey.yourdomain.com est devenu …yourdomain.com.yourdomain.com — saisissez uniquement le libellé) ; une clé DKIM de 2048 bits qui devait être scindée a été collée avec une erreur ; ou, pour le bounce domain, un CNAME proxifié (nuage orange) sur Cloudflare qui ne se résout jamais vers sparkpostmail.com. Réglez le CNAME de bounce sur DNS only, revérifiez le champ hôte, puis cliquez de nouveau sur Verify.

Guide de configuration SPF

SPF, DKIM et DMARC pour SparkPost.

SparkPost (désormais intégré à Bird, anciennement MessageBird) authentifie votre domaine depuis Configuration → Sending Domains, où il génère une clé DKIM que vous publiez sous la forme d'un enregistrement TXT sur votre domaine d'envoi. Cette signature DKIM — signée en d=yourdomain.com — est le mécanisme qui porte réellement votre validation DMARC. SPF est le piège propre à SparkPost : par défaut, SparkPost envoie le bounce/enveloppe depuis son propre domaine partagé (sparkpostmail.com), si bien qu'une vérification SPF simple réussit sur le domaine de SparkPost mais ne s'aligne jamais sur le vôtre. La solution est un Bounce Domain personnalisé — un CNAME qui pointe un sous-domaine du vôtre vers sparkpostmail.com et devient votre Return-Path, de sorte que SPF s'aligne lui aussi. Ajoutez un enregistrement de politique DMARC et vous disposez des trois, alignés, sans rien ajouter à votre SPF racine.

Include SPF

Your DNSAdd the CNAME / TXT records

SparkPostSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Pourquoi authentifier SparkPost ?

Authentifier votre domaine SparkPost n'est pas une simple formalité — cela détermine si votre courrier transactionnel et marketing à fort volume atteint la boîte de réception, tout court. Depuis février 2024, Gmail et Yahoo exigent que tout expéditeur en masse (environ 5 000 messages par jour ou plus) réussisse SPF, DKIM et DMARC avec alignement, et Microsoft a commencé à appliquer les mêmes règles aux boîtes grand public Outlook/Hotmail/Live en 2025 — précisément les volumes pour lesquels SparkPost est conçu. Tant que vous n'authentifiez pas, SparkPost signe votre courrier avec une clé partagée et le renvoie (bounce) depuis sparkpostmail.com : votre adresse From n'est pas cryptographiquement la vôtre, DMARC ne peut pas réussir, et votre réputation est mutualisée avec celle de tous les autres expéditeurs non authentifiés de cette infrastructure. Il existe une particularité propre à SparkPost qui rend DKIM non négociable : parce que SparkPost possède le Return-Path par défaut, SPF réussit mais ne s'aligne pas sur votre domaine, si bien que DKIM est le seul mécanisme qui porte votre validation DMARC tant que vous n'avez pas également configuré un bounce domain personnalisé. Mettre en place DKIM ainsi qu'un bounce domain aligne les deux mécanismes sur vous, lève le doute des destinataires sur votre identité, permet à DMARC de réussir, et construit votre réputation d'envoi sous votre propre nom plutôt que dans le pool partagé.

La réalité SPF pour SparkPost

SparkPost est nominalement un fournisseur « include » — include:sparkpostmail.com (et include:_spf.sparkpostmail.com, qui résout vers l'enregistrement identique) existent tous deux et se vérifient en DNS — mais ajouter cet include à votre SPF racine est une pratique héritée qui ne permet PAS à DMARC de réussir. Voici pourquoi. L'enregistrement en vigueur est v=spf1 exists:%{i}._spf.sparkpostmail.com ~all — une macro exists: qui autorise les IP sortantes de SparkPost par IP (%{i} est l'IP émettrice, vérifiée contre une zone joker) plutôt que de lister des plages ip4: fixes. SPF est toujours évalué par rapport au domaine de l'enveloppe MAIL FROM / Return-Path, et par défaut ce domaine est sparkpostmail.com, que SparkPost possède. SPF se résout donc et réussit sur le domaine de SparkPost, mais il ne s'aligne jamais sur votre domaine From organisationnel — et DMARC ne comptabilise SPF que lorsqu'il est aligné. Publier include:sparkpostmail.com sur votre propre domaine racine n'y change rien, car votre domaine racine n'est jamais le domaine d'enveloppe ; cela consomme simplement deux de vos dix lookups SPF (l'include lui-même plus le mécanisme exists imbriqué dans l'enregistrement de sparkpostmail.com) sans aucun bénéfice d'alignement. La voie SPF alignée est un Bounce Domain personnalisé : vous pointez un sous-domaine du vôtre (par ex. bounces.yourdomain.com) vers sparkpostmail.com avec un CNAME, SparkPost utilise ce sous-domaine comme Return-Path, et désormais la vérification SPF s'exécute contre votre sous-domaine (aligné en mode relâché sur votre domaine organisationnel) tout en héritant du SPF de sparkpostmail.com via le CNAME. Voilà pourquoi le flux propre à SparkPost vous fournit un enregistrement TXT DKIM et un CNAME de bounce domain, et non une ligne SPF à coller sur votre apex. Réservez votre enregistrement SPF racine aux expéditeurs qui placent réellement votre domaine dans le Return-Path (Google Workspace, Microsoft 365, un relais que vous contrôlez), et laissez le CNAME de bounce + DKIM faire le travail de SparkPost.

Deux façons de le configurer

Recommandé

Bounce domain personnalisé + DKIM (recommandé, aligné)

Un TXT DKIM avec un sélecteur scph signe le courrier en d=yourdomain.com — le mécanisme qui fait réellement réussir DMARC
Un CNAME de bounce domain personnalisé (par ex. bounces.yourdomain.com → sparkpostmail.com) aligne aussi SPF sur votre domaine
N'ajoute aucun lookup DNS à votre SPF racine — l'enregistrement de bounce réside sur son propre sous-domaine, pas sur votre apex
Fonctionne de la même manière sur SparkPost US et EU (l'UE pointe simplement le CNAME vers eu.sparkpostmail.com)

Ancienne méthode

Include SPF racine (hérité, ne s'aligne pas)

Vous ajoutez vous-même v=spf1 include:sparkpostmail.com ~all à votre SPF racine
SparkPost possède l'enveloppe (bounce par défaut = sparkpostmail.com), si bien que ce SPF ne s'aligne jamais sur votre domaine
Il ne fait rien pour DMARC — DKIM et le bounce domain accomplissent tout le travail
Coûte deux de vos 10 lookups SPF (l'include plus le mécanisme exists imbriqué) sans aucun bénéfice d'alignement ; on peut le laisser totalement de côté sans risque

Étape par étape

Dans SparkPost

1
Ouvrez Sending Domains et ajoutez votre domaine
Connectez-vous à SparkPost (app.sparkpost.com, ou app.eu.sparkpost.com pour les comptes UE) et allez dans Configuration → Sending Domains → Add Domain. Saisissez le domaine ou sous-domaine depuis lequel vous enverrez (un sous-domaine comme mail.yourdomain.com est courant et maintient la réputation d'envoi séparée) puis enregistrez.
2
Copiez l'enregistrement DKIM généré par SparkPost
Sur l'écran de configuration du domaine, SparkPost affiche un enregistrement DKIM sous « Set up for DKIM signing ». C'est un enregistrement TXT : l'hôte est un sélecteur généré automatiquement comme scph0421._domainkey.yourdomain.com et la valeur commence par v=DKIM1; k=rsa; h=sha256; p=… suivie de votre clé publique. SparkPost utilise par défaut une clé de 2048 bits, donc la valeur est longue — copiez le tout exactement.

Dans votre DNS

3
Publiez l'enregistrement TXT DKIM
Chez votre hébergeur DNS, créez un enregistrement TXT avec l'hôte scph0421._domainkey (sous votre domaine/sous-domaine d'envoi) et collez la valeur v=DKIM1… complète. Conservez-le en tant qu'enregistrement TXT — le DKIM de SparkPost n'est pas un CNAME. Parce que c'est une clé de 2048 bits, certains panneaux limitent une chaîne TXT à 255 caractères et vous obligent à la scinder en plusieurs chaînes entre guillemets — scindez-la, ne supprimez pas de caractères. Si votre panneau ajoute automatiquement le domaine, saisissez uniquement le libellé (scph0421._domainkey) pour éviter de le dédoubler.

Dans SparkPost

4
Vérifiez le domaine d'envoi
De retour sur l'écran Sending Domains, cochez la case confirmant que vous avez ajouté l'enregistrement et cliquez sur Verify Domain. Une fois résolu, le domaine s'affiche comme vérifié et « DKIM Signing » indique prêt — SparkPost ne signera pas avec votre clé tant que cela n'a pas basculé. La propagation prend généralement quelques minutes mais peut aller jusqu'à 24–48 heures.
5
Ajoutez un Bounce Domain personnalisé
Allez dans Configuration → Bounce Domains (ou choisissez l'option Bounce Domain lors de l'ajout d'un domaine) et ajoutez un sous-domaine pour posséder le Return-Path — par ex. bounces.yourdomain.com pour un alignement relâché, ou réutilisez votre sous-domaine d'envoi exact (mail.yourdomain.com) pour un alignement strict. C'est l'étape qui vous donne l'alignement SPF.

Dans votre DNS

6
Publiez le CNAME du bounce domain
Créez un enregistrement CNAME : hôte = votre sous-domaine de bounce (bounces), valeur = sparkpostmail.com (pour SparkPost EU, pointez-le plutôt vers eu.sparkpostmail.com). Sur Cloudflare, réglez l'enregistrement sur « DNS only » (nuage gris) — un CNAME proxifié en nuage orange ne se résoudra pas vers SparkPost et la vérification échouera.

Dans SparkPost

7
Vérifiez le bounce domain
Retournez dans Bounce Domains et cliquez pour vérifier. Une fois au vert, SparkPost utilise votre sous-domaine comme MAIL FROM d'enveloppe, si bien que SPF réussit désormais ET s'aligne sur votre domaine organisationnel — un second mécanisme aligné aux côtés de DKIM.

Dans votre DNS

8
Ajoutez un enregistrement de politique DMARC
SparkPost ne crée pas DMARC pour vous. Ajoutez un enregistrement TXT à l'hôte _dmarc avec v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est en mode surveillance seule, donc rien ne change à la délivrabilité pendant que vous confirmez que SparkPost réussit SPF et DKIM alignés ; vous le resserrerez plus tard.

Vérifier

9
Envoyez un test et lisez les en-têtes
Envoyez-vous un message via SparkPost depuis une adresse sur le domaine authentifié, ouvrez-le dans Gmail, et choisissez ⋮ → Afficher l'original. Vous voulez DKIM : PASS signé par yourdomain.com (sélecteur scph…), SPF : PASS avec le mailfrom sur votre sous-domaine de bounce (et non sparkpostmail.com), et DMARC : PASS. Confirmez ensuite que chaque enregistrement se résout à l'aide d'un contrôle de santé de domaine.

Enregistrements à ajouter

SparkPost 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	scph0421._domainkey	v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(2048-bit public key from SparkPost)DKIM — le mécanisme aligné qui fait réussir DMARC. Le sélecteur scph est généré automatiquement par compte (par ex. scph0421, scph0717) ; valeur illustrative — copiez l'enregistrement exact depuis Configuration → Sending Domains. SparkPost utilise par défaut une clé de 2048 bits, donc scindez-la en plusieurs chaînes entre guillemets si votre panneau limite les TXT à 255 caractères. Publiez sous votre domaine/sous-domaine d'envoi, par ex. scph0421._domainkey.mail.yourdomain.com.
CNAME	bounces	sparkpostmail.comBounce Domain personnalisé (Return-Path) — c'est ce qui fait qu'SPF S'ALIGNE sur votre domaine. Utilisez un sous-domaine, pas votre apex. SparkPost EU pointe ceci vers eu.sparkpostmail.com. Réglez sur « DNS only » (nuage gris) sur Cloudflare.
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVous l'ajoutez vous-même — SparkPost ne le crée jamais. Un seul par domaine ; commencez à p=none, puis montez en puissance vers quarantine/reject.
TXT	@	v=spf1 include:sparkpostmail.com ~allHÉRITÉ / OPTIONNEL — ne crée PAS d'alignement DMARC car SparkPost possède l'enveloppe. Le CNAME de bounce ci-dessus est la voie SPF alignée ; n'ajoutez ceci que si vous souhaitez que votre SPF brut référence SparkPost, et si vous le faites, fusionnez-le dans votre unique enregistrement SPF racine. Cela coûte deux lookups — l'include plus la macro exists imbriquée dans l'enregistrement de sparkpostmail.com.

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 SparkPost sur ce budget.

SPF 10-lookup budget0 used · 10 free

La configuration recommandée de SparkPost ajoute 0 requête — les 10 restent disponibles pour les expéditeurs qui, eux, ont besoin d'un include:.

DKIM

DKIM est l'enregistrement porteur pour SparkPost, car c'est le mécanisme qui s'aligne par défaut. Lorsque vous ajoutez un domaine d'envoi, SparkPost génère une paire de clés RSA (2048 bits par défaut) et vous affiche un enregistrement TXT à publier : l'hôte est un sélecteur généré automatiquement de la forme scphNNNN._domainkey.yourdomain.com (par exemple scph0421._domainkey — les quatre chiffres sont attribués par compte/clé), et la valeur est v=DKIM1; k=rsa; h=sha256; p=<votre clé publique>. Vous publiez ce TXT chez votre hébergeur DNS ; SparkPost conserve la clé privée correspondante et signe chaque message sortant avec, si bien que la signature DKIM porte d=yourdomain.com et s'aligne sur votre adresse From. Deux choses distinguent le DKIM de SparkPost des fournisseurs à délégation CNAME (SendGrid, Mailchimp, Klaviyo). Premièrement, c'est un enregistrement TXT que vous collez — et non un CNAME — donc publier un CNAME là où le TXT scph est attendu cassera la signature ; conservez le type d'enregistrement TXT. Deuxièmement, parce que vous détenez la clé publiée plutôt que de la déléguer, il n'y a pas de rotation automatique des clés : si vous devez un jour effectuer une rotation, vous générez une nouvelle clé dans SparkPost et republiez vous-même le nouveau TXT scph. Une subtilité pratique liée au défaut à 2048 bits : la clé publique dépasse la limite d'une chaîne unique TXT de 255 caractères, si bien que de nombreux panneaux DNS vous obligent à la scinder en plusieurs chaînes entre guillemets (SparkPost peut émettre une clé de 1024 bits si votre hébergeur ne gère pas les TXT multi-chaînes). Publier l'enregistrement ne suffit pas à lui seul — vous devez revenir à Configuration → Sending Domains et cliquer sur Verify Domain pour que le domaine s'affiche comme vérifié et que « DKIM Signing » indique prêt ; SparkPost ne signera pas avec votre clé tant que cela n'a pas basculé.

DMARC

DMARC est un enregistrement de politique distinct que vous ajoutez vous-même — SparkPost ne le crée pas. Publiez un enregistrement TXT à _dmarc.yourdomain.com commençant par v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est en mode surveillance seule : cela ne change rien à la délivrabilité pendant que les destinataires vous envoient par e-mail des rapports agrégés (rua), de sorte que vous puissiez confirmer que le courrier SparkPost réussit SPF et DKIM alignés sur votre domaine. C'est là que la configuration en deux volets de SparkPost porte ses fruits — une fois votre enregistrement DKIM scph vérifié, vous obtenez l'alignement DKIM, et une fois votre bounce domain personnalisé vérifié, vous obtenez aussi l'alignement SPF, si bien qu'un domaine SparkPost correctement configuré réussit DMARC sur les deux mécanismes plutôt que de s'appuyer sur DKIM seul. Surveillez les rapports pendant une semaine ou deux, assurez-vous que chaque expéditeur légitime (SparkPost plus tout ce que vous utilisez par ailleurs) s'authentifie, puis resserrez vers p=quarantine et finalement p=reject. Conservez exactement un seul enregistrement _dmarc pour l'ensemble du domaine organisationnel, quel que soit le nombre d'expéditeurs que vous exploitez — ne publiez jamais un second enregistrement DMARC spécifiquement pour SparkPost.

Vérifiez que tout fonctionne réellement

Ne vous fiez pas aux seules coches vertes du tableau de bord — confirmez-le sur un vrai message. Envoyez-vous un test via SparkPost depuis une adresse sur le domaine authentifié, ouvrez-le dans Gmail, et choisissez ⋮ → Afficher l'original. Vous voulez DKIM : PASS signé par yourdomain.com avec le sélecteur scph (et non un domaine SparkPost partagé), SPF : PASS où le mailfrom/Return-Path affiche votre sous-domaine de bounce (bounces.yourdomain.com — le signe révélateur d'échec est un mailfrom encore sur sparkpostmail.com, signifiant que votre bounce domain personnalisé n'est pas configuré), et DMARC : PASS. Dans SparkPost, Configuration → Sending Domains devrait afficher le domaine vérifié avec DKIM Signing prêt, et Bounce Domains devrait afficher votre sous-domaine de bounce vérifié. Passez ensuite votre domaine dans le contrôle de santé de domaine de Qualisend pour confirmer que le TXT DKIM, le CNAME de bounce et l'enregistrement DMARC se résolvent tous proprement, et une fois que les rapports agrégés DMARC commencent à arriver, déposez-en un dans l'analyseur de rapports DMARC — SparkPost devrait y apparaître comme une source alignée et validée.

Vérification de l'état du domaine Analyseur de rapports DMARC

Pièges courants

Configuration DNS
Le grand piège : ajouter include:sparkpostmail.com à votre SPF racine ne fait PAS réussir DMARC. SparkPost possède l'enveloppe (bounce domain par défaut = sparkpostmail.com), si bien que votre SPF racine n'est jamais consulté pour le courrier SparkPost. L'alignement provient du TXT DKIM scph plus un CNAME de bounce domain personnalisé — et non d'un include SPF.
Couverture
Avec le bounce domain par défaut, SPF réussit sur sparkpostmail.com mais ne s'aligne pas sur vous, si bien que DMARC repose entièrement sur DKIM. Ajoutez un Bounce Domain personnalisé pour obtenir un second mécanisme aligné et résister aux destinataires plus stricts.
Configuration DNS
Le DKIM de SparkPost est un enregistrement TXT (sélecteur scph), pas un CNAME. Ne changez pas le type — un CNAME là où le TXT scph doit se trouver casse la signature DKIM. Et il n'y a pas de rotation automatique des clés : pour effectuer une rotation, générez une nouvelle clé dans SparkPost et republiez le TXT.
Configuration DNS
SparkPost utilise par défaut une clé DKIM de 2048 bits, dont la valeur dépasse la limite TXT de 255 caractères. Certains panneaux DNS vous obligent à la scinder en plusieurs chaînes entre guillemets — scindez-la, ne la tronquez pas et n'ajoutez pas d'espaces parasites dans la valeur p=.
Configuration DNS
Le proxy Cloudflare casse le CNAME de bounce. Réglez l'enregistrement de bounce domain sur « DNS only » (nuage gris) — un CNAME proxifié en nuage orange ne se résoudra pas vers sparkpostmail.com et le domaine ne se vérifiera pas.
Configuration DNS
Vous ne pouvez pas utiliser votre racine/apex comme bounce domain — un CNAME sur l'apex entre en collision avec vos autres enregistrements. Utilisez un sous-domaine (bounces.yourdomain.com pour un alignement relâché, ou réutilisez votre sous-domaine d'envoi exact pour un alignement strict).
Configuration DNS
SparkPost EU est une pile distincte : connectez-vous sur app.eu.sparkpost.com, envoyez via smtp.eu.sparkpostmail.com / api.eu.sparkpost.com, et pointez le CNAME de bounce vers eu.sparkpostmail.com (et non sparkpostmail.com). Le même domaine sur US et EU correspond à deux enregistrements indépendants avec leurs propres enregistrements DNS.
Casse l'authentification
Conservez exactement un TXT SPF et un TXT _dmarc sur votre domaine. Si vous conservez malgré tout l'include SparkPost hérité pour une raison quelconque, fusionnez-le dans votre unique ligne v=spf1 — deux enregistrements SPF constituent en soi un PermError.
Configuration DNS
Vérifiez dans le tableau de bord après publication — SparkPost ne signera pas en DKIM tant que Configuration → Sending Domains n'affiche pas le domaine vérifié. La propagation peut prendre jusqu'à 24–48 heures ; si la vérification bloque, revérifiez l'hôte de l'enregistrement pour un domaine ajouté/dupliqué.

Construisez votre enregistrement SPF

SparkPost 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).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record0/10 DNS lookups

v=spf1 ~all

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 list

SPF SparkPost — FAQ

Lectures complémentaires

SPF, DKIM et DMARC expliquésComment les trois enregistrements fonctionnent ensemble — et pourquoi l'alignement, et pas seulement une validation, est ce que DMARC vérifie réellement.Comment configurer DMARCPubliez votre enregistrement _dmarc et passez de p=none à l'application sans bloquer le courrier SparkPost légitime.Comment lire les rapports DMARCDonnez du sens au XML agrégé rua afin de confirmer que SparkPost apparaît comme une source alignée et validée.Exigences des expéditeurs Google et YahooLes règles de 2024 pour les expéditeurs en masse qui rendent SPF, DKIM et DMARC alignés non négociables aux volumes de SparkPost.SPF, DKIM et DMARC sur CloudflareAjoutez correctement le TXT DKIM et le CNAME de bounce dans Cloudflare, en veillant notamment à garder l'enregistrement de bounce en DNS only (nuage gris).Contrôle de santé de domaineConfirmez que le TXT DKIM scph, le CNAME de bounce et votre enregistrement DMARC se résolvent tous proprement après la configuration.

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.

Commencer la vérification