Provider documentation checked on 8 November 2026. Account-specific values, current product scope and provider activation remain deployment prerequisites.
Cakemail separates sender-domain authentication from tracking and bounce-domain configuration. Complete both deliberately instead of treating an Authenticated badge as evidence that every link and envelope identity is ready. This guide follows the current Cakemail help workflow and adds an independent DNS and message-verification plan. It does not supply a reusable account key or claim a live tenant test.
Prepare a domain you control
Use an organization-controlled From domain with an accountable DNS operator. A mailbox on a public webmail service does not give you permission to publish records for that service's domain. Retain existing TXT, selector, tracking and bounce records before adding a new sender.
In Cakemail's domain-authentication guide, the workflow begins at Settings, Domains. Under Sender Domains, choose Authenticate Domain for the intended entry, or Create Sender and Domain if it is missing. Confirm the exact domain before copying records; another domain in the same account needs its own setup.
Publish the generated DKIM TXT and preserve DMARC
References: RFC 6376 §3.6.2.2, RFC 9989 §4.10.
The wizard provides a DKIM TXT name and value. Use the copy controls and start with Variant 1, as the provider recommends. If verification fails after publication is confirmed, consult support before trying another variant. Do not invent a selector or manually reconstruct a public key from a screenshot.
Preserve the complete owner name when translating to a relative-label DNS editor. If the editor automatically appends the zone, entering the full name can produce a duplicated suffix. A long DKIM value must remain one TXT record even when its DNS representation contains multiple character strings. Do not turn those strings into separate competing records.
The workflow also checks DMARC. If a policy already exists, preserve it and reconcile any proposed change with the domain owner. If no policy applies, establish an approved one at the correct _dmarc owner; Cakemail illustrates a monitoring policy. Monitoring does not request quarantine or rejection, and adding a child policy can affect previously inherited protection. Continue the wizard and inspect the resulting status.
Configure tracking and bounce records separately
References: RFC 1034 §3.6.2.
The tracking and bounce guide describes two CNAME records under Settings, Domains, Tracking and Bounce domain alignment. Select the domain and copy each generated Hostname and Value. Publish both exact aliases and check that each becomes valid. The documentation treats this as strongly recommended rather than mandatory for domain authentication.
A tracking domain controls campaign links; a bounce domain receives delivery-status notifications. Neither should be inferred from the visible sender alone. Before occupying a hostname, check for conflicting data or a service already using it. Do not replace a working website record to make room for a generated tracking alias without an approved migration plan.
Verify the public records and actual sender
References: RFC 9989 §4.4, RFC 6376 §6.
Query DKIM and DMARC directly at the authoritative nameserver, using the exact generated owner and type. Inspect the CNAME answers for tracking and bounce as well. The targets must match Cakemail's account output. If the authority returns no record, waiting for recursive caches cannot fix the missing publication.
Then send a harmless campaign to a controlled mailbox. Record visible From, Return-Path, DKIM d=/s= and the receiver's trusted authentication results. Check that at least one passing path aligns for DMARC. Evaluate SPF against the actual envelope domain; adding a guessed include at the corporate root is not a substitute for understanding the configured bounce route.
Test a campaign link and inspect the intended tracking hostname separately. Illustrative diagnosis: DKIM and DMARC pass but tracking remains Not valid. Keep the authentication result, investigate the tracking CNAME and avoid unnecessary key regeneration. Conversely, a working link says nothing about the validity of the message signature.
Maintain the configuration through changes
References: RFC 2308 §5.
Capture the domain status, authoritative answers and redacted test headers as an acceptance record. If verification fails, compare type, name, value and unexpected whitespace before involving support. Retain the original configuration and pause affected sends if a confirmed regression appears. A source's 24–48-hour estimate is not a reason to ignore a wrong authoritative answer.
Recheck after domain changes, sender additions, DNS migrations or selector rotation. When retiring Cakemail, stop active workflows before removing its delegation and authorization records, and preserve records needed by other senders. Authentication helps receivers evaluate domain responsibility; it does not establish that a message's content is safe or guarantee inbox placement.