Gmail SMTP with Cloudflare Email Routing: A Security-First Guide

Integrating Gmail SMTP with Cloudflare Email Routing

Google Workspace starts around £5–6 per user per month. For a domain that receives four emails a week and sends two, that is a subscription bought entirely for the sake of the text after the @.

The free workaround is well known: Cloudflare Email Routing forwards inbound mail to your existing Gmail inbox at no cost, and Gmail’s “Send mail as” feature relays outbound through smtp.gmail.com with your custom domain in the visible From: header. Twenty minutes of setup, no monthly bill, and hello@yourdomain.com on your business card.

It also fails DMARC. Not occasionally — structurally, by design, every single message. That does not matter much today, because your domain almost certainly publishes p=none and recipients therefore ignore the failure. It matters enormously the day you decide to protect your domain from spoofing, because the first thing a strict policy blocks is you. This guide covers the full setup and then explains exactly where the ceiling is, so you choose it deliberately rather than discovering it when your invoices stop arriving.

How the Setup Works

The single most useful thing to hold in your head here: inbound and outbound are two entirely unrelated systems that happen to share a domain name. Cloudflare never sees a byte of your outgoing mail. Google never touches inbound. Almost every confusing symptom in this setup comes from assuming otherwise.

• Inbound: Mail for your custom address hits Cloudflare’s MX servers. Cloudflare rewrites the envelope sender using the Sender Rewriting Scheme (SRS) — without that rewrite Google would see a forwarded message arriving from an IP the original sender’s SPF record has never heard of, and bin it — then delivers to your Gmail inbox.
• Outbound: You compose in Gmail, Gmail authenticates to smtp.gmail.com with an App Password, and Google relays the message with your custom domain in the From: header. Cloudflare is not involved and cannot help you here.

Step 1: Secure Your Google Account with 2FA

Google withdrew plain username-and-password SMTP access for consumer accounts — the old “less secure app access” toggle — because reused passwords made those endpoints a free credential-stuffing target. What replaces it is the App Password: a per-application secret that only exists once two-factor authentication is enabled. So 2FA first, or the App Passwords page will simply not appear for you.

1. Go to your Google Account Security Settings .
2. Under How you sign in to Google, select 2-Step Verification.
3. Follow the prompts to enable it.

[!NOTE] Prefer an authenticator app or a hardware key over SMS. SIM-swap attacks against phone-based second factors are routine, and your email account is the reset path for everything else you own — which makes it the highest-value target on your list, not a peripheral one.

Step 2: Generate an App Password for SMTP

An App Password is a 16-character secret scoped to one application. It lets Gmail’s SMTP relay authenticate without ever seeing your real password, and it can be revoked on its own if the machine holding it is lost. The trade-off is worth stating plainly: it also bypasses your second factor completely. Anything that can read that string can send mail as you until you revoke it.

1. Go to the Google App Passwords page .
2. In the App name field, type a descriptive label such as Gmail SMTP Custom Domain.
3. Click Create.
4. Copy the 16-character password shown on screen — you will only see it once.

[!WARNING] Treat it as a private key. Never commit it to a repository, never paste it into a support chat, and give it a name you will recognise in six months — an App Password list full of entries called “app” is a list you can no longer safely prune. If it leaks, revoke it from the same page; revocation is instant and breaks only that one integration.

Step 3: Register Your Custom Domain in Gmail

Now you tell Gmail that the address exists, so it appears in the From dropdown when you compose.

1. Open Gmail, click the gear icon, and select See all settings.
2. Go to the Accounts and Import tab.
3. Under Send mail as, click Add another email address.
4. In the window that opens:
   • Enter your Name (what recipients will see).
   • Enter your custom domain address (e.g., you@yourdomain.com).
   • Uncheck the box labelled Treat as an alias.
5. Click Next Step.

Why uncheck “Treat as an alias”? Left checked, Gmail treats the address as another label on the same mailbox and will happily put your @gmail.com address in the Reply-To header. Unchecked, it becomes a distinct sending identity and replies come back to the domain address — which is the entire point of the exercise. This is the setting people get wrong, and the symptom is subtle: everything looks right in your Sent folder while recipients quietly reply to your personal address.

Step 4: Configure SMTP Settings

Gmail now asks which server should carry mail from this address. Cloudflare Email Routing has no outbound capability at all, so the answer is Google’s own relay:

1. Enter the following details:
   • SMTP Server: smtp.gmail.com
   • Port: 587
   • Username: Your full personal Gmail address (e.g., yourusername@gmail.com).
   • Password: The 16-character App Password from Step 2.
   • Security Connection: Select Secured connection using TLS.
2. Click Add Account.
3. Google sends a verification code to the custom address. This is the moment your inbound routing gets tested for real — if Cloudflare is forwarding correctly the code lands in the same inbox seconds later. If it does not arrive, the fault is your MX records or the routing rule, not anything you have configured in this step.

Port 587 with STARTTLS is the right choice here. Port 465 still works and is no less secure in practice, but 587 is the submission port defined for authenticated clients and is the one least likely to be blocked by a residential ISP or a café network.

Step 5: Configure SPF and DMARC Records in Cloudflare

These TXT records are how a receiving server decides whether a message claiming your domain deserves the benefit of the doubt. Without them you are not neutral — you are unauthenticated, and Gmail and Outlook both weight that heavily against you.

SPF (Sender Policy Framework) Record

SPF is a published list of who may send on your behalf. Cloudflare needs to be on it for forwarding, Google for your outbound relay.

Create a TXT record in your Cloudflare DNS zone:

• Type: TXT

• Name: @ (root domain)

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

• TTL: Auto

• include:_spf.mx.cloudflare.net — Cloudflare’s routing infrastructure.

• include:_spf.google.com — Google’s outbound relay.

