Disable email forwarding on domain

I was testing email forwarding on a domain in my account, but now understand that although it works for forwarding incoming emails to my gmail account, because it requires changes to the MX DNS records on Cloudflare I cannot then set up sending outgoing email from gmail using SMTP server of my existing mail service… and there is no SMTP service in the Cloudflare offering.

So I’d like to disable email forwarding in this domain, and remove the MX DNS records.

But I can’t see any way to disable forwarding… only to enable forwarding!

The MX records in the DNS say “to remove these, disable email forwarding”… but I can’t see how to disable email forwarding!

You shouldn’t need to disable e-mail forwarding or delete the MX records. It’s probably the SPF / DMARC record that were added that are breaking your ability to send outgoing e-mail. So if you just delete/update those & leave the MX records alone, that will probably resolve your issue.

But if you really want to get rid of the MX records, from the screenshot it looks like you’ve already unlocked them, so you should be able to delete them now.

If you want to continue using Cloudflare for incoming e-mail forwarding, and still use another service for outgoing e-mail, you should probably see what the other service recommends in terms of SPF records and combine them

For example this is what Cloudflare recommend for SPF:

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

and this (as an example) is what another e-mail service recommends:

v=spf1 include:_spf.google.com ~all

You can easily combine them like this:

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

Combining them like that is safer than deleting the SPF record completely (but you can if you want to)

2 Likes

Thanks for your reply @user4358!

if you really want to get rid of the MX records, from the screenshot it looks like you’ve already unlocked them, so you should be able to delete them now

This is what I see in the DNS screen:

i.e. no way to delete them directly on the DNS page… just a suggestion to disable email routing… but also no way to disable email routing on the email routing page!

But this is where your reply gets really interesting:

If you want to continue using Cloudflare for incoming e-mail forwarding, and still use another service for outgoing e-mail

So this should be possible? This is what I want. At the moment I’m sending emails in gmail using SMTP of my existing web/mail host (hostinger)… and in that web/mail host I’ve also set up forwarding of all emails to my gmail account.

The problem I’m having is that gmail/google is blocking or rate-limiting these forwarded emails, so some are never getting to me. This is on the basis that gmail/google considers mailchannels.net (which is apparently what hostinger are using for the email service) to be used for spamming and it’s trying to protect its users from spam. I am certainly not spamming, just using the SMTP for occasional emails… very light usage, so I guess I’m being punished because other users of this web/mail host are using it for spamming.

Anyhow, given this problem, what I’m looking into is still sending in gmail via SMTP of my existing web/mail host (that is working fine), but using Cloudflare to forward emails to gmail… in the hope that these forwarded messages from Cloudflare will not be treated as coming from a spammy source, and therefore will not be rejected or rate limited.

So that should be possible… by:

(1) using Cloudflare MX records (for routing incoming email)
(2) combining SPF of Cloudflare with that of Hostinger (to enable outgoing email using SMTP)

Is that all? Sorry, my knowledge of these things is pretty shaky.

MX records determine where mail should be routed to when someone tries to e-mail the domain. MX records are mandatory for receiving mail but have nothing to do with sending e-mail out from the domain.

By default, anyone anywhere can send e-mail from any domain. Obviously from a spam perspective this isn’t ideal. So various technical solutions have been developed to LIMIT who can send e-mail from a domain. Namely, SPF, DMARC, and DKIM records (these are actually TXT records rather than actual DNS record types)

For example, Cloudflare adds this when you enable e-mail forwarding (but unlike the MX records you’re free to modify/delete it)

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

This means that only Cloudflare is allowed to send e-mail from the domain. (You might be wondering, if Cloudflare e-mail forwarding is only used for inbound e-mail, why are they also requesting to be able to send out from the domain? Well, when they receive the message they have to forward it back out, so that’s more or less it.)

The “~all” at the ends means if anyone other than Cloudflare is sending e-mails on behalf of your domain, it should be treated as an SPF failure. This will increase the probability of the message being spam-filtered, and depending on how the domain’s DMARC policy is set up, might cause the message to be rejected entirely.

