Rich Gibbs

Cloudflare Email Routing for indie founders: the 10-minute support@ setup

email · cloudflare · email-routing · dns · indie-founder · saas · support

You launched. Your domain has a website, a payment link, a privacy page that says “support@yourdomain.com,” and… no actual mailbox at that address. Real customer mail is silently bouncing.

You don’t need a $6-per-user-per-month Workspace seat to fix this. Cloudflare Email Routing forwards support@yourdomain.com (and any other alias you want) to a Gmail/Fastmail/Proton mailbox you already pay for, for free, in about ten minutes.

This post is the boring, working playbook to set it up — plus the one thing it can’t do that surprises every founder who tries it for the first time.

What Email Routing actually is

Cloudflare Email Routing is inbound-only forwarding for any domain whose DNS lives at Cloudflare. You publish a few MX and TXT records that Cloudflare manages for you, define some routing rules in the dashboard (“send anything to support@yourdomain.com to my Gmail”), and incoming mail gets re-injected into your real mailbox.

What it is not:

  • Not a mailbox. You can’t log in to a Cloudflare interface to read mail.
  • Not an outbound SMTP server. You can’t send from support@yourdomain.com through Email Routing. Replies will go from whatever mailbox you forwarded into, unless you also configure your replying client (more on this below).
  • Not a deliverability service. It accepts mail from the public internet and re-delivers it. SPF/DKIM/DMARC for your domain are still your job.

The 10-minute path

Two prerequisites:

  1. Your domain’s nameservers are Cloudflare’s. (If they aren’t, follow Cloudflare’s “Add a site” flow first; it’s free, takes about 5 minutes plus DNS propagation.)
  2. You have a Gmail / Fastmail / Proton / Mailbox.org / etc. mailbox you actually read.

1. Enable Email Routing (1 minute)

In the Cloudflare dashboard:

  • Pick your zone → Email → Email Routing.
  • Click Get started. Cloudflare will offer to add the required DNS records automatically. Say yes.

Cloudflare will publish:

  • Three MX records pointing at route1.mx.cloudflare.net, route2.mx.cloudflare.net, route3.mx.cloudflare.net.
  • A TXT record at the apex with v=spf1 include:_spf.mx.cloudflare.net ~all.
  • A DKIM CNAME (cf2024-1._domainkey) for the routing service.

If you already have an SPF record at the apex, stop and merge them by hand. You should never have two SPF records. We’ll come back to that in the gotchas.

2. Verify the destination address (2 minutes)

Still in Email → Email Routing:

  • Destination addresses → Add destination address.
  • Enter the personal mailbox you want forwarded mail to land in.
  • Cloudflare emails a verification link. Click it.
  • The destination’s status should flip to Verified.

You can verify multiple destinations and route different aliases to different mailboxes. Useful if billing@ should go to a finance address and security@ should go to a different one.

3. Add a routing rule (1 minute)

  • Custom addresses → Create address.
  • Custom address: support (so the full address is support@yourdomain.com).
  • Action: Send to an email.
  • Destination: pick the verified address.
  • Save.

Repeat for every alias you advertise: hello@, billing@, legal@, security@, dmarc-reports@ (very useful, more on this in a minute).

4. (Optional) Catch-all (30 seconds)

In Custom addresses → Catch-all address, set it to either:

  • Drop — anything not matched is silently dropped. Good for spam hygiene.
  • Send to — any unknown alias is forwarded to your fallback mailbox. Good if you advertise lots of aliases on signup forms and don’t want misspellings to bounce.

There is no third option. Pick one. “Drop” is what most indie SaaS founders should use.

5. Send a real test (1 minute)

From a different mailbox (not the destination — Gmail will helpfully suppress mail you sent to yourself), email support@yourdomain.com. It should arrive at the destination within a few seconds, with the original sender preserved in the From: header.

That’s the whole setup. The remaining time is what’s between you and a working outbound support address, which is the part that catches everyone.

The one thing Email Routing does not do — and what to do instead

Email Routing is inbound only. If you reply to a customer’s email and you do nothing else, your reply will go from your.personal@gmail.com, not from support@yourdomain.com. The customer sees a different address than the one they wrote to, the conversation feels off, and you might also leak a personal address you didn’t mean to advertise.

Three options, in order of effort:

Option A — Live with replies coming from the personal mailbox

OK for a v0 SaaS while you have ten customers. Set the Reply-To header in your mail tool to support@yourdomain.com so further replies route correctly. Most mail clients let you set a default Reply-To per identity. Customers will see your personal address in the visible From, which they will probably tolerate while you’re small.

Option B — Use Gmail’s “Send mail as” with a real outbound SMTP server

In Gmail: Settings → Accounts and Import → Send mail as → Add another email address.

You will need:

  • A real outbound SMTP host that authorizes you to send as support@yourdomain.com. Gmail itself will not let you do this without an SMTP server; the “treat as alias” path that worked years ago is gone.
  • An SMTP host can be a paid Workspace seat ($6/mo/user — the thing we just avoided), or a transactional ESP like Postmark / Resend / Mailgun / SES configured with your custom domain and DKIM.

If you already use Postmark/Resend/Mailgun/SES for product mail, set up an authorized “transactional support” sender there and feed the SMTP credentials into Gmail’s Send-mail-as flow. Postmark and Resend both have specific docs for this. Now your replies go from support@yourdomain.com over a path that aligns with DKIM.

Option C — Use a help-desk tool with custom-domain support

