As of January 2026, Google has retired the "Check mail from other accounts" POP3 feature for Gmail. This means the service no longer supports pulling emails from external providers via POP3. Moving forward, setting up email forwarding is the primary way to manage a custom domain through the Gmail web interface.
Note: This guide assumes you already have your DKIM and DMARC records properly configured for your domain.
For custom domain names, standard email forwarding often breaks SPF (Sender Policy Framework) checks because the forwarding server is not an authorized sender for the original domain.
Use a Domain Host or DNS Host that supports SRS (Sender Rewrite Scheme) to forward your emails to Gmail. This re-signs the sender address so that SPF checks pass. You will continue to SEND emails through your current outbound SMTP server.
- Backup DNS Records: Export your current DNS configuration from your provider's portal. Ensure you capture all records, including hidden or internal records.
- Move DNS to Cloudflare: Update your nameservers at your registrar to point to Cloudflare.
- Replicate Services: Identify any domain or email forwarding services your previous host provided and set them up in the Cloudflare dashboard.
- Move Domain Registry (Optional): It is often simpler to have the host and registry in the same place.
- Propagate: Wait 24 hours to ensure DNS has updated globally and services are stable.
- Set up Cloudflare Email Routing: Configure "Email Routing" for each address. Crucial: Do not let Cloudflare overwrite your existing SPF record. You must merge them into a single
v=spf1statement. - Fix SPF Records: Your SPF record must authorize the forwarding path, your primary outbound source, and Google's servers as a fallback.
- The Forwarding Path (Inbound): Cloudflare requires
include:_spf.mx.cloudflare.net. - The Sending Path (Outbound): Authorize your actual outbound mail source.
- By Domain: If your host provides a master record, use
include:your-provider.com. - By IP Address: If no include is provided, list the server IPs using the
ip4prefix. If they use a cluster, list all relevant node IPs.
- By Domain: If your host provides a master record, use
- The Google Fallback: Including
include:_spf.google.comensures that emails sent from the Gmail mobile app or during an SMTP failover are authorized.
Example merged record with multiple IPs:
v=spf1 include:_spf.mx.cloudflare.net ip4:192.0.2.1 ip4:192.0.2.2 include:_spf.google.com ~all
(Note: Replace placeholders with your actual server addresses).
Troubleshooting Tip: If you are unsure which IPs your host uses, send a test email to a service like Proton Mail and check the "Received" headers. The "offending" IP address that caused an SPF fail will be listed there.
- Test Inbound: Send emails from external services (Yahoo, Outlook) to your forwarded addresses. Check Gmail headers to ensure SPF, DKIM, and DMARC all report "PASS."
- Test Outbound: Send emails from your custom domain to verify they are received. Since the outbound SMTP path is unchanged, these should remain functional.
- Google Support: Upcoming changes to Gmailify
- Cloudflare: How Email Routing and SRS work
- Wikipedia: Sender Rewriting Scheme
Source: Vintage Veloce: Fixing SPF Fail when forwarding custom domain email to Gmail
One thing to watch out for: adding include:_spf.google.com is a broad move. It technically authorizes any Google-hosted account to send mail as your domain. If you are running a strict DMARC policy like p=reject, you do not want to rely on that broad SPF permission alone.
The real fix is ensuring your DKIM alignment is bulletproof at your SMTP host. Since my host signs every outgoing email with a unique cryptographic key, that signature is what actually proves the mail is from me and not just "some guy on a Gmail account." If your DKIM signature is solid and matches your domain, that broad Google SPF include becomes a lot less of a security risk and more of a functional fallback for mobile apps.
Quick tip on monitoring: Add an rua tag to your DMARC record (the Cloudflare dashboard toggle is the easiest way). It provides the reports you need to ensure your p=reject policy is not nuking your own mail by mistake.
I used this domain health checker to verify my alignment and catch a few other syntax errors: suped.com/tools/domain-health-checker. It is a fast, no-fluff tool that shows you exactly where your authentication trio (SPF, DKIM, and DMARC) is succeeding or failing.
Ensure your email host has a valid, publicly trusted certificate (Let's Encrypt or AutoSSL) specifically for the mail.yourdomain.com hostname. Do not proxy your mailserver at Cloudflare or use a Cloudflare "Origin CA" certificate, as Gmail will not trust it and the connection will fail.