To authenticate GetResponse marketing email, verify your From address, publish the custom DKIM TXT record generated for its domain, and check your existing DMARC policy. GetResponse already authenticates its normal sending domain with SPF; adding authorization to your visible From domain is a separate decision, not proof of SPF alignment. Complete setup with public DNS checks and a delivered newsletter using the intended sender.
Choose the correct GetResponse route
This guide covers GetResponse's standard email-marketing service and identifies where MAX differs. It does not configure employee mailboxes, an unrelated SMTP service, or every transactional integration. Use the account and sending route that will actually deliver the message. Do not transfer values between accounts or assume regional infrastructure uses identical records.
Begin with an owned domain, a working sender mailbox, permission to edit authoritative DNS, and a list of existing senders. Record the From address for newsletters and automations separately. Verifying a mailbox proves access to that address; it does not demonstrate domain authentication.
For the normal service, GetResponse describes custom DKIM as distinct from its default provider-domain signing. The practical goal is your domain's authenticated identity, not merely a signature somewhere in the message. GetResponse DKIM documentation.
MAX has separate sending-domain instructions. Where MAX hosts the sending domain's DNS, its documented arrangement differs from using another domain in From. Dedicated-IP accounts also require account-specific review. Do not redirect production nameservers or copy example IP addresses to follow this article. Obtain the exact MAX configuration from your account team. MAX SPF instructions.
Get and publish your custom DKIM record
Open Profile → Emails and Domains → Email addresses. At the appropriate domain's actions menu, look for View TXT records and the DKIM authentication option. The newer authentication flow also offers Authenticate → I'll do it myself. Copy the generated identifier and complete public-key value, rather than a selector from a screenshot. Manual DKIM setup, authentication options.
Prepare a change sheet containing the DNS zone, record type, full owner name, value and previous state. For a generated owner such as SELECTOR._domainkey.example.com, replace SELECTOR and the domain with your actual values. A DNS editor managing example.com may want only SELECTOR._domainkey; another accepts the full name. Check the saved fully qualified name before leaving the editor.
For an issued child-domain owner, use the actual account selector in place of SELECTOR:
| Full owner | Authoritative zone | Relative Name/Host |
|---|---|---|
SELECTOR._domainkey.mail.example.com |
example.com |
SELECTOR._domainkey.mail |
SELECTOR._domainkey.mail.example.com |
separately delegated mail.example.com |
SELECTOR._domainkey |
SELECTOR._domainkey.mail.example.com |
delegated _domainkey.mail.example.com |
SELECTOR |
These are owner mappings, not issued keys. Preserve legitimate NS delegations and publish through the administrator of the actual authoritative namespace. Do not delete a delegation to make a parent-zone edit appear effective. Do not change MX, parent nameservers, DNSSEC or credentials for this TXT workflow.
Publish the supplied record as TXT at that exact owner. Keep all public-key characters intact, including separators. Use the DNS host's supported long-TXT handling rather than shortening a key. Multiple character strings inside one TXT record are not separate authentication records. A private key never belongs in DNS: the provider retains the signing key and you publish its public counterpart. DKIM TXT concatenation.
Do not replace other vendors' DKIM selectors. If the same owner is already occupied, investigate ownership before changing it. A CNAME cannot normally coexist with other data at the same name; do not layer a TXT key over an existing alias. DNS alias rules.
GetResponse's 2048-bit generation option invalidates the previous key and identifier. Treat this as a rotation with a coordinated send window, not an innocent preview. Copy the new pair, publish it, and verify fresh mail before releasing campaigns. Restoring old DNS alone cannot restore a signer that the platform has invalidated. Key generation and rotation warning.
Decide whether SPF needs a change
SPF checks the SMTP envelope MAIL FROM domain (or HELO in applicable cases, including a null reverse-path), usually reflected in Return-Path, rather than simply the address a recipient sees. On GetResponse's normal route, the provider says its sending domain already has SPF and a customer From-domain SPF addition is not required to send. Its manual interface nevertheless supplies an SPF value through Authenticate → I'll do it myself → Add SPF record. Use that current value if adding the authorization is appropriate for your configuration. The native setup publishes TXT at the specified From domain, shown as the domain or @ in its own zone. Do not silently move this requested record to another owner merely because the actual message envelope differs; evaluate envelope alignment separately. GetResponse SPF behavior.
Read the existing TXT records at the owner GetResponse specifies first. If one starts with v=spf1, edit that policy rather than creating another. Preserve existing legitimate mechanisms and the agreed terminal policy. Insert the required mechanism before the existing ~all or -all; do not paste a second complete SPF policy into the first. Retain one v=spf1 declaration and one coherent policy. For an existing redirect-only policy, review the control flow rather than appending an all. SPF ignores redirect= when any all mechanism is present, regardless of ordering, and mechanisms after all are unreachable. Preserve approved qualifiers; they define SPF outcomes, not guaranteed delivery or rejection. SPF all and redirect.
Check the complete evaluation against SPF's ten DNS-lookup-term limit, including evaluated nested mechanisms, not just a count of includes. include, a, mx, ptr, exists and redirect consume this budget when evaluated; ip4, ip6 and all do not. Do not delete your mailbox provider to make space or flatten changing provider infrastructure into guessed IPs. Also do not confuse a 255-character TXT string limit with a requirement to create multiple SPF records. SPF publication and processing rules.
A passing SPF result for a GetResponse-owned bounce domain can coexist with a From address on your brand. That is not automatically aligned SPF. Your custom DKIM signature may be the mechanism that supplies DMARC alignment.
Review automatic authentication before approval
GetResponse offers Entri-based automatic setup for supported DNS providers. Its documented changes include custom DKIM, SPF and a monitoring DMARC policy when a correct policy is absent. Preview the proposed records before allowing the connector to write them. GetResponse automatic authentication.
Ask three practical questions: is this the authoritative zone, does the proposal preserve all existing senders, and could a newly added subdomain policy weaken inherited protection? A successful connection to a registrar does not answer those questions. Prefer manual publication when a change reviewer needs an exact diff or the automatic flow cannot explain a conflict. Approve only understood integration permissions and the exact authorized change set. Afterwards, compare public records with the approved change, not just the success screen. If setup fails partway, inspect what already changed before retrying; do not duplicate successful records.
Preserve DMARC and add reporting safely
DMARC passes when at least one passing SPF or DKIM identity aligns with the visible From domain. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match. Check the existing aspf and adkim settings before assuming a passing signature is sufficient. The current DMARC specification is RFC 9989, which replaces RFC 7489; pct is removed and is not a rollout control to add. DMARC standard.
For an illustrative From address news@example.com, query _dmarc.example.com TXT before making changes. For a From subdomain, inspect its exact policy owner and the applicable parent policy as well. Preserve an existing record, reporting destination and enforcement policy. Do not replace p=reject with p=none to make onboarding look successful, or add a weaker child policy without authorization.
Only for a genuinely new policy with no existing or inherited protection to weaken, an approved monitoring example is:
- Type:
TXT. - Name in the
example.comDNS zone:_dmarc. - Value:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. - TTL: the DNS host's normal default or your change plan.
Replace the example domain and mailbox. Ensure the receiving mailbox or reporting service exists and is authorized to collect the data. Preserve semicolons between tags and publish one DMARC policy, not an additional competing record. When the Organizational Domain of the report destination host differs from that of the domain where the DMARC policy was found, the report-generating receiver must check DNS authorization. Destinations within the same Organizational Domain are excepted; a different hostname alone is not enough. DNS authorization does not replace the domain owner’s approval of report-data sharing and the recipient. RFC 9990 section 4.
For a first policy on mail.example.com, the full TXT owner is _dmarc.mail.example.com: enter _dmarc.mail in the parent example.com zone, or _dmarc in a separately delegated mail.example.com zone. The same absence-of-applicable-policy and owner-approval conditions apply; inspect inherited policy before adding this child record. Do not publish through a non-authoritative parent copy.
Monitoring is not enforcement. Review all legitimate streams before a later, separately approved policy change. See raw DKIM results versus aligned DKIM results when a signature passes without authenticating the intended visible identity.
Verify DNS and a real newsletter
Run read-only queries after substituting the actual domain, selector and SPF owner. These commands are a procedure, not results from your account:
dig +short TXT SELECTOR._domainkey.example.com
dig +short TXT SPF-OWNER.example.com
dig +short TXT _dmarc.example.com
The DKIM answer must match the generated public key; the SPF owner must expose one applicable SPF policy; the DMARC owner must expose the intended single policy. If results differ, compare the authoritative nameserver with a public recursive resolver, record the TTL and investigate the name or delegation. Waiting does not fix a misspelled selector. A split quoted TXT answer is not necessarily truncation: compare the concatenated value.
Return to the account authentication view and investigate any pending or failed state against authoritative DNS. A product success indicator is not evidence of delivered signing. Next, send an authorized small newsletter to controlled receiving mailboxes using the actual From address and production route. Use receiver-generated Authentication-Results from the actual receiving service's known processing boundary. Establish through its documentation or administrator how externally supplied result fields are removed or isolated from trusted results, or obtain an authenticated receiver trace. Header position, a familiar authserv-id string or a display label alone is not proof. Ignore attacker-supplied fields and leave acceptance open if provenance is uncertain. Receiver trust boundary.
Record spf, smtp.mailfrom (or applicable HELO identity), every DKIM d= and s=, receiver dkim/header.d, dmarc and header.from. Accept the newly configured branded route only when the intended GetResponse signature passes and aligns with the intended visible From under current policy, and the trusted receiver reports dmarc=pass. SPF-only DMARC success does not establish DKIM, and a rewritten provider-owned From does not authenticate the intended brand.
For a hypothetical From: news@example.com, an intended passing signature with d=mail.example.com aligns under relaxed alignment (assuming the same Organizational Domain), but not strict alignment. A passing d=example.com is an exact match under both. These examples are not measured GetResponse defaults. Alignment comparison.
Investigate SPF separately even when DKIM produces DMARC pass: fail means the evaluated policy did not authorize that sender; temperror indicates a transient evaluation problem such as DNS failure; permerror indicates a policy that cannot be correctly evaluated, such as duplicate SPF records or excessive lookup terms. Diagnose the actual evaluated owner and route instead of adding an apex include blindly. SPF results.
Save the message date, campaign identifier, From domain, selector and receiver verdict. Repeat for an automation if it selects a different sender. A DNS checker cannot prove signing was activated, and one successful newsletter does not certify every future send or guarantee an inbox position.
Troubleshoot without weakening protection
- DKIM not found: compare every selector character and the complete saved owner. A duplicated domain suffix sends queries to the wrong name.
- Key is present but mail fails: compare the message's
s=andd=with the published record; check whether someone regenerated the key after you copied it. - SPF passes but DMARC fails: identify whose envelope domain passed and whether the custom DKIM identity aligns. Adding an apex include does not change the envelope identity.
- Only some messages fail: separate newsletter, automation and MAX paths; compare sender selection and signing domains before changing DNS globally.
- Verification remains pending: check authoritative publication and provider status independently. GetResponse’s current manual text allows up to 24 hours; a retained rotation screenshot mentions about 48 hours. Neither is a guarantee or a reason to wait on incorrect authoritative data. Check all authoritative servers for consistent publication, without removing legitimate redundant nameservers. Setup troubleshooting.
Escalate with the record owner, redacted expected value, timestamps and receiver verdict. Do not send credentials or a private key. Keep a copy of the previous zone and restrict recovery to the failed change.