How to Fix Email Forwarding Failures Using SRS
Note: This is a complex technical procedure. Do not attempt this unless you know exactly what this stuff all is and what you are doing! Proceed at your own risk.
For a simplified Markdown version of this guide, check out my GitHub Gist.
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.
GOAL: For custom domain names, email forwarding must use SRS (Sender Rewrite Scheme) so that SPF checks do not fail. This is critical when using your own domain, such as fred@mycustomdomain.com, with Gmail.
SOLUTION: Use a Domain Host or DNS Host that supports SRS to forward your emails to Gmail. This fixes the SPF "breakage" that occurs during standard forwarding. Note that you will continue to SEND emails through your current outbound SMTP server.
GENERAL STEPS
- Create a backup configuration of your DNS records. Export these from your current provider's portal. Ensure you capture every record, including "internal" or hidden records used for specialized services.
- Move DNS Hosting to Cloudflare. Update your nameservers at your registrar to point to Cloudflare's servers.
- Fix anything that might break during the DNS move. Identify services like domain forwarding or existing email forwarding that your previous DNS host was providing and replicate them in the Cloudflare dashboard.
- Move Domain Registry to Cloudflare (Optional). While not strictly required, it is easiest to have the host and registry be the same.
- Wait 24 hours for propagation. Check that your DNS host has properly updated globally. Confirm that all services from Step 3 are stable.
- Set up Email Routing at Cloudflare. Configure "Email Routing" for each address you want to forward to Gmail. Cloudflare will automatically suggest the necessary records. Crucial: If you already have an SPF record for your existing mail server, do not let Cloudflare overwrite it. You must merge the records so that you only have one v=spf1 statement.
- Fix the SPF records for Inbound and Outbound mail. Your SPF record must authorize the forwarding path, your primary outbound source, and Google's servers as a safety fallback.
- The Forwarding Path (Inbound): Cloudflare requires
include:_spf.mx.cloudflare.net. - The Sending Path (Outbound): Authorize your actual outbound source.
- By Domain: If your host provides one, use their record:
include:your-provider.com. - By IP Address: If your host does not provide a domain include, list the server IPs using the ip4 prefix. If they use a cluster (e.g., mail-node-a.provider.com), list all relevant IPs.
- By Domain: If your host provides one, use their record:
- The Google Fallback: Including
include:_spf.google.comensures that emails sent from the Gmail mobile app or during an SMTP failover are also 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(YOU MUST CHANGE THESE TO YOUR PROPER ADDRESSES AND SERVERS).
- The Forwarding Path (Inbound): Cloudflare requires
NOTE: If you aren't sure which IPs your host is using, send a test email to a service like Proton Mail or a "mail-tester" site and look at the "Received" headers. It will show the exact IP address of the server that attempted the delivery. If it is different from the one in your SPF record, that is your culprit!
- Test inbound forwarding. Send emails from various external services (Yahoo, Outlook, etc.) to your forwarded addresses. Check the headers in Gmail to ensure SPF, DKIM, and DMARC all report a "PASS."
- Test outbound sending. Send outbound emails from your custom domain and verify they are received by outside accounts. Since you have not changed the outbound SMTP path, these should remain functional.
References and Resources
- Google Support: Upcoming changes to Gmailify and POP in Gmail
- Cloudflare Documentation: How Email Routing and SRS work
- Wikipedia: Conceptual Overview of the Sender Rewriting Scheme
A Note on the "Google Security Hole"
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.