Help Scout, Plain, Front, Missive, HubSpot Service. These all accept inbound mail forwarded to a tool-specific address (you point Cloudflare Email Routing at it instead of your Gmail) and send outbound replies as support@yourdomain.com with their own DKIM you authorize. Per-seat pricing varies; some have free tiers up to a few mailboxes.

For an indie SaaS at 0–500 customers, Option B is usually the sweet spot. For a 2-3 person team that wants conversation handling, Option C earns its keep.

Common gotchas

These are the things I see indie founders get wrong with Email Routing.

Gotcha 1: dual SPF records

If your DNS already had an SPF record (because you set up Postmark or Mailgun before adding Email Routing), Cloudflare will silently publish a second one. Conforming receivers will treat dual SPF as permerror and ignore both. Result: legitimate inbound delivery may still work via MX, but your outbound SPF alignment quietly breaks.

Fix: keep one record at the apex. If you also send via Postmark and Mailgun and have routing on:

v=spf1 include:_spf.mx.cloudflare.net include:spf.mtasv.net include:_spf.mailgun.org ~all

Verify with dig +short TXT yourdomain.com | grep spf1. You should see exactly one line.

Gotcha 2: forwarded mail lands in spam

Forwarding rewrites the SMTP envelope. The original sender’s SPF/DKIM may no longer align by the time Gmail receives the forwarded copy. Symptoms: real customer mail to support@ shows up in Gmail’s Spam folder.

Fix:

  • In Gmail, open one such message → More → Filter messages like this → set criteria to to:support@yourdomain.com OR deliveredto:support@yourdomain.com, then Never send to spam + apply a Support label + optionally categorize as Primary.
  • Test from a non-destination address; do not test from another mailbox owned by the same Google account.

This is a Gmail filter, not a Cloudflare problem. Email Routing sets ARC headers correctly; some receivers still ding forwarded mail.

Gotcha 3: DMARC reports vanish

You set up DMARC at _dmarc.yourdomain.com with rua=mailto:dmarc-reports@yourdomain.com. That alias must actually route somewhere. If you forgot to add a Cloudflare Email Routing rule for dmarc-reports, the reports get dropped, and you’ll think DMARC is broken when really you just have no inbox to read it from.

Fix: add dmarc-reports@ as a routed alias. In Gmail set a filter to auto-label and skip the inbox. Aggregate reports are XML and noisy.

Gotcha 4: your “send mail as” alias still routes through gmail.com

Even with Send-mail-as configured, if you don’t enable “Treat as alias” or you don’t use a true outbound SMTP host, Gmail will sometimes send through gmail.com and tag it as a forwarded sender. The visible From: looks right, but Authentication-Results will tell on you.

Fix: read the Authentication-Results header on a real reply (View original in Gmail). You want dkim=pass header.d=yourdomain.com, not header.d=gmail.com.

Gotcha 5: paid Workspace already exists for the domain

If your domain previously had Google Workspace MX records, or M365 MX records, the dashboard will warn before overwriting them. Do not click through that warning unless you intend to abandon the existing mailbox. Cloudflare’s MX records replace whatever was there — including your live Workspace inbox.

Fix: pick one. Either keep Workspace and don’t enable Email Routing, or migrate everything to Email Routing first.

Authentication after Email Routing is on

Once routing is live, dig your domain. You should see exactly:

  • 3 MX records → route{1,2,3}.mx.cloudflare.net.
  • 1 SPF TXT (only) at the apex.
  • 1 DKIM TXT (cf2024-1._domainkey) for the routing service.
  • Your existing DKIMs from product/transactional senders.
  • 1 DMARC TXT at _dmarc.

If any of those is duplicated or missing, you have homework. The matching SPF/DKIM/DMARC checklist walks the rest.

When to upgrade past Email Routing

Email Routing is the right answer when:

  • You need 1–10 aliases on one domain.
  • Volume is “real customer mail,” not “we send 50k newsletters a month from this address.”
  • A 5–60 second delay on inbound is fine.

Outgrow it when:

  • You want a shared inbox for two or more people without forwarding to the same Gmail.
  • You need calendar/contacts/Drive on the domain (that’s Workspace’s actual value, not the email forwarding).
  • You need server-to-server inbound webhooks (Email Routing supports a “Send to a Worker” action for this; useful but past the 10-minute mark).

Want a written second-pair-of-eyes on your setup

Once routing is live and SPF/DKIM/DMARC are published, the most useful thing you can do is verify every authorized sender is aligned with your visible From: address. That’s exactly the Inbox/DNS QuickCheck — a $99 written report on one domain, delivered within 24 hours, no DNS login required.

If you’d rather DIY the whole thing, the same content in printable, fillable Markdown form (sender inventory template, SPF builder, DMARC ramp, Authentication-Results decoder) is in the Indie Founder Email DNS Pack — $19 (pay what you want, $9 minimum) on Gumroad. Either is fine. The point is to do it once, well, then never think about it again.

If you set up Cloudflare Email Routing and also publish DMARC at p=quarantine or stricter, a small but real failure mode is forwarded mail that breaks SPF or DKIM alignment at the receiving mailbox. The DMARC Quarantine Pack ($29) is the focused runbook for diagnosing that and related cases — Gmail 5.7.26 and Microsoft 5.7.509 / 5.7.515 decoded with source citations, three incident walkthroughs (one of them is a forwarding/ARC case), and a single-file Python aggregate-XML reader for reading your own reports.

DMARC Quarantine Pack — $29 on Gumroad · 14-day refund, no questions.