Mailchimp's domain verification and domain authentication are separate steps. Verification establishes access to the relevant email identity; authentication configures the domain for the sending workflow. Neither should be confused with proof that a particular campaign reached a recipient using the intended identity.
Begin with the account, the domain in the campaign's visible From address and the campaign route being assessed. Record who owns the domain and who can authorise changes to its active DNS.
Identify the sending product and current state
Mailchimp's current guidance includes automated and manual authentication paths. Establish which path the account uses and whether the domain has already been verified or authenticated.
Keep product scope explicit. If the business uses Mailchimp Transactional as well as marketing campaigns, confirm the applicable setup and test requirements for each route. A brand appearing in the same family of products does not establish shared configuration.
Use a domain the organisation controls. A public mailbox address cannot give the organisation authority to publish authentication records for that mailbox provider's domain.
Reconcile the generated records with the existing zone
For the current manual workflow, Mailchimp documents two DKIM CNAMEs and a DMARC TXT record. Use the values generated in the relevant account, not a remembered selector or a copied customer target.
Inspect the existing data at each proposed name. A new record must not overwrite an active selector, and a proposed DMARC record needs review against the policy already in force. An account setup process is not approval to reset a stronger operating policy or remove reporting destinations.
Do not create a second DMARC policy at the same owner name merely to satisfy another service. Determine whether the applicable existing policy satisfies the configuration needs, and resolve any disagreement through the supported verification process.
For an automated connection, review its intended DNS changes and access scope before authorising them. Retain the actual resulting records. Automated writing still needs a traceable owner and an understandable result.
Verify the public answers and account result
Check the exact owner names at the active authoritative host. Confirm how the DNS editor treats a full hostname, and whether it preserves the intended CNAME target.
Record the public answer and time alongside Mailchimp's validation state. An in-progress status needs investigation of publication and validation, rather than repeated deletion and recreation of records.
If validation fails, compare each requested record with its authoritative answer and check for a record-type or owner-name conflict. Avoid changing unrelated SPF policies or inbound mailbox routing without evidence that they are involved.
Send through the campaign route
Use controlled recipients and an appropriate campaign test. Save the original received message with the account and campaign reference.
Inspect the visible From domain, DKIM signing domain and trusted receiver results. Establish the aligned authentication path that supports DMARC. A policy TXT record alone cannot create a signature or repair an unrelated identity.
A synthetic example illustrates the distinction. A team verifies access to an address and sees no problem in its account list, but never completes domain authentication. The next investigation should compare that account state with the generated DNS requirements and a real campaign message. Rewriting the DMARC policy repeatedly would skip the missing setup evidence.
If a campaign passes authentication but still goes to spam, keep that finding. Authentication and placement answer different questions. Investigate the current receiver requirements and the campaign's recipient, reputation and content factors separately rather than undoing a proven identity configuration.
Keep campaign changes maintainable
Record the account, sending product, domain, generated record set, change owner and received-message evidence. Include a retirement process for agencies or accounts that stop sending for the organisation.
Review the setup when the From domain or account changes. Keep records needed by active routes until retirement is verified, and reassess older dependencies rather than retaining them indefinitely without an owner.
The sender inventory connects this campaign route to the wider programme. The useful outcome is a specific, verified identity that the team can maintain, rather than an unqualified promise that every campaign will reach the inbox.
Separate the campaign checks into a decision ledger
For fictional marketing campaign MC-01, From news@example.com is stipulated verified by email access, while domain authentication remains pending. CNAME1 and CNAME2 generated values have not been supplied, existing DMARC is assumed p=reject, and received DKIM/SPF results are unknown. Keep the campaign unverified; do not replace the existing policy with p=none or invent DNS targets to force completion. Obtain the account-generated names, reconcile each with the authoritative zone and then collect a controlled campaign original. A separate transactional application remains outside that campaign result. No account, DNS connection or campaign send was executed.
Mailchimp documents that changed CNAMEs can require disabling and re-authenticating the domain. Plan that maintenance under the change owner with affected campaigns identified; do not repeatedly reset a working configuration merely because an unrelated delivery issue appeared.
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.