Why e-mails from my domain are marked as SPAM by gmail when using Cloudflare?


I’ve recently bought domain “abecar.pl” and configured mail server provided by az.pl. I’ve decided to switch DNS to Cloudflare, and manually configure DKIM, SPF, DMARC and BIMI and check my settings with avaliable online tools like mxtoolbox and others and it’s alright. Gmail marks my e-mail headers as “Passed”, but it goes to SPAM folder. I’ve also checked if my domain/ip is on any blacklist and it’s not. Gmail postmaster has no data for me.

https://ibb.co/vH03wzd - Cloudflare configuartion
https://ibb.co/99ccLgB - Postmark report
https://ibb.co/cg4st91 - glockapps report
https://mxtoolbox.com/Public/Tools/EmailHeaders.aspx?huid=6c52824d-52b5-4749-8a2f-b831bd36fc3a - Mail headers

Vade Retro 01.425.159#82 AS+AV+AP+RT Profile: HOMEPL,VRGNI; Bailout: 150; ; [email protected]?07; From=admin ABECAR <[email protected] abecar.pl>; VRPattern=A668D9592420F06BC9821708A20B3474; Ip=,; ClusterSize=0; Param=inet=,helo=h2-ox2ap12od,mailfrom=admin ABECAR <[email protected] car.pl>,nb_rcptto=1,rcptto=heyimjuXXX @gmail.com

I think it might be Cloudflare issue, but im not sure. Maybe also the fact that i do not have A record for abecar.pl is the case? Or maybe domain is too young and it gets classified as unreliable?

“Recently” / “too young” could at least be one reason.

It is very common for spammers (and other nasty) organisations to register new domains, and flood away with their garbage from them.

For the first minimum 45 - 90 days (expect 90 days) of the domain registration, any successful deliveries with no (negative) remarks, I’d generallly say would be a miracle.

#2, The CNAME of www directing to your actual domain is useless here, as the actual domain does not have any A / AAAA records.

Your SRV records appear to suggest that insecure (non-TLS encrypted) connections to your mail server are perfectly fine, too.

As for your _dmarc record:


Those two parts are the default values of the DMARC specification, when they are not specified, and as such, they are useless to have implicitly set, and can safely be removed.

Especially the SRV thing might be a thing you would like to look at, but not directly related.

Digging in to it, it looks form the configuration here, that you are self-hosting your own email.

Self-hosting can be tricky, depending on the hosting provider you choose, it will work good at some, but may be completely impossible a others (e.g. due to the hosting provider’s lack of will to terminate bad customers, which in exchange, makes the receiving ends not care about those providers, and as such, block whole providers at once).

The IP address you have listed for “mail”, does go to a dynamic / generic assligned reverse DNS (PTR) record, cloudserver3326167-3326198.online.pro, that one is a thing you want to fix, and have it match the actual name that your mail server presents itself as.

As people say, a chain is no stronger than it’s weakest link.

Porkmark shows that you are doing excellent, … but at the same time, they are also showing huge signs of their own failures.

RCVD_IN_ZEN_BLOCKED_OPENDNS, … is the clear sign of that.

When you are running your own inbound mail server, that is checking third parties (e.g. IP block/welcome lists, domain block/welcome lists, … et cetera), you must also run your own resolver that runs the DNS lookup directly, and as such, is not shared with others. Running the DNS lookups for that over e.g. (Cloudflare), (Google), or whatever, is a failure.

Postmark also claims that your DKIM signature is incorrect / not validating, e.g. DKIM_INVALID.

I would ignore Postmark.

Although they appear to claim 57.8% spam, I see nothing on the actual screenshot you shared, that indicate what points to the decision.

Here we’re running with a bit more info:

Received: from cloudserver3326167-3326198.online.pro (cloudserver3326167-3326198.online.pro. [])
        by mx.google.com with ESMTPS id l23-20020a2e3e17000000b0029050f7ebadsi4309009lja.272.2023.
        for <[email protected]>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sun, 12 Feb 2023 07:52:32 -0800 (PST)
Received-SPF: pass (google.com: domain of [email protected] designates as permitted sender) client-ip=;
Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=dkim header.b=xdbTHR+Q;
       spf=pass (google.com: domain of [email protected] designates as permitted sender) [email protected];
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=abecar.pl

According to Authentication-Results, everything seems fine - you’re passing it all.

