Introduction

When a Plesk server stops receiving external email, the website can still work normally, which makes the mail failure look random. Inbound delivery depends on several layers lining up at the same time: the domain must route mail to the correct host, Plesk must have mail service enabled for that domain, the server must accept SMTP connections from the internet, and the local mailbox must still be deliverable. The safest fix is to verify the full inbound path from public DNS to the mailbox instead of checking only one setting in Plesk.

Symptoms

  • External senders cannot deliver mail to addresses hosted on the Plesk server
  • Webmail opens, but no new inbound messages arrive
  • Internal mail on the server may work while outside senders fail
  • Some senders get bounces, while others see connection timeouts or delayed delivery
  • The problem started after DNS changes, server migration, firewall changes, or mail service updates

Common Causes

  • MX records point to the wrong server or to an old mail host
  • The mail hostname used by MX resolves to the wrong A or AAAA record
  • Mail service is disabled for the domain or mailbox in Plesk
  • The server is not accepting inbound SMTP on port 25 because of firewall, NAT, or provider filtering
  • Postfix, qmail, or the local delivery stack on the Plesk host is unhealthy
  • The mailbox exists, but delivery fails because the account is suspended, missing, or over quota

Step-by-Step Fix

  1. Confirm the intended mail design for the domain in Plesk before changing anything, because if the domain is supposed to use Microsoft 365, Google Workspace, or another external provider, then the Plesk server should not be receiving external mail for that domain at all.
  2. Check the live MX records for the affected domain and make sure they point to the correct mail host, not to an old server, a generic web host name, or a provider you no longer use.
  3. Verify that the hostname referenced by the MX record resolves to the correct public IP address on both A and AAAA records, because external senders will follow that host, not the website record for the root domain.
  4. In Plesk, open the affected domain and confirm that mail service is enabled for the subscription and that the target mailbox actually exists, is active, and is not blocked by quota or account state.
  5. Review the mail server status on the Plesk host and inspect recent mail logs while sending a controlled test from an external mailbox, because this tells you whether the message is reaching the server, being rejected during SMTP, or being accepted but failing during local delivery.
  6. Check every network control between the internet and the server for inbound SMTP on port 25, including the server firewall, cloud security rules, edge firewall, and any NAT or port-forwarding layer, because a closed or misrouted port will stop external delivery before Plesk ever sees the message.
  7. Verify whether the hosting provider or upstream network blocks inbound SMTP on port 25 for that server class or IP range, since some VPS and cloud environments restrict mail traffic and create symptoms that look like a Plesk configuration problem.
  8. If the message reaches the server but does not land in the mailbox, trace the local delivery result for the recipient and check for mailbox-not-found, permission, storage, or domain-mapping errors so you can fix the exact handoff point inside the Plesk mail stack.
  9. Retest with several external senders only after DNS, network access, and mailbox state all match the intended design, then remove stale MX targets or obsolete mail IPs so future senders do not keep trying the wrong path.