Luther / Brady  /  email provisioning audit

How to give Brady a lot of email addresses

Short version: you already own the answer. Your Google Workspace catch-all domains are the strongest own-domain email system in this whole audit, at no extra cost. An outside service only earns its place in three specific situations. This lays out your domains, all 29 services with costs, and what we still need to pin down for Brady.

domains + pricing verified 2026-07-09 29 services audited maintained at wordpress-publisher/clients/luther/email-audit
Jump to

Your Workspace catch-all domains already win the "own domain" game

A catch-all domain means every address on it works with zero setup (james.holloway@edit-x.com, s.bennett@verovine.com, and so on), all landing in one Gmail you can read by API. That is unlimited addresses, on real domains that pass any signup form, for no cost beyond what you already pay. No service in the audit beats that for the own-domain use case.

So the honest recommendation: for creating addresses, start with your own domains. Reach for an outside service only in the three cases below.

The only three reasons to add an outside service

1 Protect your domains from cold-send volume

Google Workspace caps sending near 2,000 external recipients per user per day and will suspend accounts that look spammy. For high-volume outreach you use separate throwaway domains and mailboxes, never your main brand domains. This is the Brady case.

2 Consumer-brand addresses (yahoo / outlook)

Workspace cannot hand you an @yahoo.com or @outlook.com. If a target specifically wants those, you connect real accounts you own at those providers. Niche, usually not needed.

3 Big programmatic scale over an API

If you are spinning up and reading thousands of inboxes from code, a service like Mailgun, MailSlurp or AgentMail gives a clean API. Gmail API plus catch-all covers a lot before you need this.

Not a reason "Their domain is easier"

Convenience of a provided address is not worth it: most provided domains (mailslurp.com, mailinator.com, temp-mail pools) are on public blocklists and get rejected at signup. Your own domain is less setup than recovering from that.

Clearing up "real provider" (my column name was bad)

Every address in this audit receives real mail. They are all real. The old "real provider" column meant one narrow thing: is the address on a big consumer webmail brand, that is @yahoo.com / @outlook.com / @icloud.com, as opposed to your own domain or the service's own domain. I have renamed it Consumer mailbox.

The three flavors, all real, differ only by the domain and whether a form accepts it:

  1. Your own domain (anything@edit-x.com). Real, deliverable, lands in your Gmail. Passes every form. This is your base.
  2. Consumer mailbox (you@yahoo.com). Also real, but you can only get one by connecting an actual Yahoo/Outlook/iCloud account you own (they have no create-address API). Use only if a target wants a webmail brand.
  3. Provided / forwarding. A service receives at its domain, or at your domain, and forwards into a real inbox. The mail is real; the question is whether the domain passes. You are right: forwarding is fine, the catch is the domain on the front.

So "we cannot use them if they are not real" is half right

They are all real. The disposable ones fail not because the mail is fake, but because their domain is on the blocklist a signup form checks, so you get rejected before any mail is sent. Your domains and real consumer mailboxes never have that problem.

Your inventory

Domains you control, ready as catch-alls

Pulled live from your Google Workspace send-as aliases on 2026-07-09, so these are domains you verifiably control for email. Each one, with catch-all enabled, gives you unlimited addresses that all pass signup forms. This is your supply. Note: send-as is a proxy, listing every secondary domain in Workspace needs Admin-directory access this token does not have, so add any I missed.

Confirmed (you send-as these in Workspace)

Possibly also yours (seen in your repos/server, not in send-as, confirm)

How to turn any of these into an infinite address supply

In Google Workspace Admin, set the domain's routing to catch-all (or add a catch-all address), then every local part works instantly. Make each one look like a real person (first.last, or first-initial plus last), never a sequential ID or a plus-tag, so they read as genuine users: james.holloway@verovine.com, sarah.bennett@edit-x.com, m.torres@verovine.com. Read them all from one Gmail, or via the Gmail API by search. Zero per-address cost.

For a clean split, dedicate one or two of these domains to Brady so his traffic stays separate from your main edit-x.com identity.

The audit, with cost

All 29 services, address + cost + acceptance

Example address is what you get out of the box. Own domain / Consumer mailbox / Provided domain are the three "does it offer this" columns. Cost is the free tier then the entry paid price. Passes form? rates the provided default address; own-domain and consumer-mailbox addresses pass in every case.

Passes accepted by any form Own domain on your domain, always passes Depends passes a gmail-only block, risky if it checks disposables Rejected provided domain is on a blocklist Own domain note = how many domains you can attach

Current stack

For Brady: sending Luther email at volume

Update 2026-07-09: Brady already sends the Luther emails through Resend. That settles the big fork (this is the SEND path), so the report now centers on how Resend scales, what it costs, and the one setup detail that still matters.

Current sender: Resend (resend.com)

Brady delivers the Luther emails via Resend, a modern transactional email API. Good pick: clean API, your own verified domain, strong deliverability. It is already in the audit table above (send plus inbound, own domain, Free then $20 Pro). So the question is not which sender, it is how it scales and whether the setup fits the type of mail.

The one thing that still shapes it: transactional or cold?

If these are transactional Luther emails (confirmations, notifications, replies people expect), Resend as-is is right, just move up the plan as volume grows. If any of it is cold outreach or marketing to people who did not opt in, isolate that to a dedicated sending subdomain (for example mail.luther-something.com), warm it, and keep it off the domain your transactional mail uses so one spam complaint cannot sink both.

If Brady also needs to RECEIVE (replies, inbound)

Already solved, $0

Your catch-all domains give unlimited receiving addresses today. Dedicate a domain or two to Brady and give him real-looking person-name addresses (james.holloway@verovine.com, dwilliams@edit-x.com), never sequential IDs or plus-tags that flag as fake. Everything lands where you can read it by Gmail API. No new service, no new spend. If he needs them parsed automatically, point the domain at Cloudflare Email Routing (free) or Mailgun (free tier) with a webhook.

Scaling the send on Resend

The setup checklist, since Brady is already on Resend:

  1. Send from your own verified domain with SPF, DKIM and DMARC set (Resend walks you through it). Deliverability lives or dies here.
  2. Watch the free-tier cap: 3,000/mo and 100/day. Any real Luther volume needs Pro or Scale. See the cost table.
  3. For cold or marketing sends, use a dedicated subdomain (mail.luther-something.com) and warm it, so it cannot damage the domain your transactional mail uses. Transactional-only sends can stay on the main domain.
  4. On Scale, take the dedicated IP once you are past ~100k/mo and want to own your reputation. Below that, Resend shared IPs are fine.

What Resend costs as Luther volume grows

Resend pricing as of 2026-07-09. Overage runs about $0.90 per 1,000 on Pro, dropping toward $0.46 per 1,000 at the top of Scale. The jump from Pro to Scale mainly buys a dedicated IP and higher deliverability features, so stay on Pro until volume or reputation control forces Scale.

What to confirm to finalize the plan

  1. Type: transactional Luther email, cold outreach, or marketing? Sets whether you need a separate warmed subdomain.
  2. Volume: emails per month now, and where it is heading. That picks the Resend tier.
  3. Which domain Brady sends from today, so we confirm SPF, DKIM, DMARC and reputation are clean.