Email Routing Problems?

Is there any problems with email routing? I have checked “Catch-All” but all emails are not delivered. The message I get in Cloudflare Dashboard is:

SPF status


DMARC status


DKIM status


Rejected reason:

Unknown error: permanent error (550): 5.7.1 Service unavailable, MailFrom domain is listed in Spamhaus. To request removal from this list see

I have tried using Outlook, Yahoo and gmail. What has spamhaus got to do with MY EMAILS. I don’t use spamhaus in my email client or in my machine or on my server.

This is one domain I have checked so far.

The Spamhaus Project is an international organisation based in the Principality of Andorra, founded in 1998 by Steve Linford to track email spammers and spam-related activity, having your IP address blocked by Spamhaus means that it has been associated with some form of email spamming or scamming.

You may want to check your domain here:

Once your domain is removed from the Spamhaus list, email delivery should return to normal. In the meantime, ensure that your email complies with best practices to avoid being marked as spam.

What amazes me is that I DON’T SEND any messages to any 3rd parties using my domans. If I have to communicate with anybody, I always use hotmail, outlook, gmail, yahoo or aol. The only time I use domain emails is when I am subscribing to newsletters or registering for something free downloads. This way I can control who is selling the info to 3rd parties. This only works if I can receive the emails, which CF was blocking.

The problem I was having was NOT ABLE TO RECEIVE any emails via Cloudflare routing system. I manged to solve it by moving the domain to Namecheap who have almost identical routing system like Cloudflare under freeDNS like Cloudflare.

Why should Cloudflare filter incoming mails when user hasn’t specifically asked for it. Cloudflare should only route the emails and let users do their filtering. Why use SpamHause who are not accountable to anybody. I contacted them and they told me they control the world (indirectly, of course). I only show two fingers for their services.

Why did you mark this post as solved? I solved it by moving somewhere else. That was the only way to resolve this.

The rejection you see is not Cloudflare blocking the message, it is the final destination (the ones you forward/route to) that is rejecting the message.

Cloudflare simply displays the “error message” that the final destination rejected the message with.

Cloudflare CAN TRY to deliver the messages to the final destination, Cloudflare CANNOT force the final destination to take them, if they don’t want to.

See this (especially last section):

That being said, -

  1. What’s the domain name you had problems on?

  2. And when exactly (e.g. which date) did you register it?

  3. Did you check on Spamhaus, and actually confirm that Spamhaus themself said your domain name was on their list?

1 Like

To cut the story short, the domain in question was:

On my dashboard you’ll see 20 emails received (all test messages from me only) and 20 messages rejected. Image attached.

I did check with spamhaus and they told me they can’t deal with me unless I use a domain email. I explained to them that I can’t use a domain email because I don’t receive anything using the domain because of a block by Cloudflare who happens to be using Spamhaus. I can send you the link to our conversation by email because this forum won’t allow me to post a link.

I’ll try to attache one of the images.

By the way I solved this by moving the domain to Namecheap (temporarily) because I wanted to register VPS services with Azure, Oracle, GCP and others and domain email is the best way to do for reasons I won’t go here.

I cannot believe that Microsoft, or gmail will reject any emails. They might put in the spam folder but they don’t reject anything. At least I haven’t experienced this.

If you would do whatever you can to secure a proper email delivery, I would suggest you to avoid:

  1. Freenom (and other “free”) domain names…

  2. Certain funky ones such as e.g. “.cyou”, “.date”, “.top”, “.xyz” and similar TLD’s

  3. Inexpensive TLD’s (e.g. having a price less than the price of one of the major TLD’s, such as .com/.net/et cetera).

Spamhaus likely won’t be the only sort of “negativity” you’ll ever see.

If in doubt, you can for example take a look at these few links:

How to block specific TLDs (Top-Level Domains) in Postfix

Blocklisting top level domains with Postfix - John Bokma

blocklist_postfix/sender_access.pcre at main · joacimmelin/blocklist_postfix · GitHub

That does actually sound very sane?

If you were claiming to represent Bank of America, but coming from a or, or anything else that doesn’t appear to be Bank of America, or otherwise verifiable to be the same owner, … who wouldn’t ask for a more guaranteed “confirmation” in a such situation?

If you have some important mails on some domain(s), you should NEVER rely on any email forwarding / email routing / … whatever your provider calls them, to retrieve them.

Such account related emails, as you indicate you intend to receive, are at least what some people would consider important mails?

→ 2016: [mailop] Microsoft/Hotmail discards mails

^ Sounds to me like: “Emails are disappearing as if they never existed”

→ 2018: [mailop] Weird problems with mitigation at Hotmail/Outlook
→ 2018: [mailop] Outlook/Hotmail/etc rejecting email (but not Office 365)

→ 2019: [mailop] Anyone from Google can explain me why my mails are rejected ? (Was : Gmail Contact?)
→ 2021: [mailop] GMAIL marking random emails as spam and rejecting.
→ 2022: [mailop] Partial issues forwarding mails to

