All mail sent via mailmapping of zoneedit is marked as spam due to blacklisting

Since somewhere this week all good mail that is sent via my mailmapping to our mailboxes at our own provider is marked as spam.
Are there others experiencing the same?
 

zeadmin

Administrator
Staff member
We checked logs and can see the mail being forwarded to the destinations properly.
 
strange thing is that in all e-mail headers the SPF, DKIM and DMARC pass, but still there's like:

Precedence: junk
X-Spam: yes
X-Spam-Action: folder Spam
X-Spam-Reason: SMCH_ACTION=reject

in the headers.
 
As far as I can find it now it appears that the sending ip-addresses of Zonedit are on some blacklists. I think that may be the reason a lot of mail that is sent to me is ending up in the spambox, even if SPF, DMARC and DKIM are passed. Here below are screenshots about the ip-addresses of mx3.zoneedit.com and mx4.zoneedit.com and the blacklists they appear on. I checked at backscatterer.org and there I see that these two ip-addresses were blacklisted since March 27th (last wednesday). That's about the day our problems began.2024-03-29_09-39-05.png2024-03-29_09-37-47.png
 
Last edited:

Chris Cherry

Zoneedit Support
Our servers have been listed on Backscatter for probably a decade. It's not an RBL that anyone uses as a reference/resource. Backscatter is terrible because it makes you pay to be removed, only to have you listed again. Your Email Provider would have to subscribe to Backscatter OR Anonmails to have any of those influence your email delivery. You'd need to check with your email host for that.

Here's a question. The email is arriving at the destination (our job is done) and being marked as spam by your host. Have you asked your email host why their mail system is marking it as spam? What have they said?

Email forwarding is very prone to having messages come through as spam. It's our server forwarding a message from an email address we have nothing to do with. SPF checks are worked around via our Sender Rewrite Scheme, which includes our srszone.org domain in the headers with proper SPF info. However, that can be defeated via restrictive DMARC settings on the sender domain.
 
I understand what you mean, but the strange thing is that is started to occur somewhere this week. I know sometimes good mail will end up in the spamfolder, but since this week it's almost the other way around. So sometimes good mail will end up in the Inbox, but the rest in the spamfolder. And I'm talking about e-mails of different senders.

I did some testing last night, so I changed the mailmapping of my address to another host and the same happened.
 

Chris Cherry

Zoneedit Support
The question remains. We won't know whether we need to fix something or can fix something without knowing why the receiving email host is filtering the messages into spam.
 
Hi Chris, does it help if I send you an example (or some) of the e-mailheaders? Because when I do a e-mail header analyzer at (for example mxtoolbox) I get the following result:
2024-04-02_12-00-39.png
I get this same result on every "good" e-mail that ends up in my spamfolder.
 
Last edited:

Chris Cherry

Zoneedit Support
In this case, the sending (client) server, Sendgrid, did not use a TLS client certificate to authenticate itself to us. This is not uncommon and not required based on our server config.
 
Top