Email ending up in Spam folders

Virtualmin
1

Hi All,

Can anyone help me resolve an issue.

Mail sent from one of my virtualmin servers in being classed as ‘spam’ and ending up in Gmail junk folders etc.

I’ve got DMARC, DKIM and SPF correctly set up and I can see in the email headers these are all working ok.

Is there anything else I can do?

2

You could start by seeing if your IP is blacklisted?
https://whatismyipaddress.com/blacklist-check

3

Thanks for the reply.

I’ve checked and it’s not black listed.

I’ve also ran a test on all about spam and that came back ok.

4

Unfortunately you can do everything right, and the reputation (or lack thereof) of your IP address will result in your emails being considered as junk, even if they’re all legitimate. This is a particular problem of low-volume senders, or people hosting with providers who are known to be ‘spammy’ (Linode, AWS, Digital Ocean etc).

Nowadays unfortunately it takes a long time to establish ‘reputation’ for your IP address as a known good sender. I’m having similar issues with a new IP address for a new server for a client despite them having been active business email users from the same IP address for almost a decade. Microsoft in particular have a terrible set of algorithms which take an incredibly strict approach to what it auto-classifies as spam or legitimate, and it’s almost impossible to get them to ‘mitigate’.

Usually however, GMail is usually much better - provided you have things like PTR records set up for your IP address, you have SPF alignment, your DMARC and your DKIM is set up correctly, you are using TLS to send emails and so on.

If you’re OK with it, post the headers as received from the GMail copy of the received message and it may indicate a reason for the message(s) being flagged as spam.

Of course, what you should be doing is marking as Not Junk in the meantime to help train the filters. But there’s no magic bullet.

Certainly out of the box, Webmin’s implementation of Postfix and Dovecot is pretty good, there are a handful of things to tweak but for the most part it’s a good base setup. Fundamentally it comes down to how long you’ve been seen by other mail services as sending reputable emails to their servers. Arguably going down the road of anticompetitive practice, but all the larger operators are only getting harsher about what they consider legitimate traffic into their systems.

There’s various free web services out there to test the ‘quality’ of both your mail server setup and the content of your emails, I can recommend a few for starters if you’re interested.

It’s always going to be a struggle nowadays! Your own host plays an important part. If your IP was previously used for nefarious means, or you’re a small fish in a big pond of less than scrupulous operators, you will suffer collateral damage from their bad actions from IPs in the range your server sits in.

Read about email deliverability best practices and IP reputation, and get depressed…! :grimacing:

2 Likes
5

First check you are not a Nigerian Prince? :wink:

6

Or a banker…

7

Maybe you could ask your provider for a new IP? But if you are not blacklisted, I guess that will not help.

If you have an ‘iffy’ free domain like .tk .cc etc, they can be get spam-trapped just by default.
Although I do use .ml ones for testing without any problems.

8

Microsoft were blocking mail from one of my VPSs because someone in my subnet had previously spammed. Nothing to do with spam from the IP I was using. They are tough.

I ended up routing mail destined for Microsoft via one of my other servers inspired by the guide posted by “Razza” in this forum post: https://www.lowendtalk.com/discussion/117487/microsoft-blocking-emails-yet-claim-we-are-not-on-block-list/p2

1 Like
9

Thanks for the replies.

No problem in pasting the gmail header as they received it. Does it give any clues?

    Delivered-To: craigshaw8569@gmail.com
Received: by 2002:a02:6f08:0:0:0:0:0 with SMTP id x8csp540425jab;
        Wed, 5 Feb 2020 11:52:58 -0800 (PST)
X-Google-Smtp-Source: APXvYqw/Qa45XlUgQuI3GQ+9OAEwcrRgygva2hjFagIKctnAWnmwc9fH5ROd54SooooyRUVoNSRb
X-Received: by 2002:a1c:1d8d:: with SMTP id d135mr7454505wmd.92.1580932377946;
        Wed, 05 Feb 2020 11:52:57 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1580932377; cv=none;
        d=google.com; s=arc-20160816;
        b=u3dXfSkWD7SwyQV6I8Lv1n18Ln4QvihqlK53CFCKKkBq2MSvbbtXQfY3wl09cG2nj2
         huzhaAjBtL9JJKka/fraGBKW/qqztCf7JIZov9NYtS5G+/xM43lF/Aintes/Xzg3Is5i
         kJ6800ccxH9OdoUokBB2lP0QRmVnGel/Lhp7H+r1ezzfNQ5Qft7BMG5KAKMU2sN5W2JB
         3pKIQljnVtHW6UDzWnRG64rPOVf1nJcz3Hbc+kxdh3PgxmzrSp0J5K+27E6H4J6DiP5f
         B0Jnzc64WDhALBMKYLQ+iEFyXnXAwZyUjVHlaYHog4HnVhi9E3JQopJVNiTveavPrPPD
         VP3A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=mime-version:date:message-id:to:subject:from:dkim-signature;
        bh=P0lEOBQpaITR4phUr/0HOsb5zks9EAPyKnhWtN0fP+k=;
        b=jIKWBjKP+BZZXSCC+F/ZGl2JS8Zrok3owUYk3OHEQX6wF+ukXDN9BInXFNu05iMkmW
         5rwYT0Vkq63FlJ9IDYt6mPXimkCmnlO3fVXNguSzqE0T5OdDduArNMvCJFPmN9liTAkc
         GMazONun7Hq7yZabAwtj279haM1hG0Da9tIU5FeOAEjOzhMRIHoIe/ocWaNcCUaLx33O
         AF+X/M0KUT349DAsJQym7S9eweuY/G1SttcrXuwe6sRLZk7EDMtirXyxqdXaUvnquBQK
         mMGMHCy7nPe+QPHq92k/9gBS3GD9k7cSxugnWlbXtaa21ZRKfbmahVeXKRTI1HJ7Ym4c
         jfnQ==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@linden-d2.co.uk header.s=default header.b=Ojrht9OP;
       spf=pass (google.com: domain of craig@linden-d2.co.uk designates 212.48.74.238 as permitted sender) smtp.mailfrom=craig@linden-d2.co.uk;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linden-d2.co.uk
