Cakemail SPF, DKIM and DMARC setup, step by step

To authenticate email sent through Cakemail, verify your sender address, publish the DKIM TXT record generated for its domain, and check the domain's DMARC policy. Configure the separate tracking and bounce CNAMEs if you want branded links and a branded envelope identity. Cakemail's current workflow handles SPF through its sending infrastructure; it does not ask you to add a Cakemail SPF TXT record. The bounce configuration is the relevant SPF-alignment step. Cakemail's authentication overview

This guide covers Cakemail's current Settings → Domains sender-domain workflow and its tracking/bounce settings. It does not configure your company's Microsoft 365, Google Workspace or other mailbox service. Those services retain their own authentication records. A successful Cakemail setup must be checked on a message sent through the Cakemail workflow you actually use.

If employee mail uses Microsoft 365, retain that separate sender's configuration and use the Microsoft 365 authentication guide. Cakemail's domain badge does not validate employee mailbox mail.

This is a documentary guide, not a report of changes to a customer account, public DNS measurements or delivered-message tests.

What you need before changing DNS

Use an address on a domain your organization controls. Being able to receive mail at a public Gmail or Yahoo address does not give you DNS control of that domain. You also need access to the intended Cakemail account and to the authoritative DNS zone, which may be hosted somewhere other than your domain registrar.

Record the intended From address, domain, existing DKIM selectors, SPF policy, DMARC policy, and any services already using the proposed tracking and bounce names. Keep a recoverable copy of the zone and an owner-approved change plan. Do not replace a website, mailbox record or another sender's key simply because Cakemail proposes the same hostname.

There are three distinct readiness checks:

In Settings → Senders, add the sender using the + control, enter its name and email address, and confirm. Open the verification email in that mailbox and follow its link. Cakemail distinguishes the sender's VERIFIED state from the domain's authentication state. Adding a sender

Publish Cakemail's generated DKIM record

1. Open Settings → Domains and locate the intended entry under Sender Domains. If it is missing, use Create Sender and Domain.
2. Select Authenticate Domain and copy the generated DKIM Name and Value. The documented record type is TXT.
3. Start with Variant 1, the option Cakemail recommends for most DNS providers. Ask support about another variant if a correctly published record still fails verification.
4. Publish that record at the exact owner name in the correct DNS zone. Check DMARC as described below, then select Continue in the wizard.
5. Confirm that this particular domain becomes Authenticated. Repeat the process separately for every additional sending domain. Domain authentication

Cakemail's DNS reference describes the DKIM owner as c[CID]._domainkey.[DOMAIN], where the client ID and domain come from your account. This is a naming pattern, not a reusable selector or key. Copy the complete public-key value from the application, not an example or screenshot. You do not publish a private signing key. Cakemail DNS record reference

A DNS panel can display a long TXT value as several quoted character strings inside one record. That can be valid: the strings are concatenated for DKIM. Separate competing TXT records at the same selector are different and can break verification. Preserve the exact key material and let the DNS provider handle its supported input format. DKIM TXT representation

Configure tracking and bounce CNAMEs separately

Return to Settings → Domains, find Tracking and Bounce domain alignment, and choose the same domain. Copy both generated CNAME owners and targets. Publish them, then check each record's status individually. Cakemail describes this as strongly recommended rather than mandatory for the domain-authentication badge. Tracking and bounce setup

The current record reference uses these patterns:

Use the values shown in your account even if they differ from the illustrative pattern. Both aliases can point to the same target while serving different purposes. A working link is not a test of the bounce address or SPF. Record types and naming patterns

Keep the issued tracking and bounce CNAMEs unflattened: public DNS must return their exact aliases, not substituted IP addresses. In Cloudflare, DNS only is necessary but insufficient. Check that each issued CNAME has Flatten turned off. Cloudflare CNAME verification

Also check that the zone-wide CNAME flattening for all CNAME records setting is off; it can prevent per-record overrides. Coordinate any shared-setting change with the DNS owner and assess unrelated services first. Cloudflare flattening controls Cloudflare flattens apex CNAMEs by default and same-zone targets regardless of the flatten-all setting. If mandatory apex/same-zone behavior or a shared setting prevents the literal issued alias from being returned, stop and coordinate a supported configuration with the DNS owner and Cakemail. Do not invent a per-record exception or remove a delegation to force validation. These controls concern the tracking/bounce CNAMEs, not Cakemail's direct-TXT DKIM record.

Preserve legitimate child-domain NS delegation and publish/check at the child's authority. Do not delete its NS records to force answers from the parent zone. At a CNAME owner, conflicting A, AAAA, MX or TXT records are not a safe way to retain another service. Choose an unused hostname through the supported workflow or arrange a deliberate migration. The normal zone apex already has SOA and NS records and is not a suitable place for these CNAMEs. DNS alias rules

Does Cakemail need an SPF include?

Not for the current documented domain-authentication workflow. Cakemail says SPF is handled by its infrastructure and that the bounce-domain setup connects it to your domain. Do not add include:md02.com to your root SPF policy merely because an older recipe recommends it. If an existing or unusual account route supplies different instructions, resolve that route with Cakemail before changing a working policy. Current SPF behavior

SPF evaluates the SMTP envelope's MAIL FROM domain, not the address a recipient sees in the From field. In received mail, use the trusted receiver's smtp.mailfrom result and the Return-Path to identify that domain. If Cakemail uses a branded bounce address at em.example.com while the visible From domain is example.com, these can align under relaxed DMARC rules. They are not identical, so they do not align under strict aspf=s.

A provider-owned envelope domain can pass SPF without aligning to your brand. Adding an include at example.com cannot change the identity in that message. DKIM can still supply the passing, aligned DMARC path, but an actual SPF failure remains a separate issue to investigate. SPF identity and DMARC alignment

