Professional Business Email for $0: Cloudflare Email Routing + Gmail SMTP Actually Works

TL;DR: The thing that pushed me to figure this out was a $72 invoice. Six bucks a month sounds trivial until you're running three projects and suddenly you're paying Google $18/month just so your emails don't come from a Gmail address.

📖 Reading time: ~26 min

What's in this article

1. The Problem: You Want [e-mail] Without Paying $6/Month Per Seat
2. What You Need Before You Start
3. Step 1: Enable Cloudflare Email Routing on Your Domain
4. Step 2: Create Your Email Route (Forwarding Rule)
5. Step 3: Generate a Gmail App Password for SMTP
6. Step 4: Add a Send-As Address in Gmail
7. Step 5: Fix Your SPF Record So Emails Don't Land in Spam
8. Step 6: Test the Full Loop

---

The Problem: You Want [e-mail] Without Paying $6/Month Per Seat

The thing that pushed me to figure this out was a $72 invoice. Six bucks a month sounds trivial until you're running three projects and suddenly you're paying Google $18/month just so your emails don't come from a Gmail address. For solo devs and small teams, that math gets offensive fast — especially when you're not even using Calendar sharing or Drive storage that justifies Workspace.

Zoho Mail's free tier looks tempting on paper. You get custom domain email, it works, and the webmail UI is fine. But the SMTP sending limits are where it quietly breaks. You're capped at 100 outbound emails per day on the free tier, and if you're doing any kind of transactional mail, password resets, or client updates, you'll hit that ceiling faster than you expect. I burned a week on Zoho before realizing the limits weren't going to work once I was sending from a web app.

What you actually need is simpler than any of the paid options make it seem: receive mail at your custom domain, and send from your existing Gmail account with your domain as the "From" address. That's it. You don't need a new inbox. You don't need to learn a new email client. Your Gmail account becomes the interface, and your domain email is just the identity layer on top.

