Mailchimp SPF, DKIM and DMARC setup, step by step

Mailchimp’s current marketing-domain authentication setup uses two DKIM CNAME records and a DMARC TXT record, not a new SPF record for your visible From domain. Verify the domain, obtain the records from your Mailchimp account, publish them safely, and inspect a newly delivered campaign. Do not add a legacy SPF include just because an older tutorial lists one. Mailchimp’s current authentication workflow

This guide applies to Mailchimp Marketing. Mailchimp Transactional, formerly Mandrill, has its own sending-domain requirements and optional custom return path. Use that product’s instructions for API or SMTP transactional mail. Mailchimp Transactional authentication

No customer account was configured or test campaign sent for this guide.

What the SPF question actually means

When someone asks for a “Mailchimp SPF record,” first identify the domain being evaluated. SPF checks the envelope sender’s domain. It does not simply consult the SPF record belonging to whatever address is visible in the From field. SPF specification

This distinction explains why copying a Mailchimp authorization into the company’s root SPF record is not a reliable fix for an authentication warning. If the envelope sender is on a different domain, changing the root policy does not change that identity.

Mailchimp’s current published marketing setup requests DKIM and DMARC records. Follow that record set. If your account presents a different requirement, stop and establish whether you are configuring Marketing, Transactional, or a newly introduced feature before applying instructions from another route. Mailchimp domain-authentication overview

When maintaining SPF for other legitimate senders, keep one SPF policy per DNS owner and stay within the ten DNS-lookup-term limit, counting nested mechanisms. SPF policy and lookup limits

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

For an existing deployment, do not automatically delete historical SPF entries either. Inventory the legitimate senders and establish which service still depends on each authorization. A tidy-looking policy that breaks the invoicing system is a worse outcome than a documented cleanup scheduled after verification.

Keep employee-mail authentication separate: if Microsoft 365 sends that traffic, use the Microsoft 365 authentication guide. Do not add its tenant records as substitutes for Mailchimp’s two issued DKIM aliases.

Separate verification, signing, and DMARC

Mailchimp’s domain verification confirms access through an email-based process; domain authentication publishes DNS configuration. Completing the verification email does not finish the authentication work. Mailchimp’s verification distinction

DKIM links a message signature to a DNS key. The signature’s d= value is its signing domain and s= is its selector. Those fields help determine which DNS name to inspect when troubleshooting. DKIM specification

DMARC passes when a passing SPF or DKIM identity aligns with the From domain. Under relaxed alignment, identities can share an organizational domain; strict alignment requires equality. SPF pass and SPF alignment are separate questions. Current DMARC specification

A useful acceptance question is therefore: “Did this Mailchimp campaign authenticate with the expected domain?” Avoid reducing the answer to “a record exists.” The record might be correct for another sender, account, selector, or message route.

Prepare a safe DNS change

Collect these details before starting:

• The exact campaign From address and the domain after its @ sign.
• The Mailchimp account that owns the campaign.
• Access to the mailbox used for domain verification.
• The authoritative DNS provider, which may differ from the registrar.
• A copy of the existing DKIM entries and applicable DMARC policy.
• A test recipient you control and a person who can approve DNS changes.

Use a domain your organization controls. A public Gmail or Yahoo address cannot be authenticated as your own domain in Mailchimp. Mailchimp domain requirements

Plan the change around an actual campaign route. If production uses news.example.com but the test uses example.com, write that difference down and resolve it before treating the test as a pass. Also check whether a template, integration, or automation supplies its own From address.

Find and publish the Mailchimp DKIM records

Open Account & billing → Domains; account Managers may see Account instead. Choose Start authentication beside the verified domain. Mailchimp offers Entri-assisted setup or manual authentication. For manual setup, copy the two CNAME Host/Name and Value pairs and reconcile the DMARC TXT step with the existing policy. After publication, return to the workflow for validation. Mailchimp setup instructions

Use the account screen as the source of every DNS value. This worksheet is deliberately non-deployable:

Do not substitute a selector copied from a screenshot. Do not create a TXT key when the account requests a CNAME. If the DNS console appends the zone name automatically, enter the appropriate relative name and verify the final fully qualified result afterward.

For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.

