Free Custom Domain Email: Complete Guide to Cloudflare Email Routing + Gmail

Audience: solo operators and developers who already own a domain but still use a personal Gmail  ·  Format: step-by-step how-to  ·  2026-07-06

A domain email address without a monthly subscription

Say you already own a domain and have a site attached to it. But the email on your business card or contact page is still mybrand2025@gmail.com, that reads as amateur-tier.

The "proper" fix is usually a paid mail service like Google Workspace, which bills per user every month. For a solo operator who just needs one address, that's hard to justify indefinitely.

The combination most solo operators end up choosing: Cloudflare Email Routing receives mail for free and forwards it to your existing Gmail, while Gmail's Send mail as feature sends replies from your domain address.

One sentence summary: your domain address is the front door; Gmail does all the actual work behind it. From the outside everything comes from hello@mcpy.kr, but the mailbox where everything piles up, and the hand writing replies, is just your regular Gmail.

This guide walks through the whole setup from start to finish. Public examples use the real address hello@mcpy.kr; the actual receiving Gmail is shown as you@gmail.com, replace that with your own.

Order matters. You have to complete nameserver delegation and get inbound mail fully working before outbound authentication will succeed. The reason will be clear later. For now just remember: delegation first, receive second, send last.

Three things that will block you if skipped

Before anything else, here are the three points beginners most commonly miss. Everything else you can follow in order, but these three will cause "I did everything and it still doesn't work" if omitted.

• 1. Nameserver delegation (step zero). Change the nameservers at your registrar (e.g. Gabia) to Cloudflare's and wait for the domain status to show "Active." Every DNS record you add afterwards is invisible to the internet until this is done.
• 2. DMARC record. SPF and DKIM alone are not enough. One _dmarc TXT record tells receiving servers to trust your domain's mail and is less likely to be flagged as spam.
• 3. Verify destination before creating the routing rule. You must verify your Gmail address as a destination (Verified status) before a routing rule can use it as a target. Doing it in reverse order means the rule won't stick.

Two prerequisites: a domain and a Gmail account with two-step verification turned on. Two-step verification is required to generate an app password later, if it's not enabled, you'll hit a wall at that step.

Step 0. Delegate nameservers from Gabia to Cloudflare

This is where everything starts. A nameserver is the pointer that tells the internet "this domain's DNS is managed here." Even if you bought the domain at Gabia (a Korean domain registrar), you point that sign toward Cloudflare so Cloudflare can manage the DNS records.

The process: add your domain mcpy.kr in Cloudflare, and Cloudflare will give you two nameservers (e.g. xxx.ns.cloudflare.com, yyy.ns.cloudflare.com). Enter those two values in the nameserver settings inside Gabia's management console.

Here's where beginners get impatient. Nameserver changes don't propagate instantly, you have to wait until the domain's status in the Cloudflare dashboard shows Active. This usually takes anywhere from a few minutes to a few hours.

Why is this step zero? No matter how many MX, SPF, or DKIM records you add, the outside world can't see them until the domain is Active. "I set everything up but mail bounces" is caused by incomplete delegation nine times out of ten. Confirming Active here saves you half a day of debugging later.

Once you save the values, you've handed the ball to Cloudflare. Whether the change has actually propagated is judged by Cloudflare's status, not by your registrar.

Step 1. Enable Email Routing in Cloudflare (auto-generates MX, SPF, DKIM)

Once the domain is Active, go to Email → Email Routing in the Cloudflare dashboard and click Enable Email Routing. Cloudflare will propose the DNS records needed for inbound mail. Apply the proposed records as-is.

Cloudflare creates three types of records. Based on the official documentation:

• MX records: Tell the internet "route mail for this domain to Cloudflare's servers." Usually creates three with different priorities.
• SPF (TXT record): An authorization slip saying "Cloudflare is allowed to handle mail for this domain." This is what spam filters use to trust the mail.
• DKIM (TXT record): An anti-forgery signature attached to forwarded mail, proving content wasn't altered in transit.