• ~all — soft fail. Anything else is suspicious but not to be rejected outright. Use -all (hard fail) only once you are certain you have enumerated every service that sends as your domain, and remember that your newsletter platform, your ticketing system, and your invoicing tool all count.

Two rules that break SPF quietly. A domain may publish exactly one SPF record — two TXT records both starting v=spf1 is a permanent error, and receivers treat the whole thing as invalid rather than picking one. And the record may trigger at most ten DNS lookups when fully expanded; each include: costs at least one, and exceeding the limit fails the check for every message you send. Both failures are silent from your side. Your mail simply starts scoring worse and you have no obvious reason why.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) Record

DMARC does two jobs: it tells receivers what to do with mail that fails authentication, and — more usefully at this stage — it asks them to send you reports on what is being sent in your name. Start in monitoring mode:

• Type: TXT
• Name: _dmarc
• Content: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
• TTL: Auto

[!TIP] p=none collects reports without affecting delivery. The aggregate reports arrive as compressed XML, roughly daily, and are close to unreadable by hand — feed them to a free parser rather than trying. Be aware of the sequencing: with the Gmail SMTP setup described here, tightening to p=quarantine or p=reject will quarantine your own outgoing mail. Read the next section before you touch it.

The Crucial Catch: DMARC Alignment Failure

Here is the part most guides skip. Passing SPF is not the same as passing DMARC, and the difference is a concept called alignment.

DMARC requires two things:

1. The message passes SPF or DKIM.
2. The domain that passed must match the domain in the visible From: header — the one the recipient actually reads.

That second condition exists because SPF and DKIM, on their own, validate domains nobody ever sees. A spammer can pass SPF perfectly for cheap-vps-provider.example while displaying From: billing@yourbank.com. Alignment is what closes that hole, and it is exactly what this setup cannot satisfy:

• SPF alignment fails. Google rewrites the envelope sender (Return-Path) to your @gmail.com address so bounces come back to it. SPF therefore validates gmail.com — a genuine pass, against the wrong domain.
• DKIM alignment fails. Google signs with its own key, d=gmail.com. The signature is cryptographically valid and completely useless for your domain, because a free Gmail account cannot publish a key of yours.

Both misaligned, so DMARC fails on every message. Today nothing happens, because p=none asks receivers to take no action. That is the whole reason this configuration appears to work.

The Professional Workaround

The moment you publish p=quarantine or p=reject — which is the only way to stop other people spoofing your domain — your own mail is the first casualty. Two real fixes:

1. Google Workspace. Paid accounts let you generate a DKIM key for your own domain and publish it in DNS, producing an aligned d=yourdomain.com signature. Costs a subscription; removes the problem entirely and keeps you inside the Gmail interface.
2. A dedicated SMTP relay. Point Gmail’s “Send mail as” at a transactional provider such as SMTP2GO , Resend , or Brevo instead of smtp.gmail.com. You verify the domain, they give you DKIM records to publish, alignment works, and the free tiers comfortably cover personal volumes. The trade-off is another account, another set of DNS records, and a sending reputation that now depends on a third party’s shared IP pool.

If neither appeals, keeping this setup with p=none is a legitimate choice — provided you understand you have accepted an unprotected domain in exchange for not paying a subscription. Make that call knowingly.

Verification Tools

Never assume this works because a test message reached your own inbox. Gmail is generous with mail you send to yourself, and self-testing hides almost every problem worth catching.

• MXToolbox — syntax and lookup-count checks on SPF, DKIM, and DMARC. Catches the duplicate-record and ten-lookup failures described above.
• Mail Tester — send one real message to the address it gives you and read the full breakdown. This is where you will see SPF pass and DMARC fail on the same message, which is the clearest possible demonstration of alignment.
• Google Postmaster Tools — domain reputation and spam rates over time. Only meaningful at volume, so ignore it until you are sending regularly.

FAQ

1. Why does my email show “sent via gmail.com” to recipients?

Because it is true, and Gmail thinks recipients deserve to know. The From: header says yourdomain.com while the DKIM signature says gmail.com, so Gmail discloses the mismatch rather than hiding it. It is the visible symptom of the misalignment described above, and no DNS record will remove it — only an aligned DKIM key will.

2. Can I use custom DKIM keys with a free Gmail account?

No. Custom DKIM key generation is a Workspace feature; consumer accounts have no interface for it and no supported workaround. Aligned DKIM means Workspace or an external relay that verifies domain ownership. There is no free path through Gmail itself.

3. What is Cloudflare SRS and why does it matter?

Forwarding breaks SPF. When Cloudflare relays a message from someone@example.com to your Gmail inbox, Google performs the SPF check against Cloudflare’s IP — which example.com has never authorised — and the check fails through no fault of anyone involved. The Sender Rewriting Scheme fixes this by rewriting the envelope sender to a Cloudflare-owned address that is authorised, while leaving the visible From: untouched. It is why Cloudflare forwarding works at all, and it is handled for you.

4. Is it safe to leave p=none in DMARC indefinitely?

Safe in the sense that nothing breaks; unsafe in the sense that anyone in the world can send mail as your domain and receivers have been told explicitly not to intervene. Domains that sit on p=none for years are the ones that turn up in invoice-fraud campaigns. The route is none → quarantine → reject, moving only when the reports show your legitimate senders authenticating cleanly — and the prerequisite for step two is replacing personal Gmail SMTP with an aligned sender. In that order, or you block yourself.

5. Does this setup work on mobile?

Yes, with one restriction worth knowing: the “Send mail as” address can only be added from the desktop web interface. Once added it syncs to the official Gmail apps on iOS and Android and appears in the sender picker. Third-party mail clients are a different matter — many will not honour the alternate sending identity and will quietly send as your @gmail.com address instead.