The Received line however, shows as I mentioend above, that you deliver directly to Gmail (and other inbound mail servers), from an IP address that has huge signs of being dynamic, due to it’s dynamic / generic, and likely auto-generated kind of host name.

→ If this is actually a mail server, that you run and operate yourself, change your Postfix’s SMTP banner name to mail.abecar.pl, and have your ISP change the dynamic/generic hostname from cloudserver3326167-3326198.online.pro, to mail.abecar.pl as well.

  1. Domain has MX record(s)
  2. Domain has AAAA record(s).
  3. Domain has A record(s).

If just one of them are true, there would be nothing to worry about in that regards.

It is not related to Cloudflare at all.

The only way you can figure out what really is (or might be) the problem, is by contacting the actual destinations that reject you (or place you in spam), obviously by other ways than through email, and poke them to get more insight in why they are doing what they do.

But fixing the dynamic / generic, and likely auto-generated kind of host name as mentioned above, will likely help a lot, as many destinations will reject you based on that.



Thank you for your detailed answer. I’m not an expert in the field of mail/dns, I appreciate it.

CNAME is useless that’s right but i left it there cause i would like to point A record to a vps-hosted site

I assume that _pop3._tcp , _imap._tcp are those that are insecure. Are these really fine? If I remove these records i assume that the only traffic that will be allowed is the one over TLS, right?

I do not have access to this e-mail server except for admin panel provided by hosting company. From this admin panel I can create mailboxes, enable/disable DKIM, change mailbox passwords, but i cannot access server though SSH for example.

That’s a good point, but am I able to change this without asking the mail-hosting provider? I don’t think so.

I don’t think that it’s happening, cause I do not have direct access to the server, as I have already mentioned.

I don’t think that’s relevant if gmail says it’s valid in headers.

Now it says that 70% of tested e-mails ended up in SPAM when it comes to domains like outlook, yahoo or gmail. The rest of the information from this service is not important. It basically says try improving using different tools and not much technical stuff.

As i have said i have access to this server only through the admin panel. I assume I should ask for it my service provider, am I right?

These are google, yahoo and outlook. I don’t know if they have support e-mails. At least I couldn’t find one for Gmail. Only general stuff and a knowledge base.

Thank you for your time.

Correct assumption, that those would be the records.

The SRV records doesn’t dictate what’s allowed or not. They do simply provide help / guidance for email clients, to help (auto) configuring with as few user interaction as possible, when someone sets up their email client.

A record value of “0 0 0 .” indicates that you do not wish that kind of type, so e.g.:

_imap._tcp           SRV  0 0 0   .
_pop3._tcp           SRV  0 0 0   .

Should make clients that support SRV records understand that unencrypted IMAP and POP3 would be a no go.

That part was solely referring to Postmark, given your screenshot.

As Postmark runs an email service, you would typically expect them to know quite well about the field that they are in, right?

The screenshot does however yell incompetence from their (Postmark’s) side.

As for both of those, you’re correct.

It is only rarely (if ever), when you rent your services this way (and do not operate the server yourself), that you have access to that part of it.

As long as Postmark is the only one saying your DKIM is invalid, I would also not put too much weight in to it.

But your authentication checks (including DKIM) still passes?

I noticed that your DKIM signing is also using the relaxed/simple canonicalization setting, if you can change that to relaxed/relaxed, you could perhaps win a bit more passes on DKIM, even when the message may pass through some strange mail systems.

Mind sharing what exactly it is, that glockapps is complaining about?

Yeah, I’m also afraid you won’t get much (if any at all) assistance from any free mail provider.

“Free” does often come with a consequence, and for the majority (if not all) of those free mail providers, it usually means extra tight spam filtering (most likely, leading to rejected messages), heavily inbound rate limiting, and so on. Things that many of their users are unfortunately (too) unaware of.

But they would technically be the only ones having the data about why their systems did what they did.

1 Like

I’ve contacted my provider, they are trying to resolve the problem.

I’m considering that, cause at least I would have more impact on resolving these problems.

It does according to glockapps https://snipboard.io/ClndjY.jpg

Well, it does not say much. It just tells that it was classified as SPAM by google filters. They recommand going to some Gmail Postmaster Tools but it just does not work. Here screenshots:

I’m currently in contact with the provider. I will write if there is any progress in 2-3 days.

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