It's worth understanding what each record does, if something breaks later, it's almost always one of these three (plus DMARC from the next step).

MX (Mail Exchanger) specifies which server should receive mail for the domain. Without it, or with a wrong value, every mail server in the world has no idea where to deliver mail to your domain and simply bounces it. Cloudflare fills in MX hosts of the form *.mx.cloudflare.net.

One thing to flag: older guides hard-code route1.mx.cloudflare.net, route2, route3 as MX values, but Cloudflare assigns different hostnames per account and domain. Use exactly the three values your dashboard generates, do not copy hostnames from someone else's guide. The priority numbers should also come from your dashboard.

SPF prevents sender spoofing. The value Cloudflare inserts, per the official postmaster docs, is v=spf1 include:_spf.mx.cloudflare.net ~all. This tells receiving spam filters that Cloudflare is legitimately handling mail for your domain.

DKIM adds a digital signature to the email body, proving the content wasn't changed in transit. Cloudflare Email Routing uses the selector cf2024-1._domainkey. Without SPF and DKIM, forwarded mail is likely to be flagged as spam or rejected outright.

Step 2. Add DMARC (the most commonly skipped record)

A common scenario: you finish SPF and DKIM and then wonder "why does my mail keep landing in spam?" The missing piece is DMARC. Cloudflare doesn't always add it automatically, so adding it manually is the safe move.

As explained in the Cloudflare official docs, DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. Having a DMARC policy means major mail services are more likely to trust your domain's mail.

Add this TXT record in Cloudflare DNS → Records:

Breaking this down: p=none is monitoring mode, "don't block failures yet, just watch." Start with none while you confirm mail is flowing normally; tighten to quarantine or reject later if needed. rua=mailto:hello@mcpy.kr asks receiving servers to send authentication reports to that address, so you can see which messages are failing.

SPF, DKIM, and DMARC are a trio. SPF says "this server is authorized to send," DKIM says "the content is unchanged," and DMARC says "if either of those fails, here's how to handle it, and please send me a report." All three together give you reliable inbox delivery.

Step 3. Verify DNS records are live

Adding records doesn't mean they're visible yet. External DNS has to actually resolve the MX before inbound mail works. Check in two places: inside Cloudflare, confirm DNS → Records shows 3 MX rows plus SPF, DKIM, and DMARC. Outside Cloudflare, the most reliable check is a terminal query:

dig MX mcpy.kr +short
# If correct, three lines with priority numbers and *.mx.cloudflare.net hosts appear

If nothing shows up, or you see MX records from a previous mail service, the change hasn't propagated yet. There are typically two causes: incomplete nameserver delegation from step 0 (most common) or simply a propagation delay. If nameservers are confirmed Active in Cloudflare, wait a little and query again.

There's one more trap for domains that previously used another mail service. If old MX records are still present alongside Cloudflare's, mail delivery is unpredictable. Remove any leftover MX records so only Cloudflare's three remain.

Step 4. Register and verify the destination Gmail (Verified)

The MX records are ready to receive mail. Now tell Cloudflare where to forward that mail. Cloudflare won't forward to just any address, you must register the destination address and prove you own it.

Go to Email Routing → Destination Addresses, add you@gmail.com (your Gmail), and Cloudflare will send a confirmation email to that Gmail. Click Verify email address in that email and the address is verified. This is also documented in the official guide.

This is sensible security: without ownership verification, anyone could configure forwarding to someone else's inbox, turning Cloudflare into a mail-bombing relay. Until the destination shows Verified status, it can't be used as a forwarding target in a routing rule. Finishing this verification first is the critical ordering requirement.

This confirmation email is sent by Cloudflare directly to Gmail, not through your domain routing, so it will arrive even before your routing is fully set up. If it doesn't appear in your inbox, check spam.

Step 5. Create the routing rule (hello@mcpy.kr → your Gmail)

