Install WP Mail SMTP and pick its built-in Mandrill mailer. That is the answer most WordPress sites on Mandrill are looking for, and the rest of this guide is how to do it without the two mistakes that eat everybody’s first afternoon on the service. The Mandrill dashboard is now called the Mailchimp Transactional dashboard; the SMTP host is still smtp.mandrillapp.com and the API key is still called a Mandrill key, so a reader who typed Mandrill into Google is in the right place.
For the case for or against Mandrill itself (the mandatory Mailchimp Standard subscription, the $40 minimum, the volume where the block pricing starts making sense), start at the Mailchimp Transactional Email review. This page is the setup walk-through. It assumes the decision to use Mandrill has already been made.
Which plugin to install
Three plugins meet the WordPress-to-Mandrill job, and one is the default for most sites.
WP Mail SMTP with its Mandrill mailer is the recommended path. WP Mail SMTP ships a dedicated Mandrill option in its mailer picker that calls the Mandrill API directly rather than going over SMTP. Setup is one API key and a from-address; there is no host, port, or STARTTLS setting to get wrong. WP Mail SMTP itself is the most-installed WordPress mailer, which means the setup screens, the error messages, and the debug log format are the ones a WordPress site’s next operator is most likely to recognise on the day something breaks.
FluentSMTP does not have a dedicated Mandrill mailer, but its generic-SMTP mode reaches Mandrill on smtp.mandrillapp.com with any Mandrill API key as the password. FluentSMTP is free and open-source with no upsell path, and the routing rules (send from one address through Mandrill, another through a mailbox) are cleaner than WP Mail SMTP’s. Pick FluentSMTP over WP Mail SMTP when the site runs multiple senders and needs per-address routing.
Send Emails with Mandrill is the Mandrill-only plugin, a community-maintained fork by Miller Media of the original wpMandrill, currently at v1.6.2 (February 2026), tested against WordPress 6.9. It offers three things the generic paths do not: a mandrill_payload filter for per-send payload mutation, automatic per-message tagging by the WordPress hook that generated the send (order confirmations, password resets, and contact-form messages arrive tagged in the Mandrill activity log), and a static wpMandrill::mail() function that other plugins can invoke directly without going through wp_mail(). Pick it when at least one of those three features is doing real work for the site; otherwise the generic paths are less code, less risk, and less to maintain.
For the plugin-by-plugin comparison in the general case (not Mandrill-specific), see best WordPress SMTP plugins.
Before touching WordPress
Mandrill will not accept a send from a domain it does not recognise, and the reasons it will not accept it are the ones most first-day setups get wrong. Two things sit upstream of the WordPress install: an API key, and DNS records at the sending domain. Get both right before installing a mailer plugin.
Generate a Mandrill (Transactional) API key
Log in to Mailchimp, then open the Transactional dashboard from Automations > Transactional Email > Launch App, or from the app switcher in the top-left where it is offered. Mandrill (Transactional) is a separate application inside the same Mailchimp account, with its own settings and its own API keys. The main Mailchimp marketing API keys under Account > Extras > API keys will not authenticate SMTP; the Transactional key set is a different list, in a different dashboard, gated behind the Transactional add-on being active on the billing plan.
In the Transactional dashboard, Settings > SMTP & API Info > New API Key. Give the key a description that identifies the WordPress site. Copy the generated key immediately. Mandrill shows the key value once at creation and never again; a key with no local copy has to be regenerated.
Verify the sending domain and publish DKIM and SPF
Still in the Transactional dashboard, Settings > Domains > Sending Domains > Add a sending domain. Enter the domain the WordPress site sends From:, meaning example.com, not mail.example.com. Mandrill returns the DKIM records to publish (currently issued as two CNAME records under mandrill._domainkey.<your-domain> for new domains; older domains added under the previous UI carry a single TXT record at the same name and continue to work). Copy the record names and values verbatim from the Mandrill dashboard; do not construct them by hand.
The SPF record adds include:spf.mandrillapp.com to the domain’s existing SPF record at the apex. If the domain already has an SPF record covering Google Workspace or another sender, edit it to add the include; do not create a second SPF record at the apex, because a domain with two SPF records at the same name is a permanent SPF error under RFC 7208 regardless of what the records say. If the domain has no SPF record, publish v=spf1 include:spf.mandrillapp.com -all. The SPF merger folds include:spf.mandrillapp.com into an existing string and counts the DNS lookups against RFC 7208’s ten-lookup ceiling before you publish.
Return to the Mandrill dashboard and click Test DNS Settings on the sending domain. Verification is typically minutes when propagation is fast and up to an hour at the outside on slow DNS hosts. Both DKIM and SPF must show verified before Mandrill will send from that domain in production. The demo-sending allowance (500 messages to a verified address for new accounts) works without verification, which is a trap: a verify-passed test send does not mean production sends will be accepted.
DMARC is not Mandrill-specific but is required for domains sending more than 5,000 messages per day to Gmail or Yahoo under their 2024 bulk-sender rules. Publish _dmarc.example.com as TXT v=DMARC1; p=none; rua=mailto:[email protected] as a safe starting point; tighten to p=quarantine or p=reject once reports show no legitimate mail failing alignment. The bulk sender authentication checklist has the full order of operations.
Once DKIM and SPF verify in the Mandrill dashboard, the DNS auth checker reads how mandrill._domainkey, the apex SPF, and _dmarc look from a receiver’s perspective, which catches nameserver caches and mistyped selectors before real traffic does.
Installing and configuring WP Mail SMTP with Mandrill
The plugin install is standard: Plugins > Add New > search WP Mail SMTP > Install > Activate. On first activation, WP Mail SMTP launches its setup wizard; skip it (click Go Back to the Dashboard) and configure manually so the values below are the ones you set rather than the ones the wizard picks.
In the WP Mail SMTP settings screen, the General tab holds the sender identity. Set From Email to an address at the domain verified with Mandrill and check Force From Email, which stops plugins that hardcode their own sender (WooCommerce order emails, some form plugins) from overriding it. A From: address at an unverified domain is the single most common first-day rejection. Set From Name to the site or brand name and check Force From Name for the same reason. Leave Return Path on: Return-Path controls where bounce notifications land, and leaving it on lets Mandrill attribute bounces to the right send instead of dropping them into the WordPress admin inbox. Then set Mailer to Mandrill.
WP Mail SMTP reveals the Mandrill fields once the mailer is selected. Paste the Transactional API key generated earlier into API Key. Leave Sub Account blank unless a Mandrill subaccount was set up in the Transactional dashboard; subaccounts are a Mandrill feature for isolating sending reputation between logical senders (multiple client sites on one Mandrill account, for example), and most WordPress installs do not use them.
Save. The plugin runs a validate-connection check against the Mandrill API and shows Valid or an error. A Valid result confirms the API key is correct and the account is active; it does not confirm that the DKIM and SPF are set up correctly for the from-address, because the validation call does not attempt an actual send.
Under Email Test in WP Mail SMTP, send a test message to an address you can read. Check the HTML toggle if the site’s real mail is HTML. A success message from the plugin means the API accepted the send; verify the message actually arrived at the destination before treating the setup as done, and open the message headers to confirm Authentication-Results shows dkim=pass for mandrill._domainkey.<your-domain> and spf=pass for the sending IP. If either fails, the DNS records did not propagate or were entered incorrectly at the DNS host; return to the Mandrill dashboard’s sending domain page and re-check.
For FluentSMTP with generic SMTP, the equivalent settings are Connection Type SMTP, Host smtp.mandrillapp.com, Port 587, Encryption STARTTLS, Auto TLS on, Authentication PLAIN or LOGIN, Username your Mailchimp account email, Password the Transactional API key. For Send Emails with Mandrill, the setup is the API key alone under Settings > Mandrill.
Sending the first test and reading the failure
The two error patterns worth naming.
Domain not verified or unsigned in Mandrill’s activity log. The from-address is at a domain Mandrill has not verified, or DKIM has not propagated. Check the Mandrill dashboard’s sending domain page shows both DKIM and SPF verified for the exact domain in the from-address. [email protected] is a different domain to [email protected] under DKIM alignment rules; verify the domain the site actually sends from, not the domain the site is hosted at.
Invalid API key. The key pasted into the plugin belongs to the Mailchimp marketing API, not the Transactional API. The two lists are in different dashboards. Regenerate a key from Transactional > Settings > SMTP & API Info and paste that one.
The Mandrill Activity page shows every send in near-real-time with its delivery status and any bounce reason. Point it at the last hour and the test sends appear near the top; a message that shows Sent in the activity log but has not arrived at the destination is a receiver-side delivery decision, not a Mandrill problem, and the message headers (Authentication-Results, Received-SPF) are where the reason lives.
Mandrill-specific things to know
The 30-day activity log is the audit window. Mandrill retains message-level activity for 30 days; older sends drop out of the dashboard. Sites that need longer retention should mirror sends to a WordPress email log (Check & Log Email, Log Emails, or WP Mail SMTP’s own log tier) in parallel, because the WordPress log will still have the send after Mandrill’s window closes.
Dedicated IP is a paid add-on and needs volume to be worth having. Mandrill’s shared IPs handle low-volume WordPress traffic without issue; a dedicated IP at $29.95 per month is worth buying only when the sending volume clears roughly 50,000 messages per month, below which a dedicated IP has too little traffic to build its own reputation and can underperform the shared pool. The transactional email overview has the volume argument in more detail.
Blocks do not roll over. Mandrill’s billing unit is 25,000-message blocks at $20 each; a block bought in one calendar month and not consumed does not carry into the next. Sites with predictable traffic buy exactly what they need; sites with spiky traffic overbuy defensively and eat the unused capacity.
Subaccounts change bounce isolation, not billing. A Mandrill subaccount gives a logical sender its own reputation pool and its own activity slice, without splitting the billing account. This matters for agencies running multiple client sites on one Mandrill account; a bad-reputation send from client A no longer contaminates client B’s deliverability. Configure subaccounts in the Transactional dashboard first, then paste the subaccount identifier into the plugin’s Sub Account field.
Webhooks land where you tell them to. Mandrill can POST bounce, complaint, open, and click events to a URL; the WordPress site does not receive these by default because the URL has to be configured in the Transactional dashboard and pointed at an endpoint (a WordPress plugin, a webhook receiver, a serverless function) that handles them. Most WordPress sites do not need this; a site that runs its own suppression list or its own analytics pipeline does.
When another provider fits better
If the WordPress site sends fewer than 100,000 messages per month, is not already running Mailchimp for marketing, and does not need Mandrill’s per-message tagging or template features, the $40 minimum ($20 Standard plan plus one $20 block) buys capacity that will sit unused. Postmark is the better default at that volume ($15 for 10,000 messages, no platform subscription, cleaner dashboard, longer log retention). SMTP2GO covers the low-volume case with 1,000 messages a month free indefinitely. Brevo covers the day-rate case with 300 messages per day free. The transactional email overview and the SMTP cost calculator run the crossover math against a site’s actual monthly send volume.
Related
When you are ready to go further:
- Mailchimp Transactional Email review covers the case for and against Mandrill, pricing crossovers, and DNS reference.
- Send Emails with Mandrill review is the Mandrill-only plugin write-up: its three unique features and when they earn the install.
- WP Mail SMTP review is the recommended mailer plugin for most Mandrill setups.
- Best WordPress SMTP plugins is the general-purpose plugin comparison, not Mandrill-specific.
- WordPress email setup guide places Mandrill inside the wider WordPress email stack.