Change p=none to quarantine or reject so spoofed mail is actually handled — including when the policy is inherited from your root domain.
You got DMARC policy is monitoring only. The record exists and is valid. The problem is the policy: p=none.
p=none tells receiving servers: check DMARC, send me reports, and still deliver spoofed mail. Nothing is quarantined or rejected. Gmail, Yahoo, and other inboxes treat that as “not enforced.”
Lumail does not rewrite DNS. You change the TXT record at your DNS host.
Find the _dmarc TXT record and replace p=none with p=quarantine or p=reject. Leave v=DMARC1 and any rua= / ruf= report addresses as they are.
| Record | |
|---|---|
| Type | TXT |
| Host | _dmarc on the domain that actually publishes the policy (see below) |
| Before | v=DMARC1; p=none; rua=mailto:[email protected] |
| After | v=DMARC1; p=quarantine; rua=mailto:[email protected] |
Then later, when reports look clean: p=reject.
This is the usual source of confusion.
For hey.melvynx.com, Lumail first looks up _dmarc.hey.melvynx.com. If that name has no DMARC record, it uses the organizational domain: _dmarc.melvynx.com. The alert still names the sending domain (hey.melvynx.com), but the record you must edit is on melvynx.com.
The domain page shows this as Inherited from melvynx.com and lists the host _dmarc.melvynx.com.
| Sending domain | Record to edit | Do not edit |
|---|---|---|
hey.melvynx.com (inherited) | _dmarc.melvynx.com | _dmarc.hey.melvynx.com unless you want a different policy for that subdomain |
melvynx.com | _dmarc.melvynx.com | — |
If the root record has sp=none, that subdomain policy also stays monitoring-only. Change sp= to quarantine or reject as well, or publish a dedicated _dmarc on the subdomain.
_dmarc on that root (for example _dmarc.melvynx.com).p=none (and sp=none if present).p=quarantine or p=reject.| Policy | What receivers do with failing mail |
|---|---|
p=none | Deliver it. Monitoring only. This is the alert. |
p=quarantine | Treat it as suspicious (usually junk). Safe first step. |
p=reject | Refuse it. Use after reports show almost all legitimate mail passes. |
Do not jump to p=reject if you still send from other platforms (Google Workspace, a transactional ESP, a helpdesk) that are not aligned in SPF/DKIM. Those sends will start failing at the inbox.
rua=If the record already has rua=mailto:…, read a few days of aggregate reports before p=reject. You want your Lumail sending domain (and any other real senders) passing SPF or DKIM and aligned with the From domain.
No rua= is fine. You can still move to p=quarantine if Lumail, Google Workspace / Microsoft 365, and any other ESP you use already have working SPF + DKIM.
_dmarc on the subdomain while the live policy is on the root. The inherited p=none stays in effect until the root record changes (or you publish a stronger subdomain record)._dmarc TXT next to the first. There must be one DMARC record at that name.v=DMARC1 and p= must be exactly none, quarantine, or reject.The alert is domain:dmarc:monitoring-only. It resolves when a confirming scan sees p=quarantine or p=reject on the record Lumail actually uses (exact domain or inherited root). A failed lookup does not resolve it.