But you can add multiple providers to the SPF record, so that they can all send e-mail on behalf of the domain.

2 Likes

Thanks, @user4358 this is really helpful stuff.

You mention having a combined SPF record, but is it OK to have two separate SPF records instead? My DNS now has separate SPF records for hostinger and Cloudflare and it seems to be working OK… sending emails via hostinger SMTP and receiving emails forwarded by Cloudflare.

The troubling aspect is that my Cloudflare email routing has lots of warnings about my setup… please could you let me know if this looks OK despite the warnings?

You’ll see that I’ve actually left the hostinger MX records in place but just given them a lower priority (by adding 100) than the Cloudflare MX records… is that a sensible thing to do? Just in case Cloudflare is down the pan, it will still be able to route via hostinger?

And you’ll also see the separate SPF records, not a single combined record.

Cloudflare may complain if the SPF record is different than what they expect but they don’t actually enforce it.

As for having multiple SPF records instead of combining them into one see Multiple SPF Records: Issues and Examples | Mailtrap Blog or Multiple SPF Records: How to Merge Them (The EASY Way) basically you shouldn’t have multiple records and should instead combine them

In fact Cloudflare should stop complaining as long as long as “include:_spf.mx.Cloudflare.net” is included somewhere in the SPF record. It doesn’t care if other services are also referenced.

And when you combine the SPF records, make sure you only have one “~all”, and that it’s at the end.

As for having having old MX records for hostinger… in theory they shouldn’t do anything (unless all the Cloudflare e-mail servers are unreachable) but if you’re only using hostinger for outbound e-mail, you might as well delete them, as that’ll get rid of the warning message on the Cloudflare dashboard.

Thanks, you’re a star. I’ll give this a go. Seems to be working so far… but hopefully it will solve my original problem (i.e. hopefully gmail/google will treat emails forwarded by Cloudflare as less spammy/suspicious than emails forwarded by hostinger/mailchannels.net)!

@user4358 one more thing… I notice that in my DNS I still have some domainkey CNAME records that were recommended by hostinger:

Should I leave those in place, since I’m still sending outgoing email from hostinger SMTP?

DKIM is another mechanism for restricting/allowing who can send e-mail on behalf of domain, and if working properly it should reduce the chance of messages being spam-filtered. DKIM is a TXT record and I’m not sure exactly how those CNAMEs tie in but if hostinger recommended them I’d leave them alone. Do you actually have a DKIM record? Maybe it references those CNAMEs and that’s why they exist.

Like this? No, only the CNAME entries as per above.

okay after checking Hostinger documentation I think I see what they’re doing

instead of having you create the TXT records directly they ask you to make CNAMEs to a few of their DNS names, and the targets of those CNAMEs have the actual TXT record attached

like if you do a dig TXT hostingermail-a.dkim.mail.hostinger.com you’ll see the expected TXT record

they probably do it like that so that if they ever change their DKIM keys they can do it on their side instead of asking all their customers to update

so that should all be good

also you might want to take a look at https://www.mail-tester.com/

you can send them an e-mail and they’ll tell you how “good” it looks in terms of probability of getting spam-filtered, based on SPF / DKIM / DMARC stuff and more

if anything’s not right they’ll give feedback on what could be improved

So, leave these hostinger domainkey CNAME entries in the DNS after enabling forwarding in Cloudflare?

also you might want to take a look at https://www.mail-tester.com/

Yep, when I first identified a potential issue with emails not getting through, I did check this out, and tightened up a few things to ensure that all the correct DNS records were in place.

But actually, the problem is not with emails that I am sending from this account being rejected by the recipient (or going into spam), but rather with emails that other people are sending to this account never even reaching me (being rejected by google on the basis of mailchannels.net being associated with spamming accounts in general… not mine in particular).

Despite doing all I can, I am still hearing that some emails are being returned to sender with a message about google rate limiting that IP address (associated with mailchannels.net)… my guess is that some spammers are using hostinger and google is applying a rate limit to all.

So now I’m trying to see if it helps if Cloudflare does the forwarding to gmail, rather than hostinger/mailchannels.