A migrated WordPress site can load perfectly while Plesk handles outbound mail differently from the previous server. The new subscription may have mail disabled, a sending limit, a different PHP handler or a local-domain route that conflicts with the real mailbox provider.
Trace one synthetic message through WordPress, Plesk and the intended mail service before editing DNS.
Identify the active sending route
Determine whether WordPress is configured for local PHP mail, the Plesk mail server, authenticated external SMTP or an API mailer. Record the plugin, sender domain, destination and test timestamp.
Do not assume a copied SMTP plugin is active. Constants, must-use plugins or the hosting image may override its visible settings.
Check whether the form stored its entry; if it did not, investigate the form request before Plesk mail.
Check subscription mail settings
In Plesk, confirm whether mail service is enabled for the domain and whether the subscription is permitted to send. Server-wide and subscription-level policies may differ.
Review outgoing mail controls and limits for the domain, mailbox and subscription. A migrated site can inherit a low or exhausted quota, especially after repeated testing.
Do not raise limits without checking whether the account is compromised or already sending spam.
Inspect the mail queue and logs
With authorised server access, search the mail log and queue for the unique test recipient and time. Determine whether Plesk accepted, deferred, rejected or never received the message.
Record the queue ID and redacted response. A deferred message requires the remote status; a missing message points back toward PHP, WordPress or an external transport.
Preserve queue evidence before deleting or forcing retries. A queue may contain genuine leads.
Verify local-domain routing
If company email is hosted externally, Plesk must not incorrectly deliver the website’s messages to local nonexistent mailboxes. Compare the domain’s Plesk mail-service status with its authoritative MX design.
Disabling local mail service can be appropriate for an externally hosted domain, but only after confirming that no legitimate mailbox remains on the server.
An incorrect change can interrupt inbound mail, aliases and autoresponders, so keep a rollback and document ownership.
Compare PHP handlers and sendmail paths
The migration may have changed PHP version, handler or sendmail_path. Check which PHP configuration the domain actually uses and whether local mail functions are allowed.
Review PHP errors and Plesk’s per-domain logs at the submission time. A command-line PHP test may use different configuration from PHP-FPM serving WordPress.
Prefer authenticated SMTP or a supported transactional provider for reliable, observable delivery rather than editing system paths blindly.
Test external SMTP connectivity
If WordPress uses an external provider, verify DNS resolution and an outbound connection to the provider’s documented port. Plesk firewall rules or the infrastructure provider can block SMTP ports.
Confirm hostname, port, TLS mode and credential ownership. Never disable TLS verification or expose the password in terminal history or logs.
Ask the provider to permit the narrow destination and port if a network policy blocks it.
Recheck DNS and sender identity
Review SPF, DKIM and DMARC for the actual outbound provider. Plesk may offer DNS records for its local mail service, but those are not correct when another provider sends.
Keep one SPF TXT policy and use the exact DKIM selector from the selected sender. Do not change MX records merely to make an outbound WordPress test pass.
Use an authorised domain address in From and the visitor address in Reply-To.
Prove post-migration delivery
After correcting the confirmed Plesk or WordPress handoff, submit the live form once with a new reference. Confirm one entry, one mail attempt, queue/provider acceptance and final mailbox delivery.
Test the business recipient, Reply-To, attachments and any scheduled notifications. Review entries created during the migration window.
Request urgent repair when queue ownership, mail routing or server-wide restrictions are unclear. Provide domain, timestamp, queue ID and redacted status—never server credentials or real form contents.