“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:
→ pct=100;
→ ri=86400;
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. 1.1.1.1 (Cloudflare), 8.8.8.8 (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. [46.242.233.18])
by mx.google.com with ESMTPS id l23-20020a2e3e17000000b0029050f7ebadsi4309009lja.272.2023.02.12.07.52.32
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 46.242.233.18 as permitted sender) client-ip=46.242.233.18;
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 46.242.233.18 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.
- Domain has MX record(s)
- Domain has AAAA record(s).
- 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.