Question System Emails Marked as Spam

[Leighton Thompson]

Server operating system version

Debian 10.13

Plesk version and microupdate number

v18.0.58_build1800240123.15

Hello everyone,

I'm reaching out for assistance regarding an email delivery issue within our organization's Plesk installation. Specifically, we're encountering problems with system messages and emails sent by VPS users via cronjobs being marked as spam. While these emails are only received by our IT team, resolving this issue would be beneficial.

Here's a breakdown of our setup:

• Domain1.org.xx (with IP 2 having rDNS)
• Example.ovh (with IP 1 having rDNS)
• We have a couple of other domains hosted on Plesk, but they intentionally have emailing services disabled and we do not intend to send emails from those domains.

Our VPS is hosted with OVH, associated with the domain web.example.ovh. The primary IP for the server is IP 1, although IP 2 also resolves to the server. While Plesk manages several domains, web.Example.ovh (and its parent domain) are not included. The Plesk administration panel is accessed through https://web.example.ovh/.

Emails sent from @Domain1.org.xx are functioning as expected, achieving a 10/10 score on mail-tester.com. However, emails sent from @web.Example.ovh are failing DMARC. Although SPF and DKIM pass, Spam Assassin inside Gmail indicates a failure due to HEADER_FROM_DIFFERENT_DOMAINS=0.248.

I believe this discrepancy is causing the DMARC failure. However, I'm uncertain how to adjust the header exclusively for emails sent from @web.Example.ovh without impacting Domain1.org.xx. Currently, the "Send from domain IP addresses and use domain names in SMTP greeting" setting is enabled in Plesk. Disabling this resulted in deliverability issues for Domain1.org.xx as web.Example.ovh appeared instead.

Hopefully, this description makes sense; I've obscured some details for confidentiality reasons, which made it surprisingly challenging to articulate. I am happy to message someone an example email, but just dont want to post that publicly.

Any insights or suggestions on resolving this issue would be greatly appreciated.

Thank you for your time and assistance.

 

[Peter Debik]

You're alluding to a feature request "Implement support of SPF, DMARC and DKIM anti-spam methods for Plesk email notifications". However, in your case even if the feature already existed, it would not work, because you cannot influence the SPF and DKIM entries of a domain that is given to your server by a provider. They'd have to do it for you.

To achieve your goal nevertheless, do not let the server send notifications to a GMail account, but to an account on your server or elsewhere, where SPF and DKIM won't be an issue.

As an alternative, rename your host to a domain that you are in control of and create at least a matching SPF record for it and let the PTR record at your data center point to it. DKIM is not necessary for successful delivery to GMail, but SPF is.

 

[Leighton Thompson]

You're alluding to a feature request "Implement support of SPF, DMARC and DKIM anti-spam methods for Plesk email notifications". However, in your case even if the feature already existed, it would not work, because you cannot influence the SPF and DKIM entries of a domain that is given to your server by a provider. They'd have to do it for you.

To achieve your goal nevertheless, do not let the server send notifications to a GMail account, but to an account on your server or elsewhere, where SPF and DKIM won't be an issue.

As an alternative, rename your host to a domain that you are in control of and create at least a matching SPF record for it and let the PTR record at your data center point to it. DKIM is not necessary for successful delivery to GMail, but SPF is.

Thank you for your response. It's comforting to know that others are grappling with similar challenges, although I'm still unsure if the issues affecting our setup align precisely with those encountered by others. In my initial question, I mention that both DKIM and SPF pass. The only part failing is DMARC. I assume the passing may stem from the frequent appearance of Domain1.org.xx in the email headers. The complexity of this situation makes it difficult to discern which settings are influencing the outcomes. Ultimately, I do not mind so much as to why certain things are passing; I am more concerned about getting DMARC to pass too.

Regarding our control over domains, the .ovh domain is no different from any other TLD control-wise; we have full access. The only difference is that OVH offers it at an extremely low price for their customers, so it is useful for our backend non-user-facing services. SPF validation is successful, and there's a PTR record for Example.ovh pointing to IP 1. We have a PTR record for IP 2 making it rDNS to Domain1.org.xx

While re-routing notifications to a server-based email is a viable option, it's far from ideal, especially for critical server error reports. Furthermore, achieving compliance with stringent requirements from various mail providers, akin to Gmail's, proves challenging without the modifications suggested in the feature request by other users of your software. Given our organization's volunteer-based structure, ensuring communications reach people in a place they will check regularly is important. Thus, while re-routing emails may serve as a temporary workaround, it definitely isn't a long-term solution for us.

Ultimately, the functionality requested in the feature request holds paramount importance for our organization's operations.

Once again, I appreciate your insights and suggestions.