How does CNAME delegation enable SPF and DKIM authentication for email sending?
Updated on 18 Oct 2026: We clarified SPF delegation options and tightened the DNS verification, DKIM rotation, and DMARC matching advice.
CNAME delegation enables SPF and DKIM by pointing a hostname under your domain to DNS records controlled by your email sending provider. For SPF, a provider that supports CNAME delegation makes the bounce domain or return-path domain resolve to a hosted SPF TXT record that authorizes its sending IPs. For DKIM, the provider gives you selector hostnames that point to its hosted DKIM public keys. The receiver follows those DNS aliases during authentication, so the message can pass even when the visible From domain does not list that sender in its root SPF record.
The key caveat is domain matching. Passing SPF or DKIM only helps DMARC when the authenticated domain matches the visible From domain under the applicable DMARC mode. Relaxed matching permits different subdomains with the same Organizational Domain. A message with From company.com can pass SPF through mail.company.com if that hostname is used as the return-path domain and the DMARC domain-match mode allows the subdomain relationship. It can pass DKIM if the DKIM signature uses d=company.com or a matching subdomain, and the receiver verifies the signature with the provider's hosted public key.
This is why a customer success, CRM, helpdesk, newsletter, or transactional email platform can authenticate mail for your brand with only a few CNAMEs in DNS. You are not handing over the whole domain. You are delegating specific DNS names used for SPF return-path checks, DKIM key lookup, or both.
What CNAME delegation changes for SPF and DKIM
A CNAME does not authenticate email by itself. It delegates a DNS name so the provider can publish the SPF or DKIM data that receivers need to find. The receiver still evaluates normal SPF and DKIM rules.
- SPF path: The receiver checks the envelope sender domain for SPF and can separately check the SMTP HELO/EHLO name.
- DKIM path: The receiver reads the DKIM selector and signing domain, then looks up the public key at that exact DNS name.
- DMARC path: The receiver checks whether the passing SPF or DKIM domain matches the visible From domain.
- Delegation point: The CNAME lets the provider host the changing records while your domain keeps ownership of the delegated hostname.
The part that surprises people is SPF. Many people assume SPF must be published only at the visible From domain, such as company.com. SPF does not work that way. SPF checks the domain used in the SMTP transaction, especially the envelope sender domain. If the platform sends with a return-path like bounces@mail.company.com, the relevant SPF domain is mail.company.com, not automatically company.com.
DKIM delegation is more intuitive. The sending platform signs the message with a DKIM selector and domain, then receivers fetch the matching public key. If you publish a CNAME at the selector hostname, the provider can rotate keys and maintain the TXT record without asking you to edit DNS every time.
CNAME delegation flow for SPF return-path checks, DKIM public key lookup, and DMARC domain matching.
How SPF works through CNAME delegation
SPF authorizes a sending IP for a domain used in the SMTP conversation. The most important domain is the envelope sender domain, also called MAIL FROM, bounce domain, or return-path domain. That is where bounces go, and it is also where receivers usually evaluate SPF.
In a delegated setup, the provider asks you to create a CNAME for a subdomain such as em.company.com. The provider then uses that domain in the envelope sender. When a receiver checks SPF for em.company.com, DNS follows the CNAME to the provider's hosted DNS name and reads the SPF TXT record there.
SPF delegation example with bounce routing omittedDNS
em.company.com. CNAME u12345.prov.example. u12345.prov.example. TXT "v=spf1 ip4:192.0.2.10 include:spf.prov.example -all"
The domain owner publishes the alias, and the provider publishes the SPF policy at the target. The authenticated SPF domain remains em.company.com, even though its policy is hosted elsewhere. The provider must also configure bounce handling; SPF authorization alone does not route bounces.
- Return-path domain: SPF is checked against the domain after the at sign in the envelope sender, not the display From address.
- HELO/EHLO name: Receivers can separately check this hostname. A separate HELO pass does not satisfy DMARC for a nonempty MAIL FROM. With an empty MAIL FROM, SPF derives the envelope identity using postmaster and the HELO domain.
- Root domain SPF: Your root domain SPF record does not need to include this provider unless the root domain is also used as the envelope sender.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
The practical debugging move is to inspect the headers and find the Return-Path. If the Return-Path domain is a delegated subdomain, SPF can pass there even if you cannot see that provider in the SPF record at the visible From domain.
When SPF needs TXT instead of CNAME
A DKIM CNAME does not automatically configure SPF. Some senders require a TXT policy and separate MX records for a custom return-path rather than a CNAME. Follow the records supplied for that sender.
|
|
|
|---|---|---|
CNAME | Resolves the bounce hostname to provider-managed records. | An alias at a dedicated hostname. |
include | Authorizes IPs that pass the referenced SPF policy. | An include mechanism inside your SPF TXT record. |
redirect | Uses another SPF policy if no mechanism matches. An all mechanism prevents redirect. | A redirect modifier inside your SPF TXT record. |
SPF delegation methods depend on the sending setup
Keep one TXT record beginning v=spf1 per queried name. Add authorized senders to the existing policy before its all mechanism; duplicate SPF records cause permerror. SPF policies are not inherited by subdomains. These SPF rules are defined in RFC 7208.
How DKIM works through CNAME delegation
DKIM uses a cryptographic signature in the message headers. The sending platform signs selected parts of the message with a private key. The receiver uses the selector and signing domain in the DKIM-Signature header to find the public key in DNS.
A DKIM lookup has this shape: selector plus _domainkey plus signing domain. If the header says s=s1 and d=company.com, the receiver looks up s1._domainkey.company.com. If that hostname is a CNAME, DNS resolves to the provider's hosted key.
DKIM delegation exampleDNS
s1._domainkey.company.com. CNAME s1.domainkey.provider.example. s2._domainkey.company.com. CNAME s2.domainkey.provider.example. s1.domainkey.provider.example. TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
The CNAME target hosts the actual TXT record. This gives the provider control over key rotation and record formatting while keeping the signing identity under your domain. Some platforms use one selector. Many use two selectors so they can rotate keys without downtime. The private key stays with the provider. The external CNAME target changes the public key lookup, not the d= signing domain. The abbreviated key above is illustrative. Selector use and rotation are described in RFC 6376.
Manual TXT
- Control: You publish the exact DKIM public key as a TXT record.
- Maintenance: Key rotation requires updating the published TXT key, manually or through DNS automation.
- Risk: Copying long public keys can introduce truncation or quote errors.
CNAME delegated
- Control: You delegate only the selector hostname to the provider.
- Maintenance: The provider can rotate keys behind the CNAME.
- Risk: A wrong selector or target breaks DKIM for that stream.
Why DMARC can pass without a root SPF change
DMARC does not require both SPF and DKIM to pass. It requires at least one of them to pass and match the visible From domain. That detail explains many CNAME delegation setups.
For example, a message can show From help@company.com, use Return-Path bounce@mail.company.com, and carry a DKIM signature with d=company.com. SPF can pass through mail.company.com. DKIM can pass through the delegated selector. DMARC then passes because at least one passing mechanism matches company.com.
Authentication outcomes
Common outcomes when a provider sends through delegated SPF and DKIM DNS names.
Both methods match
SPF + DKIM match
SPF passes with a matching domain, DKIM passes with a matching domain, and DMARC passes.
One method matches
One matching pass
One mechanism passes with a matching domain, so DMARC passes.
No passing domain matches
DMARC fail
SPF or DKIM passes, but neither has a passing domain that matches From, so DMARC fails.
Both methods fail
DMARC fail
Neither SPF nor DKIM passes, so DMARC fails.
Relaxed domain matching is the default for SPF and DKIM. RFC 9989 defines a DNS Tree Walk to determine the Organizational Domain. Authenticated domains match the visible From domain in relaxed mode when they have the same Organizational Domain. The aspf and adkim tags set SPF and DKIM matching independently: r is relaxed and s is strict. Strict SPF matching requires the return-path domain to match From exactly; a matching DKIM pass can still satisfy DMARC. Older receiver implementations use public suffix lists, so verify receiver results after changes.
DMARC reports confirm what receivers saw after delegated DNS goes live. Suped's DMARC dashboard shows which source used each SPF or DKIM domain and whether it matched From. That separates a valid delegated sender from a sender that passes authentication only on an unrelated domain.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
What to check in message headers
Start troubleshooting with a message delivered to an external mailbox. Headers show the domains the receiver evaluated. Use the Authentication-Results added by the receiving mailbox service, rather than an untrusted header supplied upstream, as required by the trust model in RFC 8601.
|
|
|
|---|---|---|
From | Visible sender domain | DMARC matches SPF or DKIM to this domain. |
Return-Path | Bounce domain | Usually reflects MAIL FROM; confirm smtp.mailfrom in the receiver results. |
DKIM-Signature | Selector and domain | DKIM key lookup uses these values. |
Authentication-Results | Receiver verdict | Shows SPF, DKIM, and DMARC pass or fail. |
Received | SMTP path | Helps identify the sending infrastructure. |
Header fields that explain delegated authentication
The most common misunderstanding is treating the visible From address as the SPF identity. SPF cares about the SMTP envelope. DMARC then checks whether that SPF identity matches the visible From domain. Those are separate steps. If the message has multiple DKIM signatures, compare each passing header.d value with From; a pass for the provider domain does not cancel a matching pass for your domain.
Selected header fields, with the DKIM signature abbreviatedtext
From: Support <support@company.com> Return-Path: <bounces+12345@em.company.com> DKIM-Signature: v=1; a=rsa-sha256; d=company.com; s=s1; Authentication-Results: mx.example; spf=pass smtp.mailfrom=em.company.com; dkim=pass header.d=company.com; dmarc=pass header.from=company.com;
In that header sample, SPF passes against em.company.com, DKIM passes against company.com, and DMARC passes against the visible From domain. The root SPF record at company.com is not the deciding record for that SPF result.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
After checking a real message, confirm DNS. The SPF checker is useful for focused SPF validation, while the domain health checker gives a broader view across DMARC, SPF, and DKIM.
Common CNAME delegation patterns
Most providers use one of a few predictable patterns. The names vary, but the authentication logic stays the same.
|
|
|
|---|---|---|
Bounce CNAME | em.company.com | Resolves to provider-managed SPF and, where configured, bounce routing. |
DKIM selector | s1._domainkey.company.com | Delegates a hosted public key. |
Second selector | s2._domainkey.company.com | Allows DKIM key rotation. |
Tracking host | click.company.com | Brands links, but does not prove SPF or DKIM. |
Custom subdomain | send.company.com | Separates a mail stream when configured with its own authentication records. |
Common delegated DNS patterns for senders
Provider documentation describes this setup as domain authentication, branded sending, sender authentication, custom return-path, or subdomain delegation. In each case, check the actual DNS hostnames and message identities because the label alone does not prove that both SPF and DKIM are configured.
Klaviyo domain authentication settings showing CNAME records for a sending domain.
Do not assume every CNAME connected to an email platform is an authentication record. A click tracking CNAME or image hosting CNAME can improve branding, but it does not authorize sending IPs or publish DKIM keys.
- Authentication CNAME: Used by SPF return-path checks or DKIM selector lookups.
- Branding CNAME: Used for link tracking, open tracking, images, or web assets.
- Verification CNAME: Used only to prove domain ownership to the provider.
How to manage delegated CNAME records
Copy the provider's exact host and target values. DNS control panels handle relative names differently, so verify the fully qualified hostname after saving instead of assuming the interface appended your domain correctly. Check trailing-dot handling for targets and confirm that the record was added to the authoritative DNS zone.
- Create the exact owner name: Confirm that the saved hostname matches the bounce domain or DKIM selector supplied by the provider.
- Keep the DNS answer unchanged: Turn off HTTP proxying and CNAME flattening for authentication records so public DNS returns the required alias.
- Publish every supplied selector: A second DKIM selector lets the provider rotate keys without requiring another DNS change.
- Verify public DNS: Query the CNAME owner and its target. Confirm that the target returns the expected SPF policy or DKIM public key.
- Activate custom sending: After DNS verification, enable the custom return-path and DKIM signing in the sending platform. Some senders require a separate activation step.
- Test a received message: A provider's setup status can lag DNS, so confirm the Return-Path, DKIM selector, and Authentication-Results in real headers.
Public DNS verificationBASH
dig CNAME em.company.com +short dig TXT em.company.com +short dig TXT u12345.prov.example +short dig CNAME s1._domainkey.company.com +short dig TXT s1._domainkey.company.com +short dig TXT s1.domainkey.provider.example +short
A CNAME cannot coexist with TXT or MX data at its exact owner name. Use an unused bounce subdomain rather than replacing production records. A standard CNAME cannot be placed at the DNS zone apex because that name already has required SOA and NS records. These restrictions follow RFC 2181.
DNS propagation depends on cached answers and their TTL (time to live). If authoritative DNS is correct but a recursive resolver still returns old data, allow its cached answer to expire before retesting. Use the remaining TTL to choose when to retest.
Keep both DKIM selectors published during rotation. When retiring a sender, stop its sending and allow queued messages to complete delivery before removing its delegated records. Keep the old DKIM key available during that transition so delayed mail can still verify. Revocation takes effect as cached DNS answers expire. These key transition rules are described in RFC 6376.
Common CNAME delegation failures
Delegation usually fails because one DNS name is wrong, one domain-match assumption is wrong, or the provider is signing with a domain that does not match the visible From domain. These failures are easy to miss when you only look at setup screens.
- Wrong hostname: The CNAME is created at mail.company.com but the sender uses em.company.com.
- Mismatched DKIM: The DKIM signature passes with the provider domain, but no matching SPF or DKIM result exists, so DMARC fails.
- Strict mode: A subdomain return-path passes SPF but fails strict SPF domain matching. DMARC still passes if a DKIM signature passes with the required domain match.
- SPF lookup pressure: A CNAME-hosted policy still has the 10 DNS-query term limit across evaluated include, a, mx, ptr, exists, and redirect terms. Exceeding it returns permerror.
- Selector collision: Two providers cannot share one selector hostname with different CNAME targets. Use distinct selectors supplied for each sender.
Another common issue is assuming a CNAME under a subdomain delegates every name below it. It does not. A CNAME at send.company.com does not automatically create valid DNS for s1._domainkey.send.company.com. Each queried hostname needs the correct record. RFC 1034 distinguishes NS delegation of authority for a child zone from a CNAME alias for one exact owner name.
The fastest way to catch a broken delegation is to compare the header identity, the DNS name being queried, and the provider's expected hostname. If any one of those differs, authentication fails or passes without a DMARC domain match.
A practical setup checklist
Treat each mail platform as a separate sending source with its own return-path, DKIM selectors, and monitoring. This separation makes failures easier to isolate. A support platform, billing platform, marketing platform, and product mailer should not all depend on a single overloaded SPF record when they can authenticate through delegated identities.
- Choose the identity: Decide whether the sender should use the root domain or a subdomain for visible From and return-path matching.
- Publish exact CNAMEs: Create the hostnames exactly as the provider gives them, including selectors and bounce domains.
- Send a real message: Use a mailbox or tester that exposes full headers, then inspect Return-Path and DKIM-Signature.
- Confirm matching: Check that the SPF or DKIM domain matches the visible From domain under your DMARC policy.
- Monitor reports: Watch DMARC aggregate reports after launch, because provider setup pages do not show receiver-side results.
Suped's DMARC reporting platform groups receiver results by source and shows whether the SPF or DKIM domain matches From. Use it after activation to find senders still using a default provider domain even when their CNAME records resolve. A DMARC pass confirms authentication and domain matching; it does not guarantee inbox placement.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Views from the trenches
Best practices
Inspect Return-Path and DKIM-Signature before judging whether DNS delegation works.
Keep each sender on a distinct delegated subdomain so source problems stay isolated.
Monitor DMARC reports after setup because provider checks do not prove receiver domain matches.
Common pitfalls
Assuming visible From controls SPF hides the real envelope sender domain being checked.
Creating a CNAME at the wrong hostname leaves the queried SPF or DKIM name unresolved.
Treating tracking CNAMEs as authentication records causes false confidence in setup.
Expert tips
Use relaxed domain matching for delegated return-paths unless strict mode has clear value.
Check HELO and MAIL FROM identities when SPF results differ across receiving systems.
Assign a distinct DKIM selector to each provider so DNS changes affect only one sender.
Marketer view
Marketer from Email Geeks says a delegated subdomain can explain SPF and DKIM passes even when the root domain SPF record does not mention the sending platform.
2019-08-27 - Email Geeks
Marketer view
Marketer from Email Geeks says checking the full headers is the first step because the relevant SPF hostname is often the return-path domain, not the visible From domain.
2019-08-27 - Email Geeks
Frequently asked questions
No. A CNAME does not pass SPF by itself. It points the queried domain to another DNS name where the SPF TXT record exists. The receiver still checks whether the sending IP is authorized by the resolved SPF policy.
Yes, when the sender uses a delegated return-path domain and SPF is evaluated there. DMARC still needs the passing SPF domain to match the visible From domain, unless DKIM passes with a matching domain instead.
Delegate only the selector hostnames for a provider you trust. This gives the provider authority to sign for the d= domain using that selector. The selector does not restrict signing to one mailbox or campaign. DNS control stays limited to the delegated names, and you retain the ability to remove the delegation.
No. Tracking CNAMEs are usually for branded links or images. DMARC depends on SPF and DKIM authentication with domain matching, not click tracking or open tracking hostnames.
Set aspf and adkim independently. With aspf=s, a subdomain return-path does not match a parent From domain, but an exact-domain DKIM pass can still satisfy DMARC. Use strict settings only after checking that every legitimate sender has at least one passing mechanism with the required domain match.
Query the exact owner name in public DNS for its CNAME and then its TXT answer through the alias. Confirm that the final target returns the expected SPF policy or DKIM key. Activate the custom identity in the provider and check Authentication-Results on a real message received by an external mailbox.
