Campaign Monitor authenticates a sending domain through account setup, public DNS and a verification check. Use the exact domain that will appear in the From address, including its subdomain. This is a sender-specific configuration: authenticating Campaign Monitor does not authenticate another service that happens to use the same brand domain.
Establish the identity and change owner
Confirm that the organization controls the intended domain and that the DNS operator can change its authoritative zone. Save existing selector, SPF and DMARC records. Identify other legitimate senders before accepting any suggested policy replacement. Keep the person configuring campaigns and the person publishing DNS aligned on the full domain, not just a short label such as mail.
The sending-domain guide says that authenticating a second-level domain does not authenticate its subdomains in the platform. If campaigns use news.example.com, add that exact domain rather than assuming example.com covers the account setting.
Configure the domain and generated key
Open the profile menu, Account settings, then Sending domains. Choose Set up a sending domain or Add domain, enter the full domain and continue. Publish the generated TXT name and value at authoritative DNS, using the editor's correct full-name or relative-name convention. Return to Campaign Monitor and select I've added the records, or Re-check record if returning later.
Use a newly generated key for this setup rather than importing an existing private key by convenience. Keep private signing material out of DNS, tickets and shared worksheets. If a generated selector collides with another active record, resolve the conflict before replacing it. Public examples are not your account's key.
Preserve DMARC and reconcile SPF carefully
The documented workflow accepts an existing valid DMARC configuration. Keep its enforcement policy and reporting destinations unless the domain owner approves a separate change. Where no policy applies, establish one at the correct owner. A p=none example is a monitoring request, not enforcement and not a reason to weaken a policy inherited from a parent.
Campaign Monitor recommends optional SPF authorization using include:_spf.createsend.com. If that authorization is appropriate for your configuration, merge it into the single existing SPF policy rather than adding a second one. Preserve other legitimate senders and check the evaluated dependency path against SPF's lookup limit. The provider's email-authentication overview supplies context, but the received envelope determines which domain the receiver actually checks.
An SPF pass for a service-owned envelope is not necessarily aligned with your visible From. A passing aligned DKIM signature can satisfy DMARC even when that SPF path is unaligned. Do not promise strict SPF alignment merely because an include was added to the From domain's TXT record.
Verify records before the campaign test
Query the generated selector at each authoritative server, then inspect the applicable DMARC and SPF answers. Record the complete owner, type, value and timestamp. A DNS editor may split a long TXT value into character strings within one record; that differs from publishing multiple DKIM records. Follow the DNS provider's handling and compare the reconstructed value.
If Campaign Monitor cannot verify, check for a duplicated domain suffix, wrong record type, omitted key characters and authoritative-server disagreement. The TTL is a caching control, not a guaranteed time at which every validator updates. A cached negative answer can outlast the moment a new record is created.
Confirm the real campaign uses the intended domain
Send a controlled test campaign with the newly authenticated From address. Preserve trusted Authentication-Results, From, Return-Path and all DKIM d=/s= pairs. Confirm a passing signature aligns with the From domain under the configured mode. If the test passes but a later campaign fails, compare sender addresses and routes before modifying DNS.
Illustrative case: example.com is configured, but a campaign uses news.example.com, which was never added to the account. Correct the domain setup for the actual campaign identity; do not replace a valid parent-domain key to solve a different identity's configuration.
Retain the prior working sender until acceptance where feasible. Recheck after account changes, new sending subdomains, DNS migrations or key rotation. Before retirement, stop scheduled campaigns and confirm dependencies are no longer used. This article is a documentary guide and proposed verification plan, not evidence of a live Campaign Monitor test or guaranteed delivery.
Do not confuse a product scope gap with strict alignment
Written case CM-01 assumes the product has example.com configured but the campaign From is news@news.example.com. Separately stipulate a trusted passing DKIM signature d=example.com, s=demo1. With ordinary relaxed organizational-domain alignment, that signature can align to news.example.com; with adkim=s it does not exactly match. SPF and other signatures are unknown, so the strict-mode overall verdict is unresolved, not an established DMARC failure. Neither premise proves that Campaign Monitor has the intended subdomain configured. The campaign owner should complete the exact-domain setup and inspect the resulting controlled campaign before release. These are fictional inputs, not a captured delivery or a reason to loosen policy.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.