How do I verify multiple domains in Mailchimp to fix DMARC and DKIM issues?
Updated on 16 Oct 2026: We clarified Mailchimp's per-domain verification steps, DKIM checks, and how to preserve an existing DMARC policy.
Verify every domain that appears in the visible Mailchimp From address. If the Fresno store sends as one domain and the Bakersfield store sends as another, both domains need to be added, verified, and authenticated in the same Mailchimp account. One working domain does not cover every other domain in the account.
The fix is practical: add the second domain in Mailchimp, verify access through the email link or code, complete Mailchimp's automatic DNS connection or publish the records manually, then confirm the campaign From address uses the authenticated domain. For manual setup, copy the two DKIM CNAME records Mailchimp gives you for that exact domain, then check its DMARC TXT policy. Keep an existing valid DMARC record instead of adding a duplicate or replacing its enforcement settings. The domain after the @ sign is the domain that matters.
- Open the last campaign, inspect the From email, and write down the exact domain after the @ sign.
- Add that exact domain under Mailchimp's domain settings before sending another campaign from it.
- Publish the DKIM CNAME records in that domain's DNS zone and add a DMARC TXT record only if it needs one.
- Send a small live campaign to subscribed addresses you control and confirm dkim=pass and dmarc=pass in the received headers.
The direct fix in Mailchimp
Start in Mailchimp, not in DNS. Mailchimp must generate the records for the specific sending domain. The official Mailchimp setup guide describes verification first, followed by either an automatic DNS connection or manual authentication with two CNAME records for DKIM and one TXT record for DMARC. Verification proves access to an address on the domain. Authentication gives receiving systems a domain identity that can match the From address.
For each domain, open your profile, choose Account & billing (Account for Managers), then Domains. In Email Domains, select Add & Verify Domain and enter a working email address on that domain. Complete the verification email link or code, then select Start authentication beside that domain. These steps follow Mailchimp's verification instructions and its setup guide above.
For a two-location account, use a simple rule: every unique From domain gets its own row in Mailchimp and its own DNS work. The Fresno domain can stay as it is. The Bakersfield domain needs its own verification and authentication, even if both audiences live in one Mailchimp account and both websites share branding.
Do not reuse records blindly
Do not copy the Fresno DKIM CNAME values into the Bakersfield DNS zone unless Mailchimp displays those exact values for the Bakersfield domain. Mailchimp records are tied to the domain entry and its current authentication state. Publishing the wrong hostname or target can prevent receivers from finding the DKIM key for that domain.
Illustrative DNS pattern, use Mailchimp's exact selectorsdns
selector1._domainkey.example.com CNAME first-target-shown-by-mailchimp selector2._domainkey.example.com CNAME second-target-shown-by-mailchimp _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
The hostnames above are placeholders. Use the exact hosts and values Mailchimp shows for the domain you are authenticating. Many DNS providers automatically append the root domain, so entering a full hostname can create a duplicated name. If Mailchimp asks for a host like k2._domainkey, enter only that label when the DNS editor already shows the domain name beside the field.
Why DKIM domain matching fixes DMARC in Mailchimp
DMARC does not treat any SPF or DKIM pass as enough. At least one passing mechanism must match the domain in the visible From address. For DKIM, DMARC compares the signing domain with the From domain. For SPF, it compares the return-path domain with the From domain.
With the default adkim=r, DKIM domain matching is relaxed: the signing domain and From domain must share an organizational domain. With adkim=s, they must match exactly. For example, a signature using example.com and a From address at mail.example.com can match in relaxed mode, but not strict mode. The DMARC standard defines both modes.
For standard Mailchimp campaign authentication, follow the records shown in Mailchimp. Its current manual setup asks for two DKIM CNAME records and one DMARC TXT record. It does not ask you to add a Mailchimp include to the domain's SPF record. Adding an SPF include to your From domain does not change Mailchimp's return-path domain or fix that domain mismatch. Do not publish a second SPF record, because a domain must have only one SPF policy.
Check DKIM and DMARC in message headers
In a received campaign's Authentication-Results header, look for dkim=pass and dmarc=pass. Compare the signing domain shown as header.d or in the DKIM-Signature d= tag with the visible From domain, using the policy's matching mode. SPF can pass for a Mailchimp-controlled return path without matching your From domain. A passing DKIM signature with the required domain match gives DMARC a passing result.
Illustrative received-message headerstext
From: Fresno Store <news@example.com> Authentication-Results: receiver.example; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
What Mailchimp checks for each domain
Mailchimp treats verification and authentication as separate checks. A domain can be verified because someone used an email link or code, but still fail DKIM because the DNS records are missing or wrong. A domain can also have a DMARC record, but still fail a campaign check because neither DKIM nor SPF matches the domain visible to recipients.
|
|
|
|---|---|---|
Domain | Mailchimp | Added and verified |
DKIM | DNS | Two CNAMEs valid |
DMARC | DNS | One valid applicable DMARC policy |
Campaign | Builder and headers | DKIM and DMARC pass; signing domain matches |
Compact checklist for each Mailchimp sending domain.
A sending subdomain needs separate verification in Mailchimp. For example, mail.example.com is a different verification entry from example.com when the From address is sender@mail.example.com. Authenticate the exact domain or subdomain that Mailchimp lists for that sender. Several mailboxes on one verified domain do not each need a separate domain entry. Public domains such as gmail.com and yahoo.com cannot be verified or authenticated by your business; use a domain you control.
In Mailchimp Transactional, the same idea applies through sending domains. The Transactional docs state that sending domains need ownership verification, DKIM records, and a valid DMARC policy before mail can be sent from them. Complete setup separately in Mailchimp Transactional using its own DKIM records and Test DNS Settings. Authenticating a domain for standard campaigns does not complete the Transactional setup.
Mailchimp Domains page with one authenticated domain and another awaiting DKIM and DMARC validation.
If one domain is authenticated and the other is failing, fix the failing domain rather than changing the working one. Change the From address only after its domain has passed authentication, because an early change can create another mismatch to debug.
How DMARC fits into the fix
DMARC is the policy layer that tells receivers what to do when a message fails domain-matched authentication for the visible From domain. In this Mailchimp case, DMARC also provides aggregate reporting that shows whether each store domain passes with Mailchimp and whether another approved sender still needs attention. Gmail and Yahoo require bulk senders to use SPF and DKIM, publish a DMARC policy of p=none or stricter, and pass DMARC through a matching authenticated domain.
Gmail's bulk-sender definition is close to 5,000 or more messages to personal Gmail accounts in 24 hours, counting the same primary domain and its subdomains together. Yahoo's bulk-sender definition has no published numeric threshold. Splitting store mail across subdomains does not reset Gmail's count.
Keep the first DMARC policy conservative while fixing senders, unless the domain already has a working enforcement policy. A DMARC monitoring workflow in Suped's product groups aggregate reports by sending source and domain. That makes it practical to compare the Fresno and Bakersfield domains, isolate a failed domain match, and track the DNS change without combining both stores into one warning.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The useful view shows the sending source, affected domain, failed check, and next DNS step. For a Mailchimp account with multiple store domains, Suped helps separate a Mailchimp DKIM issue from a broader DMARC warning unrelated to the current campaign.
Example monitoring policy for a domain without DMARCdns
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
The example is for a domain with no DMARC record. Replace dmarc@example.com with a mailbox you monitor or the reporting address Suped provides for that domain. Do not publish it beside an existing DMARC record or replace an existing enforcement policy with p=none. A monitoring policy does not repair DKIM or guarantee inbox delivery. After Mailchimp passes and reports show no important legitimate source failing, move the policy through quarantine and reject in controlled stages. Use a DMARC checker to confirm the single published record is syntactically valid before waiting on report data.
Can one domain's problems affect another?
Usually, no. A failing high-level check on the Bakersfield domain does not automatically damage the Fresno domain's Mailchimp campaigns. Receivers evaluate the message they receive, including the visible From domain, DKIM signing domain, return path, sending IP, prior recipient engagement, complaint signals, and list quality.
There is still shared account risk. If both stores use the same Mailchimp account and one list causes high bounces or complaints, Mailchimp can throttle or restrict the account. If both stores send through the same shared IP pool, an IP blocklist (blacklist) issue can affect campaigns for both domains. That is different from a missing DKIM record on one domain affecting DNS authentication for another domain.
Separate DNS failures from reputation issues
Investigate a DMARC or DKIM failure using DNS and message headers. Missing or wrong records cause setup failures; message changes in transit can also break DKIM when DNS is correct. Low engagement, complaints, hard bounces, and blacklist or blocklist listings are reputation signals. Fix authentication first, then judge delivery with campaign results and mailbox placement tests.
One domain or separate store domains
The cleanest setup depends on how the business wants recipients to see each store. If both locations use one brand and one website, a single authenticated domain is simpler. If each location has its own domain, website, signage, and local inbox, separate authenticated domains are fine. The important part is consistency between the visible From domain and the domain Mailchimp authenticates.
One shared store domain
Use this when both locations are part of one brand and recipients expect a single sender.
- One DNS zone and fewer sender settings simplify maintenance.
- Local teams can lose clarity if the mailbox does not match the store.
- Authenticate one domain and keep all campaign From addresses under it.
Separate store domains
Use this when each location has its own domain and recipients know the local sender.
- Separate domains support local recognition and location-specific reporting.
- Every domain needs ongoing DNS and DMARC maintenance.
- Authenticate each domain in Mailchimp before using it in campaigns.
If more senders use the same domain, document ownership before editing DNS. The same principles apply to a broader multiple sender setup. If the immediate question is whether every Mailchimp sender needs authentication, the short answer is yes for every domain that appears in the From address, with more detail in Mailchimp sender rules.
A practical verification checklist
Before changing records, confirm which DNS provider hosts each domain. Store websites can redirect, but DNS does not follow the website redirect. If bakersfield.example redirects to fresno.example, publish its email records in the authoritative DNS zone for bakersfield.example. Managing both domains in one DNS account does not merge their zones. Check each domain's authoritative nameservers before choosing where to edit records.
Then run a domain-level check for both domains. A domain health check is useful here because it checks DMARC, SPF, DKIM, and related DNS signals in one pass. Use the DKIM selectors shown in Mailchimp when checking its CNAME records; a general domain check does not prove every selector is configured. The check does not replace Mailchimp's own verification status.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
After the DNS check passes, return to Mailchimp and watch the domain status. DNS propagation and Mailchimp's validation can take up to 48 hours, although records often update within minutes. If validation fails, use Resolve or Restart authentication and inspect the exact published record name. Check for a duplicated domain in the hostname, such as k2._domainkey.example.com.example.com. If the records are correct but authentication still fails after 48 hours, ask the DNS provider to confirm public resolution and give Mailchimp support the failing domain and exact record names.
- List every Mailchimp From email used by each audience, automation, and template.
- Group those addresses by exact domain or subdomain so you know which entries need authentication.
- Verify access using a working mailbox on each domain and complete the link or code within seven days. If several verification emails arrive, use the newest one.
- Use Mailchimp's automatic connection or add its two DKIM CNAME records manually, preserving any existing valid DMARC policy.
- Send a small live campaign to subscribed addresses you control and inspect Authentication-Results for dkim=pass and dmarc=pass.
If the domain has no DMARC record, create one record with aggregate reporting. A record generator reduces syntax mistakes when setting up several domains. If the domain already has valid DMARC, keep it and edit only the settings that need to change. If an authenticated CNAME changes later, disable authentication in Mailchimp and re-authenticate after the DNS change.
Views from the trenches
Best practices
Verify the exact visible From domain before changing DNS or blaming the Mailchimp account.
Keep each store domain authenticated in Mailchimp before using it in a campaign From line.
Use DMARC reports to confirm real campaign traffic before moving policy beyond none.
Common pitfalls
Treating one authenticated domain as account-wide coverage for every other store domain.
Pasting DKIM hostnames into DNS with the domain duplicated by the DNS provider at save time.
Confusing broad health-check warnings with the specific Mailchimp authentication failure.
Expert tips
Test each domain with one campaign and inspect the DKIM domain in the message headers.
Set the local store mailbox as a sender only after domain verification has succeeded.
Monitor domain and IP reputation separately when delivery differs between store lists.
Marketer view
Marketer from Email Geeks says both domains should be added and verified in Mailchimp because one DKIM pass only proves that one domain is configured.
2024-10-10 - Email Geeks
Marketer view
Marketer from Email Geeks says a redirected website does not change the DNS work; the sending domain still needs its own Mailchimp records.
2024-10-10 - Email Geeks
Monitor each domain after setup
For ongoing operations, keep both domains in Suped's DMARC reporting platform and review Mailchimp traffic separately for each one. Retest message headers after a From address or DNS change, then use incoming reports to confirm the result across real campaigns.
Aggregate reports normally arrive daily, as described in the aggregate reporting standard. Allow for reporting delay when checking a repair; a DNS change is not an immediate report event.
Frequently asked questions
Yes, for every custom domain used in a Mailchimp From address. A sending subdomain needs separate verification, but several mailboxes on the same domain do not each need a domain entry. You cannot verify or authenticate public domains such as gmail.com. One verified domain does not authenticate other store domains in the same account.
Yes. Multiple domains can sit in one Mailchimp account, but each domain still needs its own verification and authentication before it is used for campaigns.
No. A website redirect is separate from email authentication. Mailchimp checks DNS records for the sending domain, even if that domain redirects visitors to another website.
Follow the records shown in your Mailchimp authentication flow. The current manual flow asks for two DKIM CNAME records and a valid DMARC TXT policy, not a Mailchimp SPF include. Adding an include to your From domain does not change Mailchimp's return path or fix a domain mismatch. Never publish a second SPF record. Confirm DKIM and DMARC pass on a received campaign.
Use p=none while identifying legitimate senders if the domain has no policy. Do not weaken an existing enforcement policy automatically. Move toward reject only after reports show approved traffic passes with a matching authentication domain.
The usual causes are a validation delay of up to 48 hours, duplicated hostnames, records added to the wrong DNS zone, or values copied from another domain. Use Resolve or Restart authentication after checking the exact record names.
