Issue Plesk Obsidian for Linux intermittently fails to deliver outgoing emails even though SMTP settings and DNS records appear correct

[leadeen]

Server operating system version

Ubuntu 22.04 LTS (64-bit)

Plesk version and microupdate number

Plesk Obsidian 18.0.70 and MU 3

I’m currently troubleshooting an intermittent email delivery problem on a server running Plesk Obsidian for Linux. The domains hosted on the server have working websites, and incoming mail appears to be functioning normally, but outgoing messages are not consistently being delivered. In some cases, an email sends successfully without any noticeable delay, while at other times the application or mailbox reports an SMTP connection or delivery failure. The issue does not seem to affect every message, which makes it difficult to determine whether the problem is related to Postfix, the mail service configuration, or something happening at the server/network level.

I have already checked the usual DNS and authentication settings for the affected domain. The domain has SPF, DKIM, and DMARC records configured, and the corresponding mail settings in Plesk appear to be enabled correctly. I have also verified that the mail service is running and that the affected mailboxes have sufficient storage space. What is confusing is that the configuration does not appear to change between successful and failed attempts. When the same sender sends another message later, it may work normally, so I’m wondering if there could be an intermittent connection issue between Postfix and the remote SMTP servers rather than an incorrect DNS or authentication configuration.

The main difficulty is finding useful information in the Plesk interface because the failure is not always reproduced consistently. I have started checking the mail logs around the exact time of failed messages, but I’m not sure which entries would be most important to focus on when distinguishing between a remote rejection, SMTP timeout, DNS resolution problem, connection refusal, or a local Postfix queue issue. I also want to avoid making random changes to the mail configuration because the server does successfully send some messages and I don’t want to introduce another problem while troubleshooting this one.

Has anyone experienced this type of intermittent outgoing-mail failure with Plesk Obsidian for Linux? I would appreciate advice on the best way to trace one failed message from the application or mailbox through Postfix and determine exactly where the delivery process is breaking. In particular, I’d like to know which Plesk/Postfix logs and commands I should check, and whether there are any Plesk-specific settings that commonly cause intermittent SMTP connection or delivery problems when SPF, DKIM, and DMARC are already configured correctly.

 

[Kaspar]

The delivery status notifications (bounce messages) usually tells you exactly where it broke:

• "Connection timed out" / "Connection refused" → network-level issue reaching the remote MTA. Could be on you end, but just as well on the receivers end.
• "450/451 4.x.x" temporary reject → greylisting or rate limiting on the receiving side (very common cause of intermittent failures).
• "550/554 5.x.x" permanent reject → policy/reputation/DNS issue on their end.
• "Relay access denied" → your local Postfix config issue.

If it's mostly 4xx codes, that's a strong signal it's not your SPF/DKIM/DMARC setup at all, it's the receiving server being picky. Postfix will usually just retry later, which explains why the same message "works the next time."

If the remote server sends a NDR or bounce message back, look at the attached delivery status report (message/delivery-status) for diagnostic fields like Action, Status, and Diagnostic-Code. Intermittent failures accompanied by 4xx soft-fail connection timeouts or rate-limiting responses typically point to remote IP throttling, transient DNS resolution delays on Port 25, or poor server IP reputation rather than a local Postfix misconfiguration.

If you want to dive deeper into the errors being logged, focus on matching the timestamp and recipient address in /var/log/mail.log (or /var/log/maillog) to find the exact Postfix transaction ID. Pay close attention to the status messages returned by the remote SMTP server, lines marked with status=deferred or status=bounced will include standard SMTP reply codes and Enhanced Mail System Status Codes (e.g., 451 4.4.0 for network timeouts or 550 5.7.1 for policy rejections).