Overview
System mails generated by your Plesk server — such as bounce notices from [email protected], cron output from [email protected], or Plesk notifications — often land in the spam folder, even though normal user mailboxes (e.g. [email protected]) deliver fine.
This happens because your server's hostname is a subdomain of your main domain, and your main domain's DMARC policy is silently inherited by every subdomain that does not publish its own. Without dedicated authentication for the hostname, self-generated system mail fails DMARC alignment and is quarantined by your own authentication stack.
This article walks through the root cause, the one-DNS-record fix that solves the visible symptom for most admins, and the full authentication setup for getting non-bounce system mail to genuinely pass DMARC.
Why it happens: subdomain DMARC inheritance
Your server has a hostname like hostname.example.com. When Postfix generates mail from MAILER-DAEMON, cron, or Plesk itself, it uses that hostname in the From: header — producing addresses like [email protected] or [email protected].
If your apex domain example.com has a DMARC record with a strict policy (p=quarantine or p=reject) and no explicit subdomain policy override (sp= tag), RFC 7489 specifies that the apex p= policy is inherited by every subdomain that lacks its own DMARC record. Your server's hostname inherits the strict policy — even though there is no DKIM key or dedicated SPF for the hostname, and even though self-generated bounces cannot pass SPF or DKIM alignment in a default Plesk setup.
Your own server's mail gets quarantined by your own authentication stack.
Why bounces can never pass DMARC in a default setup
Before the fix, one technical point that most guides get wrong:
Bounces generated by Postfix use a null envelope sender (<>), per RFC 5321 §4.5.5. DMARC evaluation (RFC 7489 §3.1.1) derives its SPF-authenticated identifier from the RFC5321.MailFrom domain — not the HELO identity. With a null MailFrom there is no SPF identifier to align against the From: header, so SPF alignment is impossible no matter what SPF record you publish for the hostname.
In a default Plesk setup, Postfix-generated bounces are also not DKIM-signed.
The combination of these two facts means bounces produce dmarc=fail every time. The question receivers face is not whether to pass or fail, but what action to take on the failure. If the DMARC policy is strict, the mail is quarantined. If the policy is permissive (p=none), it is delivered normally.
The quick fix: override subdomain inheritance
Add a dedicated DMARC record for your server hostname with p=none:
_dmarc.hostname.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
This overrides apex inheritance for the hostname subdomain only. Your main domain DMARC policy stays strict, your user mailboxes stay protected, but system mail from the hostname stops being quarantined.
This single record solves the symptom for most admins. No Plesk changes are required. No server configuration is required.
Verify the record is live:
dig +short TXT _dmarc.hostname.example.com
If you also want cron output and Plesk notifications (not just bounces) to genuinely pass DMARC, continue to the complete fix below. If you just want your system mail out of spam, you can stop here.
The complete fix: authenticate non-bounce system mail
The quick fix makes bounces deliverable, but they still technically fail DMARC (with action "none"). For non-bounce system mail — cron job output, Plesk notifications, and anything else sent from root@hostname or similar — the mail has a real envelope sender and can pass DMARC. Treating the hostname as a first-class mail domain with its own DKIM key and SPF record gets these messages properly authenticated.
Step 1: Add the hostname as a Plesk domain
- In Plesk, go to Websites & Domains → Add Domain → Add Domain Without Hosting.
- Enter your server hostname (e.g.
hostname.example.com). - Enable the Mail service. Do not enable web hosting.
- If your authoritative DNS is external (Cloudflare, registrar, etc.), disable Plesk's local DNS service for this domain. You will copy the TXT records manually.
- Do not create any mailboxes and do not enable incoming mail. You only need Plesk to recognise the hostname as a managed mail domain so it can generate a DKIM keypair.
Step 2: Enable DKIM for the hostname
In the hostname domain's Mail Settings, enable Use DKIM spam protection system to sign outgoing email messages.
Plesk generates the keypair under /etc/domainkeys/ and displays the public DKIM TXT record in DNS Settings. Copy it to your authoritative DNS:
default._domainkey.hostname.example.com. TXT "v=DKIM1; p=MII..."
Step 3: Publish SPF for the hostname
Also in your authoritative DNS:
hostname.example.com. TXT "v=spf1 ip4:your.server.ipv4 ip6:your:server::ipv6 -all"
This authorises the server itself to send mail on behalf of the hostname.
Step 4: Leave the hostname DMARC at p=none
Keep the hostname DMARC record at p=none permanently:
_dmarc.hostname.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"
Even after DKIM and SPF are live, bounces from the hostname cannot align SPF (null envelope) and DKIM signing of Postfix bounces is not guaranteed across every Plesk configuration. Keeping p=none on the hostname ensures bounces still reach your inbox. The downside is minimal: no user mailboxes live at @hostname.example.com, so there is little phishing surface to protect.
Testing
Verify all records are live:
dig +short TXT hostname.example.com dig +short TXT default._domainkey.hostname.example.com dig +short TXT _dmarc.hostname.example.com
Trigger a real bounce to confirm the quick fix is working. Sending to a non-existent external domain reliably generates a bounce back to the sender:
sendmail -f [email protected] [email protected] <<EOF To: [email protected] Subject: bounce test body EOF
Wait roughly 30 seconds. The MAILER-DAEMON bounce should arrive at [email protected] in the inbox, not spam. Check the Authentication-Results header — you should see dmarc=fail (p=NONE ...). Fail is expected; the key detail is the p=NONE action.
For non-bounce mail, wait for a cron job to run or trigger a Plesk notification and inspect its headers. With the complete fix in place, you should see dkim=pass and dmarc=pass.
Note: sending to a local non-existent address (e.g. [email protected] where example.com is hosted on the same server) will not always generate a visible bounce under Plesk, because Plesk's local delivery pipeline silently accepts and discards unknown-user mail. Always test with an external non-existent domain.
Aliasing system mail (optional)
Even with full authentication in place, addresses like [email protected] and [email protected] have poor historical reputation. Mailbox providers may score them down regardless of DMARC status.
You can route mail addressed to root to a proper mailbox on your main domain. Edit /etc/aliases:
root: [email protected]
Then run:
newaliases
Cron output, Plesk admin notifications, and anything else sent to root will now be delivered to your main-domain mailbox — benefiting from that domain's reputation and full authentication.
This does not help bounces. Postfix generates bounces from MAILER-DAEMON directly, bypassing local aliases. The quick fix above is the only reliable way to stop bounces landing in spam.
Common questions
Do I need to do the complete fix, or is the quick fix enough?
The quick fix (one DMARC TXT record for the hostname) solves the visible symptom — system mail landing in spam — for the vast majority of admins. It is sufficient on its own.
The complete fix is worth doing if you want cron output and Plesk notifications to genuinely pass DMARC (not just bypass it), or if you plan to send a significant volume of automated mail from the hostname. It is overkill for solving the spam-folder symptom alone.
Why doesn't publishing SPF for the hostname fix bounces on its own?
Because DMARC-SPF alignment uses the RFC5321.MailFrom identifier, and bounces have a null MailFrom (<>). There is nothing for SPF to align against. The SPF record is useful for non-bounce mail from the hostname but cannot help bounces.
Do I need to enable web hosting for the hostname domain?
No. Set it to "No web hosting" when adding the domain. Web hosting is unnecessary and can cause SSL conflicts if the apex 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. Leaving incoming mail disabled avoids creating mailboxes for the hostname. Outgoing system mail will still send correctly.
Does disabling Plesk's local DNS for the hostname break anything?
No, as long as your authoritative DNS is managed externally (Cloudflare, registrar, etc.) and you publish the SPF, DKIM, and DMARC records there manually. If Plesk is your authoritative DNS, leave its local zone enabled so Plesk can publish the records automatically.
Which SSL certificate is used for mail?
The SSL certificate bound to the server hostname (hostname.example.com) is the one used by Postfix and Dovecot for SMTP, IMAPS, and POP3S. Keep Let's Encrypt enabled for the hostname. Certificates bound to your main domain's web hosting do not affect mail delivery.
Can I tighten the hostname DMARC policy once everything is authenticated?
Not safely. Bounces from the hostname cannot align SPF, and DKIM signing of bounces is not guaranteed across Plesk configurations. Tightening the hostname DMARC policy risks re-quarantining your own bounces. Leave it at p=none permanently.
Why do some system mails still land in spam even after full authentication?
Addresses like root@ and MAILER-DAEMON@ are historically abused and treated with low trust regardless of authentication status. Passing SPF, DKIM, and DMARC establishes the foundation, but inbox placement also depends on domain and sender reputation. Aliasing system mail to a trusted mailbox (see above) is the most effective mitigation.
Conclusion
Plesk's default advice to "change the From field" on notifications is a band-aid. The proper fix is layered:
- Publish a permissive DMARC record for your server hostname to override the apex subdomain-inheritance rule. This alone solves the visible symptom.
- For non-bounce system mail, add the hostname as a Plesk mail domain and enable DKIM, so cron output and Plesk notifications genuinely pass DMARC.
- Alias
rootto a trusted mailbox on your main domain to sidestep the historically low reputation of system-mail addresses.
Bounces from the hostname will always fail DMARC by design in a default Plesk setup. The goal is not to make them pass — it is to ensure the DMARC action for the hostname is "none", so legitimate bounces reach your inbox.
