Email problems in Plesk can affect sending, receiving, or both — and the cause is rarely obvious from the error message alone. Common culprits include misconfigured DNS records (particularly SPF and MX), a blocked outgoing port, the Plesk mail server being disabled, or a full mailbox. Problems can also stem from a backlogged mail queue, missing DKIM configuration, or an incorrect email client setup on the user’s machine. This guide works through each cause in order of likelihood, covering both server-side diagnostics and client-side checks.
Step 1: Confirm the Plesk Mail Server Is Running
The first thing to check is whether the mail service itself is active. Navigate to Plesk → Tools & Settings → Services Management. Find the Mail Server entry — this will be either Postfix or qmail depending on your Plesk version. The status should show as running. If it is stopped or shows as failed, click Start.
If the mail server fails to start, check the system journal for errors:
journalctl -u postfix --since "1 hour ago"
A failed start is often caused by a configuration syntax error or a port conflict with another service. Resolve the underlying error before proceeding.
Step 2: Check the Mail Queue for Stuck Messages
Navigate to Plesk → Tools & Settings → Mail → Mail Queue. If messages are accumulating here without being delivered, the Reason column will indicate why. Common reasons include DNS lookup failure, connection refused by the remote server, and relay denied.
You can also inspect the queue directly from the command line:
mailq
To attempt redelivery of all queued messages:
postfix flush
If the same messages keep failing, address the root cause — flushing alone will not resolve a DNS or port issue.
Step 3: Check MX Records Are Correct
If email is not being received at all, the most likely cause is an incorrect or missing MX record. Navigate to Plesk → Domains → [your domain] → DNS Settings and locate the MX record. It should point to your mail server hostname — typically mail.yourdomain.com or the server’s primary hostname.
Verify using an external DNS lookup tool, or from the command line:
dig MX yourdomain.com
The response should return your mail server hostname with a priority value (e.g. 10). If the MX record is missing, incorrect, or pointing to a hostname with no valid A record, incoming mail will fail. After making changes, allow up to 48 hours for DNS propagation, though in practice most resolvers will pick up changes within a few hours.
Step 4: Check the SPF Record
A missing or incorrect SPF record causes outgoing email to be rejected or marked as spam by receiving mail servers. The SPF record is a DNS TXT record that tells receiving servers which IP addresses are authorised to send email on behalf of your domain.
A minimum valid SPF record for a single-server setup:
v=spf1 ip4:YOUR.SERVER.IP ~all
Add or update this in Plesk → Domains → DNS Settings. Create a TXT record at the root of the domain (the Name field should be blank or contain @) with the above value, replacing YOUR.SERVER.IP with your server’s public IP address.
If your domain already has an SPF record, do not create a second one — only one SPF record per domain is valid. Edit the existing record to include the server IP.
Step 5: Check Port 25 Is Not Blocked
Many hosting providers and datacentres block outbound port 25 by default to reduce spam originating from their network. If outgoing email is not being delivered and the mail queue shows connection refused or timeout errors, this is likely the cause.
Test whether port 25 is reachable outbound:
telnet smtp.gmail.com 25
If the connection times out rather than returning a greeting banner, port 25 is blocked at the network level. There are two remedies:
- Contact your hosting provider and request that outbound port 25 be unblocked. You may need to justify the request if you are on a shared or VPS plan.
- Configure Postfix to use port 587 (SMTP submission) as a relay through an authenticated smarthost such as SendGrid, Mailgun, or your ISP’s outbound relay.
For client-side sending, instruct users to use port 587 with STARTTLS rather than port 25.
Step 6: Check for a Full Mailbox
When a mailbox reaches its quota, incoming messages will bounce back to senders with a quota exceeded error. Navigate to Plesk → Mail → Mailboxes and check the quota usage for the affected account. A bar graph or percentage will indicate how full the mailbox is.
To resolve this, either increase the quota by editing the mailbox settings, or have the user log into webmail and delete or archive old messages. If webmail is also inaccessible due to the full quota, you can increase the limit from Plesk first, allow the user to log in, and then reset it once they have cleared space.
Step 7: Check the Mail Log
The mail log is the most reliable source of diagnostic information. Navigate to Plesk → Tools & Settings → Logs and select the mail log — this is located at /var/log/maillog on CentOS/AlmaLinux or /var/log/mail.log on Debian/Ubuntu.
You can tail the log in real time from the command line while attempting to send a test message:
tail -f /var/log/mail.log
Key SMTP response codes to watch for:
- 550 — Message rejected by the receiving server, often due to policy or blacklisting
- 554 — Transaction failed; relay access denied or message blocked
- 421 — Temporary failure; the receiving server is unavailable or rate-limiting you
- 452 — Insufficient storage on the receiving server (not your problem to fix)
A 550 with a message referencing your IP address may indicate you are on a spam blacklist. Check your server’s IP against major RBLs (Real-time Blackhole Lists) using an online lookup tool, and follow the delisting process for any lists on which you appear.
Step 8: DKIM Not Configured
DKIM (DomainKeys Identified Mail) cryptographically signs outgoing email, which helps receiving servers confirm the message genuinely originated from your domain. Without it, email is more likely to land in spam folders even if SPF is correct.
To enable DKIM in Plesk, navigate to Plesk → Mail → Mail Settings for the domain and enable the Use DKIM spam protection option. Plesk will automatically generate the required DNS TXT record and begin signing outgoing mail.
Verify DKIM is working by sending a test email to a Gmail address and checking the message headers — look for a dkim=pass result in the Authentication-Results header.
Webmail Working But Email Client Not
If Roundcube or Horde webmail works correctly but a desktop client such as Outlook or Thunderbird cannot send or receive, the issue is almost always an incorrect client configuration rather than a server-side problem.
Confirm the following settings in the email client:
- Incoming mail (IMAP): server is
mail.yourdomain.com, port 993, SSL/TLS enabled - Outgoing mail (SMTP): server is
mail.yourdomain.com, port 587, STARTTLS enabled - Username is the full email address, not just the local part before the @
- The password has not expired or been changed in Plesk without updating the client
If the client throws a certificate warning, this typically means the mail hostname does not match the SSL certificate installed in Plesk. Navigate to Plesk → SSL/TLS Certificates and confirm the mail hostname is covered by the installed certificate. Plesk’s built-in Let’s Encrypt integration can generate a certificate that covers the mail subdomain if needed.
Related articles: Plesk Troubleshooting Guide
