SPF, DKIM and DMARC with Campaign Monitor

The goal with any hosted email platform is one thing: a DKIM signature made with a key published under *your* domain, so DMARC has an aligned pass to work with. For Campaign Monitor that means adding its authentication records to your DNS, confirming the domain, and then verifying from a delivered message rather than from the dashboard.

Why authentication is not optional any more

Spoofing works because SMTP lets anyone write any address into the From header. The three records close that off in layers: SPF names the servers allowed to use your domain in the envelope, DKIM proves a message was signed by a key in your DNS, and DMARC tells receivers what to do when neither of those passes *in alignment with the visible From domain* — and sends you reports about every attempt.

Google and Yahoo both made this mandatory for bulk senders in February 2024, and Microsoft introduced equivalent requirements for consumer Outlook addresses in 2025. The shared baseline is SPF and DKIM in place, a DMARC record of at least p=none, aligned authentication, working one-click unsubscribe, and complaint rates held low — Google publishes 0.3% as the figure to stay beneath. Campaigns from an unauthenticated domain are now rejected rather than merely filtered.

SPF: the mechanisms worth knowing

A record is a version tag, a list of mechanisms, and a default:

v=spf1 include:_spf.google.com ip4:203.0.113.0/24 ~all

The qualifier on all sets the default: ~all softfails (accept but mark), -all hardfails, ?all is neutral and +all authorises the entire internet. Use ~all while you are still finding senders and -all once DMARC reports show nothing legitimate is missing.

Two hard limits: one `v=spf1` record per domain — two produces PermError and disables SPF for everything — and a maximum of 10 DNS-querying mechanisms per evaluation, counted recursively through includes, with no more than two lookups that return nothing.

Setting up the sending domain

1. In Campaign Monitor, add the domain you want in From and open its authentication screen.
2. Publish the records it issues. Campaign Monitor's DKIM is CNAME-based: you create a CNAME on a selector under _domainkey.yourdomain.com pointing into Campaign Monitor's own zone, which means it rotates the key and you never republish a public key or fight your DNS host's 255-character TXT string limit. Take the exact host and target from the dashboard — the values are account-specific.
3. Enter only the relative part of the host if your DNS panel appends the zone automatically, or you will create selector._domainkey.yourdomain.com.yourdomain.com.
4. Keep the record DNS-only. A CNAME proxied through a CDN returns the proxy, not the delegation.
5. Wait for confirmation, then verify independently.

dig +short CNAME <selector>._domainkey.yourdomain.com
dig +short TXT   <selector>._domainkey.yourdomain.com

The TXT query should return a v=DKIM1; k=rsa; p=... value even though you published a CNAME. That is the resolver following the chain, and it is the proof the setup works end to end.

The check the dashboard cannot do for you

Send a campaign to a test address on Gmail and one on Outlook. Open the raw source and read two lines:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=<selector>; ...
Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=<platform bounce domain>;
  dkim=pass header.i=@yourdomain.com;
  dmarc=pass (p=NONE) header.from=yourdomain.com

d= is the signing domain. If it is your domain, you are aligned and safe to enforce DMARC. If it is the platform's domain, the signature is valid and unaligned, and p=reject would block your own campaigns.

Notice that SPF here passed for the platform's bounce domain, not yours. That pass contributes nothing to DMARC, which is why adding an ESP's SPF include to your record often changes nothing — and still costs you a DNS lookup. Check the Return-Path header before you edit your SPF record at all. If Campaign Monitor offers a custom Return-Path on a subdomain of yours, configuring it converts that unaligned SPF pass into an aligned one.

DMARC rollout

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

Published at _dmarc.yourdomain.com. Run it a week, inventory every sender from the aggregate reports, fix each one to sign with an aligned key, then p=quarantine for a week, then p=reject. Set sp= explicitly when you tighten p=, and if rua points at another domain, that domain must authorise reports with a v=DMARC1 record at yourdomain.com._report._dmarc.<their-domain>.

The From-domain decision

Marketing volume on a subdomain such as news.yourdomain.com, with human one-to-one mail on the apex, is the configuration that fails safest: each gets its own SPF budget and its own reputation, and a badly received campaign stops costing you replies to your sales mailbox. The trade-off is slightly weaker brand recognition in the sender line.

What not to do

• Do not use a free-mail address in From. Those domains publish p=reject and your campaigns will be rejected by DMARC-enforcing receivers.
• Do not publish a second SPF record when adding a platform. Merge into the one you have.
• Do not re-use one DKIM selector across two platforms. Selectors are namespaces and a collision silently replaces a working key.
• Do not enforce DMARC on the strength of a dashboard tick. Verify in headers, then in reports.
• Do not leave includes for platforms you have stopped using; dead includes count against SPF's void-lookup limit.

MailPilot checks SPF, DKIM and DMARC for each connected mailbox's sending domain and measures real per-provider inbox placement with a seed-inbox network, so you can tell an alignment problem apart from a reputation problem instead of guessing between them.