Why a store needs more than "email works"
A blog can tolerate an hour of failed email. A store cannot: order confirmations, shipping notices, password resets and abandoned-cart reminders are the customer-facing half of the business, and every one that goes missing is a support ticket or a chargeback. Email providers do have outages, SMTP ports do get blocked by hosts overnight, and API keys do get rotated by a colleague who did not know the store used them.
The basics of getting email out of WordPress at all are in WordPress not sending email. This guide is the resilience layer on top.
Step 1: send through an API, not SMTP
Dragon SMTP Pro sends through the HTTP APIs of Amazon SES, Postmark, Mailgun, Brevo and Resend instead of an SMTP connection. Three reasons that matters for a store:
- Port 443. Shared hosts block SMTP ports; nobody blocks HTTPS.
- Speed. An API call is quicker than an SMTP handshake, and it happens during checkout, so the customer feels it.
- Provider message IDs come back on every send, which makes "did it go" a lookup rather than a guess.
Under the Pro Providers tab, add your primary provider with its API key. Keep the free plugin's forced From address at your own domain, and make sure SPF, DKIM and DMARC are published for that provider (the Deliverability tab checks).
Step 2: add a backup connection
Under Failover, add a second connection: another API provider, or a plain SMTP mailbox as a last resort. When the primary fails outright (rejected, unreachable, authentication error), the send is retried once through the backup.
The detail that separates a safe failover from a dangerous one: ambiguous failures are not retried by default. A timeout means the primary may have sent the message before the connection dropped; retrying would send the customer two order confirmations, or two password reset links. The default treats a timeout as a failure to log and alert on, not to repeat. An aggressive mode exists if your provider's behaviour makes duplicates impossible and you would rather over-send than under-send, but choose it knowingly.
Authorise the backup sender in DNS too. A failover that lands in spam is not a failover.
Step 3: alert on failure
Under Alerts, send a notification by email (to an address on a different domain or provider, so an outage cannot suppress its own alert) and, ideally, to a Slack-compatible webhook. Alerts are throttled, so an outage produces a handful of messages rather than one per lost email.
Step 4: log everything, and resend what was lost
Dragon Email Log records every message with status and source; the Pro edition, activated by the same SMTP Pro licence, adds the part that matters after an incident: one-click resend of any logged message, filtering (including regex search) to find every order email in the outage window, CSV export, and diagnostics on failed sends.
The recovery procedure after an outage is therefore: filter the log to the window and the failed status, review the list, resend. Ten minutes, and every customer gets their confirmation with an honest delay rather than never.
Set the log's retention to match your data policy: order emails contain names and addresses.
Step 5: rehearse it
Once, deliberately: put a wrong API key on the primary, place a test order, and confirm that the backup sent it, the alert arrived, and the log shows the failed primary attempt and the successful failover. Put the key back. Fifteen minutes now saves the evening it would otherwise cost.
Checklist
- Primary provider on an API connection, DNS authorised
- Backup connection configured and DNS authorised
- Failover left on the safe default for ambiguous failures
- Alerts to an address outside the primary provider, and to Slack
- Email Log Pro active; resend tested
- Failover rehearsed with a deliberate failure