Resend is a newer transactional email provider built for developers, and it has the shortest setup of any option in this category. That is genuinely its main advantage — there is no OAuth application to register, no region to choose, and no sandbox to escape.
It is a good fit for a WordPress site that wants reliable transactional delivery without an afternoon of configuration.
Before you start
One decision matters more than the rest: verify a domain, not just an address.
Resend lets you send from a verified domain. If you skip domain verification and try to send from an address on a domain you have not verified, sending fails. More importantly, domain verification is what publishes the DKIM records that make your mail pass DMARC — so it is not a formality you can defer.
You will need access to your domain’s DNS. Specifically, to whatever service your nameservers point to, which is often not your registrar.
Setting it up
1. Add and verify your domain
In the Resend dashboard, add your domain. Resend gives you DNS records to publish — a DKIM record and an SPF-related record.
Publish them at the DNS host your nameservers point to. This is the step that most commonly goes wrong, and the failure is silent: records added at your registrar do nothing when DNS is served by Cloudflare.
Two panel-specific traps:
- Many DNS panels append your domain automatically. Entering the full hostname produces something like
resend._domainkey.example.com.example.com. If the panel shows the domain beside the field, enter only the prefix. - If you already have an SPF record, merge Resend’s mechanism into it. Do not add a second record — a domain may have only one, and two means both fail.
Verification usually completes in minutes, though DNS can take longer to propagate.
2. Create an API key
Create a key with sending permission. Resend offers full-access and sending-only keys; a sending-only key is the right choice for a website, on the principle that a compromised site should not be able to read your account.
Copy the key immediately — it is shown once.
3. Connect WordPress
In NimblyMail, choose Resend as the mailer and paste the API key. Set your From address to something on the domain you just verified.
NimblyMail stores the key encrypted at rest rather than as plain text in the options table. If you would rather keep it out of the database entirely, define it in wp-config.php:
define( 'NIMBLYMAIL_RESEND_API_KEY', 'your-key-here' );A constant takes precedence over the stored setting, which also means a database restored from production onto staging cannot carry live credentials into an environment you did not intend.
4. Test properly
Send a test, then open it in Gmail, choose Show original, and confirm:
spf=pass dkim=pass dmarc=passA test that arrives is not proof of correct setup. A test that arrives with all three passing is.
The mistakes that actually happen
From address does not match the verified domain. The most common failure. Verifying yourshop.com and sending as [email protected] will not work unless that subdomain is verified too. WordPress plugins often set a From address independently, so check what is actually being sent rather than what you configured.
Using a free-mail From address. Sending as a Gmail or Yahoo address will fail DMARC regardless of Resend’s configuration, because those domains instruct receivers to reject third-party mail sent on their behalf.
Full-access key on a website. Works, and gives a compromised site more than it needs.
Assuming verification is permanent. If DNS is migrated later — a host change, a Cloudflare move — the records must come with it. This is a common way working mail breaks months after setup, and nothing announces it.
SMTP or the API
Resend supports both, and the SMTP route has an unusual detail worth stating because it looks like a mistake.
For SMTP, the username is the literal string resend and the password is your API key. Not your email address, not your account name. People assume this is placeholder text and substitute their own username, which fails authentication.
The API is generally the better choice for WordPress, because it runs over HTTPS on port 443 and is therefore immune to the blocked-port problem that affects a lot of shared hosting. If your test emails hang for twenty seconds and then time out, that is a blocked port, and switching to the API resolves it without touching anything else.
Subdomains, and why they are worth using
Resend verifies subdomains separately from the root domain. This trips people up — verifying yourshop.com does not verify mail.yourshop.com — but it is also an opportunity rather than only an obstacle.
Sending transactional mail from a subdomain such as mail.yourshop.com gives you two things:
- A separate SPF budget. SPF permits ten DNS lookups per domain, and a busy root domain with several services can already be near the limit. A subdomain starts fresh.
- Reputation separation. If you later send marketing from elsewhere, its reputation cannot drag down your receipts and password resets.
The cost is one extra verification and remembering that your From address lives on the subdomain. For a store, it is usually worth it.
Is Resend the right choice?
Good fit if you want transactional delivery with minimal setup, you are comfortable in a developer-oriented dashboard, and your volume is moderate.
Consider alternatives if you need a long-established deliverability track record for high-stakes mail, or if you want features Resend deliberately does not have — it is focused rather than broad.
Compared with the alternatives: Amazon SES is cheaper at volume but has by far the most setup friction, with a per-region sandbox that catches most people out. Gmail and Microsoft 365 are mailbox services with human-scale sending limits and no delivery logs for application mail. Resend sits in a useful middle — proper transactional infrastructure, without an AWS console.
After setup
Two things worth doing once it works.
Watch your bounce rate. Every transactional provider suspends accounts that generate excessive bounces and complaints. On a WordPress site the usual cause is repeatedly retrying an address that hard-bounced.
Put the DNS on a recurring check. Domain verification depends on records that live outside your site, maintained by whoever administers your DNS. NimblyMail’s audit re-checks SPF, DKIM, DMARC and connectivity weekly, reading the expected values from the mailer you have configured — so if the Resend records are removed during an unrelated DNS change, you find out from an audit rather than from a customer who never received their receipt.