---
title: "Why Plesk System Mail (MAILER-DAEMON, root) Goes to Spam and How to Fix It"
description: "Stop Plesk bounce notices, cron output and root mail landing in spam by publishing a DMARC record for the server hostname, then adding DKIM and SPF."
url: "https://docs.noiz.ie/plesk/why-plesk-system-mail-mailer-daemon-root-goes-to-spam-and-how-to-fix-it/"
section: "Plesk"
categories:
  - "Control Panels > Plesk > Administration"
  - "Email > Deliverability"
last_reviewed: "27 July 2026, against the current Plesk Obsidian release"
---

# Why Plesk System Mail (MAILER-DAEMON, root) Goes to Spam and How to Fix It

## Overview

System mails generated by your Plesk server, such as bounce notices from `MAILER-DAEMON@hostname.example.com`, cron output from `root@hostname.example.com`, or Plesk notifications, often land in the spam folder, even though normal user mailboxes (e.g. `info@example.com`) 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.

**Last reviewed:** 27 July 2026, against the current Plesk Obsidian release. This guide is written for Noiz hosting and is kept current against Plesk. It complements, and does not replace, the official Plesk and standards documentation linked below.

### Official Documentation Reference

- [Plesk Obsidian Administrator Guide: DKIM, SPF, and DMARC Protection and ARC Support](https://docs.plesk.com/en-US/obsidian/administrator-guide/mail/antispam-tools/dkim-spf-and-dmarc-protection-and-arc-support.59433/)
- [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://datatracker.ietf.org/doc/html/rfc7489)
- [RFC 6376: DomainKeys Identified Mail (DKIM) Signatures](https://datatracker.ietf.org/doc/html/rfc6376)
- [RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email](https://datatracker.ietf.org/doc/html/rfc7208)
- [RFC 5321 §4.5.5: the SMTP null reverse-path used by bounce messages](https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.5)

## Prerequisites

- Administrator access to your Plesk server (needed only for the complete fix, not the quick fix).
- The ability to publish TXT records in the authoritative DNS for your domain (the Noiz DNS zone, Cloudflare, or your registrar).
- Your server hostname and its public IPv4 and IPv6 addresses.

## 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 `MAILER-DAEMON@hostname.example.com` or `root@hostname.example.com`.

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 fail DMARC in a default setup

Bounces generated by Postfix use a null envelope sender (`<>`), per RFC 5321 §4.5.5. DMARC uses the SPF result for the MAIL FROM identity (RFC 7489 §4.1), and when the envelope sender is null, SPF defines that identity as `postmaster` at the HELO name the server announced (RFC 7208 §2.4). A bounce from a server that introduces itself as `hostname.example.com` is therefore checked against the SPF record for `hostname.example.com`, which aligns with the `MAILER-DAEMON@hostname.example.com` sender.

In a default Plesk setup there is no SPF record for the hostname, and Postfix-generated bounces are not DKIM-signed. With neither identifier passing, bounces produce `dmarc=fail`. Receivers then decide 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.

Publishing SPF for the hostname (Step 3 of the complete fix below) lets bounces pass SPF, and therefore DMARC, provided the server's HELO name is the hostname and the record lists every address the server sends from.

## 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:dmarc-reports@example.com"
```

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 on its own they still technically fail DMARC (with action "none"). Non-bounce system mail (cron job output, Plesk notifications, and anything else sent from `root@hostname` or similar) has a real envelope sender and *can* pass DMARC, and bounces can pass through the hostname's SPF record as described above. 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

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**. Do **not** enable web hosting.
4. If your authoritative DNS is external (the Noiz DNS zone, Cloudflare, your registrar, etc.), disable Plesk's local DNS service for this domain. You will copy the TXT records manually.
5. 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. Because a bounce's SPF identity is `postmaster` at the server's HELO name, the same record covers bounces, provided Postfix announces itself as `hostname.example.com`. The `Received:` header of a test bounce shows the HELO name the server used.

### 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:dmarc-reports@example.com; fo=1"
```

Even after DKIM and SPF are live, bounces pass DMARC only through SPF on the HELO name, which fails if the HELO name changes or the server sends from an address the record does not list, 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 youraccount@example.com test@nonexistent-test-domain-xyz.invalid <<EOF
To: test@nonexistent-test-domain-xyz.invalid
Subject: bounce test

body
EOF
```

Wait roughly 30 seconds. The MAILER-DAEMON bounce should arrive at `youraccount@example.com` in the inbox, not spam. Check the `Authentication-Results` header. With only the quick fix in place you should see `dmarc=fail (p=NONE ...)`: fail is expected at that stage, and the key detail is the `p=NONE` action. Once the hostname SPF record is live and the HELO name matches, you should see `spf=pass` and `dmarc=pass` instead.

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. `nonexistent@example.com` 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 `root@hostname.example.com` and `MAILER-DAEMON@hostname.example.com` 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: youraccount@example.com
```

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.

### Does publishing SPF for the hostname help bounces?

Yes, when the HELO name matches. A bounce has a null envelope sender (`<>`), so SPF checks `postmaster` at the server's HELO name instead (RFC 7208 §2.4), and DMARC uses that result (RFC 7489 §4.1). If Postfix announces itself as `hostname.example.com` and the hostname's SPF record lists every address the server sends from, bounces pass SPF with alignment. Keep the `p=none` record anyway, because a HELO name change or a missing address would otherwise send bounces straight back to spam.

### 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 (the Noiz DNS zone, Cloudflare, your 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 pass only through SPF on the HELO name, and DKIM signing of bounces is not guaranteed across Plesk configurations. Tightening the hostname DMARC policy risks re-quarantining your own bounces if either condition slips. 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 only masks the symptom. The proper fix is layered:

1. **Publish a permissive DMARC record for your server hostname** to override the apex subdomain-inheritance rule. This alone solves the visible symptom.
2. **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.
3. **Alias `root` to a trusted mailbox on your main domain** to sidestep the historically low reputation of system-mail addresses.

Bounces from the hostname fail DMARC in a default Plesk setup, and pass only when the hostname SPF record matches the server's HELO name. The goal is not to depend on that. It is to ensure the DMARC action for the hostname is "none", so legitimate bounces reach your inbox.

Noiz manages the mail authentication stack on its Plesk hosting. If your site is on a Noiz managed plan and system mail is still landing in spam after applying the quick fix, open a support ticket from the client area and the Noiz team will review the hostname's DNS, SPF, and DKIM configuration for you.

---
Source: https://docs.noiz.ie/plesk/why-plesk-system-mail-mailer-daemon-root-goes-to-spam-and-how-to-fix-it/