How to strengthen DMARC
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.
What to change
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.
If you send from a subdomain
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.
Step by step
- Open the sending domain in Lumail (Domains → the domain in the alert).
- Read the DMARC row. If it says Inherited from the root domain, the host to edit is
_dmarcon that root (for example_dmarc.melvynx.com). - Copy the current value. You only change
p=none(andsp=noneif present). - At your DNS host (Cloudflare, Porkbun, Route 53, Namecheap, …), edit that TXT record.
- Wait for DNS (often minutes, sometimes up to 48 hours).
- Back on the domain page, click Check that they are live / verify. Lumail’s next deliverability scan will clear the alert when it sees
p=quarantineorp=reject.
Which policy to pick
| 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.
Review reports first if you have 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.
Common mistakes
- Editing
_dmarcon the subdomain while the live policy is on the root. The inheritedp=nonestays in effect until the root record changes (or you publish a stronger subdomain record). - Adding a second
_dmarcTXT next to the first. There must be one DMARC record at that name. - Breaking the record: it must start with
v=DMARC1andp=must be exactlynone,quarantine, orreject. - Expecting Lumail to flip the policy. We only read DNS.
After you change it
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.