SPF, DKIM et DMARC pour SMTP.com.
SMTP.com est un relais SMTP et une API e-mail — vous y dirigez votre application, votre CRM ou votre serveur de messagerie et il distribue en votre nom, de sorte que votre propre domaine doit l'autoriser. La configuration repose sur trois enregistrements DNS plus un réglage côté compte : un véritable include SPF (include:_spf.smtp.com) que vous fusionnez dans le SPF de votre domaine racine, un DKIM CNAME de domaine personnalisé sur le sélecteur smtpkey que SMTP.com doit également activer sur votre compte pour que le courrier soit signé au nom de votre domaine plutôt que du sien, partagé, et un enregistrement de politique DMARC que vous publiez vous-même. Alignez ces trois éléments et SMTP.com relaie en étant pleinement authentifié à votre nom, avec un DKIM aligné sur votre domaine d'expéditeur (From) pour que DMARC réussisse au lieu de s'appuyer sur le domaine de signature partagé de SMTP.com.
Pourquoi authentifier SMTP.com ?
Authentifier le domaine que vous relayez via SMTP.com détermine si votre courrier atteint la boîte de réception, et pour un relais à fort volume, les enjeux sont plus élevés que pour un hébergeur de boîtes aux lettres. Depuis février 2024, Gmail et Yahoo exigent que chaque 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 au courrier à fort volume entrant vers Outlook.com/Hotmail/Live en 2025 — précisément les volumes pour lesquels les gens utilisent SMTP.com. Le piège propre au relais : par défaut, SMTP.com signe en DKIM votre courrier sortant avec l'un de ses propres domaines partagés (d=smtpsend.com) et gère les rebonds sur son propre return-path, de sorte que ni SPF ni DKIM ne s'aligne sur votre domaine d'expéditeur (From). Cela signifie qu'un domaine SMTP.com non configuré ne dispose d'aucun mécanisme aligné — DMARC ne peut pas réussir, les destinataires peuvent afficher une mention « via smtpsend.com », et la réputation d'expédition que vous payez pour construire se mélange à celle de tous les autres expéditeurs non authentifiés sur l'infrastructure partagée. Activer l'include SPF et, surtout, le DKIM de domaine personnalisé est ce qui rend le courrier cryptographiquement vôtre, fait réussir DMARC et permet à la réputation de se construire sous votre propre domaine.
La réalité SPF pour SMTP.com
SMTP.com est un véritable fournisseur « include » : vous ajoutez un mécanisme partagé, include:_spf.smtp.com, à l'unique enregistrement SPF TXT de votre domaine racine, ce qui donne v=spf1 include:_spf.smtp.com ~all. C'est un vrai include partagé — chaque client SMTP.com utilise le même — et il est léger : l'include se résout en un enregistrement plat contenant seulement deux plages IPv4 et son propre softfail (v=spf1 ip4:192.40.160.0/19 ip4:74.91.80.0/20 ~all), il ne coûte donc qu'UNE seule de vos 10 recherches DNS SPF, et non les deux ou trois que rapportent certains vérificateurs en cache. Voici toutefois la nuance honnête qui piège les gens : ajouter cet include autorise les IP d'envoi de SMTP.com, mais cela ne suffit pas, à lui seul, à faire réussir DMARC. Par défaut, SMTP.com relaie avec son propre domaine d'enveloppe / return-path (il traite vos rebonds), et SPF est toujours évalué par rapport à ce domaine d'enveloppe — la vérification réussit donc par rapport à l'infrastructure de SMTP.com plutôt que de s'aligner sur votre domaine d'expéditeur (From). L'include reste malgré tout l'étape SPF correcte, documentée et recommandée (il évite les échecs SPF bruts et correspond à ce qu'attend la configuration de SMTP.com), c'est pourquoi vous devriez le publier — mais le mécanisme qui porte réellement votre réussite DMARC est le DKIM CNAME de domaine personnalisé, qui signe avec d=yourdomain.com. Considérez l'include comme nécessaire mais non suffisant : publiez-le, puis appuyez-vous sur DKIM pour l'alignement (le seul autre chemin vers un SPF aligné consiste à mettre en place un domaine de return-path/rebond personnalisé sur votre propre domaine avec SMTP.com, ce que la plupart des comptes laissent de côté au profit de DKIM). Et conservez exactement un seul enregistrement SPF sur le domaine — si vous envoyez aussi via Google Workspace, Microsoft 365 ou un autre outil, fusionnez include:_spf.smtp.com dans cette unique ligne v=spf1 plutôt que de publier un second SPF TXT (deux enregistrements SPF constituent un PermError).
Étape par étape
- 1
Identifiez le domaine que vous relayez
Connectez-vous au Control Panel de SMTP.com et notez le domaine d'expéditeur (From) au nom duquel votre application/API envoie (le domaine de votre en-tête From:, par ex. yourdomain.com). SMTP.com relaie le courrier pour toute adresse From que vous définissez, l'authentification se fait donc sur ce domaine organisationnel — pas sur un hôte appartenant à SMTP.com. C'est aussi là que se trouvent vos identifiants d'expéditeur/relais et vos réglages Reputation Defender.
- 2
Ajoutez ou fusionnez l'include SPF
Chez votre hébergeur DNS, créez UN enregistrement TXT sur la racine (hôte @ ou vide) avec v=spf1 include:_spf.smtp.com ~all. Si un enregistrement v=spf1 existe déjà (Google Workspace, Microsoft 365, un autre relais), n'en ajoutez pas un second — fusionnez include:_spf.smtp.com dans cet unique enregistrement aux côtés des autres mécanismes. Conservez le softfail ~all utilisé par SMTP.com, sauf si vous êtes certain que chaque expéditeur est répertorié.
- 3
Activez la signature DKIM de domaine personnalisé
Par défaut, SMTP.com signe avec son domaine partagé (d=smtpsend.com), ce qui ne s'aligne PAS. Pour que le courrier soit signé avec d=yourdomain.com sur le sélecteur smtpkey, la signature DKIM de domaine personnalisé doit être activée sur votre compte — c'est un réglage côté compte, demandez-le donc via le support SMTP.com ou votre gestionnaire de compte et confirmez le sélecteur/la cible exacts qu'ils vous attribuent (la paire largement publiée figure ci-dessous).
- 4
Ajoutez le CNAME DKIM
Créez un enregistrement CNAME : hôte smtpkey._domainkey (donc smtpkey._domainkey.yourdomain.com) pointant vers smtpcustomer._domainkey.smtpsend.com. Il s'agit d'une délégation — SMTP.com détient la clé privée derrière cette cible partagée et signe en votre nom. Conservez le type CNAME ; ne le remplacez pas par TXT ou A.
- 5
Publiez l'enregistrement DMARC
SMTP.com ne crée pas DMARC pour vous. Ajoutez un enregistrement TXT sur l'hôte _dmarc avec v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est en mode surveillance uniquement, de sorte que rien ne change au niveau de la distribution pendant que vous confirmez que le courrier de SMTP.com est signé et aligné ; vous le durcirez plus tard.
- 6
Corrigez le doublement d'hôte et le proxy Cloudflare
Si votre registrar ajoute automatiquement le domaine, saisissez uniquement l'étiquette (smtpkey._domainkey, et @ pour le SPF) pour ne pas vous retrouver avec smtpkey._domainkey.yourdomain.com.yourdomain.com. Sur Cloudflare, réglez le CNAME DKIM sur « DNS only » (nuage gris) — un CNAME proxifié en nuage orange ne se résoudra pas vers smtpsend.com et la validation DKIM échoue.
- 7
Envoyez un test et lisez les en-têtes
Une fois le DKIM personnalisé activé et les enregistrements propagés (généralement quelques minutes, jusqu'à 24 à 72 heures), relayez un test via SMTP.com vers une adresse Gmail, ouvrez-le et choisissez ⋮ → Afficher l'original. Vous voulez DKIM : PASS avec d=yourdomain.com et le sélecteur smtpkey (le signe révélateur d'un échec est d=smtpsend.com, ce qui signifie que la signature personnalisée n'est pas encore active), SPF : PASS et DMARC : PASS.
- 8
Confirmez que chaque enregistrement se résout
Passez votre domaine dans le contrôle de santé de domaine de Qualisend pour confirmer que le SPF reste à un enregistrement unique sous la limite des 10 recherches, que le CNAME smtpkey._domainkey se résout vers smtpsend.com et que l'enregistrement DMARC est présent. Une fois que les rapports agrégés commencent à arriver, déposez-en un dans l'analyseur de rapports DMARC pour voir SMTP.com apparaître comme une source alignée et validée.
Enregistrements à ajouter
SMTP.com 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 | @ | v=spf1 include:_spf.smtp.com ~allSPF racine — conservez exactement UN enregistrement SPF ; fusionnez cet include si vous avez déjà une ligne v=spf1. include:_spf.smtp.com se résout à plat (deux plages ip4 + ~all), il coûte donc 1 recherche DNS. Autorise les IP de SMTP.com mais ne s'aligne pas par défaut. |
| CNAME | smtpkey._domainkey | smtpcustomer._domainkey.smtpsend.comDKIM de domaine personnalisé (le mécanisme aligné). À titre indicatif — c'est la cible partagée largement documentée, mais confirmez le sélecteur/la cible exacts que SMTP.com attribue à votre compte. SMTP.com doit AUSSI activer la signature personnalisée côté compte, sinon le CNAME ne sert à rien. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVous l'ajoutez vous-même — SMTP.com ne le crée jamais. Un enregistrement DMARC par domaine ; commencez à p=none, puis durcissez vers quarantine/reject une fois que DKIM s'aligne proprement. |
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 SMTP.com sur ce budget.
SMTP.com utilise 1 de vos 10 requêtes ; les mécanismes ip4: et ip6: sont gratuits.
DKIM
DKIM est la partie qui vous fait réellement gagner votre réussite DMARC avec SMTP.com, et c'est l'étape que la plupart des gens manquent parce que SMTP.com « signe déjà » avant même que vous fassiez quoi que ce soit — mais avec le mauvais domaine. Par défaut, le relais signe en DKIM votre courrier sortant en utilisant l'un de ses propres domaines partagés (d=smtpsend.com). Cette signature est cryptographiquement valide, mais comme il ne s'agit pas de votre domaine, elle ne s'aligne pas et ne fait donc rien pour DMARC sur yourdomain.com. Pour corriger cela, vous activez le DKIM de domaine personnalisé, qui consiste en deux actions coordonnées : (1) publier un CNAME sur smtpkey._domainkey.yourdomain.com pointant vers smtpcustomer._domainkey.smtpsend.com, et (2) faire basculer votre compte par SMTP.com pour qu'il signe avec votre domaine sur le sélecteur smtpkey — c'est un réglage côté compte que l'on met généralement en place via le support SMTP.com ou votre gestionnaire de compte, ouvrez donc un ticket et confirmez le sélecteur/la cible exacts qu'ils vous attribuent (certains comptes peuvent recevoir une paire différente). Parce que l'enregistrement est un CNAME (et non une clé TXT que vous collez), SMTP.com détient la clé privée derrière cette cible partagée et peut la faire tourner sans que vous ayez à retoucher le DNS — le compromis du modèle à cible partagée est que la clé ne vous est pas propre, mais l'alignement ne dépend pas de l'unicité de la clé : ce qui compte, c'est que la valeur d= de la signature soit votre domaine organisationnel, ce qui devient le cas une fois la signature personnalisée activée. L'enregistrement publié de votre côté est petit et statique ; le gros du travail (la signature elle-même) se fait sur les serveurs de SMTP.com. Tant que le CNAME ne se résout PAS ET que la signature personnalisée n'est PAS activée, la fonction Afficher l'original continuera d'indiquer d=smtpsend.com et DMARC n'aura aucun mécanisme aligné.
DMARC
DMARC est un enregistrement TXT de politique distinct sur votre domaine que SMTP.com ne crée pas — vous le publiez chez votre hébergeur DNS. Ajoutez un enregistrement TXT sur _dmarc.yourdomain.com commençant par v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est en mode surveillance uniquement : cela ne change rien à la distribution mais indique aux destinataires de vous envoyer des rapports agrégés (rua), afin que vous puissiez confirmer que le courrier SMTP.com réussit un DKIM aligné sur votre domaine avant d'appliquer quoi que ce soit. Cette étape de surveillance compte plus que d'habitude avec SMTP.com, précisément parce que son SPF ne s'aligne pas par défaut — les rapports sont le moyen de vérifier que le DKIM CNAME personnalisé porte bien l'alignement. Surveillez-les pendant une semaine ou deux, assurez-vous que chaque source légitime (SMTP.com plus tout autre expéditeur) s'authentifie, puis durcissez la politique vers p=quarantine et à terme p=reject. Ne passez PAS directement à une politique stricte avant d'avoir confirmé que DKIM signe avec d=yourdomain.com — si la signature personnalisée n'est pas encore activée, un enregistrement p=reject fera rebondir votre propre courrier relayé. Conservez exactement un seul enregistrement _dmarc pour l'ensemble du domaine, quel que soit le nombre d'expéditeurs que vous utilisez ; n'ajoutez jamais un second enregistrement DMARC spécifiquement pour SMTP.com.
Vérifiez que tout fonctionne réellement
Ne vous fiez pas au Control Panel ni à un minuteur de propagation seul — confirmez l'authentification sur un vrai message. Relayez un test via SMTP.com vers une boîte Gmail (ou Outlook), ouvrez-le et choisissez ⋮ → Afficher l'original. Vous voulez DKIM : PASS avec d=yourdomain.com et le sélecteur smtpkey — si vous voyez d=smtpsend.com, la signature personnalisée n'est pas encore active, donc le CNAME est publié mais SMTP.com n'a pas basculé votre compte. Vous voulez aussi SPF : PASS (il réussira, mais rappelez-vous qu'il est aligné sur l'enveloppe de SMTP.com, pas sur votre domaine, à moins d'avoir mis en place un return-path personnalisé) et DMARC : PASS, qui devrait ici être obtenu par l'alignement DKIM. Vous préférez un rapport complet ? Envoyez un test à check-auth@verifier.port25.com et il vous renvoie par e-mail une analyse ligne par ligne. Passez ensuite le domaine dans le contrôle de santé de domaine de Qualisend pour confirmer que votre SPF est un enregistrement unique sous la limite des 10 recherches, que le CNAME smtpkey._domainkey se résout proprement vers smtpsend.com et que DMARC est présent — et une fois les rapports agrégés arrivés, déposez-en un dans l'analyseur de rapports DMARC pour voir SMTP.com apparaître comme une source alignée et validée.
Pièges courants
- Configuration DNS
L'include SPF réussit mais ne s'aligne PAS par défaut. Par défaut, SMTP.com relaie avec son propre domaine de return-path/enveloppe, si bien que include:_spf.smtp.com autorise les IP et réussit la vérification SPF brute par rapport à SMTP.com — pas par rapport à votre domaine d'expéditeur (From). Ajouter l'include seul ne vous donnera pas une réussite DMARC ; c'est le CNAME DKIM personnalisé qui le fait.
- Casse l'authentification
Par défaut, DKIM signe avec d=smtpsend.com (le domaine partagé de SMTP.com), ce qui valide mais ne s'aligne pas. Vous devez activer le DKIM de domaine personnalisé pour que le courrier soit signé avec d=yourdomain.com sur le sélecteur smtpkey — sinon DMARC n'a aucun mécanisme aligné.
- Casse l'authentification
Le DKIM personnalisé est un réglage côté compte, pas seulement un enregistrement DNS. Publier le CNAME smtpkey._domainkey ne sert à rien tant que SMTP.com n'a pas activé la signature personnalisée pour votre compte — ouvrez un ticket de support / demandez à votre gestionnaire de compte, puis confirmez le sélecteur et la cible exacts qu'ils vous attribuent.
- Configuration DNS
La cible du CNAME DKIM est un hôte partagé (smtpcustomer._domainkey.smtpsend.com) et c'est voulu, pas une erreur de copier-coller. SMTP.com détient la clé privée derrière et la fait tourner pour vous ; l'alignement fonctionne quand même parce que le d= de la signature est votre domaine. Conservez un CNAME — jamais un TXT.
- Configuration DNS
Le proxy Cloudflare casse le CNAME DKIM. Réglez smtpkey._domainkey sur « DNS only » (nuage gris) — un CNAME proxifié en nuage orange ne se résoudra pas vers smtpsend.com et l'activation DKIM échoue.
- Casse l'authentification
Conservez exactement UN enregistrement SPF TXT sur la racine. Si vous envoyez déjà via Google Workspace, Microsoft 365 ou un autre relais, fusionnez include:_spf.smtp.com dans cette unique ligne v=spf1 — deux enregistrements SPF constituent en soi un PermError.
- Configuration DNS
Doublement du champ hôte : de nombreux registrars ajoutent automatiquement votre domaine, de sorte que saisir smtpkey._domainkey.yourdomain.com produit smtpkey._domainkey.yourdomain.com.yourdomain.com. Saisissez uniquement l'étiquette (smtpkey._domainkey, et @ pour l'enregistrement SPF) si le panneau ajoute le domaine pour vous.
- Couverture
Utilisez le ~all fourni avec l'include de SMTP.com tant que vous n'avez pas inventorié tous les expéditeurs. Un -all prématuré peut faire échouer durement du courrier légitime provenant d'un outil que vous avez oublié d'ajouter à la même ligne SPF.
Construisez votre enregistrement SPF
SMTP.com est présélectionné ci-dessous. Ajoutez toutes les autres plateformes par lesquelles vous envoyez, puis publiez l'enregistrement fusionné unique.
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).
- 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 SMTP.com — 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.