The stack that makes this free: Cloudflare Email Routing forwards anything sent to [e-mail] to your personal Gmail. Then Gmail's "Send mail as" feature, configured with your domain registrar's SMTP relay (or Gmail's own), handles outbound so replies show your domain address. Cloudflare doesn't publish hard sending limits for Email Routing — it's treated as infrastructure, not a metered service. Total cost assuming you own the domain: $0. Domain registration runs you ~$10-15/year depending on the TLD, but you were probably buying that anyway.

One honest caveat before you spend time on this: this setup is not for high-volume sending. Gmail's free SMTP relay caps you at 500 emails per day (to a max of 500 unique recipients), and Gmail accounts used heavily for outbound can get flagged. If you're running a SaaS with 500+ outbound emails daily — password resets, notifications, receipts — skip this entirely and go straight to Postmark ($15/month for 10K emails) or AWS SES ($0.10 per 1,000). This setup is for the professional appearance problem, not the bulk delivery problem. For a broader look at tools worth paying for versus rigging for free, the Essential SaaS Tools for Small Business in 2026 guide covers the tradeoffs across the full stack.

What You Need Before You Start

The only real blocker here is the domain. Everything else you can set up in minutes, but if your domain isn't already on Cloudflare's nameservers, you're looking at DNS propagation time before anything works — and that can be anywhere from 15 minutes to 48 hours depending on your registrar. Check your current nameservers with:

dig NS yourdomain.com +short
# or on Windows
nslookup -type=NS yourdomain.com

If you see anything other than ns1.cloudflare.com and ns2.cloudflare.com (or similar Cloudflare nameservers), you'll need to either migrate to Cloudflare or use a completely different approach for email routing. The free email routing feature is exclusive to domains managed through Cloudflare DNS — there's no workaround. Adding the domain to Cloudflare and updating your registrar's nameservers is usually a 10-minute task, but budget an extra few hours for propagation before testing anything.

For the Gmail side: use a secondary Google account, not your main personal one. Here's why — you're going to configure this account's SMTP server to send mail as your custom domain address. Your "Sent" folder, storage, and spam filters all live in that Gmail account. If something gets misconfigured, you don't want business replies and personal emails tangled together. A free Gmail account created specifically for this setup costs you nothing and keeps things clean.

The App Password requirement catches people off guard. Google removed the option to use your regular Gmail password with third-party SMTP clients back in 2022. You now must have 2FA enabled on the account before the App Passwords option even appears in your Google Account settings. The flow is:

1. Go to myaccount.google.com/security
2. Enable 2-Step Verification if it isn't already on
3. Search for "App passwords" in the Google Account search bar — it won't appear in the nav otherwise
4. Generate a password for "Mail" / "Other device" — name it something like "Cloudflare Business Email"

Save that 16-character App Password somewhere immediately. Google shows it exactly once. You'll be pasting it into Gmail's SMTP settings later, and if you lose it, you generate a new one — minor annoyance, but avoidable. With that in hand and your domain on Cloudflare nameservers, you're actually ready to start.

Step 1: Enable Cloudflare Email Routing on Your Domain

The thing that surprised me when I first set this up was how fast Cloudflare provisions the DNS records — we're talking under 60 seconds from clicking "Get Started" to seeing all three MX records live in the DNS table. No ticket, no waiting for propagation, no manual copy-pasting of values.

Head to your Cloudflare dashboard, pick your domain from the list, then look for Email in the left sidebar. From there, click Email Routing, then the blue Get Started button. Cloudflare will immediately stage the DNS records it needs. Once you confirm, your DNS zone gets three MX records added automatically:

route1.mx.cloudflare.net  (priority 17)
route2.mx.cloudflare.net  (priority 28)
route3.mx.cloudflare.net  (priority 55)

It also drops in a TXT record for SPF on your root domain:

v=spf1 include:_spf.mx.cloudflare.net ~all

Screenshot this TXT record or paste it somewhere. When we layer in Gmail SMTP sending later, we're going to modify this SPF string — and you need to know the Cloudflare part is already there so you don't accidentally overwrite it. SPF records are "last write wins" and you can only have one. Clobbering this record is the #1 reason the whole setup breaks silently later.

The gotcha that bites almost everyone: if your domain ever had a previous mail provider — a cPanel host, a Zoho free trial, Google Workspace that lapsed — there are old MX records sitting in your DNS. Cloudflare will flag this with a warning and refuse to mark routing as active. It will not delete those old records for you. You have to go into the DNS tab yourself, find the old MX entries, and manually delete them. Common culprits look like:

• mail.yourdomain.com pointing to a shared hosting server
• mx.zoho.com / mx2.zoho.com from a forgotten trial
• aspmx.l.google.com from an expired Workspace account

Delete all of them. Only Cloudflare's three mx.cloudflare.net records should remain. After cleanup, go back to Email Routing and check the status indicator at the top of the page. You want a green dot that says Active — not "Misconfigured", not "Pending". If it still shows misconfigured after deleting the old records, hit the re-check button and give it 30 seconds. DNS within Cloudflare's own zone propagates almost instantly since they control the authoritative nameserver directly, so if it's still broken after a minute, you missed a record somewhere.

Step 2: Create Your Email Route (Forwarding Rule)

The thing that trips most people up here isn't the configuration — it's the verification step that Cloudflare quietly requires before anything actually works. Skip that email confirmation and you'll spend 20 minutes wondering why your test emails are disappearing into a void.

Go to your Cloudflare dashboard → select your domain → Email → Email Routing → Routing Rules. Hit Create address. The setup is two fields: the custom address you want (the part before the @) and the Gmail address you want it forwarded to. Pick something you'd actually put on a business card:

Custom address:  [e-mail]
Action:          Send to → [e-mail]

The moment you save that rule, Cloudflare fires a verification email to your Gmail. You must click the confirm link in that email — Cloudflare holds the route in a pending state until you do. Check your spam folder too, because Gmail occasionally sandboxes Cloudflare's verification messages. Once confirmed, the rule status flips from "Unverified" to active and you're live. The whole thing takes under 90 seconds if you catch the email fast.

Immediately send a test email to [e-mail] from a completely separate account — not the Gmail you're forwarding to, because that creates a loop. A throwaway account or a colleague's address works fine. You should see it land in Gmail within 60 seconds. If it takes longer than two minutes, the MX records haven't propagated yet — Cloudflare sets these automatically when you enable Email Routing, but DNS propagation can lag. Give it 10 minutes max and try again before digging into anything else.

You can create multiple routing rules on the same domain — hello@, support@, invoices@, all forwarding to the same Gmail or different ones. Each destination address needs its own verification click, so if you're setting up three addresses at once, watch for three separate confirmation emails.

The catch-all option is under Routing Rules → Catch-all address at the bottom of the page. Flip it to "Send to" your Gmail and enable it. This means [e-mail] — literally any prefix — routes to your inbox. That's genuinely useful when someone typos your address or when you give out variations like [e-mail] for tracking which services sell your email. The real downside: spambots constantly probe random addresses at domains they find, so admin@, webmaster@, noreply@ will all start delivering junk. My take — enable catch-all only if you're actively using the tracking trick or expecting inbound from unpredictable addresses. Otherwise stick to explicit rules and keep your inbox cleaner.

Step 3: Generate a Gmail App Password for SMTP

The thing that trips most people up here: the App Passwords menu is hidden behind 2-Step Verification. If 2FA isn't enabled on your Google account, the option simply doesn't appear — no error, no explanation, it's just not there. Go enable 2FA first, then come back. The second gotcha is that App Passwords are a personal Gmail feature only. If you're signed into a Google Workspace account (your email ends in a custom domain and an admin manages it), this entire flow doesn't apply to you — your admin controls SMTP credentials separately.

Once 2FA is confirmed active, navigate directly to the right spot:

https://myaccount.google.com/apppasswords

Or go the manual route: myaccount.google.com → Security → How you sign in to Google → 2-Step Verification → scroll to the bottom → App passwords. Google moves this UI around occasionally, so if you can't find it, the direct URL above always works. You'll be asked to re-authenticate before you see the form.

In the App passwords form, the dropdowns are a bit misleading. For "Select app" choose Mail. For "Select device" choose Other (Custom name) and type something descriptive like Business Email SMTP — not "my phone" or "laptop", something that'll make sense to you in six months when you're auditing what has access to your account. Hit Generate.

Google returns a 16-character password formatted with spaces like abcd efgh ijkl mnop. The spaces are cosmetic — when you paste it into Gmail's SMTP settings later, paste the whole string including spaces, or strip them, both work. What doesn't work is closing that modal and expecting to retrieve it later. Google shows it exactly once. No "view again" button, no recovery option — if you lose it you revoke the old one and generate a new one, which means updating your Gmail settings again.

Put this password in your password manager right now, before you do anything else. Label it something like Gmail SMTP — Business Email ([e-mail]). A Notion doc is not acceptable storage for this — Notion pages get shared, exported, accidentally made public. A sticky note gets photographed. Your password manager (1Password, Bitwarden, whatever you use) is the right home. If you don't use a password manager yet, this is a good forcing function to start.

Step 4: Add a Send-As Address in Gmail

The "Treat as an alias" checkbox is the one thing that trips people up here. Leave it unchecked. If you check it, Gmail treats both addresses as the same inbox and handles replies inconsistently — sometimes it'll respond from your personal address even when someone emailed your business address. Unchecked means Gmail treats it as a genuinely separate sending identity.

Go to Gmail → click the gear icon → See all settings → Accounts and Import tab → find the "Send mail as" section → click Add another email address. A popup appears. Fill in whatever display name recipients should see — your full name, your company name, "Support Team", whatever fits. For the email address, enter your actual business address like [e-mail]. Then uncheck that alias box and hit Next.

The SMTP screen is where people fumble if they use the wrong credentials. Use exactly these settings:

SMTP Server:  smtp.gmail.com
Port:         587
Username:     [e-mail]   (your FULL Gmail, not the business one)
Password:     xxxx xxxx xxxx xxxx             (the 16-char App Password, spaces don't matter)
Security:     TLS

The username being your personal Gmail address surprises most people — you're authenticating to Google's servers as yourself, then telling it to send from the business address. If you paste your App Password here and get an auth error, double-check that you're not accidentally using your real Gmail password. Google will silently reject it without a helpful error message in some cases.

After you click Add Account, Gmail fires off a verification email to [e-mail]. This is the satisfying moment where the whole chain clicks: Cloudflare forwards that email → to your Gmail inbox → you grab the 6-digit code → paste it back into the confirmation box. It feels circular because it is, but it's exactly how you confirm you actually control that address. Check your inbox within a few minutes — the code expires.

Once verified, go back to Accounts and Import and click make default next to your business address. From that point on, every new email you compose will show [e-mail] as the sender. You can still manually switch to your personal address per email using the "From" dropdown — but the default will be your business address, which is what you want 95% of the time.

Step 5: Fix Your SPF Record So Emails Don't Land in Spam

The thing that trips most people up at this stage: Cloudflare auto-creates an SPF record when you enable Email Routing, and Gmail needs its own entry in that same record. Two legitimate senders, one record — and if you naively add a second TXT record for Gmail, you've just broken SPF entirely. Email receivers that see multiple SPF records will treat both as invalid and reject or spam your mail.

Log into Cloudflare, go to your domain's DNS settings, and find the TXT record that was created automatically. It looks like this:

v=spf1 include:_spf.mx.cloudflare.net ~all

Edit that existing record — don't create a new one. Add include:_spf.google.com so the final value is:

v=spf1 include:_spf.mx.cloudflare.net include:_spf.google.com ~all

The ~all at the end is a softfail, meaning mail from unlisted servers gets flagged rather than outright rejected. That's fine for most setups. Don't change it to -all (hardfail) until you're confident every sending path is covered — one misconfiguration and your own legitimate emails bounce.

After saving, verify it propagated correctly. Run this from your terminal:

dig TXT yourdomain.com +short

You want to see exactly one line starting with v=spf1. If you see two, delete one immediately — it doesn't matter which content is "more correct," having two is worse than having one incomplete record. DNS propagation typically takes a few minutes with Cloudflare since they push changes fast, but give it up to 15 minutes before panicking.

On DKIM: Cloudflare Email Routing currently does not add DKIM signatures to mail it forwards. That's a known limitation. The good news is Gmail's SMTP does DKIM-sign outbound mail automatically using Google's own keys, so any reply you send through Gmail's SMTP is properly signed. You don't need to configure anything extra for that path. Where you're unprotected is inbound mail that gets forwarded onward — but since you're the final recipient in this setup, that's not a real attack surface. If you eventually want to send transactional mail or need full DMARC alignment, that's when you'd add a custom DKIM record, but for a professional inbox that costs $0, the Gmail SMTP signing alone gets you past most spam filters.

Step 6: Test the Full Loop

Most people declare victory after clicking "Send test" in the SMTP settings dialog. Don't. That test only confirms the credentials work — it doesn't tell you whether replies show the right sender, whether your headers are clean, or whether Gmail silently re-routes the From address back to your personal account. Run the full loop before you trust this setup with real clients.

Step 1: Inbound Test — External → Your Domain

Grab a non-Gmail account (a work Outlook, a friend's Yahoo, anything off Google's infrastructure) and send a plain-text email to [e-mail]. You're specifically looking for two things: it lands in your Gmail inbox within 60 seconds, and the To field shows [e-mail], not your personal Gmail address. If it doesn't arrive, go back to your Cloudflare Email Routing dashboard and verify the MX records have propagated — run this to check:

# Should return Cloudflare's MX hosts: route1/2/3.mx.cloudflare.net
dig MX yourdomain.com +short

Propagation can take anywhere from 2 minutes to a few hours depending on your previous TTL settings. If the MX records are correct but mail still isn't arriving, check the "Activity" log inside Cloudflare Email Routing — it'll tell you whether the forward is failing silently.

Step 2: Reply Test — The From Address Is the Whole Point

Reply to that inbound test email from inside Gmail. Before hitting send, look at the From field. If you configured the "Send mail as" alias correctly in Gmail Settings → Accounts, you should see [e-mail] selected automatically — Gmail is smart enough to match the alias when you reply to mail delivered via that route. If it defaulted back to your personal address, go to Settings → Accounts and Info → Send mail as, find your domain alias, and tick "Reply from the same address the message was sent to." Have the recipient confirm what they see in the From header — not just the display name, the actual address.

Step 3: Compose a New Outbound Email

This is the test most people skip. Composing a fresh email (not a reply) means Gmail defaults to your primary account unless you manually change it. Click the From field, switch to [e-mail], send to the same external account, and have them check two things: the sender address and the display name. The display name comes from whatever you set in the "Send mail as" dialog — if you put "Alex | Acme Co" there, that's what recipients see. Clean. Professional. Zero cost.

Step 4: Read the Raw Headers

In the received email on the external account, pull up the raw headers. In Gmail that's the three-dot menu → "Show original." You're hunting for three specific lines:

• SPF=pass — confirms Google's servers are authorized to send for your domain. If you see softfail or neutral, your SPF record is missing or misconfigured.
• DKIM=pass — Gmail signs outbound mail with Google's DKIM key automatically. You don't configure this yourself, but verify it's present.
• Sending IP resolves to Google — look for something like mail-sor-f69.google.com in the Received headers. This confirms the mail actually routed through Google's SMTP and not some third-party relay.

The thing that catches people off guard: if you see a mailed-by header showing smtp-relay.gmail.com but signed-by showing your domain, that's actually correct and good. Gmail's "Send mail as" feature using the SMTP relay path signs with Google's infrastructure but associates the identity with your domain. Recipients and spam filters both respect this.

Step 5: Run mail-tester.com Before You Go Live

Go to mail-tester.com, grab the unique test address they generate (looks like [e-mail]), and send a real email to it from your [e-mail] alias — write an actual sentence or two, not just "test." Then check your score. Aim for 8/10 or higher. Common reasons you'd land below that:

• No SPF record on the domain (should already be handled if you're routing through Google, but double-check)
• Plain-text only email with no body content — spam filters penalize empty test messages
• Your domain is brand new and has no sending history — this hurts the score slightly but resolves itself after a few weeks of clean sends
• Missing List-Unsubscribe headers — only relevant for bulk mail, not transactional, so don't panic about this one

A score of 9.5/10 or 10/10 is achievable with this setup. I've hit it consistently on fresh domains using Cloudflare routing + Gmail SMTP because you're piggybacking on Google's IP reputation rather than sending from a cold, unknown mail server. That's the actual value of this whole approach — not the $0 cost, but the deliverability you get for free by using Google's infrastructure.

Gotchas I Hit (And How to Get Around Them)

Most of these problems have a one-line fix once you know what you're looking at. The annoying part is that the error messages don't tell you that. Here's what I actually ran into and how I got past each one.

Verification Email Never Arrived

Before anything else, check Gmail's spam folder — Google occasionally flags verification emails from custom domains as suspicious. If it's not there, the issue is almost always that your routing rule wasn't saved properly in Cloudflare Email Routing, or the destination Gmail address hasn't been verified yet. Cloudflare requires you to click a confirmation link in that destination inbox before it'll actually forward anything. Go back to Email → Email Routing → Routes and confirm the rule shows "Active" not "Pending". If it says Pending, Cloudflare already sent a confirmation — check that Gmail inbox again, including spam.

Gmail Saying "Username and Password Not Accepted" Over SMTP

This one ate 45 minutes of my afternoon once. The error looks like an auth failure but it's almost never your actual credentials — it's that you used your real Gmail password instead of a generated App Password. Google's SMTP server rejects regular passwords if 2FA is on, full stop. Go to myaccount.google.com → Security → 2-Step Verification → App passwords, generate one specifically for this mail setup, and use that 16-character string in Gmail's SMTP config instead. Also double-check that 2FA is fully activated, not just "set up" — I've seen accounts where 2FA was mid-enrollment and the App Passwords option simply doesn't appear.

# SMTP settings that actually work
SMTP Host: smtp.gmail.com
Port: 587
Encryption: TLS/STARTTLS
Username: [e-mail]   ← your real Gmail, not the custom domain
Password: xxxx xxxx xxxx xxxx           ← 16-char App Password, no spaces

Your Emails Landing in Recipients' Spam

Nine times out of ten this is a broken SPF record — either missing a required include, or you've got two SPF records fighting each other (which invalidates both). Run this and look carefully at the output:

dig TXT yourdomain.com | grep spf

You should see exactly one TXT record starting with v=spf1. It needs to include both Cloudflare's mail infrastructure and Google's. If you set these up at different times, you may have accidentally created two separate SPF records. Merge them into one:

v=spf1 include:_spf.mx.cloudflare.net include:_spf.google.com ~all

Multiple SPF records = immediate SPF fail for most receiving mail servers. Delete duplicates mercilessly.

Cloudflare Email Routing Shows "Misconfigured"

This almost always means there's a leftover MX record from a previous provider — your old web host, a legacy G Suite setup, whatever. Cloudflare Email Routing requires that it fully controls your MX records. Go to DNS → Records, filter by type MX, and delete anything that isn't one of Cloudflare's three official entries:

route1.mx.cloudflare.net  (priority 86)
route2.mx.cloudflare.net  (priority 41)
route3.mx.cloudflare.net  (priority 30)

If you see aspmx.l.google.com or anything from your old registrar still in there, that's your problem. Kill it.

Send-As Still Showing Your Personal Gmail Address

Two separate things need to be configured for this to work correctly. First, when you added the Send-As address in Gmail settings, "Treat as an alias" must be unchecked — this is what forces Gmail to actually authenticate via SMTP rather than just slapping a different From header on outbound mail. Second, go to Settings → Accounts → Send mail as and click "make default" next to your custom domain address. Otherwise Gmail falls back to your personal address for new emails and some mobile clients entirely ignore the per-thread From selection.

Hitting the 500 Email/Day Ceiling

Google's free tier caps outbound SMTP at 500 emails per 24-hour rolling window per account. That sounds like a lot until you're running a mailing list, sending order confirmations, or doing any kind of drip sequence. If you're bumping against this limit, the free setup has genuinely done its job — you've validated your domain and proven sending volume. At that point, move to a proper transactional provider: SendGrid's free tier gives you 100 emails/day permanently, or AWS SES charges $0.10 per 1,000 emails after the first 62,000/month (if you're sending from EC2). Neither requires abandoning your custom domain — you just swap the SMTP credentials.

When This Setup Breaks Down (Be Honest With Yourself)

I've seen people try to scale this setup beyond what it was designed for and then blame the tools when things fall apart. Before that happens to you, be honest about your actual use case — because this setup has a clear ceiling, and hitting it is frustrating if you weren't expecting it.

If you have more than one person who needs email on this domain, stop now. Cloudflare email routing can forward [e-mail] and [e-mail] to two different Gmail accounts, sure. But the moment someone needs to "reply as" their address from mobile, or you need to audit who sent what, or Bob leaves and you need to revoke access — you're doing all of that manually, in your head, across disconnected personal Gmail accounts. I watched a two-person team try to run client communication this way for three months. It ended with duplicated replies to clients and zero visibility into the inbox. Use Google Workspace at $6/user/month. It's not expensive for a business problem.

Do not send transactional or bulk email through this setup. Gmail's SMTP relay has a hard cap of 500 emails per day for personal accounts, and Google will flag your account if it detects non-human sending patterns. If your app is firing password resets, order confirmations, or notification digests through this Gmail SMTP config, you're one bad day away from your account getting rate-limited or suspended. Use Resend, Postmark, or Amazon SES for anything automated. Resend's free tier covers 3,000 emails/month, Postmark starts at $15/month for 10,000. This Gmail route is strictly for you, typing emails to humans.

The shared inbox problem is a real wall. If your team needs to see a single [e-mail] inbox together — assigning threads, leaving internal notes, tracking resolution — this setup gives you nothing. You'd be forwarding to one person's Gmail and pretending that's a support queue. Tools like Zoho Mail's free tier (up to 5 users) or Help Scout's $20/month starter plan exist specifically for this. The Cloudflare + Gmail hack is a single-user workaround, not a team collaboration layer.

Calendar invites are the thing that catches people off guard most often. You can send email perfectly from [e-mail] via Gmail SMTP, but the moment you send a Google Calendar invite, the recipient sees it coming from your @gmail.com address regardless. Gmail SMTP only controls email sending — it has no authority over Calendar's identity layer. If you're doing any kind of client scheduling where the invite needs to show your domain, this setup visibly breaks professionalism. Google Workspace fixes this because Calendar and Gmail are tied to the same Workspace identity.

The honest math: if you're a solo freelancer sending maybe 20 emails a day to clients and prospects, the $0 setup covered in this article is genuinely fine for years. But if you're past that — team members, automated sends, shared queues, calendar-heavy workflows — the friction of fighting these limitations will cost you more than $6/month in wasted time. That's the actual comparison. Not "free vs paid," but "free vs the compounding annoyance of a tool being used outside its design."

Quick Reference: The Full Config at a Glance

Everything you need in one place — copy these values directly, no hunting through multiple dashboard screens.

Cloudflare MX Records

Three records, all pointing to Cloudflare's mail exchange servers. The priority numbers matter — lower number gets tried first. Add all three for redundancy:

Type  Name  Value                          Priority  TTL
MX    @     route1.mx.cloudflare.net       13        Auto
MX    @     route2.mx.cloudflare.net       21        Auto
MX    @     route3.mx.cloudflare.net       34        Auto

SPF TXT Record

This single record covers both incoming routing through Cloudflare and outgoing mail through Gmail SMTP. The ~all (softfail) is intentional — using -all (hardfail) can silently drop legitimate forwarded mail in certain configurations:

Type  Name  Value                                                              TTL
TXT   @     v=spf1 include:_spf.mx.cloudflare.net include:_spf.google.com ~all  Auto

Gmail SMTP Outbound Settings

The thing that trips people up: the password field does not accept your Google account password. You need a 16-character App Password generated at myaccount.google.com/apppasswords — and that only appears after you enable 2FA on your Google account. Gmail will silently reject the connection otherwise with a generic auth error.

SMTP Server:  smtp.gmail.com
Port:         587
Security:     STARTTLS (not SSL/TLS — that's port 465)
Username:     [e-mail]   ← your actual Gmail, not the custom domain
Password:     xxxx xxxx xxxx xxxx  ← 16-char App Password (spaces optional)

Limits You Actually Need to Know

• Cloudflare Email Routing (free tier): receive-only forwarding, no documented cap on incoming messages, supports up to 200 custom addresses per domain
• Gmail free SMTP: 500 outbound emails per day — enough for most small business use, but if you're sending bulk newsletters this ceiling will hurt you
• App Passwords: you can create multiple; if you ever revoke one, Gmail immediately rejects any client using it — good for security, annoying to debug at 2am

---

Disclaimer: This article is for informational purposes only. The views and opinions expressed are those of the author(s) and do not necessarily reflect the official policy or position of Sonic Rocket or its affiliates. Always consult with a certified professional before making any financial or technical decisions based on this content.

---

Originally published on techdigestor.com. Follow for more developer-focused tooling reviews and productivity guides.