Campaign Monitor SPF and DKIM setup

What you are setting up

Campaign Monitor sends your campaigns, and authenticating your sending domain lets it sign that mail as you so it passes DMARC. Everything here is a TXT record; there are no CNAMEs: a DKIM key, an optional SPF record, and a DMARC record. DKIM is the leg that carries DMARC; SPF is recommended but Campaign Monitor handles it for you by default.

Set up the sending domain

In Campaign Monitor, click your profile image and go to Account settings > Sending domains, then click Set up a sending domain (or Add domain), enter the domain (Campaign Monitor's example is mail.example.com), and click Continue. It shows you up to three TXT records:

Type:  TXT     (DKIM)
Host:  cm._domainkey        (some hosts want cm._domainkey.mail.example.com)
Value: (copy the exact DKIM key Campaign Monitor shows you)

Type:  TXT     (SPF, recommended)
Host:  @                    (or mail, for a mail.example.com sending domain)
Value: v=spf1 include:_spf.createsend.com ~all

Type:  TXT     (DMARC, required)
Host:  _dmarc
Value: v=DMARC1; p=none;

The DKIM selector is cm, and the key is generated for your account, so copy it from the console. SPF and DMARC are the same for everyone. If you already have an SPF record, add include:_spf.createsend.com right after v=spf1 (with a space) rather than publishing a second record, and if you already have a valid DMARC record, leave it; Campaign Monitor says changing it could cause problems. Publish the records, click I've added the records, and if anything is still pending later, use Re-check record on the Sending domains page.

About the DMARC record

Campaign Monitor requires a DMARC record once DKIM verifies and gives you the minimal v=DMARC1; p=none; to start. A DMARC record at your organizational domain covers a sending subdomain such as mail.example.com unless that subdomain publishes its own, so you do not need a separate one per subdomain. When you are ready to enforce, build a fuller record with our DMARC builder and progress past p=none once your reports are clean.

The Campaign Monitor gotchas

The re-check waits on your TTL. Campaign Monitor's records default to a 300-second TTL, which is the time it needs to validate the domain, and some hosts enforce a longer minimum (GoDaddy's is 600). An SPF re-check in particular may not succeed until the old TTL has passed, so a re-check right after publishing can still show pending. Give it the TTL before you conclude something is wrong. Two more DNS-host quirks from Campaign Monitor's own notes: a few hosts refuse semicolons or underscores in a TXT value (writing \; sometimes works around it; if not, you need a different DNS provider), and the DKIM key should be a fresh one, not an old key reused.

If you do not authenticate, your mail shows Campaign Monitor's servers. Unauthenticated mail appears in Gmail with a “via” note and in Outlook as coming from a Campaign Monitor server (cmail2.com), and only an authenticated domain can be chosen as the sender when you create a campaign, which is the deliverability hit you are trying to avoid. And the universal DNS trap applies: if your host appends your domain automatically, enter only cm._domainkey, _dmarc, or @, or you end up with cm._domainkey.yourdomain.com.yourdomain.com and Campaign Monitor looks in the wrong place.

Confirm it worked

• Check the records. Our DKIM checker confirms cm._domainkey resolves, and a free DMARC audit confirms SPF and DMARC parse.
• Send a test and read the headers. Once the domain shows as authenticated, send yourself a campaign, open the original, and confirm the DKIM signature shows d=yourdomain.com and dmarc=pass. Our header analyzer makes it readable.
• Watch the reports. Campaign Monitor should appear as an aligned, passing source in your DMARC aggregate reports, labeled as a known sender in trustyourinbox.