GetResponse stays with a classic TXT DKIM record, with one quirk that catches nearly everyone once: its selector is a hexadecimal string such as dbaa517f, which people read as a fragment of the value rather than as a host name.
DKIM
In the sending addresses tab, a domain’s actions menu gives you the TXT record to publish:
dbaa517f._domainkey TXT (value provided by GetResponse)The selector differs per account: take it from the interface.
The duplicated domain trap
Most DNS zone editors automatically append your domain to whatever you type in the « name » field. Pasting dbaa517f._domainkey.yourdomain.com then produces:
dbaa517f._domainkey.yourdomain.com.yourdomain.comThe record exists, it is syntactically valid, and it will never be queried. Enter only dbaa517f._domainkey — the relative part. Some editors, conversely, require the full name: check what you end up with after saving rather than assuming.
SPF
GetResponse sends with its own envelope address: an SPF record on your side would pass without aligning. DKIM is what carries DMARC compliance, and your SPF record stays reserved for your other senders.
DMARC
Publish the monitoring policy on _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:your-address@yourdomain.comOnly tighten once every sender is identified. The progression, step by step.
Common mistakes with GetResponse
- The duplicated domain in the host name. The most frequent error, and the most invisible: nothing in DNS flags it.
- Taking the selector from a tutorial. It is specific to your account; someone else’s matches no key.
- Publishing DMARC before DKIM is validated. A strict policy published first will reject your own campaigns.
- Sending from an unauthenticated domain while another one is authenticated: alignment is judged on the
From:domain.
Once it is in place, Clarsend reads your reports and shows you what passes, what fails, and who is sending without your knowledge.