Resolved Mails marked as Spam

[l4k3d3v1l]

Server operating system version

Ubuntu 22.04.3

Plesk version and microupdate number

Obsidian 18.0.55

Hello everyone,
im going crazy because im not able to fix my mail problems.

Have running a VPS with linux and Plesk, multiple Domains on the Server running.
Sending mails the problem is that from 1 domain (ar-bieler.eu) everything looks fine and mails are delivered without marked as spam. But from 2. domain (sondelfreunde.eu) the mails always are marekd as spam.

compared all settings and cant find a difference. Im flipping out because i cant understand why this happen.
Anyone an idea?
TY in advance


That is going to SPAM, sent from problem-domain

Delivered-To: [email protected]
Received: by 2002:a05:6a20:4c1e:b0:14e:b18f:e54d with SMTP id fm30csp3309287pzb;
Thu, 7 Sep 2023 05:23:42 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IHBKsOb6VDj3WKKvXEDjFGqJZ3BaDFw836PAXRDLTBUwXRLHh4IEmqjGg3/K2uN0CBrIXb/
X-Received: by 2002:adf:e744:0:b0:319:74d5:a2d7 with SMTP id c4-20020adfe744000000b0031974d5a2d7mr5489454wrn.32.1694089421869;
Thu, 07 Sep 2023 05:23:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1694089421; cv=none;
d=google.com; s=arc-20160816;
b=viOA2sKu8txow9oo6gUDqLA9wL/NY9PoNVpa4XxkevB3BzXKklxcnGcoX7oeH50Xb/
AcnWjMy9uemBF9ky0/vY3Rq2VzWBsC7mI8Algsgt3JDMB0teuPxKX0ZqfxzGH8MOLjbh
vtoyTtoljLCRWMZQ4gpoeNISqCVNPc5MTMQimSSV+o+k32X6HfY2qX2D/xm8DkehwE5H
gRn/gYp95Z/h9Ks97XcojgRseb4ZoE27t8ctI+7ugbQkf+XdUKwSdYo52ZSBOn0oZDcj
5olRAdvkIBseI51Dt5NCpJfpT97FEn5mqiI9qz5VBqVmCyFb3mOjbFQonPHulByYsyRG
gesg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=content-transfer-encoding:subject:from:to:user-agent:mime-version
:date:message-id:dkim-signature;
bh=bj74/rslR0bn/dJ9cdn2gpaxFeMo+U6NOpehHz71RU4=;
fh=dGoG7Ntqvck8IUsZQ2lCa2K1h833cVxovj0BzNdhzoM=;
b=TWmXMq8iJFJhozkayGsnqrxhUAfquifJhh6io4RXcjMLoUW4F6HCbDLtGhwBVY7XIQ
VDq/pNhU2Tuc3hWnNL3z+Qf4q8+RBn2jUQmEQRInUFvDLw5zcvlpIgALpg54r7dePs8Q
wZOOUaF2CNZIwohn+XdSxNtlo6PvnJ7sRjexQyb5RPBUm0fwsbj0sdOGfqq/qyP+GFii
qtgYiHV8M1L/mlANNLfZdTDfpw4Y61UrCrZ2fVFpVQWfJQ3X7Uv9XV/8veFZbZEA18Sp
Esxl4u4afvzNryuTyi7TlYJHhP9K4pNhgiTA1LqRU7BdzEUtpxuZkXvwinVBepV4DB49
TPIQ==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass [email protected] header.s=default header.b=hCbZ3T4Y;
spf=pass (google.com: domain of [email protected] designates 81.169.234.105 as permitted sender) smtp.mailfrom=[email protected];
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sondelfreunde.eu
Return-Path: <[email protected]>
Received: from rbmedidata.de (rbmedidata.de. [81.169.234.105])
by mx.google.com with ESMTPS id x14-20020adff0ce000000b003180693d179si8490054wro.289.2023.09.07.05.23.41
for <[email protected]>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 07 Sep 2023 05:23:41 -0700 (PDT)
Received-SPF: pass (google.com: domain of [email protected] designates 81.169.234.105 as permitted sender) client-ip=81.169.234.105;
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=default header.b=hCbZ3T4Y;
spf=pass (google.com: domain of [email protected] designates 81.169.234.105 as permitted sender) smtp.mailfrom=[email protected];
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sondelfreunde.eu
Received: from [192.168.178.20] (unknown [77.21.30.188])
by rbmedidata.de (Postfix) with ESMTPSA id E2E971A03E9
for <[email protected]>; Thu, 7 Sep 2023 14:23:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sondelfreunde.eu;
s=default; t=1694089421;
bh=bj74/rslR0bn/dJ9cdn2gpaxFeMo+U6NOpehHz71RU4=; h=To:From:Subject;
b=hCbZ3T4YghOZ3ihTgxVtfIQ2J1k7tdjJuyHoRQSdNlaq8qJW/a8w7esYbqs7zYyFw
k9AWenF71wxv9mLiH1vlo3EBvvLUHmOvd0Nr3qd1SLqkYcfxaBlLX/6QmqQrnbZMZ1
VrU2+J5lk0ue1MlfuXDBzSgEyZszF0NNK9djnxLHd7jrQHDAjbOY3cr4R3wT98L4Ot
8Qg0UJLdCo+BoByNfpjH57BZRy+6ACS9IDsK/gDuAR8Fwel3mvBvTrXjKGZ0ue9SHv
RfAlh+2dbw+Afw1ZOKCp+YNZhdWyDN53jN+uz7Lp9BZvtmJ5VyosZm8tCZZu1KRN/r
ZeJf2rqObHi8Q==
Authentication-Results: h2991872.stratoserver.net;
spf=pass (sender IP is 77.21.30.188) smtp.mailfrom=[email protected] smtp.helo=[192.168.178.20]
Received-SPF: pass (h2991872.stratoserver.net: connection is authenticated)
Message-ID: <[email protected]>
Date: Thu, 7 Sep 2023 14:23:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: xxxx.com
From: "Sondelfreunde.eu" <[email protected]>
Subject: testmail
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-PPP-Message-ID:
<[email protected]>
X-PPP-Vhost: sondelfreunde.eu

