Estimated reading time: 8 minutes
You’re hitting Migadu’s 100 outbound emails per day cap. Clients are missing order confirmations. You’re eyeing the Standard plan at $290 and wondering how you got here.
Before you reach for your wallet, check your logs. There’s a good chance the problem isn’t Migadu at all — and if you’re on Zoho, cPanel hosting mail, or any other mailbox service with a daily send cap, the same applies to you. This is a category-wide characteristic of mailbox hosting, not a quirk of any one provider. The fix is the same regardless of which one you’re on and Claude is handy to have in the loop as you work through the fix 😉
The Setup
I run a Migadu Mini plan for client email hosting — $90/year, 1,000 inbound and 100 outbound per day, multiple domains under one account. For human mailbox sending — staff emails, client correspondence — 100/day is genuinely plenty. Two busy people would struggle to send 100 individual emails in a working day.
So when both domains on the account started bumping the limit on busier days, my first instinct was a plan problem. The options looked like:
- Upgrade to Standard — $290/year, $200 more, limits I’d never fully use
- Split into two Mini accounts — $90 each, move one domain, migrate the mailboxes
The split felt like the right economics. Then I looked at the logs.
Check the Logs First
Both sites run WooCommerce. Both use FluentSMTP, routed through Migadu. A quick check of the FluentSMTP activity logs on each site told the actual story: the outbound allowance wasn’t being eaten by humans — it was WooCommerce order confirmations, password resets, new account notifications, review request emails, and various plugin-generated notifications firing automatically through the same mailboxes Migadu manages.
The 100/day limit wasn’t too small. It was just being used for the wrong thing.
Migadu is excellent at what it’s designed for: reliable, privacy-respecting mailbox hosting for humans. It is not a transactional email relay, and routing automated site-generated mail through it is the email equivalent of using your business landline to send faxes. Technically it works, right up until it doesn’t.
The fix isn’t a bigger Migadu plan. It’s routing transactional mail through infrastructure built for transactional mail, and leaving Migadu to do what it does well.
The Right Tool: A Dedicated Transactional Relay
Dedicated transactional email services — Amazon SES, Postmark, Brevo, SMTP2GO and others — exist specifically for this use case. They handle volume, reputation separation, bounce processing, and deliverability at scale, with proper reporting. Most have generous free tiers. None of them cost $200/year more than what you’re already paying.
For this situation I chose SMTP2GO, for a few reasons:
- Free plan covers 1,000 emails/month with a 200/day cap — more than enough headroom once human sending stays on Migadu
- Single account, multiple sending domains — both client sites under one place to monitor
- Clean API key permissions model (more on that shortly)
- Native integration in Gravity SMTP, which I’m rolling out across managed sites as part of care plan work
If you’re on a Gravity Forms Elite or legacy Developer licence, you already have Gravity SMTP included. It’s a standalone plugin — Gravity Forms itself doesn’t need to be installed — and it hooks into wp_mail to route all outbound WordPress mail through whatever sending service you configure. A clean drop-in replacement for FluentSMTP or WP Mail SMTP.
The DNS Side — What Actually Changes
This is where a lot of guides gloss over the detail. Here’s what the DNS picture looks like when you’re adding SMTP2GO to a domain that already has Migadu configured.
A typical Migadu zone looks roughly like this:
; Inbound
@ IN MX 10 aspmx1.migadu.com.
@ IN MX 20 aspmx2.migadu.com.
; DKIM (CNAMEs to Migadu's signing infrastructure)
key1._domainkey IN CNAME key1.example-shop.com._domainkey.migadu.com.
key2._domainkey IN CNAME key2.example-shop.com._domainkey.migadu.com.
key3._domainkey IN CNAME key3.example-shop.com._domainkey.migadu.com.
; SPF
@ IN TXT "v=spf1 include:spf.migadu.com ~all"
; DMARC
_dmarc IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc_reports@example-shop.com;"When you add SMTP2GO domain authentication, it gives you three CNAMEs to add. You do not touch the SPF record. SMTP2GO uses a CNAME-based return-path approach: the bounce subdomain points back to SMTP2GO’s infrastructure via CNAME, and they handle SPF alignment on their side. No SPF merge needed, no risk of breaking the 10-lookup limit.
The three CNAMEs SMTP2GO provides look roughly like this (your wizard will give you the exact values):
; SMTP2GO — ADD these three, leave everything else untouched
em#### IN CNAME return.smtp2go.net.
s####._domainkey IN CNAME <dkim target from wizard>
link#### IN CNAME <tracking target from wizard>Everything Migadu — the MX records, the three keyN._domainkey CNAMEs, the SPF include, the SRV records — stays exactly as-is. Migadu keeps doing inbound and human outbound. You’re only adding three records, not editing anything live.
Do this for every domain you’re verifying in SMTP2GO before touching WordPress.
One Gotcha: DMARC Strict Alignment
If any of your domains use strict DMARC alignment — adkim=s; aspf=s; — pay attention here.
Under strict SPF alignment, the envelope sender domain must match the From domain exactly. SMTP2GO’s return-path is a subdomain (e.g. em####.example-shop.com), which under strict alignment won’t pass SPF for the root domain. DKIM carries the DMARC pass on strict domains. That’s fine — SMTP2GO’s domain authentication signs as d=example-shop.com exactly, so adkim=s is satisfied. But it means your DKIM CNAME must verify green in the SMTP2GO wizard before you set it as primary. There’s no SPF backstop if DKIM isn’t working.
If your DMARC policy uses relaxed alignment (the default when no adkim/aspf flags are set), you don’t need to worry about this.
The Setup Order
Getting this right means transactional mail never has a gap in delivery. The sequence:
1. Set up SMTP2GO first — completely — before touching WordPress.
- Create the account
- Add both sender domains via the wizard (Sending → Verified Senders → Add a sender domain)
- Add the three CNAMEs to each domain’s DNS zone
- Wait for all six CNAMEs to show green in the SMTP2GO dashboard
- Don’t proceed until they’re all verified
2. Create API keys — one per site, not one shared key.
SMTP2GO lets you create multiple API keys under one account. Use this. Name each key clearly (e.g. example-shop-wp, example-agency-wp). The practical benefit: SMTP2GO’s activity log filters by API key, so you can see each site’s sending separately. Invaluable during the first week of monitoring.
On permissions — use least privilege. You do not need to give Gravity SMTP access to account management, subaccounts, SMTP users, templates, IP allow lists or SMS. The permissions it actually needs:
/email/send— sends mail/email/mime— handles some WooCommerce email formats/activity/search— delivery status checks/stats/email_summary,/stats/email_bounces,/stats/email_spam,/stats/email_history— reporting/suppression/view,/suppression/add— bounce/complaint handling
Everything else: off.
3. Install and configure Gravity SMTP.
- Install the plugin (download from your Gravity Forms account area)
- Go to SMTP → Settings → Integrations → add SMTP2GO
- Paste the API key, set Default From Email (must be on your verified domain), enable Force From so WooCommerce and other plugins can’t override it
- Set SMTP2GO as Primary
4. Send a test email via SMTP → Tools → Send a Test.
Confirm it lands. Check SMTP2GO’s activity dashboard to see it logged. If it shows as rejected, the most common cause is the From address not matching the verified sender domain — fix it in the integration settings and retest.
5. Deactivate FluentSMTP — only once the test passes.
Don’t run both plugins active simultaneously. Two plugins hooking wp_mail will conflict.
The Result
Both domains still on the same Migadu Mini plan. No upgrade, no account split, no mailbox migration. Migadu’s outbound allowance now carries only human sending — well under 100/day. SMTP2GO handles all WooCommerce transactional and review notification mail from both sites on the free plan, with clean per-site reporting via separate API keys.
If monthly volume trends toward the 1,000/month free cap, the paid plan is $15/month — a straightforward client conversation with actual usage data to back it up.
The Takeaway
Before you change your email hosting plan, check what’s actually using your sending allowance. If you’re running WooCommerce (or any other plugin-heavy WordPress setup) and routing all mail through a single SMTP account, there’s a reasonable chance your mailbox hosting plan is absorbing traffic it was never designed for.
Migadu for mailboxes. A transactional relay for automated site mail. They’re different tools for different jobs, and using the right one costs less than you might expect.