A CNAME cannot share its owner with incompatible DNS records. If an entry already exists, establish whether it belongs to Mailchimp or another service before changing it. DNS record-conflict guidance

For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.

Preserve the domain’s DMARC policy

Treat the DMARC step as a review of the domain’s existing policy, not a request for a second provider-specific policy. Ask the person responsible for domain security to approve changes to enforcement, alignment and reporting destinations.

For a new deployment, make an explicit policy decision based on the complete sender inventory. For an established deployment, retain the approved policy unless the owner deliberately changes it. Do not overwrite an enforcement policy with a tutorial’s monitoring example just to make an onboarding screen easier to complete.

Only when no direct or applicable inherited policy exists and the domain owner approves first-time monitoring, publish one TXT policy with v=DMARC1; p=none at the intended From domain’s DMARC owner. For example.com, the full owner is _dmarc.example.com, entered as _dmarc in that zone. For news.example.com, use full owner _dmarc.news.example.com: _dmarc.news relative to the parent zone, or _dmarc in the separately delegated child zone. Do not create a child monitoring exception to an existing protective policy. The minimal value requests no reports; append ; rua=mailto:APPROVED_REPORT_ADDRESS only after replacing the placeholder with a provisioned, approved destination. DMARC policy publication.

Adding a report recipient is also a data-routing decision. Document who will receive aggregate reports and why. Avoid copying a third party’s reporting address from an example when your organization already uses its own reporting service.

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Test a newly delivered marketing campaign

After the account validates, run a small authorized send to a mailbox you control. Prefer the actual campaign or automation route rather than an unrelated mailbox send. A message sent before authentication completed cannot validate the new configuration.

Use a short record of the evidence:

In Gmail, use More → Show original to examine headers. Google’s full-header instructions

Read the recipient’s trusted Authentication-Results and record spf, dkim and dmarc, alongside the domains those results refer to. Do not trust an arbitrary Authentication-Results line merely because it appears in the source. Authentication-Results trust rules

Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.

Diagnose SPF at the actual smtp.mailfrom independently, even when aligned DKIM supplies DMARC pass. fail or softfail calls for checking whether the connecting sender is authorized for that envelope route; temperror indicates transient evaluation trouble such as a DNS timeout; permerror calls for checking malformed syntax, duplicate policies and the evaluated DNS-term budget. A passing but unaligned SPF identity is a separate condition. SPF result meanings.

Accept the campaign test only when the expected Mailchimp DKIM signature passes, its signing domain aligns with the intended From domain, and the trusted receiver reports DMARC pass. DNS and Mailchimp status alone are insufficient.

Compare the authenticated DKIM domain with the campaign’s From domain. Retain the selector as well: it lets the DNS administrator check the specific key path used by that message rather than guessing which Mailchimp record matters.

A practical troubleshooting example

Suppose a new campaign shows SPF pass but DMARC fail. An administrator proposes adding an SPF include to example.com. Before making that change, collect the envelope domain and all DKIM results.

If SPF passed for an unrelated envelope domain, the root-domain edit does not address the mismatch. If the expected DKIM signature is missing or fails, investigate the Mailchimp domain connection and the selector used. If DKIM passes under a different company domain, verify the campaign’s From address and intended brand.

This is a diagnostic example, not an observed Mailchimp incident. Its purpose is to prevent a DNS edit based on an incomplete “SPF passed” screenshot.

Common setup problems and next actions

The domain is verified but not authenticated. Resume the DNS authentication workflow. The verification email and DNS publication are different checkpoints.

The CNAME is saved but cannot be found publicly. Check authoritative nameservers, the owner-name suffix, record type and target. Compare an authoritative response with a recursive resolver before blaming propagation.

Mailchimp still shows authentication in progress. Mailchimp documents that validation can take up to 48 hours. If public answers are correct and the wait exceeds its stated window, collect the evidence and escalate instead of repeatedly recreating the records. Mailchimp validation timing

DNS changed after a previous successful setup. Recheck the current account instructions and arrange a controlled revalidation. Do not remove active authentication without considering scheduled sends.

Authentication passes but the message goes to spam. Review permission, list quality, complaints, content and unsubscribe handling. Gmail’s sender requirements cover more than DNS authentication. Google sender guidelines