One Inbox, Unlimited Aliases: Cloudflare Email Routing to Gmail with MTA-STS

I wanted the convenience of using a different email address for every website without maintaining a collection of mailboxes.

The idea was simple: let every address at a custom domain arrive in one Gmail inbox.

[email protected]
[email protected]
[email protected]
[email protected]
                 ↓
       Cloudflare Email Routing
                 ↓
              Gmail

A catch-all rule makes that possible. Adding MTA-STS gives the receiving side a stronger transport-security policy, so compatible sending mail servers know which MX hosts are legitimate and that delivery must use trusted TLS.

What we are building

The finished path is deliberately short:

External sender
      ↓
Cloudflare MX servers
      ↓
Cloudflare Email Routing catch-all
      ↓
Verified Gmail address

Cloudflare receives mail for the domain and forwards it to Gmail. There is no mailbox stored at Cloudflare and no need to create each alias before using it.

MTA-STS applies to the first hop. It tells compatible sending mail servers that mail for the domain should be delivered only to the MX hosts listed in the policy, over TLS with a valid certificate.

Before changing anything

You need:

• A domain using Cloudflare’s authoritative DNS.
• Access to the domain’s Cloudflare account.
• A Gmail address that can receive Cloudflare’s verification message.
• A clear understanding of any existing email service on the domain.

That last item matters. Enabling Email Routing changes the domain’s MX records. If the domain already receives mail through Google Workspace, Microsoft 365, Fastmail, or another provider, replacing its MX records changes the active mail system.

Export or record the existing DNS configuration before onboarding the domain, and do not mix MX records from different providers unless the providers explicitly document that design.

Step 1: onboard the domain for Email Routing

In the Cloudflare dashboard:

1. Go to Compute → Email Service → Email Routing.
2. Select Onboard Domain.
3. Choose the domain.
4. Review the DNS records Cloudflare proposes.
5. Complete the onboarding.

Cloudflare configures the records needed for routing, including the receiving MX records and related authentication records.

Afterward, open Email Routing → Settings and confirm that the routing DNS records are healthy. If the dashboard still reports missing records, wait a few minutes and check again before creating routing rules.

The important outcome is that the domain’s MX records now point to Cloudflare:

dig MX example.dev

Do not copy MX values from a blog post. Let Cloudflare create the current records and verify them in the dashboard.

Step 2: add and verify Gmail as the destination

Cloudflare will not forward mail to an address until its owner confirms it.

1. Open Email Routing → Destination Addresses.
2. Enter the Gmail address that will receive the forwarded messages.
3. Submit it.
4. Open the verification message in Gmail.
5. Select Verify email address.

The destination should now appear as verified.

This validation is an important safety control. Without it, someone could create forwarding rules that send unwanted mail to addresses they do not own.

Step 3: enable the catch-all rule

Now configure the domain so that any local part is accepted.

1. Open Email Routing → Routing Rules.
2. Find Catch-all rule and enable it.
3. Set the action to Send to an email.
4. Choose the verified Gmail destination.
5. Save the rule and confirm it shows as Active.

At this point, addresses do not need to be pre-created. These can all reach the same inbox:

[email protected]
[email protected]
[email protected]
[email protected]

You can still create explicit routing rules when a particular address needs different treatment. Specific rules are useful for sending selected addresses to another verified inbox, a Worker, or a drop action.

A catch-all trade-off

A catch-all is convenient, but it accepts misspellings and mail sent to guessed addresses. That can increase spam.

A practical pattern is to use unique aliases for services and let Gmail filters label them. If one address starts receiving junk, the exposed alias becomes obvious.

Remember that Email Routing handles incoming mail. It does not automatically let Gmail send as every address under the domain. Outbound custom-domain identity requires a suitable SMTP or mailbox provider and its own SPF, DKIM, and DMARC design.

Step 4: test the forwarding path

Send a message from an account that is not the destination Gmail account to a new alias such as:

[email protected]

Using an unrelated sender avoids confusing behavior caused by sending a message back toward the same account from which it originated.

Confirm:

• The message reaches Gmail.
• The original sender and recipient are visible.
• Replies go where you expect.
• Cloudflare’s Email Routing activity view shows the message as delivered.

If delivery fails, check the domain’s MX records, the Gmail destination’s verification state, and whether the catch-all rule is active.

What MTA-STS is

SMTP historically uses opportunistic TLS. A sending server normally tries to encrypt delivery, but the basic protocol can be vulnerable to downgrade or redirection attacks when an attacker interferes with the negotiation or DNS answer.

MTA-STS, short for Mail Transfer Agent Strict Transport Security, lets a receiving domain publish a policy that says:

