blueredix logo
SCAN On-demand vulnerability scans from €149
medium dmarc-monitor-only

DMARC policy is monitoring-only (p=none)

A DMARC record exists, but the policy is set to p=none. Receivers report on failures but take no action, so spoofed messages still pass through. Here is how to escalate safely to quarantine and reject.

What this means

Your domain has a DMARC record published. That is the right starting point. The problem is the p= tag: it currently reads p=none, which tells receiving mail servers to observe and report, but not to act. Spoofed mail that fails the SPF and DKIM checks is still delivered to the recipient’s inbox.

p=none is the correct mode for the first weeks of a DMARC rollout, when you want to learn which legitimate senders use your domain without breaking their mail. Many domains stay there indefinitely, either because nobody escalates the policy, or because the operator is afraid of bouncing genuine traffic. The result is a half-finished deployment that produces reports, but no protection.

Why it matters

DMARC delivers most of its value at p=quarantine or p=reject. Specifically:

  • Spoofing still works against your customers. A receiving server that sees p=none treats failures as informational. Invoice fraud, fake-CEO mail, and phishing against your users continue to land in inboxes.
  • Bulk-sender requirements are not met. Since February 2024, Google and Yahoo require a DMARC record on any domain that sends more than 5,000 messages per day to their users. The exact policy strength is not yet enforced, but the published direction is towards rejecting mail from senders stuck at p=none over time.
  • You may be misreading the reports. A common pattern: an operator reads the daily aggregate report, sees no failures, and concludes “we are protected”. The reports cover compliant mail flows, but p=none deliberately allows non-compliant flows to proceed unblocked. The absence of reported failures is not the absence of attacks.

Why teams stay at p=none longer than they should

Three patterns we see repeatedly:

  1. Forgotten senders. Marketing automation, an old transactional provider, the help-desk software, a vendor that sends invoices on your behalf. None of them are aligned to DMARC, and quarantining would kill a real business flow. The fix is alignment per sender, not staying at p=none forever.
  2. No report-reading discipline. RUA aggregate reports are XML archives; raw they are unreadable. Without a parser (Postmark, dmarcian, EasyDMARC, URIports, Valimail) the team never gets a clear picture of what would break under enforcement.
  3. Risk aversion. “If we set p=reject and miss something, the CEO’s mail bounces.” This risk is real, but pct= and the gradual rollout below contain it.

How to escalate safely

A four-week escalation path that contains the risk:

Step 1. Get reports into a usable form

Point the rua= address at a parsing service (free tiers exist at the providers above). Wait one week. Read the resulting dashboard and confirm that every legitimate sender that uses your domain is DMARC-aligned (passes either SPF or DKIM with the alignment flag the report shows).

Step 2. Fix the misaligned senders

For each sender failing alignment, either:

  • Add the sender’s mail servers to your SPF record, and ensure the Return-Path header is on your domain (SPF alignment requires the envelope-from match), or
  • Have the sender DKIM-sign with a key on your domain (most modern providers offer per-customer DKIM keys: ask their support team).

DKIM is the more reliable of the two for forwarded mail.

Step 3. Move to quarantine with pct=25

Update the record:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@your-domain.example;

Now 25% of failing mail goes to spam folders. Hold this for one week and watch the reports. If a legitimate flow surfaces, fix the alignment, do not roll back the policy.

Step 4. Ramp pct to 100, then move to reject

Increase pct= to 100 over a week, then change p= to reject:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@your-domain.example;

The domain is now fully protected. Continue monitoring weekly for new senders that may be added later.

A note on subdomains

DMARC inherits automatically. A p=reject record on your-domain.example also covers shop.your-domain.example and marketing.your-domain.example unless you publish a different record there. Use the sp= tag if you want a different policy specifically for subdomains, e.g. sp=quarantine while the parent is at p=reject.

Further reading