HomeBlogAboutLog in

8 Steps to Set Up DKIM CNAME Records for Third-Party Senders Without Breaking DMARC

Executive Summary

A DKIM CNAME record lets a third-party sender sign your mail with your own domain. That signature is what DMARC alignment checks. These eight steps cover record collection and selector naming, so your messages keep passing authentication after you hand sending to an outside platform.

When a third-party sender mails on your behalf, DMARC asks one question. Does the DKIM signature match the domain in the From field? If it does not, mail can miss the inbox even when SPF passes. The fix is a set of DKIM CNAME records that delegate key hosting to your email service provider.

1. What a DKIM CNAME Record Actually Delegates

DKIM signs each message with a private key. The matching public key sits in DNS under a selector. A CNAME record points that selector lookup at a host the provider runs. The provider rotates keys on its own schedule and the signature still reads d=yourdomain.com.

The lookup format is fixed:

<selector>._domainkey.yourdomain.com

If your selector is s1 and your domain is example.com, the record lives at s1._domainkey.example.com.

2. Collect the Exact Records From Your Provider

Do not invent these values. Copy them from the sending platform. Some providers hand out a single CNAME, while others supply two selectors or account-tied hostnames.

Each record has a host and a target. The TTL controls how long resolvers cache the answer. Write everything down before you touch DNS.

One wrong character in the target turns a passing signature into a DMARC failure. Copy and paste the value, then read it back out loud.

3. Name Selectors With a Purpose

The selector appears inside every DKIM signature as the s= tag. Give each sender its own value. Use s1 for your main platform and mailchimp for a newsletter tool. That way you can trace a failing signature back to the source without guessing.

Avoid the generic word default when the provider lets you choose. Shared names make troubleshooting slower.

4. Publish Each Record as a CNAME

Add the record under the selector subdomain. Root-level CNAMEs cause conflicts with other records. Selector names avoid that problem by design. Set the TTL to 3600 seconds or lower while you test.

Follow your provider’s instruction on the target value. Some want a trailing dot and some reject it.

5. Remove the Old TXT Key First

If you signed with a provider-hosted TXT key before, delete it. A CNAME and a TXT record cannot share the same name. When both exist, resolvers return errors and the lookup fails.

Check with a DNS query before you assume the change is live:

dig CNAME s1._domainkey.example.com

6. Confirm the Signature Aligns With Your From Domain

DMARC alignment comes in two modes. Relaxed alignment matches the organizational domain, so mail.example.com aligns with example.com. Strict alignment demands an exact match. Most policies use relaxed, which is why a CNAME delegation works cleanly.

DMARC passes when SPF or DKIM aligns. DKIM holds up better through forwarding because it does not depend on the sending IP.

Test fact: a message can pass SPF and still fail DMARC. Alignment is the part that matters.

7. Verify With Real Messages and Real Headers

Send a test to a Gmail account you control. Open the message, choose Show Original and find the Authentication-Results header. You want a line reading dkim=pass with header.d matching your domain.

Cross-check with a lookup tool such as MXToolbox or dmarcian. These read your DNS and report the selector status. A pass in the header plus a valid record in DNS means the setup is complete.

8. Tighten DMARC Only After Alignment Holds

Start at p=none and read your aggregate reports. These arrive daily at the address in your rua tag. When dkim=pass shows up consistently for your third-party sender, move the policy to p=quarantine. Move to p=reject once the reports stay clean for a few weeks.

Jumping straight to reject is the most common way teams block their own mail.

Two Mistakes That Break Alignment

Duplicate records top the list. A stale TXT key sitting beside your new CNAME will fail every lookup. The other common error is a selector typo in the DNS host field. The provider signs with s=s1 and your record sits under s=sl, so the lookup returns nothing. Check both against the provider panel before you blame DMARC.

What to Do Next

Pull the records from your provider and publish them as CNAMEs. Send one test message and read the Authentication-Results header before you change your DMARC policy. One verified dkim=pass line tells you more than any dashboard summary.

Keep reading those aggregate reports. Alignment drifts as senders change and a quick review catches a failed selector before your customers do.

Read the full guide: Fix DMARC Failure: A Case Study in Third-Party Email Alignment