Keep the existing root SPF record for your other senders. At every owner where an SPF policy is needed, publish only one v=spf1 record. An approved change must preserve required authorizations and the intended ending mechanism. Evaluate the total DNS-query-causing terms, including nested includes and redirects, against SPF's limit of ten. Counting only the includes visible in the first record is insufficient. SPF record and lookup limits

Put each DNS record at the correct owner

The zone being edited determines which relative name to enter. The following names explain the mapping only; SELECTOR must be replaced with the selector generated for your domain.

Some panels accept full names instead. Check the saved, fully qualified owner so that a suffix is neither omitted nor doubled. @ means the apex of the zone currently open, not necessarily the company's root domain. If a child domain is delegated to different authoritative nameservers, add its records there; entries below the delegation left in the parent editor will not serve as the child's authoritative data. DNS zones and delegation

For the first DMARC example below, _dmarc.example.com is relative _dmarc in zone example.com. A child policy at _dmarc.news.example.com is _dmarc.news in that parent zone, or _dmarc in a separately delegated news.example.com zone. If the DKIM namespace _domainkey.news.example.com is itself delegated, the issued TXT key's relative owner is just its generated SELECTOR; preserve that delegation and use its actual authority. These are naming examples, not instructions to create a new delegation or override inherited policy.

Preserve DMARC protection and arrange reporting

Cakemail checks for DMARC during authentication. Its starter example uses p=none, but do not replace an established quarantine or reject policy with that example. Inspect the policy for the exact From domain and any applicable inherited parent policy. Adding a weaker child policy can change protection that the child previously inherited. Cakemail authentication check and DMARC policy discovery

Only for a domain without an established applicable policy, and after the domain owner approves monitored deployment, a starting record could look like this:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

This is an example, not a record to paste unchanged. Create a real report destination you control or use the exact destination issued by your reporting service. A basic p=none record without rua does not request aggregate reports. Avoid adding forensic-report destinations without a deliberate privacy review. Read the reports for legitimate sending sources and alignment failures before considering stronger enforcement. Aggregate reporting and external destinations

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, which is not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Follow the reporting service's exact authorization instructions when needed. This protocol check is separate from the domain owner's approval to share report data with that recipient. RFC 9990 section 4.

DMARC passes when SPF passes and aligns, or DKIM passes and aligns. Relaxed alignment compares organizational domains; strict alignment requires the relevant authenticated domain to match the visible From domain exactly. Do not weaken adkim or aspf simply to turn a failed deployment into a green indicator. DMARC authentication and alignment

Verify public DNS before testing a message

Replace every uppercase placeholder below. These are read-only diagnostic examples; no results are claimed here.

dig +short NS DNS_ZONE
dig @AUTHORITATIVE_NS DKIM_OWNER TXT +noall +answer
dig @AUTHORITATIVE_NS TRACKING_OWNER CNAME +noall +answer
dig @AUTHORITATIVE_NS BOUNCE_OWNER CNAME +noall +answer
dig @AUTHORITATIVE_NS DMARC_OWNER TXT +noall +answer
dig DKIM_OWNER TXT +noall +answer
dig BOUNCE_OWNER TXT +noall +answer
dig DMARC_OWNER TXT +noall +answer

Use the authoritative server for each owner, including a delegated child where applicable. Expect the DKIM TXT to match the account's public key, the tracking and bounce CNAMEs to match their supplied targets, and the DMARC policy to reflect the approved configuration. A recursive TXT lookup at the bounce owner should follow the alias and expose the SPF policy used for that envelope route. If necessary, query the CNAME target directly and inspect its SPF dependencies.

An authoritative lookup establishes what was published. Recursive lookups establish what a caching resolver currently returns. If the authority is wrong, repair the record or zone selection; merely waiting will not fix it. Cakemail gives a possible 24–48-hour verification window, not a promise that every incorrect record will become valid with time. Complete the application check as a separate step.

Accept the setup only after a real delivered-message check

After the owner authorizes testing, send a harmless message through the actual Cakemail campaign or sending workflow to a controlled external mailbox. Repeat for materially different domains and routes. Inspect the full original message and the receiving system's trusted Authentication-Results, not an untrusted header inserted upstream. Authentication-Results trust boundary

Establish which results were generated inside the receiving service's known processing boundary and how that service removes, ignores or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving-mail administrator to confirm the boundary. A familiar authserv-id string or header position alone is not proof. Reject attacker-supplied or otherwise untrusted fields; obtain the receiver's own diagnostic evidence when provenance is uncertain. Operational receiving-result trust.

Record these observations:

1. From: the intended branded sender domain, without an unexpected rewrite.
2. DKIM: dkim=pass for the intended branded header.d/d= domain and the expected s= selector, plus alignment to From under the applicable adkim mode. A passing provider-domain signature alone is not acceptance of branded DKIM.
3. SPF: the actual smtp.mailfrom domain and spf result. For the direct route, expect SPF to pass. Record separately whether it aligns under aspf.
4. DMARC: dmarc=pass for the intended header.from, consistent with at least one passing, aligned path.
5. Links and bounces: the intended tracking hostname works in the test, and the received envelope uses the expected bounce domain. Do not infer one from the other.

If DMARC passes through SPF but branded DKIM is missing or broken, the DKIM work is not finished. If DKIM passes and aligns but SPF is fail, softfail, neutral, none, temperror or permerror, document and repair the SPF issue rather than calling it an alignment limitation. A directly delivered baseline helps distinguish a provider configuration error from later forwarding effects.

Troubleshooting Cakemail authentication