belkins.app

Guide / Mailchimp DNS authentication

Mailchimp domain authentication pending

Compare the exact records currently shown in the Mailchimp account with public DNS answers for the same domain or subdomain. A pending status can mean that validation is still in progress, a host or value differs, or the account is using a different product path.

Folderly editorial owner reviewed 28 September 2026 constructed examples only

If Mailchimp still shows Authentication in progress after DNS edits, compare the exact records currently shown in that Mailchimp account with public DNS answers for the same verified domain or subdomain. For the current standard Mailchimp email-domain authentication flow, Mailchimp’s manual instructions call for two CNAME records for DKIM and one TXT record for DMARC. Mailchimp says most records update within a few minutes, but validation can take up to 48 hours. These are account states, not proof of how a recipient evaluated a message. Read Mailchimp’s setup guide for the names and values shown by the account.

Quick answers

What should standard Mailchimp authentication publish? The current manual setup says two DKIM CNAME records and one DMARC TXT record. Copy the exact host and value from the account; there is no safe universal selector or target to paste from an article.

How long should a pending status last? Mailchimp says most records update within minutes and validation can take up to 48 hours. That is the documented window for this Mailchimp flow, not a universal promise about every DNS provider or resolver.

Does domain verification mean authentication succeeded? No. Verification confirms access to an address on the domain. Authentication is a separate DNS setup; Mailchimp also says a sending subdomain must be verified separately.

Does a custom return path belong in this setup? Mailchimp documents a custom return-path domain for Mailchimp Transactional. The standard email-marketing authentication pages reviewed here do not document that setting, so do not transfer Transactional records into a regular Mailchimp account.

Identify the product and preserve the actual instruction

Record whether the sender uses standard Mailchimp email marketing or Mailchimp Transactional. Their screens and supported controls differ. Also record the account, exact sending domain, visible From: domain, and current status before changing anything.

Mailchimp’s verification and authentication states are separate. Verification links and codes expire after seven days; an expired verification message is a different problem from a DNS authentication check. Use Verify an Email Domain when the domain has not reached the verified state.

The values in the Mailchimp control panel win over every example in an article. client.example, k2._domainkey, and any target shown below are illustrative unless the account itself displays them. Keep client domain screenshots and copied values private.

Use the evidence table before touching DNS

What a Mailchimp observation establishes and who acts next
What you observe Safe read-only comparison What it establishes Next owner action
Mailchimp says Authentication in progress Compare the status and start time with public CNAME and TXT answers for the exact account domain. Mailchimp is still validating; it does not establish that every record is visible or correct. If values match, wait within Mailchimp’s stated window and record the recheck time.
A requested CNAME is not returned publicly Query the exact host from the account and confirm which nameservers are authoritative. The record is not observable through the DNS path tested. The cause remains unknown. Ask the authorized DNS operator to check the active zone and publication result.
The host appears as k2._domainkey.example.com.example.com Compare the provider’s stored host with the fully qualified name. Mailchimp documents this domain-duplication mistake and says to use only k2._domainkey when the provider appends the domain. The provider created a different name from the requested one. Correct only the host field, then recheck the public answer. A real account may use another selector.
A CNAME exists but its target differs from Mailchimp’s current value Compare record type, host, and target character by character with the current account instruction. A record exists, but it is not evidence that Mailchimp can validate this setup. Route the discrepancy to the DNS/ESP owner; do not replace a live record without checking what else uses it.
The DMARC TXT host or value differs Compare the account’s _dmarc host and value with the public TXT answer. The public record differs from the value Mailchimp asked this account to publish. Have the authorized DNS owner review existing DMARC ownership before changing it.
A CNAME was edited after the account was authenticated Check the change time against Mailchimp’s status. Mailchimp warns that changing CNAMEs after authentication can interfere with information it stores. After records are final, disable authentication and authenticate again as Mailchimp advises.
Mailchimp is authenticated, but a received message has an unexpected SPF/DKIM result Compare receiver-generated Authentication-Results, visible From:, SPF smtp.mailfrom, and DKIM d= from the same path. The account badge and message-level result are different evidence layers. Use the alignment guide to interpret the domains.

“Record absent,” “record different,” and “status pending” are observations. “The registrar is broken” or “Mailchimp is ignoring DNS” is a hypothesis that needs more evidence.

