Client's email is always landing in people's junk folder

My two MiaB email servers send out several million emails a year. I have maybe 20 domains that I host for folks. But one customer is having so many troubles and I am at wits end on what the issue is. He sells branded merchandise and his vendors, clients, and potential clients are all claiming to always find his email in their junk folders.
There is a DKIM, there is a SPF, the DNS is as perfect as I can get. He sends his email through my server. He has a nice sig at the end of his emails. I am not on any blacklists. Any time I watch the server when he sends his email, his email gets to its destination perfectly. But it seems they always end up in the junk/spam folder.

Any ideas please! I don’t know what to do for the guy; I have run out of suggestions.

Keith.

The only thing I don’t have is the reverse lookup resolving the IP address to the server for IPv6. My data center is having a hell of time figuring out how to provide such services to their customers.

Here is the SPAM score my MiaB gives his email when he sends me an email.

X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5% * [score: 0.0396] * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.0 HTML_IMAGE_RATIO_04 BODY: HTML has a low ratio of text to image * area * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from * author’s domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid

X-Spam-Score: -1.6

X-Spam-Status: No, score=-1.6 required=10.1 tests=ALL_TRUSTED,BAYES_05, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_IMAGE_RATIO_04,HTML_MESSAGE autolearn=ham autolearn_force=no version=3.4.6

If it is Rdns of the IPV6. Just disable IPV6 sending by editing /etc/postfix/main.cf insert a line smtp_address_preference = ipv4

By the way the header that you quote is from trusted hosts (sending from your smtp to your smtp) and it is not valid. Try sending the message to gmail> hit Show original to observe the headers. See if dkim, dmarc and spf are OK. You can observe the rdns in the first “Received: from” line and it should match.
Or send me a message I will forward you the headers (see private message for email)

Spamassasin RDNS_None should give +1.27 score and the message should land in Inbox anyway. Maybe the recipient has some rule in its email client to treat this message as spam.

IPv6 is very important to me. I moved data centers for it. :slight_smile:
Thanks for the offer; I am going to send the test message to you.
The issue is that a bunch of the guy’s customers are making the same claim that the email is always in the junk folder.

It’s interesting that your IP is clean but this one sender gets junked. I wonder if he has been marked as spam by a lot of the recipients and therefore the receiving providers are moving him to junk internally regardless of the reputation of your IP and the setup of the DNS, DKIM, etc.

Is there a way to check if it is just some of the big email providers like Gmail, Hotmail, Outlook, etc. that he is having an issue with that shows a pattern or is it a lot of different recipients. Keep in mind that a lot of companies use 365 or Google for their hosted email services so it may seem like a small provider but still fall under internal screening by the big guy upstairs.

You can also use sites like https://www.mail-tester.com/ to test deliverability. Let your customer send an email to such a test email address.

I used isNOTspam.com earlier today. They have his email as fine for everything except Baysian tests; saying his email is 99-100% spam. I am beginning to think it is because he has HTML turned on with his Outlook client and so despite his content being fine enough it looks way worse than it is. I asked him to turn it off; so we’ll see if it helps.

Of course, I am still open to any suggestions.

|-0.1|DKIM_INVALID|DKIM or DK signature exists, but is not valid|
|-0.1|DKIM_SIGNED|Message has a DKIM or DK signature, not necessarily valid
This rule is automatically applied if your email contains a DKIM signature but other positive rules will also be added if your DKIM signature is valid. See immediately below.|
|-0.001|HTML_MESSAGE|HTML included in message
No worry, that’s expected if you send HTML emails|
|-0.001|SPF_HELO_NONE|SPF: HELO does not publish an SPF Record|
|-0.01|T_SPF_PERMERROR|SPF: test of record failed (permerror)|

Are the last two misconfigurations on my part with MiaB or does MiaB just not do those things?

Mailinabox should do spf, dkim and dmarc. https://www.learndmarc.com/ is a good one to look specifically at those.
DKIM_INVALID and SPF_HELO_NONE should not happen.

learndmarc.com passed me with flying colors.

DKIM_INVALID and SPF_HELO_NONE might have happened because I redirected his email through my account.

I sent you the headers the only score is this: everything else is OK.

1.3 RDNS_NONE Delivered to internal network by a host with no rDNS

Just disable IPV6 sending as per the post above, if you have IPv4 rDNS setup.

Not sure I entirely understand. The important thing is that he sends the email to those test sites exactly as if he’s sending an email to a customer. It should not be your account that sends the email.

Without rDNS on his ipv6 it ends up in SPAM definetly. I tested this with gmail. Since @Keith_Rettig has a working ipv4 rDNS I am not sure why he is sending via IPv6 without rDNS?

Spamhaus keeps track of sending patterns and of course the big tech mailbox providers. I am sure that he defaults to SPAM in their internal lists as he lacks a ptr record on IPV6 and then they link him to the domain >> defferal, bounce, etc. @Keith_Rettig See the logs if any of the defferals make your server to try to send via IPv4 when deffered with a delay. Use
sudo cat /var/log/mail.log | grep “postfix/smtp” | grep -P ‘status=’

smtp_address_preference = ipv4
has been set. server rebooted. now I wait to see if there is any effect to his email landing in spam or not.

Thank you, @vele