Moving DMARC to reject without blocking your own mail

A DMARC record with p=none only watches: it asks receivers to send you reports and still delivers everything. Only p=quarantine (spam folder) and p=reject (refuse the message) stop other people from sending mail as your domain. They also stop your own mail when one of your senders is set up wrong, so you get there in stages.

Step 1: collect reports and find every sender

Publish p=none with a rua address and wait for the daily aggregate reports. Group them by sending service and decide for each one whether it is yours. The invoicing tool, the newsletter service, the helpdesk and the website contact form all send as your domain, and someone has to remember them. The hosted DMARC reports in ProbeKit do the grouping, recognize about forty common platforms, and say “not enough data yet” until there is enough mail to judge.

Step 2: fix what fails

For each real sender, make SPF or DKIM pass in alignment with your From domain. DKIM is the safer choice for services that send on your behalf, because it survives forwarding. Mail that passes SPF only for the provider’s own domain is not aligned and still fails DMARC. Senders that are not yours go on a “not ours” list, and reject is exactly what you want for them.

Do not move on until nearly all of your real mail passes DMARC. ProbeKit’s defaults are 95 percent before quarantine and 99 percent before reject, with at least 100 messages in the last 14 days and no unidentified sender with 10 or more messages. Forwarded mail and mailing lists are left out of that share, because they break alignment through no fault of yours.

Step 3: tighten in stages

1. Publish p=quarantine; pct=25; t=y and read the reports for a week.

2. Publish p=quarantine; pct=100; t=y and read the reports for another week.

3. Publish p=quarantine with both extra tags removed, then repeat the same three stages for p=reject.

Why two extra tags? The DMARC standard was revised in 2026 (RFC 9989). It dropped pct and added t=y, a testing flag that makes a receiver treat reject as quarantine and quarantine as none while reports keep flowing. Receivers adopt the new rules at their own pace, so each stage publishes both tags: no receiver, old or new, is ever stricter than the stage intends. The last stage removes both.

ProbeKit never changes your DNS. Each stage is a record for you to publish at your DNS host, with a reminder to check the reports afterwards and an alert if mail that used to pass starts to fail. Keep the TTL short (300 seconds is common) while you ramp up, so a rollback reaches receivers quickly.

Domains that send very little mail

Reports only come from receivers that send them, so a domain with a few messages a month can never show enough data to prove that enforcing is safe. The low-volume track asks for more time and more evidence instead of less: 60 days of observation, a report in the last 30 days, every sender identified, your confirmation that the list covers every system that sends as the domain, 14 days between stages, and reject only after 30 days at full quarantine with no failures. It lowers the risk; it cannot prove safety.

Domains that send no mail at all

A parked domain should say so. Publish an SPF record that allows nobody (v=spf1 -all) and p=reject for the domain and its subdomains. If the domain also receives no mail, a null MX (0 ., RFC 7505) tells senders to stop trying. ProbeKit offers this track after 30 days of reports with no legitimate mail, and it asks you to confirm that nothing sends as that domain.

Rolling back

Every stage keeps the record that was live before it. If a sender breaks, publish that earlier record and press Roll back so the wizard follows along. A change reaches every receiver only after the old record’s TTL runs out, which is why a short TTL matters.

Reaching reject is not the end. A new tool that sends as your domain will bounce from the first day, so keep the reports coming in and let ProbeKit alert you when mail that used to pass starts to fail.