A precise, read-only comparison process

  1. Capture the account instruction. Open the verified domain under Account & billing → Domains, choose Start authentication, and select the DNS provider. For manual setup, copy the two DKIM CNAMEs and one DMARC TXT record exactly as shown. Save type, host/name, target/value, domain, and status in a private worksheet. If Entri was used, record its “records created” confirmation, then verify the public result independently.
  2. Confirm the domain boundary. Check whether the campaign uses example.com or news.example.com. A parent-domain record does not prove a subdomain’s setup is complete. Confirm that the visible From: address belongs to the domain under review.
  3. Query DNS without changing it. Use the account’s actual host with a resolver or commands such as:
    dig +short CNAME <Mailchimp DKIM host>
    dig +short TXT _dmarc.<domain under review>
    dig +short NS <domain under review>
    These commands only read DNS. Compare the returned CNAME target and TXT content with Mailchimp’s current instruction. If a provider UI shows a short host but the public answer is empty, record both forms and ask the DNS owner which zone is authoritative.
  4. Check the documented host-field mistake. A DNS panel may append the zone name to a host field. Mailchimp’s example says entering k2._domainkey.example.com can create k2._domainkey.example.com.example.com; in that panel, use only k2._domainkey. This is field normalization, not a universal selector.
  5. Wait, then escalate with evidence. If public answers match the account instruction and status remains pending after Mailchimp’s 48-hour window, record timestamps, status text, and a sanitized comparison. Use Mailchimp or the DNS provider’s documented support path. If a previously authenticated CNAME was changed, finalize the records first, then disable and re-authenticate as Mailchimp instructs.
  6. Verify the message separately. An account status does not certify alignment for every recipient. Send one authorized test through the same campaign path and record the receiver’s result, visible From: domain, SPF-authenticated identity, and passing DKIM d= domain. Use the provider requirements guide for destination-specific rules and the operator handoff guide to assign the next action.

SPF, DKIM, DMARC, and the return path are different controls

The current standard Mailchimp setup page instructs the operator to publish DKIM CNAMEs and a DMARC TXT record. It does not give a universal client-side SPF record to paste into every domain. SPF may still appear in a received message because the sending path has an envelope or MAIL FROM identity. Record that identity from the receiver’s result; do not infer an aligned SPF pass from Mailchimp’s account badge or guess a new SPF value. Any SPF change must account for the other services already authorized to send for the domain.

Mailchimp Transactional documentation is a separate product contract. It documents DKIM, DMARC, and a custom return-path feature using a subdomain CNAME to mandrillapp.com; it says Mailchimp Transactional still handles the bounces. If the account is Transactional, follow its authentication and delivery documentation and the values shown in that account. Do not transfer those records into standard Mailchimp.

Authentication also does not settle reputation, acceptance, or inbox placement. A DNS record can be present while a received message uses another path, and a message can show a valid SPF or DKIM result for a domain that does not align with the visible From: domain. Keep message evidence private and sanitized; the aligned-authentication guide works through that comparison.

When the answer is still unknown

Write “Mailchimp account status observed; message-level authentication not observed” when there is no receiver result for the exact path. Write “public DNS comparison incomplete” when the active nameserver or current account instruction is unknown. A DNS lookup alone does not prove that Mailchimp accepted the record or that a recipient aligned a message.

Scope fit / one Mailchimp path

When a scoped handoff helps

If one real domain or subdomain and one Mailchimp path still need interpretation, prioritization, and a client-ready handoff, request a Folderly Launch Audit scope. The fixed US$495 pilot is read-only advice for one domain or subdomain and one ESP/CRM path, with a 48-hour report window after the agreed start, payment, and complete intake; it includes up to five prioritized actions, a 45-minute handoff, and one recheck within seven days of the report. The authorized operator makes DNS and Mailchimp changes. There is no managed DNS, implementation, warming, reputation recovery, list repair, multidomain review, or inbox-placement guarantee.

Prepare an editable scope draft

Research note. Reviewed 28 September 2026 from first-party Mailchimp pages: Set up email domain authentication, Verify an Email Domain, and Mailchimp Transactional’s authentication and delivery documentation. Examples are placeholders, not customer evidence. Mailchimp’s account instructions control record names and values; its UI, plan availability, and documentation can change. The 48-hour statement is Mailchimp’s documented validation window for the cited setup flow, not a universal DNS propagation promise.