With the destination Verified, add the final connection: a routing rule that says "send mail arriving at hello@mcpy.kr to you@gmail.com."

In Email Routing's rule screen, set it up as follows:

Once this rule is active, mail sent to hello@mcpy.kr flows into you@gmail.com. Start with one main address. You can always add more rules later, support@, team@, or any role-based address, just by adding additional routing rules.

This completes the receive side of the setup. At this point, if someone sends a test email to hello@mcpy.kr, it should arrive in your Gmail inbox. When it does, inbound mail is confirmed, and that confirmation is required before outbound authentication will work.

Step 6. Configure Gmail to send from your domain address

Cloudflare Email Routing is receive-only. To reply using hello@mcpy.kr as the From address, you need a separate setting in Gmail. Without it, replies go out from your personal Gmail, which confuses the recipient.

Use Gmail's Send mail as feature. Based on the official Gmail help article, the path is:

• Gmail → Settings (gear icon) → See all settings → Accounts and Import tab
• Send mail as → Add another email address
• Enter your display name and hello@mcpy.kr; check "Treat as an alias"

The display name is what appears in the recipient's inbox as the sender name. "Treat as an alias" controls whether Gmail treats this as another face of the same account, for an individual adding their own domain address, check this. After clicking Next, Gmail asks for SMTP credentials, that's the next step.

Step 7. Enter SMTP and the app password (two-step verification required)

When registering an external address as a Send mail as source, Gmail verifies the account through SMTP authentication. Enter the following values:

Port 587 with TLS is the standard outbound combination today. There is one landmine nearly every beginner steps on here: entering your regular Gmail login password in the password field will fail. The error you'll see is 534-5.7.9 Application-specific password required.

Order matters again here. An app password can only be created after two-step verification is already turned on. With 2FA disabled, the app password menu doesn't even appear. That's why "Gmail with two-step verification enabled" was listed as a prerequisite. Google also confirms that app passwords are only issued for accounts with 2-step verification active.

To create an app password: with two-step verification already on, go to Google Account → Security → App passwords, give it a name (e.g. domain-mail), and generate. A 16-character string appears, that's the key.

One critical warning: this 16-character string is shown only once. Once you close the window, it's gone. Copy it into the SMTP password field immediately or save it somewhere secure. If you miss it, you'll have to generate a new one.

Step 8. Verify the sender address (receive must be live for this loop to close)

After entering the SMTP credentials, Gmail sends a confirmation email to hello@mcpy.kr. You need to click the link inside it to complete sender verification. Think about where that confirmation email will go, this is where the whole structure of this guide becomes clear.

The verification loop works like this: Gmail sends a verification email to hello@mcpy.kr. That email travels through the domain's MX record into Cloudflare. Cloudflare routing forwards it to your Gmail (you@gmail.com). You click the link right there in your inbox. In other words, the verification email makes one round trip back to you.

That means inbound mail must be working before the sender verification email can arrive. If you try to configure sending before receive is set up, the confirmation email bounces or never arrives, and you get stuck wondering why verification won't complete, when the real problem is that inbound mail isn't configured yet.

That's why this guide has repeated "delegation first, receive second, send last" throughout. If the hello@mcpy.kr receive test passed in the previous step, this confirmation email follows the same path and arrives safely. Click the link and you're done.

Step 9. Test both directions for real

Don't trust the setup is complete just because you got through the steps. Test both directions and confirm delivery with your own eyes, that's when you can call it done.

For the receive test, send an email from any other account to hello@mcpy.kr. If the message arrives in your you@gmail.com inbox with subject and body intact, receive is working.

For the send test, compose a new email in Gmail, change the From field to hello@mcpy.kr, and send it to an external address. If the recipient sees the sender as hello@mcpy.kr (not your personal Gmail), send is working too.

Both passing means your domain email is fully operational. In Gmail's Send mail as list, set hello@mcpy.kr as the default From address so every new email goes out from your domain address automatically.

