3,932 Australian domains analysed. Most fail basic email authentication. [2026 Report]

How to Set Up SPF, DKIM and DMARC for GetResponse (2026)

DMARC Busta Team
January 23, 2026
9 min read
How to Set Up SPF, DKIM and DMARC for GetResponse (2026)

Photo by TheStandingDesk on Unsplash

GetResponse is an email marketing and automation platform used by businesses to send newsletters, campaigns, and transactional messages. If your domain sends through GetResponse without proper SPF, DKIM, and DMARC records, your messages are at risk of spoofing and deliverability failures. By the end of this guide you will have all three authentication layers published in DNS and verified as passing.

Before you begin

  • Write access to the DNS zone for the domain you send from — via your registrar, hosting panel, or a dedicated DNS provider such as Cloudflare or Route 53.
  • Admin-level access to your GetResponse account with permission to manage domain authentication settings.
  • An active mailbox at Gmail or Yahoo you can send a test message to and inspect the raw headers.
  • A note of any other services already sending mail from your domain (Google Workspace, HubSpot, etc.) so you can merge their SPF entries without exceeding the DNS lookup limit.

Step 1: Identify what's sending from GetResponse

GetResponse routes outbound mail through its own sending infrastructure, which spans multiple IP ranges and may vary by account region or dedicated IP configuration. Before touching DNS, confirm which From address your campaigns use. If your messages leave with a From: header at your-domain.com, that domain's SPF and DMARC records govern authentication. If you use a custom subdomain such as mail.your-domain.com as an envelope sender or reply-to, you may need separate DNS records on that subdomain as well. Check GetResponse's sender details screen and note the exact domain and any dedicated IP addresses assigned to your account before proceeding.

Step 2: Add the SPF include

GetResponse requires an include: mechanism in your domain's SPF record so its sending servers are authorized to send on your behalf. Locate the exact SPF include string inside GetResponse's account settings under the domain or email authentication area — the platform documents this value in its DNS setup guide and it may be region-specific.

Your domain should have at most one SPF TXT record on the apex (@). If one already exists, merge the new include into it rather than creating a second record.

Before (existing SPF with another provider):

your-domain.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"

After (GetResponse include merged in):

your-domain.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:<getresponse-spf-include> ~all"

Replace <getresponse-spf-include> with the exact string from GetResponse's documentation. Keep ~all (softfail) while you are in the monitoring phase; you can harden to -all once DMARC reporting confirms all legitimate sources are covered.

SPF lookup limit warning: The SPF specification permits a maximum of 10 DNS-resolving mechanisms (each include:, a:, and mx: counts toward the limit). Many SaaS platforms chain multiple nested includes internally, consuming several lookups on their own. If your domain already has several services in its SPF record, run your updated record through an SPF validation tool before publishing to confirm you are under the 10-lookup ceiling. Exceeding the limit causes permerror, which DMARC treats as an SPF failure.

Step 3: Enable DKIM in GetResponse

DKIM requires publishing a public key in DNS as a TXT record under a specific selector subdomain. The general workflow in GetResponse is:

  1. Log in to your GetResponse account and navigate to the email authentication or domain verification section. This is typically found under Account Settings — look for a section related to domains, senders, or email authentication. Consult GetResponse's current help documentation for the exact menu path, as UI labeling changes between product versions.
  2. Add or select the domain you want to authenticate.
  3. GetResponse will generate a DKIM key pair and present you with a TXT record to publish. The record will include a selector name (a string that identifies which key to use) and the public key value.
  4. Copy both values exactly as displayed — the public key is typically a long Base64-encoded string.

Publish the record in your DNS zone in the following form:

; Record name (host):
<selector>._domainkey.your-domain.com

; Record type: TXT
; Record value:
"v=DKIM1; k=rsa; p=<your-public-key>"

Replace <selector> with the selector name shown in GetResponse's interface and <your-public-key> with the Base64 string they provide. If the public key string is longer than 255 characters, your DNS provider may require you to split it into two quoted strings within the same TXT record:

"v=DKIM1; k=rsa; p=<first-chunk>"
"<second-chunk>"

Most modern DNS consoles handle this automatically, but if DKIM validation fails after publishing, key splitting is the first thing to check.

After the record propagates (allow up to 48 hours, though often faster), return to GetResponse and use any built-in verification button to confirm the platform can resolve the key successfully.

Step 4: Publish your DMARC record

DMARC ties SPF and DKIM together and tells receiving mail servers what to do when messages fail authentication. Start with p=none — this is a monitoring-only policy that collects data without affecting delivery. Do not move to p=quarantine or p=reject until you have reviewed at least 14 days of aggregate reports and confirmed that all legitimate sending sources are passing.

Publish the following TXT record on _dmarc.your-domain.com:

