Plesk mail server: baseline placement before you cut over

Plesk bundles Postfix + Dovecot (Linux) or MailEnable (Windows) with a clean UI for DNS, mailbox, and antivirus management. It's a solid stack for SMBs hosting their own mail on a VPS. Migrations into Plesk from cPanel or legacy self-hosted Exim, or out of Plesk to a managed provider (Google Workspace, Microsoft 365), are routine — and routinely painful when nobody measures placement on either side.

This article is about the one step 90% of migrations skip: baselining inbox placement on the old system, then re-testing after the cutover to confirm you didn't regress. Without that, "why is mail going to Spam now?" has zero answers.

What typically breaks in a Plesk migration

• DKIM selector mismatch. Old system signed with selector s1, Plesk signs with default. The old selector stays in DNS but the new outbound mail is signed with a missing key — pass becomes fail.
• SPF include dropped. Old system included spf.mandrillapp.comfor transactional mail; new SPF on Plesk only includes mx. Half your mail fails SPF overnight.
• DMARC already at p=reject. Previous team locked it down. First day after migration every unaligned message is rejected by Gmail. You discover this only when customers complain.
• New IP has no reputation. Plesk VPS IP is fresh. Gmail and Microsoft grey-list or deliver to Spam for the first two weeks regardless of auth.
• PTR still points at old server. Forgotten at the VPS provider's panel. FCrDNS fails, mail gets scored down.

Pre-migration baseline (on the old system)

1. Grab 20+ seed addresses covering Gmail, Outlook, Yahoo, Mail.ru, GMX, ProtonMail.
2. Send a real message from the old system — same From address, same template as your highest-stakes mail (receipt, password reset, order confirmation).
3. Record the placement per provider: Inbox / Promotions / Spam / Rejected / No-show.
4. Also record the Authentication-Results header per provider — SPF, DKIM, DMARC verdicts on the old path.
5. Store this as your baseline. Date-stamp it.

Plesk mail server setup that matches

In Plesk > Tools & Settings > Mail Server Settings, make sure these are enabled before you migrate a single mailbox:

• DKIM signing: On. Plesk uses selector default; match it to your old selector or publish both in DNS during the transition.
• SPF check & policy: On for inbound. Not relevant outbound but confirms your config understanding.
• DMARC checks on inbound: On.
• Server-wide mail hostname: set to mail.yourdomain.com — matches PTR.
• Greylisting: Off for outbound-only servers; leaves inbound greylisting to your RBL stack.

# /etc/postfix/main.cf  (Plesk-managed, edit via Plesk or CLI)
myhostname = mail.yourdomain.com
mydomain = yourdomain.com
smtp_tls_security_level = may
smtpd_tls_security_level = may
smtp_tls_loglevel = 1

# DKIM/OpenDKIM milter (Plesk wires this when DKIM toggle is on)
milter_default_action = accept
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

# Rate-limit outbound per Plesk mailbox (PLESK_OUTGOING_MAIL_LIMITS)
smtpd_client_message_rate_limit = 50
anvil_rate_time_unit = 60s

The Plesk UI writes most of this for you when you tick the DKIM box. Verify by inspecting /etc/postfix/main.cf — don't trust the UI to have done it.

DKIM key continuity

Gmail penalises sudden DKIM key rotation. Carry the old key into Plesk if you can:

# On the old server
$ cat /etc/opendkim/keys/yourdomain.com/s1.private
# copy that file

# On Plesk server
$ mkdir -p /etc/opendkim/keys/yourdomain.com
$ cp s1.private /etc/opendkim/keys/yourdomain.com/s1.private
$ chown opendkim:opendkim /etc/opendkim/keys/yourdomain.com/s1.private
$ chmod 600 /etc/opendkim/keys/yourdomain.com/s1.private

# /etc/opendkim/KeyTable
s1._domainkey.yourdomain.com yourdomain.com:s1:/etc/opendkim/keys/yourdomain.com/s1.private

# /etc/opendkim/SigningTable
*@yourdomain.com s1._domainkey.yourdomain.com

$ systemctl restart opendkim postfix

Leave the old public DKIM record in DNS for 30 days after the cutover. Some in-flight messages can still arrive and need to verify. You now have two valid DKIM keys; the new key is what Plesk signs with. Rotate the old key out after the overlap window.

Cutover day — low-TTL, dual-run, re-baseline

1. 48 hours before: drop MX + DKIM + SPF TTLs to 300 seconds.
2. T-0: flip MX to the new Plesk server. Leave the old server accepting mail for 48 hours (some caches take time).
3. T+1h: re-run the placement test, same 20 seed addresses, same template, same From.
4. Compare to baseline. If Gmail dropped from 100% to 30% Inbox, stop everything and inspect Authentication-Results — you almost certainly have DKIM or PTR misalignment.
5. T+24h: re-test. New IP warming typically lifts placement 10-30 points in the first week.
6. T+7d, T+14d, T+30d: re-test. Restore TTLs to 3600 after 14 days.

Migrating out of Plesk to a managed provider

Moving from Plesk self-hosted to Google Workspace, Microsoft 365, Fastmail, Zoho? The playbook flips. Your baseline is Plesk. Risks are different:

• SPF gains new include: include:_spf.google.com orinclude:spf.protection.outlook.com. Add it, don't remove the old Plesk mx mechanism until you cut the old server off.
• DKIM is re-keyed at the provider. You cannot reuse your Plesk private key. Publish the provider-issued DKIM, keep your old one for 30 days.
• MX changes — dual-delivery is dangerous. Set a clear T-0 and remove the old Plesk MX within 48 hours. Split-brain mailboxes are worse than a brief outage.

Plesk migration deliverability checklist

1. Placement baseline on the old system, 20+ seeds, stored and dated.
2. DKIM keys copied or dual-published; both verifiable in DNS.
3. SPF include list audited — every real sender covered, no +all.
4. DMARC at p=none during migration, tightened after 2 weeks clean.
5. PTR set at VPS provider, matches hostname -f on Plesk server.
6. TTLs dropped pre-cutover.
7. Placement re-test at T+1h, T+24h, T+7d.
8. Old server accepting mail for 48h post-cutover.

Frequently asked questions