Return-Path: <craig@linden-d2.co.uk>
Received: from green6041.server-cp.com (linden-d2.co.uk. [212.48.74.238])
        by mx.google.com with ESMTPS id v10si365859wrs.42.2020.02.05.11.52.57
        for <craigshaw8569@gmail.com>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Wed, 05 Feb 2020 11:52:57 -0800 (PST)
Received-SPF: pass (google.com: domain of craig@linden-d2.co.uk designates 212.48.74.238 as permitted sender) client-ip=212.48.74.238;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@linden-d2.co.uk header.s=default header.b=Ojrht9OP;
       spf=pass (google.com: domain of craig@linden-d2.co.uk designates 212.48.74.238 as permitted sender) smtp.mailfrom=craig@linden-d2.co.uk;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linden-d2.co.uk
Received: by green6041.server-cp.com (Postfix, from userid 0) id 2F66CC06BDBF2; Wed,
  5 Feb 2020 19:52:57 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linden-d2.co.uk; s=default; t=1580932377; bh=P0lEOBQpaITR4phUr/0HOsb5zks9EAPyKnhWtN0fP+k=; h=From:Subject:To:Date; b=Ojrht9OPuuoTLxYxUUPJ6/Z3PfsykzAXqI2+kbp6wvd08KNvd8WpKFJJsjU3Zdg8I
	 q2tT1VRMvyzR2oqsLBHMJgTSMGzv7FD5EBkTivQP0+Ny9mhtR8Y7vSNe2aVWRE8rv+
	 fmhuvyrMw4L31FtrJycopDtfQe0SWmGa7TpIHG63264C4V+6RmdWgY9aYoOcSOiX/g
	 cu8idMxc2fkYczat766PGBrpPldAmGzSEAimHdhYcikQo2Yd8E/RgAlD3ZZfl8Q4O8
	 xxfNsL3ff5KdmkK9KeGz49htBTFUdPKtNUoHeQR45Z3UkAEg/ycufvmKSB34C05XxR
	 3GWPprz/u+jeA==
From: craig@linden-d2.co.uk
Subject: hello
To: craigshaw8569@gmail.com
Message-Id: <1580932377.1418@linden-d2.co.uk>
X-Originating-IP: 146.198.7.202
X-Mailer: Webmin 1.941
Date: Wed, 05 Feb 2020 19:52:57 +0000 (GMT)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="bound1580932377"
X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.5.1 (green6041.server-cp.com [0.0.0.0]); Wed, 05 Feb 2020 19:52:57 +0000 (GMT)
10

@cs10 from your log it looks to me you doing okay only my 2 cents to this would be to have look how youre sending emails out, encryptions etc… - i think this would give you defo end point solution to your problem. - this problem is really solved - please mark it solved.

11

There’s no two ways about it - Microsoft seem to hate new senders. Their algorithm is so heavily biased against low volume, newly seen MTAs that they assume they’re always going to be bad. My suspicion is that they now primarily rely on multiple users repeatedly marking as Not Junk in order to rebias their filters, combined with prior knowledge of previous emails and delivery volumes. (chicken and egg situation much?)

It’s a method which is not suitable for low volume independent senders, and their deliverability team has been so hamstrung by legal restrictions that they don’t seem functionally capable of supporting senders whose mails are being auto-junked.

Now, back to GMail…

GMail are usually more benign with assessing new senders. For IPv6, PTR records must exist and be valid for sending IPs.

It’s not historically been as important, but more emphasis is now being put on PTRs. One thing I’d check is why the HELO in those headers doesn’t match your IP’s current PTR, which doesn’t help.

I started an SMTP session just now to your server and it idented with the same (wrong?) HELO - any particular reason why Postfix is still announcing as green6041.server-cp.com when all your DKIM, SPF etc is running off the corporate domain?

I use a generic HELO which is on my own domain for the server; other clients’ domains send emails through and that there’s no problem as the HELO and PTR for the server IPs (v4 and v6) match. Well, I have problems with Microsoft, but who doesn’t. :wink:

Also try mail-tester.com and port25’s auth checker and see what they say…

For parsing headers I like to use http://mha.azurewebsites.net/ (the standalone version of the Message Analyzer on https://testconnectivity.microsoft.com/). Other useful stuff:

1 Like