Migrate WordPress & WooCommerce email

What changes, what doesn't

Nothing in your application code. WordPress sends everything -- password resets, WooCommerce order confirmations, form notifications -- through wp_mail(), and the official Euromail plugin redirects that to EuroMail with an API key -- or, if you'd rather stay on a generic SMTP plugin, four connection settings. What makes this migration different from swapping API providers is that a live store has real volume from minute one: an order confirmation refused during cutover is a customer email that never arrives. This guide is ordered so that never happens.

If you're coming from another provider's SMTP endpoint (SES, Mailgun, SendGrid, Postmark), the SMTP-plugin path of this guide is identical -- only the host and credentials change. Their API-side differences are covered in the provider-specific migration guides, e.g. SES, Mailgun, and SendGrid.

Step 1: Create the account a day early

Every new EuroMail account spends its first 24 hours -- counted from account creation -- inside a probation window: a send-rate cap (5 emails/minute, 25/hour on day one) and a recipient allowance of 20 tokens refilling at 2 per hour, counted per deliverable recipient. A settled, non-zero invoice raises the allowance to 1,000 (a plan still inside its trial does not count). The allowance expires with probation at 24 hours; the rate cap loosens to 15/minute and 75/hour for the rest of the first week -- 1,800 emails a day, comfortably above a typical store.

For a store migration the answer is simple: sign up and verify your domain today, cut over tomorrow. By then the recipient allowance is gone and only the week-one rate cap remains, far above normal store volume. If you must move a high-volume store the same day, settle your first invoice first -- 1,000 recipients covers a typical store's day -- or keep the old mailer active in parallel for the first 24 hours.

A refused send returns SMTP 452 (transient). Mail servers retry that; wp_mail() does not -- which is exactly why this step comes first.

Step 2: Verify your domain

Follow Domain Verification: add the DKIM and return-path records, wait for green checks. Your From address (e.g. [email protected]) must be on the verified domain.

Before verification completes you are in sandbox mode: sends are limited to your own account email and don't consume any allowance. That is the safe place for the next step.

Step 3: Point WordPress at EuroMail and test

Install the official Euromail plugin -- it's pending review on wordpress.org, so for now grab the latest release zip from github.com/kalle-works/euromail-wordpress/releases and upload it under Plugins → Add New → Upload Plugin. Then Euromail → Settings and paste your API key.

Over a generic SMTP relay, the plugin adds exactly what a live migration benefits from:

• Idempotent retries -- every send carries an idempotency key, reused across retries, so a retried order confirmation can't double-send.
• A retry queue, not a one-shot attempt -- a refused send (a 5xx, a 429, a transport error) is queued and retried automatically over the following hours instead of just being gone.
• A delivery log with webhook-driven status -- see every send's outcome in wp-admin, updated live as delivery/bounce/complaint events arrive, instead of inferring failures from customer complaints.
• Automatic fallback between the API and SMTP, so a transient outage on one path doesn't need you to notice and switch manually.

Full detail on all of this is in the plugin guide.

Prefer to keep using a generic SMTP plugin instead? Full walkthroughs (WP Mail SMTP, FluentSMTP, Post SMTP) live in Send Email via SMTP. The short version:

Either way, send a test email to your own address first (works even before domain verification, via sandbox mode), then -- once the domain is verified -- place a real test order in your store and confirm the confirmation arrives.

If you go the generic-SMTP-plugin route, pick one with a send log if you can (FluentSMTP has one built in; WP Mail SMTP's log is a paid feature). WordPress swallows mail errors silently by default, and during a migration you want to see every refusal, not infer it from a customer complaint -- which the official plugin's log gives you either way.

Step 4: Bring your suppression list

If the store previously sent through another provider, its bounce and complaint list protects your new sending reputation. Export it there, then import via the dashboard's CSV upload (Suppressions → Import) or replay it through the API:

curl -X POST https://api.euromail.dev/v1/suppressions \
  -H "X-EuroMail-Api-Key: em_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "email_address": "[email protected]",
    "reason": "migrated: hard bounce at previous provider"
  }'

Details in Suppression Lists. Skipping this step means re-bouncing every dead address on your list -- against a brand new sender reputation.

Step 5: Cut over, keep the rollback warm

The plugin (official or generic SMTP) is your parallel-run mechanism: the old provider's credentials stay saved in it -- or in a second, deactivated plugin -- and rolling back is re-selecting the old mailer, or switching the backend setting back. No DNS wait, no code.

Watch the first hours in Analytics and Deliverability Insights, and check the plugin's send log for anything refused.

Honest gaps

• A send refused mid-request is only queued if something catches it. wp_mail() itself has no retry or queue -- that's WordPress, not EuroMail. The official plugin closes most of this gap: a retryable failure (a 5xx, a 429, a transport error) is queued and retried automatically. What neither the plugin nor any SMTP provider can catch is PHP dying mid-request before wp_mail() returns at all (a fatal error, a killed process) -- if order email is business-critical on top of that, a queueing plugin or WooCommerce's action-scheduler-based follow-ups are worth having regardless of provider.
• API-only features don't reach a generic SMTP plugin. Idempotency keys, scheduled sending, and per-send tags are API features (Sending Emails) that the official plugin's API backend uses automatically (idempotency keys on every retry) or that you'd reach via the PHP SDK directly for the rest. SMTP sends still flow through the same pipeline -- suppressions, webhooks, and analytics all apply regardless of path.

Cutover checklist

1. Create a EuroMail account at least 24 hours before cutover (probation limits expire with account age) and an API key with the emails:send scope (API Keys).
2. Verify your sending domain; confirm the checks are green.
3. Install and configure the Euromail plugin (GitHub release zip until it's live on wordpress.org, or a generic SMTP plugin); test to your own address, then with a real test order.
4. Import suppressions from your previous provider.
5. Switch the plugin's mailer to EuroMail during a quiet hour; keep the old mailer's settings saved as the rollback.
6. Watch the first hours in Analytics and the plugin's send log.
7. After a clean day, revoke the old provider's credentials.