SPF, DKIM & DMARC for GetResponse.
GetResponse authenticates your sending domain from Profile → Emails and domains, and it does it differently from CNAME-delegation ESPs: you generate a DKIM key inside GetResponse and publish it as a TXT record, optionally add GetResponse's shared SPF include (include:_spf.getresponse.com), and add a DMARC policy record yourself. You can let GetResponse write all three records for you through its automatic (Entri) integration with 45+ DNS hosts, or add them by hand. Once the DKIM TXT resolves and GetResponse confirms it, your newsletters and automations are signed as your own domain, DMARC passes on DKIM alignment, and the \"sent on behalf of\" / via-getresponse attribution that recipients see on unauthenticated mail disappears.
Why authenticate GetResponse?
Authenticating your GetResponse domain is what decides whether your campaigns hit the inbox or the spam folder. Since February 2024, Gmail and Yahoo require every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft extended the same expectations to Outlook.com/Hotmail/Live consumer inboxes in 2025 — the exact audiences most newsletters target. GetResponse now strongly advises every sender to use an address on their own private domain as the From address (not gmail.com or yahoo.com, which it will block or downgrade) and to configure both DKIM and DMARC. Until you authenticate, GetResponse sends under its own signing domain: recipients see the mail isn't really from you, your From address doesn't align, DMARC can't pass, and your reputation is pooled with every other unauthenticated sender on the platform. There's a GetResponse-specific twist that makes DKIM non-negotiable: GetResponse keeps its own Return-Path (bounce domain) on outbound mail, so SPF is evaluated against GetResponse's domain and never aligns to your From domain — DKIM signed as d=yourdomain.com is the only mechanism that carries your DMARC pass. Skip the DKIM key and you have no aligned authentication at all, no matter how the SPF check looks.
The SPF reality for GetResponse
GetResponse is a genuine \"include\" provider — the shared mechanism is include:_spf.getresponse.com — but here SPF is the optional side of the setup, not the load-bearing part. GetResponse's own docs say an SPF record is \"recommended, but not required to send,\" and they spell out why: \"the sending domain is GetResponse and is already SPF signed.\" Because GetResponse keeps the envelope sender / Return-Path on its own bounce domain (GetResponse processes the bounces, not you), SPF is always checked against GetResponse's domain, resolves to a raw PASS on its own, and never aligns to your From domain — and DMARC only counts SPF when it aligns. That's why GetResponse's authentication flow centers on a DKIM TXT key and a DMARC record: DKIM signed as d=yourdomain.com is what aligns and satisfies DMARC. So treat the root include as a helpful \"authorize GetResponse's IPs\" mechanism that some inbound filters like to see a clean pass from — not as the thing that makes DMARC work, and not something you must add. If you do add it, the good news is it's cheap: include:_spf.getresponse.com resolves to a single flat record of ip4: ranges with no nested includes, so it costs exactly ONE of your 10 SPF DNS lookups. Merge it into the single v=spf1 record on your root domain — before the trailing ~all — rather than publishing a second SPF TXT (two SPF records is a PermError), and let DKIM do the real DMARC work.
Two ways to set it up
Automatic authentication (Entri)
- GetResponse detects your DNS host and writes the DKIM key, an SPF record, and a p=none DMARC record for you after you log in to the host
- Supports 45+ providers including Cloudflare, GoDaddy, Namecheap, AWS Route 53, and SiteGround
- Removes the two most common failure modes: host-field doubling and truncated DKIM keys
- Best when you control the DNS host login and want the fastest, lowest-error path
Manual — "I'll do it myself"
- GetResponse shows you the DKIM identifier + key, the SPF value, and the DMARC record to copy
- You paste them at your registrar yourself — needed when DNS is managed by someone else or the host isn't supported by Entri
- You must add the DKIM TXT exactly (selector and full 2048-bit key) or GetResponse won't confirm it
- Same end records as the automatic path — just added by hand
Step by step
- 1
Open Emails and domains
Log in and go to Profile → Emails and domains (in the newer UI it's Tools → Emails and domains). This one screen manages both your verified From addresses and full domain authentication. Add and confirm the From address on your own domain first — GetResponse won't let you send from unverified or free public domains like gmail.com/yahoo.com.
- 2
Start authentication for the domain
On the Email addresses tab, find your domain in the list, click the Actions menu (the 3 dots) next to it, and choose Authenticate (older accounts show View TXT records → Authenticate your domain with DKIM). This opens the authentication panel where GetResponse generates your keys.
- 3
Choose automatic or manual
Pick "Authenticate automatically" to let GetResponse's Entri integration log into your DNS host and publish the DKIM, SPF, and (if none exists) a p=none DMARC record for you. Or choose "I'll do it myself" to reveal the records and paste them at your registrar. Both paths create the same DNS entries.
- 4
Generate and copy the DKIM key
On the manual path, GetResponse shows a DKIM identifier and a DKIM key. The identifier is a unique per-domain selector (a short hex string) that becomes your record host, and the key is the long public key value. Move the slider to "Generate a 2048-bit DKIM key for stronger protection" (GetResponse's recommendation) and copy BOTH fields exactly — a single missing character in the identifier is a common failure.
- 5
Publish the DKIM TXT record
At your DNS host add a TXT record: Host = <your-identifier>._domainkey (e.g. 1a2b3c4d._domainkey), Value = the DKIM key from GetResponse (it begins k=rsa; p=… / v=DKIM1; k=rsa; p=…). Keep it as TXT — GetResponse DKIM is a self-published key, not a CNAME delegation. If your host limits TXT strings to 255 characters, make sure the full 2048-bit key is stored (split into quoted chunks if needed) or only part of it publishes.
- 6
Add or merge the SPF include (optional)
SPF is recommended but not required at GetResponse. If you add it, put include:_spf.getresponse.com into the single v=spf1 TXT record on your root domain, before the trailing ~all — e.g. v=spf1 include:_spf.getresponse.com ~all. If you already have an SPF record (Google Workspace, Microsoft 365, etc.), merge the include into that one line; never publish a second SPF TXT. It costs just one DNS lookup.
- 7
Add the DMARC record
GetResponse does not create DMARC for you on the manual path. Add a TXT record at host _dmarc with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only, so it changes nothing about delivery while you confirm alignment. Keep exactly one _dmarc record for the whole domain.
- 8
Let GetResponse confirm the domain
DNS changes can take up to 24–48 hours to propagate. GetResponse automatically re-checks and flips the domain to Authenticated once it detects the DKIM record — you don't have to click anything, though you can re-open the Actions menu to re-check. GetResponse also suggests sending a newsletter to yourself as a quick propagation test.
- 9
Check the headers on a real message
Send a test campaign to a Gmail address, open it, and use ⋮ → Show original. You want DKIM: PASS with d=yourdomain.com (via your GetResponse selector) and DMARC: PASS. SPF will show a pass against GetResponse's Return-Path domain, which is expected — DKIM alignment is what carries DMARC here.
- 10
Send from the authenticated From address
In your message and list settings, make sure the From address is the one on the authenticated domain so mail is actually DKIM-signed as your domain. Authenticating DNS does nothing for a campaign still set to send from a different or unverified address.
Records to add
GetResponse generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| TXT | 1a2b3c4d._domainkey | k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(2048-bit public key from GetResponse)DKIM — illustrative value. The host label (selector) is a unique identifier GetResponse generates per domain; copy the exact identifier and key from the Authenticate panel. This is a self-published TXT, not a CNAME. GetResponse may show the value beginning k=rsa; p= (equivalent to v=DKIM1; k=rsa; p=). |
| TXT | @ | v=spf1 include:_spf.getresponse.com ~allOptional. Merge include:_spf.getresponse.com into your single root SPF line — never add a second SPF record. Resolves to a flat ip4-only record, so it costs 1 DNS lookup. It authorizes GetResponse's IPs but does NOT align (GetResponse owns the Return-Path and is already SPF-signed there), so DKIM is what carries DMARC — many senders skip this record entirely. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYou add this yourself (the automatic/Entri path adds a p=none record if none exists). One per domain; start at p=none, then tighten to quarantine/reject once GetResponse mail passes aligned. |
Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.
The 10-lookup budget
SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what GetResponse's setup costs against that budget.
GetResponse adds 1 of your 10 lookups; ip4: and ip6: mechanisms are free.
DKIM
DKIM is the heart of GetResponse authentication because it's the mechanism that actually aligns to your domain. Unlike CNAME-delegation ESPs (Mailchimp, SendGrid), GetResponse generates a key and hands you a self-published TXT record: a DKIM identifier (a unique per-domain selector, shown as a short hex string) and a DKIM key (the public key value). You publish a TXT record with host <identifier>._domainkey.yourdomain.com and the value GetResponse gives you, which begins k=rsa; p=… (equivalent to the standard v=DKIM1; k=rsa; p=… form). GetResponse holds the matching private key and signs your outbound mail with it, so once the record resolves, campaigns are signed as d=yourdomain.com and DMARC can pass on DKIM alignment. Choose the 2048-bit option GetResponse offers rather than a legacy 1024-bit key. Two provider-specific gotchas GetResponse's own docs call out: because a 2048-bit key is longer than a single 255-character TXT string, some hosts publish \"only a part of the DKIM record\" — if your host caps key/TXT length the key is truncated and DKIM fails, so store the full value (split into quoted chunks if your panel requires). And because the selector is a generated identifier, GetResponse warns that a name that \"misses the last sign of the correct selector\" (publishing 4e4a47e instead of 4e4a47eb, for example) produces a selector mismatch that silently fails validation. Copy both fields verbatim. There's no CNAME and no \"Start signing\" toggle: GetResponse detects the record on its own within 24–48 hours and marks the domain Authenticated.
DMARC
DMARC is a separate policy TXT record on your domain. On the manual path GetResponse does not create it for you (on the automatic/Entri path it will add a p=none record if you don't already have one). Publish it at _dmarc.yourdomain.com starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only: it changes nothing about delivery while you watch the aggregate (rua) reports to confirm GetResponse mail is passing DKIM aligned to your domain. This matters more for GetResponse than for a provider whose SPF aligns: because GetResponse owns the Return-Path, your DMARC pass rests entirely on DKIM, so use the rua reports to verify DKIM alignment is solid before you tighten. Watch the reports for a week or two, make sure GetResponse and every other legitimate sender is authenticating, then ramp to p=quarantine and eventually p=reject. You may see strict alignment (adkim=s / aspf=s) mentioned, but leave alignment relaxed (the default) unless you have a specific reason — relaxed alignment still requires the organizational domain to match and is more forgiving of subdomains. Keep exactly one _dmarc record for the whole domain no matter how many senders you use; never add a second DMARC record specifically for GetResponse.
Check it actually worked
Don't trust GetResponse's \"Authenticated\" badge alone — confirm it on a real message. Send a test campaign (or a plain newsletter to yourself) to a Gmail address, open it, and choose ⋮ → Show original: you want DKIM: PASS with signed-by / d=yourdomain.com via your GetResponse selector, and DMARC: PASS. SPF will show a pass against GetResponse's own Return-Path domain — that's expected and fine; DKIM alignment is what makes DMARC pass here, so don't be alarmed that SPF doesn't show your domain. You can also spot-check the raw records with dig TXT <identifier>._domainkey.yourdomain.com and dig TXT _dmarc.yourdomain.com. Then run your domain through Qualisend's domain health check to confirm the DKIM TXT, the optional SPF include, and the DMARC record all resolve cleanly and that your SPF stays under the 10-lookup limit. Once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer — GetResponse should appear as an aligned, passing source on DKIM.
Common gotchas
- Coverage
SPF passes but doesn't align: GetResponse uses its own Return-Path/bounce domain (already SPF-signed on GetResponse's side), so include:_spf.getresponse.com authorizes GetResponse's IPs and gives a raw SPF pass, but it does NOT align to your From domain. DKIM is the only mechanism that carries your DMARC pass — never skip the DKIM key thinking SPF covers you.
- DNS setup
Truncated DKIM key: a 2048-bit key is longer than a single 255-character TXT string, and GetResponse warns that some hosts publish 'only a part of the DKIM record.' Store the full value (split into quoted chunks if your panel requires) or DKIM validation fails.
- Coverage
Selector mismatch: the DKIM host is a generated identifier, and GetResponse explicitly warns against a name that 'misses the last sign of the correct selector' (e.g. 4e4a47e instead of 4e4a47eb). A mistyped or truncated identifier silently never validates — copy it verbatim.
- DNS setup
Host-field doubling: many registrars auto-append your domain, so entering 1a2b3c4d._domainkey.yourdomain.com becomes 1a2b3c4d._domainkey.yourdomain.com.yourdomain.com. Enter just the label (1a2b3c4d._domainkey) if the panel adds the domain for you.
- Coverage
Free/public From addresses are blocked: GetResponse won't authenticate or reliably send from gmail.com, yahoo.com, outlook.com, etc. You must send from an address on your own domain — that's the whole point of authenticating.
- DNS setup
DKIM is a TXT record, not a CNAME: unlike Mailchimp or SendGrid, GetResponse gives you a static key to paste. There's no CNAME to delegate and no automatic key rotation, so if you ever regenerate the key you must update the TXT record yourself.
- Breaks auth
Keep exactly one SPF record: if you also send via Google Workspace, Microsoft 365, or another tool, merge include:_spf.getresponse.com into the existing v=spf1 line. Two SPF TXT records on the same domain is a PermError that breaks SPF entirely.
- Coverage
Automatic (Entri) auth can partially fail: if the connected DNS host rejects an API change, GetResponse may add some records and not others, or ask you to finish manually. After an automatic run, re-check that all three records actually exist at your host.
Build your SPF record
GetResponse doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.
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 listGetResponse SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.