Step 10. Set up a Gmail spam filter (skipping this sends real messages to spam)

The final step is easy to overlook. Mail forwarded by Cloudflare arrives looking like it came through your domain rather than directly from the original sender, so Gmail occasionally misclassifies it as spam. The DMARC record from step 2 helps reduce this, but a Gmail filter locks it in.

Path: Gmail Settings → Filters and Blocked Addresses → Create a new filter. Enter from:(hello@mcpy.kr) as the condition, then on the next screen check "Never send it to Spam." This ensures mail coming to your domain address lands in your inbox, not spam.

Why this matters: even if everything else is configured perfectly, a customer inquiry sitting in spam is as good as missed. This is the last safety net for inbound mail.

Troubleshooting: where to look first

Problems almost always come from a small set of known places. Knowing which symptom points where saves a lot of time.

Confirmation email bounces / no relevant answers error. Almost always an inbound issue. The typical error is DNS type 'mx' lookup of mcpy.kr had no relevant answers, "can't find MX records." Check in order: are Gabia's nameservers actually pointing to Cloudflare and showing Active? (most common cause), do 3 MX records exist in Cloudflare DNS, is the destination Verified, is the routing rule Enabled? Incomplete nameserver delegation makes all DNS records invisible to the internet regardless of what's in Cloudflare.

SMTP authentication fails. If 534-5.7.9 Application-specific password required appeared, you entered your login password. Enable two-step verification, generate a new app password, and re-enter it. Also double-check server smtp.gmail.com, port 587, TLS.

Gmail keeps showing "Unverified." The confirmation email wasn't received or the link wasn't clicked. Wait a few minutes, resend the verification email, and check both inbox and spam. Cloudflare's Activity Log also shows whether that email was actually routed.

Mail arrives but keeps going to spam. The DMARC record (_dmarc TXT) is missing, or the Gmail filter from step 10 wasn't created. Check both.

When you outgrow a solo setup

This setup's limitation is worth being honest about: all real mail lives in a single Gmail account. Perfect for solo use, but once the team grows, the lack of separate permissions and shared mailboxes starts to become awkward.

There's no need to rebuild everything immediately. The lightest option is to keep the current structure and just add more addresses. Add a Cloudflare routing rule for support@mcpy.kr pointing to one person's Gmail, and another for biz@mcpy.kr pointing to another. Fast, still free, but no access control or audit trail.

When the team grows beyond two or three people and each person needs an independent @mcpy.kr mailbox, that's when to consider switching to a paid team mail service like Google Workspace. That's when you get per-user mailboxes, organizational accounts, and permission revocation for departing employees. You could also keep the main domain address on the free setup and put only core team members on paid accounts. The point is sequence: start free, migrate when the need arises, no reason to pay team rates from day one.

Summary: follow this order and you won't get stuck

The explanations end here. When you actually sit down to do this, the checklist below and its verification questions are all you need. Skip any one of them and it will come back to bite you.

If you can only remember one thing, make it this:

Delegation first, receive second, send last. Even the verification email travels that same path.

Sources

• MX, SPF, DKIM auto-creation and destination verification: Cloudflare Docs, Enable Email Routing
• SPF value, DKIM selector (cf2024-1), and exact record values: Cloudflare Docs, Email Routing Postmaster
• DMARC combines SPF and DKIM to define failure handling: Cloudflare Docs, DMARC Management
• Gmail Send mail as and SMTP settings: Google Support, Send emails from a different address
• App passwords require 2-step verification and are shown only once (16 characters): Google Support, Sign in with app passwords

Public brand values (mcpy.kr, hello@mcpy.kr) are used as real examples. The receiving Gmail is shown as a placeholder (you@gmail.com), substitute your own address. App password values are not included. MX hostnames, priority numbers, and the two nameserver values are assigned per domain by Cloudflare, so use whatever your own dashboard generates rather than copying values from this or any other guide.