testmail

 

[Peter Debik]

Header looks good. I assume that only Gmail is marking incoming mail from the domain as spam? If the SPF record is correct (it is) and DKIM key is correct, yet the mail is still marked as spam, maybe it's the mail content that is causing it? Using the Google Postmaster Tools Get started with Postmaster Tools - Gmail Help can help.

 

[l4k3d3v1l]

Header looks good. I assume that only Gmail is marking incoming mail from the domain as spam? If the SPF record is correct (it is) and DKIM key is correct, yet the mail is still marked as spam, maybe it's the mail content that is causing it? Using the Google Postmaster Tools Get started with Postmaster Tools - Gmail Help can help.

Thank your for having a look at it.

 

[tramvainqueur]

From my experience: Some e-mail-servers look at the PTR and test the rDNS. So PTR shall show to the used MX, but if any FQDN is set, this seems to be often good enough. Also rDNS seems for most not having to show to the MX, just an FQDN, but in some cases some e-mail-servers want a rDNS and that it is valid. For a valid rDNS your server in plesk may not have the name DOMAIN, but SUBDOMAIN.DOMAIN like server.domain.tld. Then rDNS has to be set in the network of the hosting provider. Often this can not be set by oneself if not owning the network, but many providers give you a web interface where you can set remotely the wanted rDNS (for me I had to set subdomain.domain.tld ... FQDN was not allowed, but e-mail-test-sites say, rDNS is valid now). Normall the PTR domain records for IPv4 & IPv6 should show to a FQDN (I set the MS as "subdomain.domain.tld." - yes, point at final for being FQDN - and against this setting does no e-mail-test-site complain).

But if a valid rDNS can not be set, a rDNS and PTRs are often accepted although they are not valid. Often they only have to exist. But if you can, better set a valid rDNS.

 

[tramvainqueur]

*ouch* edit for little updating not possible as it lastet more than 4 minutes ... well then back again but updated:

From my experience: Some e-mail-servers look at the PTR and test the rDNS. So PTR shall show to the used MX, but if any FQDN is set, this seems to be often good enough. Also rDNS seems for most not having to show to the MX, just an FQDN, but in some cases some e-mail-servers want a rDNS and that it is valid. For a valid rDNS your server in plesk may not have the name DOMAIN (domain.tld), but SUBDOMAIN.DOMAIN (subdomain.domain.tld) like server.domain.tld. Then rDNS has to be set in the network of the hosting provider. Often this can not be set by oneself directly if not owning the network, but many providers give you a web interface where you can set remotely the desired public rDNS (for me I had to set subdomain.domain.tld ... FQDN was not allowed, but e-mail-test-sites say, rDNS is valid now). Normally the PTR domain records for IPv4 & IPv6 should show to a FQDN (I set the MX as FQDN "subdomain.domain.tld." - yes, point at final for being FQDN valid - and against this setting to the server does no e-mail-test-site complain ... they are happy now ...).

But if a valid rDNS can not be set, a rDNS and PTRs are often accepted although they are not valid. Often they only have to exist. However if you can, better set a valid rDNS although many bis e-mail-servers do not require this, if I remember well.

update: eliminated some orthographic mistakes and some minor gramatical changes

 

[l4k3d3v1l]

After changed my Server (a new one with new IP) everything works fine.
Because everything is set up the same way, im sure the problem was that the old Server was blacklisted.

Now happy, that everything works fine.
Thx for Reply

 

[tramvainqueur]

rDNS & PTRs set correctly?
Do you configure DNS server and server with plesk itself separated? Has set the provider rDNS automatically correct?

After server change ('long time' ago) I also had problems as the IP-address was blacklisted on several places. But one can demand the removal on some lists and on some the almost clean configuration seems to have achieved that this IP-address got removed automatically from their blacklists, too. So an IP-address blacklisted on several DNSBL can be cumbersome but can be cleaned. Most cleaning is automatically if server and its configuration and the domain records are clean enough.

After this I had some times a strange problem with missing rDNS & PTR (and not correctly configured), but since I configured them, no problem anymore (only the problem, that changes in domain records need propagation time and this depended on area but this is technologically natural and can not be avoided ...).