Moving to enforcement Step 9 of 30

The 14-day review: moving to p=quarantine

When the policy advisor recommends testing p=quarantine (14 days of reports) and enforcing it (30 days), what it checks, and how to make the change.

Updated

p=none only watches. The first step towards protecting your domain is p=quarantine, which asks receivers to send mail that fails DMARC to the recipient’s junk folder. It’s a step you take when the evidence says your own mail will pass — and DMARCLoop’s policy advisor tells you when that is.

Quarantine is also the step that can be undone. Mail that fails is delivered to the junk folder, not refused, so if a sender you missed starts failing, the recipient can still find the message, and you can fix the sender or step the policy back without anything having been lost. That’s why it comes before p=reject, where failing mail is refused outright.

Fourteen days is the earliest the advisor will suggest the first step, not a date to aim for. Most domains take longer, and that’s fine.

What the advisor checks

The advisor is the Next step panel on the domain page. These are the checks it runs, exactly as it runs them:

Check To test quarantine (t=y) To enforce quarantine Why
Days of reports at least 14 at least 30 Two weeks covers weekly senders; a month covers monthly ones before anything is acted on.
Messages observed at least 100 at least 100 Below that, a pass rate is noise rather than evidence.
Mail passing DMARC at least 95% at least 95% Most of your mail must already be authenticated.
Persistent failing sources none none See below.

Days of reports are days actually covered by reports over the last 90 days, not days since you added the domain. A domain that sends little mail, or that took a few days to start reporting, takes longer to get there.

A persistent failing source is one that has failed DMARC on three or more separate days with meaningful volume (50 messages, or half a percent of your mail). A pass rate alone can’t tell “0.5% spoofing” from “0.5% is the payroll system nobody authorised” — but the payroll system turns up every week, and a spam run doesn’t. So any persistent failing source blocks the recommendation, by name, however good the overall percentage looks.

Reading the Next step panel

Until everything is in place, the panel says Keep monitoring (nothing is wrong; there isn’t enough evidence yet) or Resolve these sending sources (everything else is ready, but something keeps failing). Beneath it, each blocker is listed on its own line:

  • “9 of 14 days observed” — wait.
  • “Not enough mail observed” — wait; a low-volume domain gets there more slowly.
  • “91.3% aligned” — work through the Not aligned and Partly aligned groups in Sending sources.
  • A source’s name or address — that source keeps failing. Follow the link to see what it’s sending, then authorise it or confirm it isn’t yours.

When the checks pass, the panel changes to Ready to test p=quarantine.

The Next step panel recommending p=quarantine in testing mode

We also send a one-off Ready to tighten policy email when a domain becomes ready. Nothing changes until you edit the record yourself.

Test first, then enforce

DMARCbis (RFC 9989) replaced the old pct percentage rollout with a testing flag, t=y. A policy published with t=y asks receivers to report on it as if it applied, but not to act on it. So each step up is two changes:

  1. Publish p=quarantine with t=y. Edit the record at _dmarc — change p=none to p=quarantine and add t=y, keeping everything else, including the rua address:

    v=DMARC1; p=quarantine; t=y; rua=mailto:d1…@reports.dmarcloop.com
    
  2. Leave it until the advisor is ready, and keep an eye on the sources list. Testing acts on nothing, so the advisor waits for 30 days of reports before it shows Ready to enforce p=quarantine — enough for a monthly sender, such as invoicing or payroll, to have appeared.

  3. Remove t=y. From then on, receivers send failing mail to junk:

    v=DMARC1; p=quarantine; rua=mailto:d1…@reports.dmarcloop.com
    

The DMARC record section of the domain page shows the record as we last read it; use Check now after each edit to confirm the change is live.

If the domain uses hosted records, make each change on the hosted DMARC screen instead of in your DNS.

A receiver that hasn’t implemented DMARCbis yet may not recognise t=y and apply the policy as written. That’s one more reason the advisor waits for the evidence before it suggests even the testing step — and, at quarantine, the worst case is mail in a junk folder rather than mail lost.

If something goes wrong after you enforce

If a domain is enforcing while a source that looks legitimate keeps failing, the panel says Mail is being affected right now and we send a Mail being blocked alert naming the source. Fix the source — authorise it with DKIM or SPF — rather than loosening the policy, which would reopen the domain to spoofing.

Next

The 30-day review: moving to p=reject.

Stuck? Reply to any email DMARCLoop sends, or contact us — a person reads it.