Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Identify Mandrill as Mailchimp Transactional
Mandrill is the former name of Mailchimp Transactional. Mailchimp distinguishes this event-driven API or SMTP service from its Marketing product. A newsletter campaign authenticated in Mailchimp Marketing is therefore not evidence that an application's Mandrill route is configured correctly. This guide covers the Transactional account that actually sends the application message. Confirm that account before opening DNS. Mailchimp product index and Transactional versus Marketing email.
Choose one representative business event, such as a synthetic purchase confirmation, and identify the application owner, mail administrator and DNS owner. Record the sending account, application environment, From domain, template identifier and transport. If staging and production use different accounts, keep separate acceptance records. A test made from a developer's personal account cannot approve the production dependency. Use harmless content and controlled recipients; do not place real reset links, order details or credentials in a troubleshooting document.
Capture the configuration before changing it
Build a small route inventory before publication. For each active integration, retain its From address, account reference, template, configured return-path override and whether it uses global defaults. Record existing DNS at the proposed owners and the current DMARC policy. This inventory is an original change-control recommendation, not an account inspection performed for this article.
Ask the application owner to identify any wrapper library, middleware or rules that can replace sender fields. Treat a change of sending domain as an application change as well as a DNS change. Establish a maintenance window appropriate to the business event: delaying a receipt and delaying an access email can have very different consequences. Name a person who can pause only the affected workflow if the test fails, and preserve its last approved configuration.
Use current DKIM instructions and resolve conflicting examples
In Transactional Settings > Domains, add the intended sending domain and open View DKIM settings. The detailed documentation currently specifies two CNAMEs: mte1._domainkey.<domain> to dkim1.mandrillapp.com, and mte2._domainkey.<domain> to dkim2.mandrillapp.com. Replace the domain placeholder and verify the account's instructions before publication. Run Test DNS Settings afterward. Authentication and Delivery.
There is a documentation inconsistency worth catching: the first-email tutorial contains both a two-CNAME instruction and an older mandrill._domainkey TXT paragraph. Do not combine them into an invented migration recipe or remove an existing selector solely because the tutorial differs. Use the account-displayed instructions, supported by the detailed authentication page, and obtain support confirmation if they disagree. First-email tutorial.
Check the final fully qualified DNS owner, not just the text entered in the DNS console. A host field may append the zone automatically. Before adding a CNAME, check for an existing record at that same owner and investigate ownership instead of deleting it blindly. Save the intended and published values in the change record, with the resolver and time used for verification.
Complete ownership and DMARC checks separately
The provider requires verified ownership, valid DKIM and a DMARC policy. Ownership can use the account's verification TXT value or an email confirmation. The minimum documented DMARC policy is p=none, but that is an onboarding minimum, not a reason to weaken an established policy. Transactional authentication requirements.
If the integration provisions domains through the API, the add-domain response exposes verify_txt_key and separate configuration fields including dkim, dkim2, dmarc and verified_at. Treat these as provider configuration evidence; none is a substitute for a received message. Do not insert example API keys, response values or verification tokens from documentation into your account. Keep credentials out of retained screenshots and logs. Add a sender domain API.
DMARC policy discovery and DMARC message success are different checks. A domain can publish a valid policy while a particular message fails alignment. At acceptance, compare the receiver's authenticated domains with the visible From domain under the actual alignment modes. Do not label a message authenticated merely because a dashboard accepts the policy. DMARC identifier alignment.
Decide whether the envelope identity needs customization
The default return-path uses mandrillapp.com. A custom return-path uses a customer subdomain CNAME to mandrillapp.com, registered and tested under Tracking & Return Path Domains. Apply it through Sending Defaults or a supported per-message override. The provider continues handling bounces. Custom return-path domains.
Select an unused subdomain, document which account owns it, and make its intended scope explicit. Do not confuse this with the domain used in tracked links. A branded click URL proves neither SPF nor DKIM alignment. Test a message with the real application's effective configuration rather than assuming that an account default overrides every request.
SPF evaluates the SMTP envelope identity, whereas DKIM uses the signature's d= domain and s= selector. An SPF include at a different domain does not change the envelope identity. A subdomain may satisfy relaxed alignment without meeting strict equality; an aligned passing DKIM signature can provide the DMARC pass independently. Examine both methods without promising that every message will pass. SPF, DKIM and DMARC.
Separate submission failures from delivery failures
For an SMTP connection error, first verify the host, supported connection settings and credential type. Mailchimp documents smtp.mandrillapp.com and a Transactional API key for the SMTP password, not the web-interface password. Require a correctly validated encrypted SMTP connection before sending credentials or message content. Investigate transport logs without exposing the secret. DNS authentication repairs will not fix a blocked outbound port or wrong SMTP credential. SMTP integration troubleshooting.
If the application reached Transactional, inspect API Logs and the returned status. The provider records authenticated SMTP submissions as API calls too. A queued message may reflect quota, account state or asynchronous processing rather than bad DNS. Record the actual queued_reason before changing records, and avoid repeatedly triggering the same business event. A repeated purchase confirmation is not a harmless diagnostic if it confuses a customer. Outbound email and API Logs.
Use per-message activity to connect the application event to delivery evidence. Content and detail retention are limited, so capture the needed record promptly under your retention policy. Engagement metrics are not authentication results: an open or click does not establish aligned signing. Activity and Reports.
Complete the original received-message identity table
This acceptance plan has not been executed. Send one controlled message through each materially different production-equivalent route. Each original table row must contain application environment, account, template or event, timestamp, message identifier, visible From, Return-Path, trusted receiver SPF domain and result, every DKIM d=/s= and result, DMARC result, applicable alignment mode and restricted original-message location. Record expectations separately from observations.
If submission succeeds but alignment fails, compare the actual sender and envelope with the approved mapping before publishing another DNS change. Restore the last approved application setting when safe, retain working signing records during investigation and pause the affected workflow if necessary. Do not bypass authentication checks or lower the whole domain's enforcement as an emergency shortcut. Retest after the smallest verified correction.
No tenant settings, live DNS or received message were tested for this manuscript. The source conflict requires account-specific reconciliation, and the original identity table, exact-route confirmation and human SME review remain open. This is an unpublished implementation candidate, not a claim that any Mandrill installation has passed authentication.