Free email on your own domain with Cloudflare Email Routing and Gmail

Once you own a domain, hello@example.com looks far better on a CV or a contact page than a free webmail address. A hosted mailbox for it usually costs a few dollars a month per address, and for a personal site that's hard to justify. All you really want is for mail to reach the inbox you already read.

Cloudflare Email Routing does exactly that, for free. Cloudflare becomes your domain's mail server, accepts messages for the addresses you choose, and forwards them to Gmail. Gmail's Send mail as feature then lets you reply from the same address.

receiving:  sender ──▶ MX: route1-3.mx.cloudflare.net ──▶ rule hello@ ──▶ forwarded to you@gmail.com
replying:   you@gmail.com ──▶ "Send mail as" hello@example.com ──▶ smtp.gmail.com ──▶ recipient

What you get:

• Free and unlimited addresses. hello@, jobs@, newsletter@, each forwarding wherever you like.
• No mailbox to host. Cloudflare stores nothing. Mail goes straight through to your inbox.
• An optional catch-all that forwards anything sent to @example.com.
• Replies from your domain, sent through your Gmail account, for as long as Gmail supports it.

This guide goes from "my domain has no email" to "mail to hello@ lands in Gmail, and I can answer from it". The last section covers the limits of the free setup, so read it before you print the address on anything.

What you need

• A domain whose DNS is on Cloudflare. If it isn't there yet, Step 1 of the Cloudflare Tunnel guide covers moving the nameservers.
• A Gmail account to receive the mail. Any mailbox works for receiving. The reply steps are Gmail-specific.
• 2-Step Verification turned on for that Google account, for the reply step.

Throughout this post, replace example.com with your domain and you@gmail.com with your mailbox.

Step 1: Add and verify the destination

Cloudflare only forwards to addresses you have proved you own.

1. In the Cloudflare dashboard, open your domain and go to Email > Email Routing.
2. Under Destination addresses, add you@gmail.com.
3. Cloudflare emails that address a verification link, and the address shows as Pending. Click the link. If the email doesn't arrive within a few minutes, check the spam folder.

When the status changes to Verified, the address can be used in rules. Destination addresses belong to your Cloudflare account, so you can reuse a verified one for any other domain you add later.

Step 2: Create the routing rules

Each rule maps one address on your domain to an action.

1. Go to Routing rules > Create routing rule.
2. For Email pattern, enter the part before the @ (for example hello) and pick your domain.
3. For Action, choose Send to an email and select you@gmail.com.
4. Save, and repeat for every address you want, for example mail@.

The Catch-all rule at the top decides what happens to mail for addresses you didn't create. It starts as Drop. Two rules to know:

• Catch-all on means any address works. It's handy for giving every site its own sign-up address (shop-name@example.com), but it also forwards every guess a spammer makes.
• Catch-all off keeps your inbox clean, and you add addresses as you need them. New rules work immediately, with no DNS change.

Step 3: Point the domain's mail at Cloudflare

Mail finds your domain through its MX records. They have to point at Cloudflare, and nothing else.

1. Remove old mail records first. Many registrars (Namecheap, for example) add default forwarding MX and SPF TXT records when you buy a domain, and they come along when you move DNS to Cloudflare. Cloudflare refuses to add its records while other MX records exist ("Existing non-Cloudflare MX records conflict with Email Routing"). Under DNS > Records, delete the old MX records and the old v=spf1 ... TXT record. If you still receive mail through another provider, stop here, because this replaces it.

2. Add Cloudflare's records. Back in Email Routing > Settings, the DNS records section lists what's missing. Click Add missing records. Cloudflare adds and locks these:

   Type	Name	Value
   MX	@	route1.mx.cloudflare.net, route2.mx.cloudflare.net, route3.mx.cloudflare.net
   TXT	@	v=spf1 include:_spf.mx.cloudflare.net ~all (SPF: who may send for the domain)
   TXT	cf2024-1._domainkey	v=DKIM1; ... (DKIM: the key Cloudflare uses to sign forwarded mail)

3. Add a DMARC record. This one tells receiving servers what to do with mail that fails the SPF and DKIM checks. Start in monitor mode, which reports problems but never blocks anything. Under DNS > Records > Add record:

   Type	Name	Content
   TXT	_dmarc	v=DMARC1; p=none; rua=mailto:hello@example.com

The Email Routing overview should now show Routing status: Enabled and DNS records: Locked. Locked records can't be edited by accident while you work on other DNS records.

Step 4: Check it works

Ask DNS what the world now sees:

dig +short MX example.com
# route1.mx.cloudflare.net, route2... and route3..., each with a priority number (the numbers vary)
dig +short TXT example.com                       # "v=spf1 include:_spf.mx.cloudflare.net ~all"
dig +short TXT cf2024-1._domainkey.example.com   # "v=DKIM1; h=sha256; k=rsa; p=..."
dig +short TXT _dmarc.example.com                # "v=DMARC1; p=none; ..."

