Why Plesk system mails (MAILER-DAEMON, root, etc.) go to spam and how to fix it Print

Overview

System mails generated by Plesk — such as undelivered mail notices from MAILER-DAEMON@hostname.example.com or cron job notices from root@hostname.example.com — often land in the spam folder, even though normal user mailboxes (e.g. info@example.com) deliver correctly.

This happens because Plesk’s hostname domain is not configured in Plesk by default, so there are no DKIM keys or SPF records published for it. Without that, system mails fail DMARC alignment and are treated as suspicious.

What Plesk’s official docs say

Plesk’s official response to this problem is usually to “change the From field” in notifications or to add a weak DMARC record. While this may reduce spam foldering, it doesn’t solve the underlying issue: authentication alignment for the hostname domain.

The correct solution

To fix this properly, you must configure full SPF, DKIM, and DMARC for both:

• Your main domain (e.g. example.com)
• Your server hostname (e.g. hostname.example.com)

Step 1: Add the hostname as a domain in Plesk

1. In Plesk, go to Websites & Domains → Add Domain → Add Domain Without Hosting.
2. Enter your server hostname (e.g. hostname.example.com).
3. Enable the Mail service but disable incoming mail (to avoid creating real mailboxes for the hostname).

This makes Plesk treat the hostname as a managed mail domain, allowing DKIM to be enabled.

Step 2: Enable DKIM for both domains

1. For your main domain (example.com): go to Mail Settings → enable Use DKIM spam protection system to sign outgoing email messages.
2. For your hostname (hostname.example.com): do the same in its Mail Settings.

Plesk will now generate DKIM keypairs under /etc/domainkeys/ and show you the public TXT records in the DNS Settings page. Copy these into your authoritative DNS (don’t rely on Plesk-managed DNS if you’re using external nameservers).

Step 3: Publish SPF records

In your external DNS, add SPF records for both domains:

example.com.            TXT "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:additionalmail.net -all"

hostname.example.com.   TXT "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 -all"

Step 4: Publish DMARC records

Add DMARC records in monitor mode:

_dmarc.example.com.          TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-reports@example.com; fo=1; adkim=s; aspf=s"

_dmarc.hostname.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1; adkim=s; aspf=s"

This avoids quarantining while you confirm everything is aligned. Later you can change p=none to p=quarantine or p=reject.

Testing

1. Use dig to confirm your TXT records are live:

   dig TXT example.com TXT hostname.example.com \
       TXT default._domainkey.example.com TXT default._domainkey.hostname.example.com \
       TXT _dmarc.example.com TXT _dmarc.hostname.example.com +short
   

2. Send a test mail from info@example.com (user mailbox).
3. Trigger a bounce by sending to a non-existent address. The bounce will arrive from MAILER-DAEMON@hostname.example.com.
4. Check Gmail/Outlook headers for:

   spf=pass
   dkim=pass
   dmarc=pass
   

Additional considerations

• Even with full SPF/DKIM/DMARC, providers may still spam-folder messages from root@… or MAILER-DAEMON@… due to reputation. The safer approach is to alias these to a proper address like noreply@example.com.
• The SSL certificate that matters for mail is the one bound to your server hostname. Keep Let’s Encrypt enabled for hostname.example.com. You don’t need a cert for example.com web hosting if it points elsewhere.
• Reputation takes time. Passing authentication is the foundation, but inbox placement improves as providers learn to trust your domain.

Common questions

Do I need to enable web hosting for the hostname domain?

No. When adding the hostname (e.g. hostname.example.com) in Plesk, set it to “No web hosting”. You only need the mail service enabled to generate DKIM keys. Web hosting is unnecessary and can cause SSL conflicts if the root domain points elsewhere.

Should I enable incoming mail on the hostname domain?

No. In almost all cases you do not want to accept mail at @hostname.example.com. Disable incoming mail to prevent creating mailboxes for the hostname. System-generated mail will still send, and DKIM will still sign outgoing messages.

Does disabling DNS service for the hostname in Plesk break anything?

No. The DNS service inside Plesk is optional and only relevant if Plesk is your authoritative DNS. If your DNS is hosted externally (registrar, Cloudflare, etc.), you should disable DNS in Plesk and manually copy the TXT records (SPF, DKIM, DMARC) into your external zone.

Which SSL certificate is used for mail?

The SSL certificate bound to the server hostname (hostname.example.com) is the one used by Postfix/Dovecot for SMTP/IMAP/POP. Keep Let’s Encrypt enabled for the hostname. Certificates for example.com web hosting do not affect mail delivery.

Why do system mails still land in spam even after SPF, DKIM and DMARC pass?

Addresses such as root@… and MAILER-DAEMON@… are historically abused and treated with low trust. Passing authentication stops outright rejection, but inbox placement also depends on reputation. For better results, alias system mail to a trusted address like noreply@example.com under your main domain.

Do I need separate DMARC records for the hostname?

Yes. You need a DMARC policy for both the main domain and the hostname, because system-generated mail uses the hostname in the From/Return-Path. Without it, bounces and cron notices will fail DMARC alignment.

Conclusion

Plesk’s advice to simply “change the From field” is a band-aid. The proper fix is to treat your server hostname as a first-class mail domain: add it in Plesk, enable DKIM, and publish SPF + DMARC records. Do the same for your main domain. With both authenticated and aligned, system mails and user mails pass modern checks and stand a much better chance of reaching the inbox.