SPF, DKIM et DMARC pour GetResponse.
GetResponse authentifie votre domaine d'envoi depuis Profil → E-mails et domaines, et il procède différemment des ESP qui reposent sur la délégation par CNAME : vous générez une clé DKIM à l'intérieur de GetResponse et vous la publiez sous forme d'enregistrement TXT, vous ajoutez éventuellement l'include SPF partagé de GetResponse (include:_spf.getresponse.com), et vous ajoutez vous-même un enregistrement de politique DMARC. Vous pouvez laisser GetResponse écrire les trois enregistrements à votre place grâce à son intégration automatique (Entri) avec plus de 45 hébergeurs DNS, ou les ajouter à la main. Une fois que l'enregistrement TXT DKIM se résout et que GetResponse le confirme, vos newsletters et vos automatisations sont signées comme provenant de votre propre domaine, DMARC passe grâce à l'alignement DKIM, et la mention « sent on behalf of » / via-getresponse que les destinataires voient sur le courrier non authentifié disparaît.
Pourquoi authentifier GetResponse ?
Authentifier votre domaine GetResponse est ce qui décide si vos campagnes atterrissent dans la boîte de réception ou dans le dossier spam. Depuis février 2024, Gmail et Yahoo exigent que chaque expéditeur en masse (environ 5 000 messages ou plus par jour) passe SPF, DKIM et DMARC avec alignement, et Microsoft a étendu les mêmes attentes aux boîtes de réception grand public Outlook.com/Hotmail/Live en 2025 — précisément les audiences que ciblent la plupart des newsletters. GetResponse conseille désormais vivement à chaque expéditeur d'utiliser une adresse sur son propre domaine privé comme adresse d'expéditeur (et non gmail.com ou yahoo.com, qu'il bloquera ou dégradera) et de configurer à la fois DKIM et DMARC. Tant que vous n'authentifiez pas, GetResponse envoie sous son propre domaine de signature : les destinataires voient que le courrier ne provient pas vraiment de vous, votre adresse d'expéditeur ne s'aligne pas, DMARC ne peut pas passer, et votre réputation est mise en commun avec celle de tous les autres expéditeurs non authentifiés de la plateforme. Il y a une particularité propre à GetResponse qui rend DKIM incontournable : GetResponse conserve son propre Return-Path (domaine de rebond) sur le courrier sortant, de sorte que SPF est évalué par rapport au domaine de GetResponse et ne s'aligne jamais sur votre domaine d'expéditeur — DKIM signé en d=yourdomain.com est le seul mécanisme qui porte votre validation DMARC. Sautez la clé DKIM et vous n'avez aucune authentification alignée du tout, quelle que soit l'allure du contrôle SPF.
La réalité SPF pour GetResponse
GetResponse est un véritable fournisseur « include » — le mécanisme partagé est include:_spf.getresponse.com — mais ici SPF est la partie facultative de la configuration, pas l'élément porteur. La documentation de GetResponse indique qu'un enregistrement SPF est « recommandé, mais pas requis pour envoyer », et elle en explique la raison : « le domaine d'envoi est GetResponse et il est déjà signé SPF ». Parce que GetResponse conserve l'expéditeur d'enveloppe / Return-Path sur son propre domaine de rebond (GetResponse traite les rebonds, pas vous), SPF est toujours vérifié par rapport au domaine de GetResponse, se résout en un PASS brut à lui seul, et ne s'aligne jamais sur votre domaine d'expéditeur — or DMARC ne prend SPF en compte que lorsqu'il s'aligne. Voilà pourquoi le flux d'authentification de GetResponse s'articule autour d'une clé TXT DKIM et d'un enregistrement DMARC : DKIM signé en d=yourdomain.com est ce qui s'aligne et satisfait DMARC. Considérez donc l'include à la racine comme un mécanisme utile pour « autoriser les IP de GetResponse », qu'un certain nombre de filtres entrants apprécient de voir passer proprement — et non comme l'élément qui fait fonctionner DMARC, ni comme quelque chose que vous devez ajouter. Si vous l'ajoutez tout de même, la bonne nouvelle est qu'il est peu coûteux : include:_spf.getresponse.com se résout en un unique enregistrement plat de plages ip4: sans includes imbriqués, il ne coûte donc exactement qu'UNE seule de vos 10 recherches DNS SPF. Fusionnez-le dans l'unique enregistrement v=spf1 de votre domaine racine — avant le ~all final — plutôt que de publier un second TXT SPF (deux enregistrements SPF constituent un PermError), et laissez DKIM faire le vrai travail DMARC.
Deux façons de le configurer
Authentification automatique (Entri)
- GetResponse détecte votre hébergeur DNS et écrit pour vous la clé DKIM, un enregistrement SPF et un enregistrement DMARC p=none après votre connexion à l'hébergeur
- Prend en charge plus de 45 fournisseurs, dont Cloudflare, GoDaddy, Namecheap, AWS Route 53 et SiteGround
- Élimine les deux modes d'échec les plus courants : le doublement du champ hôte et les clés DKIM tronquées
- Idéal lorsque vous contrôlez la connexion à l'hébergeur DNS et voulez le parcours le plus rapide et le moins sujet aux erreurs
Manuel — « Je le fais moi-même »
- GetResponse vous montre l'identifiant + la clé DKIM, la valeur SPF et l'enregistrement DMARC à copier
- Vous les collez vous-même chez votre registraire — nécessaire lorsque le DNS est géré par quelqu'un d'autre ou que l'hébergeur n'est pas pris en charge par Entri
- Vous devez ajouter le TXT DKIM à l'identique (sélecteur et clé 2048 bits complète), sinon GetResponse ne le confirmera pas
- Mêmes enregistrements finaux que le parcours automatique — simplement ajoutés à la main
Étape par étape
- 1
Ouvrir E-mails et domaines
Connectez-vous et allez dans Profil → E-mails et domaines (dans la nouvelle interface, c'est Outils → E-mails et domaines). Cet unique écran gère à la fois vos adresses d'expéditeur vérifiées et l'authentification complète du domaine. Ajoutez et confirmez d'abord l'adresse d'expéditeur sur votre propre domaine — GetResponse ne vous laissera pas envoyer depuis des domaines non vérifiés ou des domaines publics gratuits comme gmail.com/yahoo.com.
- 2
Lancer l'authentification du domaine
Dans l'onglet Adresses e-mail, trouvez votre domaine dans la liste, cliquez sur le menu Actions (les 3 points) à côté de celui-ci, et choisissez Authentifier (les comptes plus anciens affichent Afficher les enregistrements TXT → Authentifier votre domaine avec DKIM). Cela ouvre le panneau d'authentification où GetResponse génère vos clés.
- 3
Choisir automatique ou manuel
Choisissez « Authentifier automatiquement » pour laisser l'intégration Entri de GetResponse se connecter à votre hébergeur DNS et publier pour vous les enregistrements DKIM, SPF et (s'il n'en existe aucun) un enregistrement DMARC p=none. Ou choisissez « Je le fais moi-même » pour révéler les enregistrements et les coller chez votre registraire. Les deux parcours créent les mêmes entrées DNS.
- 4
Générer et copier la clé DKIM
Sur le parcours manuel, GetResponse affiche un identifiant DKIM et une clé DKIM. L'identifiant est un sélecteur unique par domaine (une courte chaîne hexadécimale) qui devient l'hôte de votre enregistrement, et la clé est la longue valeur de clé publique. Déplacez le curseur sur « Générer une clé DKIM 2048 bits pour une protection renforcée » (la recommandation de GetResponse) et copiez les DEUX champs à l'identique — un seul caractère manquant dans l'identifiant est une cause d'échec courante.
- 5
Publier l'enregistrement TXT DKIM
Chez votre hébergeur DNS, ajoutez un enregistrement TXT : Hôte = <votre-identifiant>._domainkey (par ex. 1a2b3c4d._domainkey), Valeur = la clé DKIM de GetResponse (elle commence par k=rsa; p=… / v=DKIM1; k=rsa; p=…). Gardez-le en TXT — le DKIM de GetResponse est une clé que vous publiez vous-même, pas une délégation par CNAME. Si votre hébergeur limite les chaînes TXT à 255 caractères, assurez-vous que la clé 2048 bits complète est stockée (fractionnée en segments entre guillemets si nécessaire), sinon une partie seulement se publie.
- 6
Ajouter ou fusionner l'include SPF (facultatif)
SPF est recommandé mais pas requis chez GetResponse. Si vous l'ajoutez, placez include:_spf.getresponse.com dans l'unique enregistrement TXT v=spf1 de votre domaine racine, avant le ~all final — par ex. v=spf1 include:_spf.getresponse.com ~all. Si vous avez déjà un enregistrement SPF (Google Workspace, Microsoft 365, etc.), fusionnez l'include dans cette même ligne ; ne publiez jamais un second TXT SPF. Il ne coûte qu'une seule recherche DNS.
- 7
Ajouter l'enregistrement DMARC
GetResponse ne crée pas DMARC pour vous sur le parcours manuel. 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, il ne change donc rien à la distribution pendant que vous confirmez l'alignement. Conservez exactement un seul enregistrement _dmarc pour l'ensemble du domaine.
- 8
Laisser GetResponse confirmer le domaine
Les changements DNS peuvent prendre jusqu'à 24 à 48 heures pour se propager. GetResponse revérifie automatiquement et bascule le domaine sur Authentifié dès qu'il détecte l'enregistrement DKIM — vous n'avez rien à cliquer, même si vous pouvez rouvrir le menu Actions pour relancer la vérification. GetResponse suggère aussi de vous envoyer une newsletter à vous-même comme test rapide de propagation.
- 9
Vérifier les en-têtes sur un vrai message
Envoyez une campagne de test vers une adresse Gmail, ouvrez-la, et utilisez ⋮ → Afficher l'original. Vous voulez DKIM: PASS avec d=yourdomain.com (via votre sélecteur GetResponse) et DMARC: PASS. SPF affichera un passage par rapport au domaine Return-Path de GetResponse, ce qui est attendu — c'est l'alignement DKIM qui porte DMARC ici.
- 10
Envoyer depuis l'adresse d'expéditeur authentifiée
Dans les paramètres de votre message et de votre liste, assurez-vous que l'adresse d'expéditeur est bien celle du domaine authentifié afin que le courrier soit réellement signé DKIM comme votre domaine. Authentifier le DNS ne sert à rien pour une campagne encore réglée pour partir d'une adresse différente ou non vérifiée.
Enregistrements à ajouter
GetResponse 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 | 1a2b3c4d._domainkey | k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(2048-bit public key from GetResponse)DKIM — valeur à titre indicatif. L'étiquette d'hôte (sélecteur) est un identifiant unique que GetResponse génère par domaine ; copiez l'identifiant et la clé exacts depuis le panneau Authentifier. Il s'agit d'un TXT publié par vous-même, pas d'un CNAME. GetResponse peut afficher la valeur commençant par k=rsa; p= (équivalent à v=DKIM1; k=rsa; p=). |
| TXT | @ | v=spf1 include:_spf.getresponse.com ~allFacultatif. Fusionnez include:_spf.getresponse.com dans votre unique ligne SPF racine — n'ajoutez jamais un second enregistrement SPF. Se résout en un enregistrement plat uniquement en ip4, il coûte donc 1 recherche DNS. Il autorise les IP de GetResponse mais NE s'aligne PAS (GetResponse possède le Return-Path et y est déjà signé SPF), donc c'est DKIM qui porte DMARC — beaucoup d'expéditeurs sautent complètement cet enregistrement. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVous l'ajoutez vous-même (le parcours automatique/Entri ajoute un enregistrement p=none s'il n'en existe aucun). Un seul par domaine ; commencez à p=none, puis resserrez vers quarantine/reject une fois que le courrier GetResponse passe aligné. |
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 GetResponse sur ce budget.
GetResponse utilise 1 de vos 10 requêtes ; les mécanismes ip4: et ip6: sont gratuits.
DKIM
DKIM est le cœur de l'authentification GetResponse car c'est le mécanisme qui s'aligne réellement sur votre domaine. Contrairement aux ESP qui reposent sur la délégation par CNAME (Mailchimp, SendGrid), GetResponse génère une clé et vous remet un enregistrement TXT que vous publiez vous-même : un identifiant DKIM (un sélecteur unique par domaine, affiché sous forme de courte chaîne hexadécimale) et une clé DKIM (la valeur de clé publique). Vous publiez un enregistrement TXT avec l'hôte <identifier>._domainkey.yourdomain.com et la valeur que GetResponse vous donne, qui commence par k=rsa; p=… (équivalent à la forme standard v=DKIM1; k=rsa; p=…). GetResponse détient la clé privée correspondante et signe votre courrier sortant avec elle, de sorte qu'une fois l'enregistrement résolu, les campagnes sont signées en d=yourdomain.com et DMARC peut passer grâce à l'alignement DKIM. Choisissez l'option 2048 bits que GetResponse propose plutôt qu'une clé 1024 bits héritée. Deux pièges propres au fournisseur que la documentation même de GetResponse signale : parce qu'une clé 2048 bits est plus longue qu'une seule chaîne TXT de 255 caractères, certains hébergeurs ne publient « qu'une partie de l'enregistrement DKIM » — si votre hébergeur limite la longueur de clé/TXT, la clé est tronquée et DKIM échoue, alors stockez la valeur complète (fractionnée en segments entre guillemets si votre panneau l'exige). Et parce que le sélecteur est un identifiant généré, GetResponse avertit qu'un nom qui « omet le dernier caractère du sélecteur correct » (publier 4e4a47e au lieu de 4e4a47eb, par exemple) produit une non-concordance de sélecteur qui échoue silencieusement à la validation. Copiez les deux champs à l'identique. Il n'y a pas de CNAME ni de bouton « Start signing » : GetResponse détecte l'enregistrement de lui-même sous 24 à 48 heures et marque le domaine comme Authentifié.
DMARC
DMARC est un enregistrement TXT de politique distinct sur votre domaine. Sur le parcours manuel, GetResponse ne le crée pas pour vous (sur le parcours automatique/Entri, il ajoutera un enregistrement p=none si vous n'en avez pas déjà un). Publiez-le à _dmarc.yourdomain.com en 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 pendant que vous observez les rapports agrégés (rua) pour confirmer que le courrier GetResponse passe DKIM aligné sur votre domaine. Cela compte davantage pour GetResponse que pour un fournisseur dont le SPF s'aligne : parce que GetResponse possède le Return-Path, votre validation DMARC repose entièrement sur DKIM, alors utilisez les rapports rua pour vérifier que l'alignement DKIM est solide avant de resserrer. Surveillez les rapports pendant une semaine ou deux, assurez-vous que GetResponse et tous les autres expéditeurs légitimes s'authentifient, puis passez à p=quarantine et finalement à p=reject. Vous verrez peut-être mention de l'alignement strict (adkim=s / aspf=s), mais laissez l'alignement en mode souple (le réglage par défaut) sauf si vous avez une raison précise — l'alignement souple exige toujours que le domaine organisationnel corresponde et se montre plus tolérant vis-à-vis des sous-domaines. 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 GetResponse.
Vérifiez que tout fonctionne réellement
Ne vous fiez pas au seul badge « Authentifié » de GetResponse — confirmez-le sur un vrai message. Envoyez une campagne de test (ou une simple newsletter à vous-même) vers une adresse Gmail, ouvrez-la, et choisissez ⋮ → Afficher l'original : vous voulez DKIM: PASS avec signed-by / d=yourdomain.com via votre sélecteur GetResponse, et DMARC: PASS. SPF affichera un passage par rapport au propre domaine Return-Path de GetResponse — c'est attendu et normal ; c'est l'alignement DKIM qui fait passer DMARC ici, alors ne vous inquiétez pas que SPF n'affiche pas votre domaine. Vous pouvez aussi vérifier ponctuellement les enregistrements bruts avec dig TXT <identifier>._domainkey.yourdomain.com et dig TXT _dmarc.yourdomain.com. Passez ensuite votre domaine par le contrôle de santé du domaine de Qualisend pour confirmer que le TXT DKIM, l'include SPF facultatif et l'enregistrement DMARC se résolvent tous proprement et que votre SPF reste sous la limite de 10 recherches. Une fois que les rapports agrégés DMARC commencent à arriver, déposez-en un dans l'analyseur de rapports DMARC — GetResponse devrait y apparaître comme une source alignée et validée sur DKIM.
Pièges courants
- Couverture
SPF passe mais ne s'aligne pas : GetResponse utilise son propre domaine Return-Path/de rebond (déjà signé SPF côté GetResponse), donc include:_spf.getresponse.com autorise les IP de GetResponse et donne un passage SPF brut, mais il NE s'aligne PAS sur votre domaine d'expéditeur. DKIM est le seul mécanisme qui porte votre validation DMARC — ne sautez jamais la clé DKIM en pensant que SPF vous couvre.
- Configuration DNS
Clé DKIM tronquée : une clé 2048 bits est plus longue qu'une seule chaîne TXT de 255 caractères, et GetResponse avertit que certains hébergeurs ne publient « qu'une partie de l'enregistrement DKIM ». Stockez la valeur complète (fractionnée en segments entre guillemets si votre panneau l'exige), sinon la validation DKIM échoue.
- Couverture
Non-concordance de sélecteur : l'hôte DKIM est un identifiant généré, et GetResponse met explicitement en garde contre un nom qui « omet le dernier caractère du sélecteur correct » (par ex. 4e4a47e au lieu de 4e4a47eb). Un identifiant mal saisi ou tronqué ne se valide jamais, silencieusement — copiez-le à l'identique.
- Configuration DNS
Doublement du champ hôte : de nombreux registraires ajoutent automatiquement votre domaine, de sorte que saisir 1a2b3c4d._domainkey.yourdomain.com devient 1a2b3c4d._domainkey.yourdomain.com.yourdomain.com. Saisissez uniquement l'étiquette (1a2b3c4d._domainkey) si le panneau ajoute le domaine pour vous.
- Couverture
Les adresses d'expéditeur gratuites/publiques sont bloquées : GetResponse n'authentifiera pas et n'enverra pas de façon fiable depuis gmail.com, yahoo.com, outlook.com, etc. Vous devez envoyer depuis une adresse sur votre propre domaine — c'est tout l'intérêt de l'authentification.
- Configuration DNS
DKIM est un enregistrement TXT, pas un CNAME : contrairement à Mailchimp ou SendGrid, GetResponse vous donne une clé statique à coller. Il n'y a pas de CNAME à déléguer ni de rotation automatique des clés, donc si vous régénérez un jour la clé, vous devez mettre à jour l'enregistrement TXT vous-même.
- Casse l'authentification
Conservez exactement un seul enregistrement SPF : si vous envoyez aussi via Google Workspace, Microsoft 365 ou un autre outil, fusionnez include:_spf.getresponse.com dans la ligne v=spf1 existante. Deux enregistrements TXT SPF sur le même domaine constituent un PermError qui casse SPF entièrement.
- Couverture
L'authentification automatique (Entri) peut échouer partiellement : si l'hébergeur DNS connecté rejette une modification via l'API, GetResponse peut ajouter certains enregistrements et pas d'autres, ou vous demander de finir manuellement. Après un passage automatique, revérifiez que les trois enregistrements existent réellement chez votre hébergeur.
Construisez votre enregistrement SPF
GetResponse 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 GetResponse — 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.