Treat address verification and authentication separately
A verified From address proves access to that mailbox; it does not by itself prove that a newsletter has aligned DKIM or SPF. Start with a domain your organization controls, an approved sender address, DNS administrative access and an owner for the campaign. Inventory other services already sending for the domain before changing its records.
GetResponse's documented domain workflow is under Profile > Emails and Domains. Custom DKIM uses a key and identifier generated in the account. Do not use a generic selector from a tutorial or a key exported from another account. The relevant question is which domain signs the actual message, not whether a sender address has been added successfully.
Keep this email-domain work separate from website and landing-page domain configuration. Redirecting nameservers or connecting a website is not necessary merely to publish an authentication record at the existing DNS host.
Generate and publish the DKIM record
In Email addresses, open the domain's Actions menu, choose View TXT records and Authenticate your domain with DKIM. Copy the displayed identifier and key. The documentation also offers a 2048-bit key option and warns that confirming generation invalidates the existing key and identifier. Plan that action as a coordinated rotation, not as a harmless display preference.
Before rotating, record the current selector and the signing state, identify the person who can publish DNS promptly, and agree how campaigns will be paused or recovered if validation fails. Do not presume an old key remains usable after the product invalidates it. Resolve any overlap or rollback capability with the provider before depending on it.
Publish the returned TXT owner and complete value at the authoritative DNS service. Check the editor's suffix rules and long-TXT handling. A truncated key, missing selector character or duplicated domain suffix can make an apparently saved record unusable. If the UI cannot preserve the entire value, obtain supported DNS-host guidance rather than splitting the key into independent records.
Review automatic setup before approving it
GetResponse also documents an automatic flow using Entri. After a sender address is added and verified, choose Authenticate from the domain menu. The flow can show the proposed text records before it proceeds, detect the DNS provider and request the relevant sign-in and confirmation. Manual setup remains an alternative if the integration cannot complete the job.
The automatic process is documented to add custom DKIM, an SPF TXT record and a p=none DMARC policy when a correct policy does not already exist. Inspect the proposed changes against existing records before authorizing them. Automation does not remove the need to preserve an enforced policy, avoid duplicate SPF records or review permissions granted to a DNS integration.
Do not assume that a successful integration confirmation proves every requested record was published at the right owner. Compare authoritative answers afterward and retain the exact change set. If the process fails partway, inspect what already changed before retrying, so a second attempt does not create conflicts or obscure recovery.
Understand the separate SPF decision
GetResponse's SPF page says its sending domain already has SPF and that adding a record to the customer's visible-From domain is not required simply to send through the service. It provides account-displayed SPF information for customers who choose to configure it. Use those current values rather than guessing a universal include.
The protocol distinction matters: SPF evaluates the envelope sender domain, not the visible From header. A permission added to example.com cannot manufacture alignment if the message actually uses an unrelated envelope domain. A valid custom DKIM signature aligned with example.com can supply the DMARC path independently. Verify what the message does before treating a root SPF change as the repair.
Where a legitimate SPF update is needed, review the existing policy and its DNS-lookup cost. Retain a single valid candidate SPF record at that owner and preserve other approved senders. Do not concatenate two full v=spf1 policies or create a second TXT policy beside the first.
Verify the actual campaign
Query each authoritative server for the exact DKIM owner and compare the complete public value with the account. Repeat product validation as appropriate, allowing for previously cached answers after authoritative publication is correct. Then send a controlled newsletter through the intended GetResponse workflow to an authorized recipient with access to raw received headers.
Capture visible From, envelope domain, every DKIM d= and s=, and trusted receiver authentication results. Synthetic example: a message has From news@example.com, SPF passes for a provider-owned envelope, and DKIM passes with d=example.com. The provider-owned SPF pass is not aligned to example.com, but the exact-domain DKIM pass can satisfy DMARC. If the signing domain is instead provider-owned, do not call it custom-domain success merely because DKIM itself passed.
Test each materially different From domain and sending workflow. A newsletter sent from a different address than the acceptance sample may exercise a different domain configuration. A successful DNS test is not a substitute for that route-level verification.
Diagnose and retain a recovery record
If the key is missing in DNS, repair the exact owner or value. If the key is correct but the signature is absent or uses another domain, check the selected sender and product setup. If authentication passes but placement is poor, investigate consent, reputation, content and receiver policy separately; DKIM does not guarantee inbox placement.
Keep the old configuration, proposed changes, actual changes, validation result and message evidence. Do not weaken a domain-wide DMARC policy to hide a failed rotation. This guide is based on retained first-party documentation and synthetic interpretation, not a live GetResponse tenant or delivered campaign. Production acceptance requires the administrator's current evidence and human approval.
Decide what recovery means after invalidation
For written rotation case GR-01, assume the administrator confirmed generation of the 2048-bit option, the new account identifier is demo-new and the zone still contains only demo-old. No current public key or received signature has been observed. The campaign owner pauses the affected release while the DNS owner obtains and publishes the exact newly generated value at its required owner. Republishing an old value is not a supported recovery assumption after the documented invalidation; ask the provider about any recoverable signing state before relying on it. Close only after authoritative comparison and a controlled campaign whose actual d=/s= and trusted result meet acceptance. No key generation, DNS edit or send occurred for this example.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.