Authenticate the exact domain used in your Campaign Monitor From address, publish the account-generated DKIM TXT record, and complete the provider's verification. Preserve your existing DMARC policy. Campaign Monitor recommends an optional SPF authorization, but adding it does not by itself make the envelope sender align with your visible From domain. Your acceptance test should include an aligned DKIM pass in a real delivered campaign, not just a green DNS check.
Scope and prerequisites
This procedure covers Campaign Monitor's own sending-domain workflow for campaign email. It does not configure Campaigner, another Marigold product, an external mailbox, or every transactional integration. Authentication must be checked separately for any additional sending route. The public setup instructions do not identify a paid-plan prerequisite; this guide does not promise that every account role can administer domains.
Write down the intended From address, account or client, DNS administrator and campaign being changed. An agency should identify the client account before generating records. A successful configuration in one account is not evidence of another account's signing state.
Campaign Monitor distinguishes a branded website or tracking domain from email authentication. Setting a custom login or tracking hostname is not the DKIM procedure. Confirm which problem you are solving before editing DNS. Official domain overview.
Use a domain your organization controls. A Gmail address does not give you permission to authenticate gmail.com. Likewise, owning example.com does not mean the registrar still hosts its DNS. Look up the authoritative nameservers and arrange access to the service that actually publishes the zone.
Before the change, export the relevant DNS records, including SPF, existing DKIM selectors and DMARC. Preserve their TTLs and identify other teams using the same domain. Schedule a small controlled campaign for validation and record who can pause sending if its headers do not match the intended configuration. This is change-management advice, not a claim that a test has been performed.
Configure DKIM
In Campaign Monitor, open your profile, then Account settings → Sending domains. Choose the add-domain option and enter the exact sending domain. Publish the generated TXT name and value in authoritative DNS, then use I've added the records or Re-check record. Once verified, select that authenticated domain when defining the campaign sender. Campaign Monitor explicitly requires subdomains to be authenticated separately from their parent. Current setup instructions.
Do not reuse a public key copied from an article. The value must correspond to the key Campaign Monitor uses for your account. For a new setup, prefer the native generated-key route rather than importing an existing private key for convenience. Keep private material out of DNS, tickets and shared worksheets. The provider's example selector is cm, but your account's instructions remain the source of truth. Never publish a private key.
Translate the host field carefully. Suppose the complete generated owner is cm._domainkey.mail.example.com:
- In the example.com zone, an editor that appends the zone needs cm._domainkey.mail.
- In a separately delegated mail.example.com zone, that editor needs cm._domainkey.
- In a separately delegated
_domainkey.mail.example.comzone, that editor needscm. - An editor requiring fully qualified names needs the complete owner.
Use the existing authoritative delegation; an inactive parent-zone copy will not work. Preserve NS delegations, DNSSEC, unrelated selectors and mailbox MX. Do not change them to make this guide fit. Do not add TXT at an owner already occupied by a CNAME; resolve the conflict with the affected service owners. This native route issues TXT, not an instruction to invent a CNAME or substitute ALIAS/ANAME.
These are illustrative name translations, not records to copy. The wrong zone-relative label can produce a record that exists but is never queried by a receiver. A TXT value split into quoted character strings by a DNS tool is not necessarily damaged; compare the reconstructed value, not its display wrapping. Strings within one TXT record concatenate without inserted whitespace; do not create multiple independent keys. DKIM TXT storage
If the same name already has a key, stop before replacing it. Another Campaign Monitor account may rely on that selector. Campaign Monitor has a dedicated multiple-account authentication procedure. Resolve ownership and the supported sharing method first. A new key that verifies for one account can invalidate messages signed with the previous private key.
Decide whether to add SPF
SPF checks the SMTP MAIL FROM identity (or HELO in applicable cases, such as a null reverse-path), normally reflected in the delivered Return-Path. It does not simply check whichever domain appears beside the sender's name. Campaign Monitor's authentication documentation explains that by default it supplies SPF for its own Return-Path domains. That service-owned envelope need not match your customer From domain; inspect the actual delivered identity rather than assuming a universal Return-Path. Consequently, SPF can pass while being unaligned for DMARC. Campaign Monitor authentication explanation.
The documented optional authorization is include:_spf.createsend.com. Treat this as authorization advice, not a custom-return-path switch. If your team elects to follow the recommendation, amend the existing SPF record for the intended domain only after reviewing its other senders and lookup budget. Do not add a second v=spf1 record. Campaign Monitor SPF recommendation.
For example, an SPF policy already authorizing your mailbox platform must retain that authorization. Keep one version marker and one deliberate terminal policy. An all mechanism makes later mechanisms unreachable and causes redirect to be ignored wherever that modifier appears. SPF all processing Do not silently replace -all with ~all or remove mechanisms merely to match a tutorial. SPF permits at most ten evaluated DNS-lookup-causing terms, including nested includes and redirects, not just the number of include strings visible in your editor. SPF specification.
If a checker reports unaligned SPF but the receiver reports aligned DKIM and DMARC pass, another root-domain include is not the remedy. Conversely, investigate an actual SPF fail by comparing that envelope domain and connecting IP with approved authorization, including forwarding effects. For permerror, check duplicate policies, syntax and evaluated lookup limits. For temperror, investigate temporary DNS failures and retest after recovery. These errors need separate attention even when DKIM supplies a DMARC pass. Record both outcomes instead of calling all SPF alignment failures authentication failures.
Preserve DMARC
Look for an existing policy at the exact From domain and determine whether a parent policy applies when no local policy exists. Keep established reporting destinations, alignment settings and enforcement. A new p=none record on a subdomain can override inherited protection; absence of a local record is not permission to weaken it.
DMARC needs at least one authenticated, aligned identifier: SPF or DKIM. Relaxed alignment compares organizational domains; strict alignment requires an exact domain match. Check adkim and aspf rather than assuming a passing signature for any related domain is sufficient. Current DMARC standard, RFC 9989.
Where no effective policy exists, the domain owner can approve a monitored introduction using p=none and an authorized reporting destination. This is not an instruction to reset an existing policy. Do not add duplicate DMARC records or transplant a third party's reporting address. RFC 9989 replaces RFC 7489 and removes pct; do not build a new rollout around that retired tag.
Only with no direct or applicable inherited policy, an owner-approved monitoring plan and an approved reporting mailbox may this first-policy template be used:
Type: TXT
Full owner: _dmarc.mail.example.com
Value: v=DMARC1; p=none; rua=mailto:YOUR_APPROVED_REPORT_MAILBOX
The owner is illustrative for From mail.example.com: use relative _dmarc.mail in the parent example.com zone, or _dmarc in a separately delegated mail.example.com zone. A _domainkey delegation does not contain this name. Replace the example domain and replace the mailbox placeholder with the mailbox address only, not another mailto: prefix. Never publish placeholders or add a second policy. Return to Sending domains → Re-check record after the approved DMARC change. Native DMARC check
An aggregate-report destination in a different Organizational Domain from the domain where the DMARC policy was found requires the report-generating receiver to check authorization in the destination’s DNS. A destination within the same Organizational Domain is excepted; a different hostname alone is not the trigger. Have the reporting operator supply and confirm authorization for the actual policy domain. RFC 9990 section 4 This protocol check is separate from the owner’s approval of data sharing, access and retention. Do not enable failure reporting without its own privacy review.
For a hypothetical From news@news.example.com, a trusted passing DKIM signature d=example.com aligns in relaxed mode, assuming Organizational Domain example.com, but not under strict adkim=s. A passing d=news.example.com aligns in both modes. Other signatures and SPF can affect the overall DMARC result. This identity comparison does not establish that Campaign Monitor has news.example.com configured: its exact-domain account requirement is a separate check. These examples are not measured deliveries.
Keep the DNS correction and policy decision separate. If an existing reject policy exposes a misconfigured campaign, fix the campaign identity or signing configuration before considering a policy exception. Record any exceptional change with its approver, reason and planned review date.
Verify DNS and a delivered campaign
Use the complete owner names from the account. The commands below are read-only examples. Replace the example names with the actual domain, selector and authoritative server before using them:
dig +short NS example.com
dig @ns1.example.net cm._domainkey.mail.example.com TXT
dig @1.1.1.1 cm._domainkey.mail.example.com TXT
dig @1.1.1.1 mail.example.com TXT
dig @1.1.1.1 _dmarc.mail.example.com TXT
The authoritative response should contain the intended public key at the exact owner. A public resolver should eventually agree after relevant caches expire. NXDOMAIN, SERVFAIL and an empty answer are different conditions; preserve the full response rather than interpreting all three as “propagation.” Inspect applicable parent DMARC policy too. A root SPF check alone does not prove the actual envelope domain's SPF behavior.
Return to Campaign Monitor and recheck. Then, with authorization, send a small real campaign to controlled external recipients using the intended From domain. A preview or editor test is useful for layout but is not sufficient evidence for a different production route.
Use results produced inside the actual receiving service’s known processing boundary. Ask its administrator or consult its documentation to establish which component authenticated the message and how externally supplied Authentication-Results fields are removed or isolated at ingress. Correlate the result with that service’s original-message view or authenticated trace. A familiar authserv-id or header position alone is not proof. Ignore untrusted fields; if provenance remains unclear, leave acceptance open and obtain the receiver’s trace. Forged authentication-result fields, RFC 8601 section 7.1
From the receiving mailbox's original headers, record:
- The visible From domain and delivered Return-Path.
- The DKIM-Signature d= domain and s= selector.
- The trusted receiving mailbox infrastructure's Authentication-Results, including dkim, spf and dmarc outcomes, not arbitrary sender-supplied copies of that field. Authentication-Results trust boundary.
- Whether the passing DKIM identity aligns under the domain's current policy.
Success means the expected public DNS exists, Campaign Monitor accepts the configuration, and the trusted receiver reports the intended Campaign Monitor signature passing with its issued selector and d= aligned under the current adkim policy, plus dmarc=pass for the intended From domain. SPF-only DMARC pass or a provider-rewritten From does not establish this branded DKIM route. SPF may pass for the service's domain without aligning. A key lookup alone cannot verify a message signature. DKIM specification.
Retain the message identifier, send time, campaign and sanitized headers. Do not treat an authentication pass as a promise of inbox placement. Complaints, consent, engagement, content and receiver filtering remain separate questions.
Troubleshoot safely
DKIM remains unverified: Compare the full owner and value against the current account screen. Check authoritative DNS first. A doubled domain suffix, incorrect TXT type or incomplete key will not repair itself by waiting.
Verified but not yet signing: The native troubleshooting guide allows up to 30 minutes after verification for signing to start. This is provider guidance, not proof of activation or a guaranteed delivery deadline. Recheck the actual campaign domain and message after that interval, then contact Support if signing remains absent. Native signing troubleshooting
One client works, another fails: Inspect both account configurations and actual selectors. Do not regenerate or overwrite a shared key until every dependent account has been identified.
The received From address has been rewritten: Campaign Monitor documents a default sending-domain fallback for unauthenticated customer domains. It substitutes an account-specific provider subdomain in From and signs with its own domain; replies normally go to the original address unless Reply-To is customized. That message can authenticate successfully without proving your customer domain is configured. Compare the received identity with the intended one. Default-domain behavior.
DNS looks right, but the campaign uses another identity: Check the campaign's selected sender and the received From header. Authenticate the actual subdomain, not just its parent. Campaign Monitor requires authentication before using a customer domain in From. From-domain requirement.
DKIM passes but DMARC fails: Compare the passing d= value with From and check strict alignment. A signature belonging only to the service is not evidence of customer-domain alignment. If an intervening gateway modified the message, compare a direct delivery with the forwarded path.
A DNS migration breaks sending: Restore the documented authentication records at the new authoritative host, validate publicly, and retest before resuming volume. Do not remove enforcement or unrelated sender records as an emergency shortcut.
For conflicting TXT policies, use EmailAuth’s multiple SPF records diagnosis. The sending provider supplies its required values; the authoritative DNS host publishes them.