Then send a real message from a different account, such as a work address or a friend's, to hello@example.com. Gmail tends to hide mail you send to yourself, so a test from the same Gmail account can look like it failed when it didn't. Within a minute or two the message should be in your inbox, and Email Routing > Activity log should list it as forwarded.

Step 5: Reply from your own address in Gmail

Receiving works. Now teach Gmail to send as hello@example.com.

A date to know. Google has announced that, starting January 2027, Gmail will stop supporting "Send mail as" for addresses that aren't hosted by Google, and setting up new ones may stop working before then. Check Google's help page on sending from a different address for the current status before you rely on this step. Receiving through Email Routing isn't affected. If the option is gone, see "The catch" at the end of this post for alternatives.

Create an app password

Gmail will send your custom address through Google's own SMTP server, logged in as your Gmail account. That login needs an app password, a 16-character code just for this. Your normal Google password is rejected.

1. Make sure 2-Step Verification is on in your Google account's security settings.
2. Open myaccount.google.com/apppasswords, name the password (for example "Gmail SMTP example.com"), and create it. Copy the code.

The app password must belong to the same Google account you'll put in the username field, so check which account you're signed in to before you create it.

Add the address

1. In Gmail, go to Settings > See all settings > Accounts and Import > Send mail as > Add another email address. A small popup window opens.

2. Enter your name and hello@example.com. Leave Treat as an alias ticked, and click Next Step.

3. Gmail may suggest an SMTP server for your domain. Replace it with Google's own, because Email Routing only receives mail and can't send it. Fill in:

   Field	Value
   SMTP Server	smtp.gmail.com
   Port	587
   Username	you@gmail.com
   Password	the app password
   Security	TLS (recommended)

4. Click Add Account. Gmail sends a confirmation email to hello@example.com. It arrives through the routing you just built, which makes it a free end-to-end test. Click the link, or enter the code in the popup.

5. Back under Send mail as, choose Reply from the same address the message was sent to. A reply to mail that came in through hello@ then goes out from hello@ by itself.

When you write a new email, the From field now offers hello@example.com.

The catch: DMARC and sending through Gmail

Receiving through Cloudflare is solid. Sending through Gmail works too, but strict receivers (Proton Mail, for example) may show an authentication warning, even though the message is delivered.

The reason is how receiving servers check a sender. DMARC passes only if the message is vouched for by your domain, which is the one in the From line:

• DKIM: Gmail signs your message, but as gmail.com, not example.com.
• SPF: the hidden envelope sender is your Gmail address, so SPF checks gmail.com's servers, not yours.

Both checks pass for gmail.com and neither matches example.com, so DMARC fails. Adding Google's servers to your SPF record doesn't help, because the envelope sender is still gmail.com. Free Gmail can't sign mail for a custom domain.

What to do about it:

• Keep DMARC at p=none while you send this way. Mail is still delivered. Some receivers show a warning, and some may file it as spam. Never move to p=quarantine or p=reject with this setup, or your own replies get filtered.
• For mail that matters, send through a service that signs for your domain. You verify the domain with it by adding a few DNS records (its DKIM key and an SPF include), and messages then pass DMARC everywhere. Receiving can stay on Cloudflare either way. Two routes:
  • An SMTP relay with a free tier, such as Resend, Brevo or Amazon SES. Use its SMTP server in a mail client that can send through any server, or in Gmail's Send mail as for as long as Gmail still allows it.
  • A mailbox provider that hosts your domain, such as Google Workspace, Proton, Zoho or Fastmail. This is the long-term option, since it doesn't depend on Gmail's Send mail as at all. Most are paid, and they replace Email Routing with their own MX records.

Troubleshooting

Symptom	Likely cause	Fix
"Existing non-Cloudflare MX records conflict with Email Routing"	The registrar's old forwarding records are still there	Delete the old MX and SPF TXT records, then click Add missing records again
Destination address stays Pending	The verification link wasn't clicked	Check spam, or resend it from Destination addresses
Mail to hello@ never arrives	MX doesn't point at Cloudflare, or the rule is off or targets an unverified address	Run dig MX, then check the rule and the Activity log
Forwarded mail lands in spam	Missing SPF or DKIM records	Check them with dig, and mark the message as not spam once
"Send mail as" fails with error 535, "Username and Password not accepted"	A normal password, or an app password from a different Google account	Create an app password in the account named in the username field. With several accounts signed in, a private window with just that account helps
Receivers show an authentication warning on mail you sent	Mail sent through Gmail's SMTP fails DMARC alignment	See "The catch" above

Recap

1. Verify your Gmail address as a destination in Email Routing.
2. Create a routing rule for each address. Leave the catch-all off unless you want it.
3. Remove the old MX and SPF records, click Add missing records, and add DMARC with p=none.
4. Test from another account and check the Activity log.
5. To reply, add the address to Gmail's Send mail as with smtp.gmail.com and an app password, while Gmail still supports it.
6. Know the DMARC limit, and move to a service that signs for your domain when deliverability matters.

Your domain now receives email at any number of addresses, without a mailbox to pay for or a mail server to run.