I cannot force you to believe me, and you do not have to take my word for it, but at least according to many threads out on the Internet, the rejections from those two major (free) email providers has been a reality for years.

Well, given your initial post of this thread, I’d say you actually have.

Here’s an example on how the Cloudflare Dashboard looks, when I am rejecting messages on the final destination:

I also tested using a sender domain that is currently listed on the Spamhaus DBL, and that was passing through Cloudflare (and to my final destination) just fine.

As such, I would still stand by my words in the message above, that it wasn’t Cloudflare rejecting the message, but your final destination.

The rejection message from your first post does make it look a lot like the final destination for that specific message was Microsoft (e.g.,,, …).

1 Like

As such, I would still stand by my words in the message above, that it wasn’t Cloudflare rejecting the message, but your final destination.

Surely, if the final destination was rejecting a message, why is it not returned to the original sender? The RFC prescribes that rejected email should always be returned to the original sender. CF is not the sender but a “carrier” per se.

Anyway Let’s agree to disagree on this matter because the problem is now resolved as far as I am concerned.

That would be something you would need to take up with the original sender’s provider, as it is their mail server (and/or system) being broken.

Or, if there are other intermediates in the line between them and before Cloudflare, it would be the latest one of them, which actually “accepted” the message.

Here’s another one:

I assume that is the kind of bounce you refer to?

If the original sender didn’t get a such kind of Non Delivery Report (NDR) from their (provider’s) mail server, the problem is on their( provider’s) end.

Cloudflare never accepted the message, as such, Cloudflare is not responsible for generating the Non Delivery Report (NDR), that would be on sender’s mail server’s responsibility, until Cloudflare had accepted the message.

Cloudflare is literally, as a SMTP proxy, saying “Hang on, I’ll ask the upstream (final destination) what they want to do with this message, and let you know” while the transmission is still open, which means if the upstream (final destination) rejects it, Cloudflare will reject the transmission from the original sender too.

If Cloudflare had done the store-and-forward approach, and said “OK, I accept the message, and deal with it later”, then your statement would be correct, and the generation of the Non Delivery Report (NDR) would be on Cloudflare’s responsibility.

Accepting the message and dealing with it later most often open up your MTA to become a potential Gatling gun for useless noise (also known as “backscatter”).

The responsibility for generating the Non Delivery Report (NDR) reside with the latest server “accepting” the message.

$ telnet 25
Connected to
Escape character is '^]'.
220 Cloudflare Email ESMTP Service ready
EHLO mail.example.invalid greets mail.example.invalid
MAIL FROM: <[email protected]>
250 2.1.0 Ok
RCPT TO: <[email protected]>
250 2.1.0 Ok
354 Start mail input; end with <CR><LF>.<CR><LF>
From: <[email protected]>
To: <[email protected]>
Subject: hi there
Date: Thu, 13 Apr 2023 16:01:23 +0200 (CEST)
Message-ID: <>

521 5.3.0 Upstream error, please check for possible reasons why. {queue-id}
Connection closed by foreign host.

Above transcript where Cloudflare in the end responds “521 5.3.0”, doesn’t equal “accepting the message”.

For the screenshots above:

  1. Me ↔ (Google)
  2. Google ↔ Cloudflare
  3. Cloudflare ↔ My mail server

Since Cloudflare returned 521 5.3.0 to Google, because I returned 550 5.7.1 to Cloudflare, the latest server accepting the responsibility for the message was actually (Google).

As per the second screenshot, Google fulfilled that responsibility, and generated the Non Delivery Report (NDR) as they were supposed to.

Backscatter (email) - Wikipedia

Mail transfer agents (MTAs) which forward mail can avoid generating backscatter by using a transparent SMTP proxy.

SMTP proxy - Wikipedia

SMTP proxies are specialized mail transfer agents (MTAs) that, similar to other types of proxy servers, pass SMTP sessions through to other MTAs without using the store-and-forward approach of a typical MTA. When an SMTP proxy receives a connection, it initiates another SMTP session to a destination MTA. Any errors or status information from the destination MTA will be passed back to the sending MTA through the proxy.[1]

… which is how Cloudflare does the forward, and why they are not responsible for generating the Non Delivery Report (NDR).

Sounds indeed like there are no way out other than that.

That said, I wish you good luck with your email forwarding./ routing!

1 Like

This is the only part that makes no sense. I’m not sure who wrote that and why no one corrected it before taking it live. For some reason Cloudflare refers to the destination as “upstream” which is the inverse of the direction mail flows. “Upstream” is the sender, not the recipient. Email doesn’t flow uphill any more than water starts its journey downstream.

1 Like

I totally agree, and it also crossed my mind the first time that I saw it.

My part with “upstream (final destination)” was however solely to clarify that upstream (at least, currently) refers to the final destination.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.