SPF, DKIM et DMARC pour Elastic Email.
Vérifier un domaine dans Elastic Email se résume à quatre enregistrements DNS et à un clic dans le tableau de bord : un enregistrement SPF TXT qui ajoute l'include partagé d'Elastic Email, un enregistrement DKIM TXT sur le sélecteur api, un CNAME de suivi qui personnalise vos liens de clic/ouverture à votre marque, et un enregistrement de politique DMARC. Ce qui est inhabituel ici, c'est la clé DKIM — Elastic Email remet à chaque client la même clé publique partagée plutôt que d'en générer une par domaine, et son include SPF est une recherche dynamique par macro plutôt qu'une liste d'IP statique. Publiez les enregistrements, cliquez sur Verify, et Elastic Email envoie en tant que votre domaine, pleinement authentifié — et lève le plafond de 500 e-mails par jour qu'il impose aux domaines non vérifiés.
Pourquoi authentifier Elastic Email ?
Authentifier votre domaine Elastic Email est ce qui vous sort de la zone de pénalité des 500 messages par jour et du pool partagé. Tant qu'un domaine n'est pas vérifié, Elastic Email le plafonne à 500 e-mails par jour et n'envoie votre courrier qu'avec une attribution faible à votre nom. Depuis février 2024, Gmail et Yahoo exigent de tout expéditeur en masse (environ 5 000 messages par jour et plus) qu'il passe SPF, DKIM et DMARC avec alignement, et Microsoft a commencé à appliquer la même règle au trafic Outlook/Hotmail/Live en 2025 — et comme Elastic Email est largement utilisé pour l'envoi marketing et transactionnel à fort volume, cette exigence s'applique précisément au courrier que vous y faites transiter. Publier SPF et DKIM (plus le CNAME de suivi et une politique DMARC) aligne votre courrier sur votre propre domaine, retire la marque générique Elastic Email des liens suivis, débloque le plafond quotidien, et fait en sorte que la réputation d'envoi que vous construisez profite à votre domaine plutôt qu'à l'infrastructure partagée par tous les comptes de la plateforme.
La réalité SPF pour Elastic Email
Elastic Email est un véritable fournisseur « include » : vous ajoutez un seul mécanisme partagé, include:_spf.elasticemail.com, à l'unique enregistrement SPF TXT de votre domaine. La ligne recommandée par Elastic Email est v=spf1 a mx include:_spf.elasticemail.com ~all, mais la seule partie qui autorise les serveurs d'Elastic Email est l'include — le a et le mx sont du texte générique standard qui autorise votre propre hébergeur web/mail et sont facultatifs. Ce qui rend cet include inhabituel, c'est ce vers quoi il se résout : au lieu d'une liste statique de plages ip4:, _spf.elasticemail.com publie v=spf1 exists:%{i}._spf.elasticemail.info ~all — une vérification exists: basée sur une macro qui recherche l'IP d'envoi exacte (%{i}) au moment de la vérification. Deux conséquences pratiques en découlent. Premièrement, l'include coûte DEUX de vos 10 recherches DNS SPF, et non une : une pour l'include lui-même et une pour le mécanisme exists imbriqué (conservez aussi le a et le mx et la ligne recommandée par Elastic Email atteint déjà quatre recherches avant même que vous n'ajoutiez tout autre expéditeur). Deuxièmement, comme l'autorisation est calculée dynamiquement par IP, Elastic Email peut ajouter ou retirer des IP d'envoi sans que vous ayez jamais à modifier le DNS de nouveau. Conservez exactement un seul enregistrement SPF sur le domaine — si vous envoyez déjà via Google Workspace, Microsoft 365, un CRM, etc., fusionnez include:_spf.elasticemail.com dans cette unique ligne v=spf1 plutôt que de publier un second enregistrement SPF (deux enregistrements SPF constituent une PermError). Elastic Email livre la ligne avec ~all (softfail) parce que la plupart des expéditeurs envoient aussi depuis d'autres services ; ne durcissez en -all qu'une fois que chaque source légitime est répertoriée.
Étape par étape
- 1
Ouvrez Manage Domains
Connectez-vous sur app.elasticemail.com et allez dans Settings → Domains → Manage Domains. Cliquez sur Start Verification, saisissez le domaine depuis lequel vous envoyez, et cliquez sur Continue. Elastic Email génère alors les enregistrements DNS exacts pour ce domaine.
- 2
Lisez les enregistrements générés
Sur l'écran de vérification, Elastic Email liste les enregistrements à publier : une ligne SPF TXT, un enregistrement DKIM TXT sur l'hôte api._domainkey, un CNAME de suivi (hôte tracking → api.elasticemail.com), et un enregistrement DMARC suggéré. Gardez cet onglet ouvert — vous cliquerez sur Verify ici une fois le DNS actif.
- 3
Ajoutez ou fusionnez l'enregistrement SPF
Chez votre hébergeur DNS, ajoutez un enregistrement TXT sur le domaine racine (hôte @ ou vide) avec v=spf1 a mx include:_spf.elasticemail.com ~all. Si un enregistrement SPF existe déjà, ne créez PAS un second — fusionnez include:_spf.elasticemail.com dans la ligne v=spf1 existante. Vous pouvez retirer le a et le mx si vous n'envoyez pas depuis le serveur web/mail de votre propre domaine.
- 4
Publiez l'enregistrement DKIM TXT
Ajoutez un enregistrement TXT avec l'hôte api._domainkey et la valeur affichée dans votre tableau de bord (elle commence par k=rsa; t=s; p=MIGf…). C'est la clé DKIM partagée d'Elastic Email — copiez la valeur textuellement depuis Manage Domains et ne renommez pas l'hôte.
- 5
Ajoutez le CNAME de suivi
Ajoutez un enregistrement CNAME avec l'hôte tracking pointant vers api.elasticemail.com. Cela personnalise vos liens suivis d'ouverture/clic à votre marque avec votre propre sous-domaine et fait partie de la vérification complète du domaine. Sur Cloudflare, réglez-le sur DNS only (nuage gris) pour qu'il se résolve.
- 6
Publiez l'enregistrement DMARC
Ajoutez un enregistrement TXT à l'hôte _dmarc avec v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Commencez à p=none (surveillance seule) pour que rien ne soit affecté pendant que vous confirmez l'alignement, puis durcissez plus tard.
- 7
Cliquez sur Verify record
De retour sur l'écran de vérification, cliquez sur Verify record. Des coches vertes apparaissent à côté de chaque enregistrement à mesure qu'Elastic Email le confirme dans le DNS. La propagation peut prendre jusqu'à 24–48 heures, alors revérifiez si un enregistrement n'est pas détecté immédiatement.
- 8
Définissez comme expéditeur par défaut
Une fois vérifié, définissez éventuellement le domaine comme expéditeur par défaut pour que les nouvelles campagnes et les envois par API l'utilisent automatiquement. La vérification supprime également le plafond de 500 e-mails par jour qui s'applique aux domaines non vérifiés.
- 9
Envoyez un test et vérifiez les en-têtes
Envoyez un message depuis une adresse du domaine vérifié, ouvrez-le dans Gmail, et choisissez ⋮ → Afficher l'original. Confirmez DKIM: PASS signé par yourdomain.com (sélecteur api), SPF: PASS, et DMARC: PASS.
Enregistrements à ajouter
Elastic Email 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 a mx include:_spf.elasticemail.com ~allSPF racine — ne conservez qu'un seul enregistrement SPF et fusionnez-y l'include. Seul include:_spf.elasticemail.com autorise Elastic Email ; le a et le mx sont facultatifs. L'include coûte 2 recherches DNS (l'include + une macro exists imbriquée). |
| TXT | api._domainkey | k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCbmGbQMzYeMvxw…Clé DKIM PARTAGÉE d'Elastic Email (sélecteur api) — chaque compte publie la même valeur. Copiez la valeur complète textuellement depuis Manage Domains ; elle s'aligne sur votre domaine même si la clé est partagée. |
| CNAME | tracking | api.elasticemail.comSuivi d'ouverture/clic à votre marque. Fait partie de la vérification complète. Sur Cloudflare, réglez sur DNS only (nuage gris). |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comUn seul enregistrement DMARC par domaine. Commencez à p=none, puis durcissez vers quarantine/reject. |
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 Elastic Email sur ce budget.
Elastic Email utilise 2 de vos 10 requêtes ; les mécanismes ip4: et ip6: sont gratuits.
DKIM
Le DKIM sur Elastic Email est une clé publique unique et partagée avec le sélecteur api — et non une clé par domaine que vous générez. Chaque client publie exactement le même enregistrement TXT : hôte api._domainkey.yourdomain.com, valeur k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ… (une clé de 1024 bits). Vous pouvez le vérifier vous-même : api._domainkey.elasticemail.com se résout vers la valeur identique. Elastic Email détient l'unique clé privée correspondante et signe votre courrier sortant avec d=yourdomain.com, de sorte que même si la clé est partagée, la signature S'ALIGNE tout de même sur votre domaine — ce qui est exactement ce dont DKIM a besoin pour contribuer à une réussite DMARC. Parce qu'elle est partagée, quelques points en découlent : vous ne pouvez pas faire tourner la clé vous-même, c'est une clé de 1024 bits plutôt que la valeur par défaut moderne de 2048 bits, et vous devriez copier la valeur exacte depuis votre propre écran Manage Domains plutôt que d'en coller une provenant d'un article tiers — si Elastic Email fait un jour tourner la clé partagée, le tableau de bord fait foi. Publiez-la exactement telle qu'affichée : ne renommez pas l'hôte api._domainkey, ne le convertissez pas en CNAME, et n'ajoutez ni ne retirez de caractères (le flag t=s dans la valeur est celui d'Elastic Email, pas une faute de frappe). En pratique, le DKIM est ici le mécanisme porteur pour DMARC — il s'aligne sur votre domaine à chaque message quel que soit le transfert, alors que SPF n'aide que lorsque votre domaine est l'expéditeur d'enveloppe.
DMARC
DMARC est un enregistrement TXT distinct que vous publiez vous-même — Elastic Email ne le crée pas, même si son processus de vérification vous en réclame un. Ajoutez un enregistrement à _dmarc.yourdomain.com commençant par v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est en mode surveillance seule : il ne change rien à la distribution mais demande aux destinataires de vous envoyer des rapports agrégés, afin que vous puissiez confirmer que le courrier d'Elastic Email passe DKIM (et, lorsque votre domaine est l'expéditeur d'enveloppe, SPF) aligné sur votre domaine avant d'appliquer quoi que ce soit. L'écran de vérification d'Elastic Email vous pousse directement vers p=quarantine ou p=reject, et il a raison de dire qu'une politique none ne vous apporte que peu de protection — mais avancez de manière délibérée : surveillez les rapports rua pendant une semaine ou deux, confirmez que chaque expéditeur légitime (Elastic Email plus tout autre outil sur le domaine) est aligné, puis durcissez vers quarantine et enfin reject. Conservez exactement un seul enregistrement _dmarc pour l'ensemble du domaine, quel que soit le nombre d'expéditeurs que vous utilisez ; ne publiez jamais un second enregistrement DMARC uniquement pour Elastic Email.
Vérifiez que tout fonctionne réellement
Ne vous fiez pas aux seules coches vertes dans Manage Domains — confirmez sur un vrai message. Envoyez un test depuis une adresse du domaine vérifié, ouvrez-le dans Gmail, et choisissez ⋮ → Afficher l'original : vous voulez DKIM: PASS signé par yourdomain.com avec le sélecteur api, SPF: PASS, et DMARC: PASS. Si SPF affiche un domaine d'enveloppe Elastic Email au lieu du vôtre, pas de panique — c'est DKIM qui porte la réussite DMARC, et c'est très bien ainsi. Vous pouvez aussi vérifier ponctuellement les enregistrements bruts avec dig TXT api._domainkey.yourdomain.com, dig TXT yourdomain.com (pour la ligne SPF), dig TXT _dmarc.yourdomain.com, et dig CNAME tracking.yourdomain.com. Faites ensuite passer le domaine par le {healthCheck} de Qualisend pour confirmer que chaque enregistrement se résout et que votre SPF reste sous la limite de 10 recherches (rappelez-vous que l'include d'Elastic Email en compte deux), et une fois que les rapports agrégés DMARC commencent à arriver, déposez-en un dans l'{dmarcAnalyzer} pour vérifier qu'Elastic Email y apparaît comme une source alignée et validée.
Pièges courants
- Configuration DNS
La clé DKIM d'Elastic Email est partagée, non pas propre à chaque domaine — chaque compte publie la même valeur api._domainkey. C'est prévu et cela s'aligne tout de même sur votre domaine, mais cela signifie que vous ne pouvez pas faire tourner la clé vous-même, que c'est une clé de 1024 bits, et que vous devriez copier la valeur exacte depuis Manage Domains plutôt qu'un article tiers au cas où Elastic Email la ferait tourner.
- Casse l'authentification
L'include coûte DEUX recherches SPF, et non une : include:_spf.elasticemail.com plus la macro exists:%{i}._spf.elasticemail.info imbriquée à l'intérieur. Conservez le a et le mx suggérés par Elastic Email et la ligne recommandée atteint déjà ~4 recherches avant que vous n'ajoutiez tout autre expéditeur — attention à la limite de 10 recherches.
- Casse l'authentification
Conservez exactement un seul enregistrement SPF sur le domaine. Si vous envoyez déjà via Google, Microsoft 365, un CRM, etc., fusionnez include:_spf.elasticemail.com dans la ligne v=spf1 existante — deux enregistrements SPF distincts constituent une PermError qui casse SPF entièrement.
- Configuration DNS
Le a et le mx dans le SPF recommandé d'Elastic Email sont du texte générique standard pour votre propre hébergeur web/mail, pas pour Elastic Email. Si vous n'envoyez pas réellement de courrier depuis l'enregistrement A ou les serveurs MX de votre domaine, retirez-les et utilisez v=spf1 include:_spf.elasticemail.com ~all pour récupérer deux recherches.
- Configuration DNS
Sur Cloudflare, réglez le CNAME de suivi sur DNS only (nuage gris). Un CNAME proxifié en nuage orange ne se résoudra pas vers api.elasticemail.com, donc le suivi et la vérification complète échouent.
- Configuration DNS
Les domaines non vérifiés sont plafonnés à 500 e-mails par jour. Si vos envois sont silencieusement limités, le domaine n'a presque certainement pas terminé sa vérification — compléter SPF + DKIM + le CNAME de suivi et cliquer sur Verify est ce qui lève le plafond.
- Configuration DNS
Publiez l'enregistrement DKIM exactement à l'hôte api._domainkey, en tant qu'enregistrement TXT, avec la valeur textuelle. Renommer l'hôte, utiliser un CNAME, ou altérer la longue chaîne p= font tous échouer DKIM silencieusement alors que le tableau de bord peut encore sembler partiellement vert.
- Couverture
Vous envoyez depuis un sous-domaine (ex. mail.yourdomain.com) ? Placez chaque enregistrement sur le sous-domaine — SPF sur le sous-domaine, api._domainkey.mail, tracking.mail, et _dmarc.mail. Les enregistrements du domaine racine ne couvrent pas un sous-domaine d'envoi.
Construisez votre enregistrement SPF
Elastic Email 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 Elastic Email — 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.