• These are the MX hosts authorized to receive my mail.
• Delivery to them must use TLS.
• Their certificates must be valid.
• If those conditions cannot be met, do not silently fall back to insecure delivery.

The mechanism is defined in RFC 8461.

MTA-STS uses two similarly named but different hostnames:

The underscore is not a typo. The DNS discovery record uses _mta-sts; the HTTPS policy host uses mta-sts.

Step 5: publish the MTA-STS DNS signal

In Cloudflare DNS → Records, create:

Type: CNAME
Name: _mta-sts
Target: _mta-sts.mx.cloudflare.net
Proxy status: DNS only

Proxy mode must be disabled for this record.

Cloudflare’s target publishes the MTA-STS TXT value and policy ID. A sender uses that ID to determine whether its cached copy of the policy is still current.

Verify it with:

dig TXT _mta-sts.example.dev

Because this is a CNAME, the answer should show the alias and ultimately a TXT value similar to:

v=STSv1; id=...

The exact ID can change. The important checks are that the CNAME points to Cloudflare and the resolved TXT policy uses STSv1.

Step 6: serve the policy over HTTPS

MTA-STS senders retrieve the policy from one exact URL:

https://mta-sts.example.dev/.well-known/mta-sts.txt

Cloudflare provides an MTA-STS proxy Worker example. The Worker proxies Cloudflare’s managed Email Service policy through the required hostname on your domain.

Deploy that Worker to the same Cloudflare account. Then:

1. Open the Worker’s settings.
2. Go to Settings → Domains & Routes.
3. Select Add.
4. Add the custom domain mta-sts.example.dev.
5. Wait until the custom domain and its TLS certificate are active.

This Worker does not receive, inspect, or forward email. Its only job is to make the MTA-STS policy available over HTTPS at the standard path.

Step 7: verify the policy

Fetch the policy directly:

curl https://mta-sts.example.dev/.well-known/mta-sts.txt

For Cloudflare Email Routing, the managed policy should look like:

version: STSv1
mode: enforce
mx: *.mx.cloudflare.net
max_age: 86400

Each line has a specific meaning:

• version: STSv1 selects the MTA-STS standard.
• mode: enforce tells supporting senders not to deliver when the policy cannot be satisfied.
• mx: *.mx.cloudflare.net identifies Cloudflare’s allowed receiving hosts.
• max_age: 86400 lets senders cache the policy for one day.

Also verify the HTTPS response and certificate:

curl -i https://mta-sts.example.dev/.well-known/mta-sts.txt

The request should succeed without certificate warnings and return the policy as plain text.

For an existing production mail domain or a provider migration, test carefully before enforcing a new policy. A self-managed rollout can begin with mode: testing and TLS reporting before moving to enforce. Cloudflare’s managed proxy serves the policy intended for its own MX infrastructure, so enable it only after the Email Routing records are healthy.

Optional: add TLS reporting

MTA-STS controls sender behavior, while SMTP TLS Reporting—usually called TLS-RPT—can report failures.

A typical record is:

Type: TXT
Name: _smtp._tls
Content: v=TLSRPTv1; rua=mailto:[email protected]

With the catch-all active, that reporting address can forward to Gmail without being created separately. Be aware that reports are usually machine-readable and may be noisy. A dedicated alias and Gmail label make them easier to manage.

If the domain already has a TLS-RPT record, update it rather than publishing a second conflicting record.

Final verification checklist

• Email Routing shows the domain as active.
• Cloudflare’s MX records are present and no obsolete MX records remain.
• The Gmail destination is verified.
• The catch-all action is active and points to Gmail.
• A test from an unrelated external account reaches Gmail.
• _mta-sts.example.dev resolves through Cloudflare’s MTA-STS CNAME.
• The HTTPS policy URL loads with a valid certificate.
• The policy’s mx value matches Cloudflare’s receiving hosts.
• Optional TLS-RPT reports go to an address you monitor.

The finished result

The setup is small enough to understand at a glance:

Any address @ example.dev
             ↓
Cloudflare receives it over TLS
             ↓
Catch-all routing rule
             ↓
One verified Gmail inbox

The catch-all provides flexible inbound identities without maintaining separate mailboxes. Gmail remains the place where messages are read, searched, filtered, and archived. MTA-STS adds a published transport-security contract for compatible senders.

The most important operational rule is simple: whenever the MX provider changes, review the MTA-STS policy as part of the same migration. DNS may route mail to the new service immediately, while senders can continue caching the old security policy until its max_age expires.

References

For current setup details, refer to Cloudflare’s official documentation:

• Route emails
• Email routing rules and catch-all addresses
• Configure MTA-STS
• RFC 8461