To authenticate Mailchimp Transactional, formerly Mandrill, verify your sending domain, publish the current two DKIM CNAME records and maintain a valid DMARC policy. For SPF alignment, inspect the actual envelope sender and configure a custom return-path domain when needed. An SPF include at your visible From domain does not, by itself, align Mandrill's default return path. Transactional authentication requirements
This guide covers application messages sent through the Transactional API or Mandrill SMTP service, such as password resets and order confirmations. It is separate from Mailchimp Marketing domain authentication. Completing the Marketing workflow does not establish that your application's Transactional route is ready.
Establish the account and sending-domain scope
Mailchimp's current Fundamentals documentation distinguishes the demo, available with any account level, from full Transactional access, which requires a Standard or Premium account. Confirm the actual product and account your integration uses before changing DNS. Transactional account prerequisites
You need access to the Transactional application, control of your sending domain, its authoritative DNS and an inbox for controlled receipt tests. Identify every application, From domain, account and SMTP/API path. Keep API credentials out of the DNS worksheet: they authorize application access and are not public authentication records.
Record the current SPF and DMARC policies, both DKIM owners, any legacy Mandrill selector, and an existing custom return-path configuration. Preserve previous values so a failed change can be reversed without guessing. Domain aliases or customer domains need their own verified scope; do not assume an account-wide green status covers a different From domain.
The public documentation reviewed here does not prescribe a separate regional DKIM target map. Follow the current domain settings rather than inventing regional hostnames. Shared versus dedicated sending infrastructure does not remove the need for domain authentication.
Add and verify the sending domain
In the Transactional app, open Settings → Domains, add the domain used in your From address, and inspect its status. Domain ownership verification and DKIM validation are separate checks. Mailchimp's first-email guide walks through both rather than treating possession of an API key as ownership proof. Add and verify a Transactional domain
Use the current account's ownership method. The authentication documentation supports a unique TXT verification value displayed under the domain's details, or verification through an email address at the domain. Copy the issued value exactly; never reuse a token from a tutorial. Complete the check in the same account your application uses. Ownership verification
Before emailing a verification link, confirm the mailbox can receive messages. Before using TXT verification, confirm the correct zone and owner. Neither method authorizes replacing your mailbox provider's MX records. Inbound mail processing is a separate feature, not a prerequisite to moving all organizational mail to Mandrill.
Publish the current DKIM CNAME records
Mailchimp's authentication update specifies this pair. Replace YOUR_DOMAIN with the exact sending domain and compare the result with View DKIM settings in your account:
- CNAME
mte1._domainkey.YOUR_DOMAIN→dkim1.mandrillapp.com - CNAME
mte2._domainkey.YOUR_DOMAIN→dkim2.mandrillapp.com
These are current documented service targets, not invented tenant keys. Both records belong to the current workflow. The March 2024 requirements introduced the paired CNAME setup and DMARC requirement. Mailchimp authentication change notice
Use Test DNS Settings after publication. The first-email guide currently includes both newer two-CNAME wording and an older single-TXT example. Resolve that conflict using the dedicated Authentication and Delivery guide, the explicit change notice and the account's current settings, not the stale mandrill._domainkey recipe. First-email instructions and current DKIM specification
Check whether your DNS host appends the zone name automatically. Preserve _domainkey exactly. Do not put a CNAME alongside conflicting TXT or other data at the same owner, and keep these names unproxied where the host offers HTTP proxying. Preserve old selectors until their remaining use has been checked; adding the current pair does not justify deleting every record containing “mandrill.”
For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names. Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, 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 Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.
Understand SPF before adding an include
SPF evaluates the SMTP MAIL FROM domain, commonly visible in Return-Path after delivery. DMARC compares that authenticated identity with the visible From domain. Editing an SPF policy at a hostname that the message never uses for MAIL FROM cannot change this comparison. SPF identity rules
Mandrill's default return path uses mandrillapp.com. For your custom From domain, default-provider SPF authentication and customer-domain SPF alignment are therefore different questions. An otherwise valid provider SPF pass is not automatically an aligned pass. This is an alignment consequence of the documented return path, not a claim that all default messages fail SPF. Default return-path behavior
Do not add a blanket root-domain include merely because an older Mandrill article lists one. First confirm your actual envelope identity and current account instructions. If a separate, supported workflow requires an SPF edit, merge it into the existing single v=spf1 policy, retain legitimate senders and evaluate nested includes against the ten DNS-lookup-causing-term limit. Do not publish duplicate SPF policies or use +all to conceal a failure.
If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.
Configure a custom return path when alignment needs it
Choose an unused subdomain you control, publish its CNAME to mandrillapp.com, then add and test it under Settings → Tracking & Return Path Domains. Use a subdomain, not the domain root. Apply it in Sending Defaults or select it per message. One return-path domain cannot normally be assigned to multiple Transactional accounts; ask support before designing that shared arrangement. Custom return-path setup
For API sending, the per-message field is return_path_domain. This means one global default need not represent every application's actual choice. Record overrides in the route worksheet and inspect the delivered outcome. Per-message return-path selection
For SMTP, the documented integration supports custom headers, including the return-path selection mechanism described in the authentication guide. Confirm your plugin transmits the intended X-MC-ReturnPathDomain header rather than assuming a UI field changes all messages. Authentication credentials and domain authentication are separate layers. SMTP integration
Never add a separate SPF TXT record on the custom return-path CNAME owner. Follow the CNAME chain when inspecting its SPF data. A return-path subdomain may align under relaxed DMARC but not under strict aspf=s when From uses the parent domain. Test the actual identities before deciding whether this optional configuration satisfies your policy.
Preserve DMARC without weakening existing protection
Mailchimp requires a valid DMARC policy for Transactional sending. That requirement does not mean you should replace an existing quarantine or reject policy with its minimal monitoring example. Inspect any record on the From domain and any applicable inherited parent policy first. Avoid creating a weaker child policy that overrides inherited protection.
DMARC passes when at least one passing SPF or DKIM result aligns with From. Relaxed alignment permits a shared organizational domain; strict alignment requires an exact domain match. Thus aligned DKIM can pass DMARC when default-return-path SPF is unaligned. Current DMARC standard
For first-time setup, if no existing or inherited policy applies and monitoring is approved, create one TXT record at _dmarc.YOUR_FROM_DOMAIN. Replace YOUR_FROM_DOMAIN with the exact visible From domain. In a DNS interface that appends the zone, enter only the required relative name; inspect the final owner to avoid duplicating the domain. A minimal monitoring value is v=DMARC1; p=none. This requests no DMARC-specific enforcement and does not itself request reports or guarantee delivery. Where a policy already exists, review that policy instead of adding another or weakening it. Return to Sending Domains → Test DNS Settings and confirm that DMARC is valid. Mailchimp DMARC setup
For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.
For monitoring reports, append rua=mailto: followed by the real, approved reporting address, separated from the existing tags by a semicolon. Do not publish a placeholder address. Confirm that mailbox or report service is ready, preserve existing reporting destinations, and complete the required DNS authorization for an external report destination before expecting reports. External destination authorization
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.
Inventory other senders before enforcement. RFC 9989 replaced RFC 7489 and removed pct; do not build a new staged rollout around that obsolete percentage tag.
Validate public DNS and a delivered application message
Replace uppercase placeholders in these read-only lookup patterns:
dig +short CNAME mte1._domainkey.YOUR_DOMAINdig +short CNAME mte2._domainkey.YOUR_DOMAINdig +short TXT mte1._domainkey.YOUR_DOMAINdig +short TXT mte2._domainkey.YOUR_DOMAINdig +short CNAME CUSTOM_RETURN_PATHdig +short TXT CUSTOM_RETURN_PATHdig +short TXT _dmarc.YOUR_DOMAIN
Expect the paired CNAME targets documented above and retrievable public-key data through their alias chains. Where a custom return path is configured, verify its target and SPF resolution. Compare public resolver answers with authoritative DNS when they disagree. DNS verification does not prove a message used the intended signer.
Next, send an authorized, non-sensitive test through the real application to an inbox you control. Test-mode messages are not delivery tests: Transactional test API keys do not send actual mail. A successful simulated event cannot supply recipient headers. Test-mode behavior
Inspect the received message's trusted Authentication-Results. Record spf with smtp.mailfrom, dkim with header.d, and dmarc with header.from. The signature's s= should identify a published selector, and its d= should align as required. Check the visible From itself, not just Reply-To. Repeat for SMTP/API paths, customer domains and per-message overrides that differ.
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust. For this branded-DKIM deployment, require the intended provider signature itself to have trusted dkim=pass and a d= domain aligned with the intended unchanged visible From under effective adkim, plus the trusted receiver’s dmarc=pass for that From. A DMARC pass through SPF alone does not complete the DKIM task. DMARC alignment. Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.
Keep a redacted header sample, lookup results, send time, application route and provider message identifier. A dashboard acceptance event is not proof of inbox placement. Provider activity and recipient evidence answer different questions. Activity and reports
Troubleshoot Mandrill-specific failures
Rejected as unsigned: inspect ownership, DKIM and DMARC status for the exact From domain in the sending account. Do not rotate API keys to repair missing domain records.
Only the legacy TXT selector exists: compare current account settings with the two-CNAME requirements. Add the supported current configuration and validate a new message before retiring legacy data.
SPF passes but DMARC fails: compare MAIL FROM with From, then inspect DKIM. A root SPF edit does not repair a provider-owned envelope identity. Check whether the application overrides a custom return-path default.
One customer domain works and another fails: inspect each domain's ownership and DKIM records. A common account default may not align with every customer's From domain; review per-message selection without sharing one return-path name across accounts accidentally.
SMTP login fails: obtain the credentials from SMTP & API Info. Mailchimp documents smtp.mandrillapp.com and an active API key as the SMTP password. Use encrypted transport and never paste credentials into DNS or support screenshots. SMTP credentials
Completion and verification limits
Complete the job only after domain status, public DNS and recipient headers agree for the application paths you actually use. Review aggregate reports for missed senders before strengthening policy. Keep rollback records and retire obsolete DNS deliberately.
No customer account, DNS deployment, SMTP/API submission or delivered message was tested. This review does not establish live page behavior, indexing, rankings or inbox placement.