_dmarc.your-domain.com. 3600 IN TXT "v=DMARC1; p=none; adkim=r; aspf=r; rua=mailto:dmarc-rua@dmarcbusta.pro; ri=86400"

Field reference:

Tag Value Meaning
v DMARC1 Protocol version — required, must be first.
p none Policy applied to failing messages. Start here.
adkim r Relaxed DKIM alignment — allows subdomain matches.
aspf r Relaxed SPF alignment — allows subdomain matches.
rua mailto:dmarc-rua@dmarcbusta.pro Address that receives aggregate XML reports.
ri 86400 Reporting interval in seconds (24 hours).

Once your aggregate reports show a consistent, clean picture — all GetResponse traffic passing SPF or DKIM with correct alignment — you can progress to p=quarantine and eventually p=reject.

Step 5: Verify it works

Before sending a test email, confirm your DMARC record actually published. Use our free DMARC Checker to look up _dmarc.your-domain.com and verify the record is live, has the correct policy (p=none, quarantine, or reject), and is configured for aggregate reporting. While you are there, run the SPF Checker against your domain to make sure the SPF lookup tree is clean — once both records check out, the live email test below will give you the final confirmation.

DNS propagation can take up to 48 hours. Once you believe the records are live, send a test campaign or a single test message from GetResponse to a Gmail or Yahoo address you control. Then:

  1. Open the message in Gmail and click the three-dot menu → Show original. In Yahoo, use More → View raw message.
  2. At the top of the raw headers you will see an Authentication-Results header. Look for the following three results:
Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of sender@your-domain.com designates x.x.x.x as permitted sender)
       smtp.mailfrom=sender@your-domain.com;
  dkim=pass header.i=@your-domain.com header.s=<selector>;
  dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=your-domain.com

What each result means:

  • spf=pass — The sending IP is listed in your SPF record for the envelope sender domain.
  • dkim=pass — GetResponse signed the message with the private key matching the public key you published, and the signature is intact.
  • dmarc=pass — At least one of SPF or DKIM passed and the authenticated domain aligns with the From: header domain. This is the result that matters for policy enforcement.

If any result shows fail, permerror, or temperror, work through the common errors section below before progressing your DMARC policy.

Common errors with GetResponse

  • DKIM selector not found (dkim=permerror or dkim=none). The TXT record was published under the wrong hostname. Double-check that you did not accidentally publish it as <selector>._domainkey without appending your domain, or that your DNS provider did not automatically append the domain and create a duplicate suffix (e.g. <selector>._domainkey.your-domain.com.your-domain.com). Query the record with dig TXT <selector>._domainkey.your-domain.com to confirm it resolves.
  • DKIM public key split incorrectly. If you manually split the key value into chunks and introduced a space or formatting error inside the Base64 string, DKIM verification will fail. Copy the key value from GetResponse's interface again and let your DNS provider handle any splitting automatically.
  • SPF permerror due to too many lookups. Adding GetResponse's include to an already complex SPF record may push you over the 10-lookup limit. Use an SPF lookup counter tool to audit the chain. Consider consolidating sends or using SPF delegation (such as DMARC Busta's SPF Auto-Repair) to flatten nested includes.
  • DMARC alignment failure despite SPF passing. SPF passes on the envelope MAIL FROM domain, but DMARC alignment checks the From: header domain. If GetResponse sends with a different envelope domain (e.g. a GetResponse-owned bounce domain), SPF will not align. In this case, DKIM alignment is the path to a DMARC pass — ensure DKIM is correctly configured and the signing domain matches your From: header domain.
  • Multiple SPF records on the same apex. Publishing a second TXT record with v=spf1 instead of merging it into the existing one causes an immediate permerror. Your domain must have exactly one SPF TXT record. Merge all includes into a single record.

How DMARC Busta helps

The steps above represent the manual baseline. Maintaining that baseline across multiple domains, tracking SPF lookup counts as vendors update their infrastructure, and interpreting aggregate XML reports at scale is where manual management breaks down. DMARC Busta's Autopilot mode is designed to manage DMARC progression from p=none through to p=reject without requiring you to manually parse reports and make policy decisions. SPF Auto-Repair monitors your SPF chain and is designed to handle automated delegation and source management so that lookup-limit overflows are caught and resolved before they cause delivery failures. The managed DMARC reporting dashboard is built to handle aggregate report ingestion and surface actionable findings across 10,000+ domains — suited for both single-domain operators who want clarity and MSPs managing large domain portfolios.

If you are managing GetResponse alongside several other sending platforms — transactional email services, CRMs, helpdesk tools — DMARC Busta's multi-source view is designed to give you a unified picture of what is passing, what is misaligned, and what requires action, without opening individual raw XML files.

Start your free trial and put your email authentication on autopilot.

Share this article

Related Articles

Put Your Email Security on Autopilot

Let AI handle DMARC compliance while you focus on your business.