How to Move DMARC From None to Reject

Reject is earned, not guessed

A bad DMARC change can block your own payroll, support, invoices, alerts, or newsletter mail. Treat reject like a cutover, not a DNS cleanup.

The safe path is simple. Watch first, fix every real sender, then enforce. DMARC passes when either SPF or DKIM passes and the passing domain aligns with the visible From domain. If real mail cannot pass aligned SPF or aligned DKIM, p=reject can ask receivers to refuse it.

• Start at p=none with aggregate reports turned on.
• Build a sender inventory from RUA reports and your own vendor list.
• Fix SPF, DKIM, and alignment for every real sender.
• Move to quarantine only after normal mail is passing DMARC.
• Move to reject after fresh reports show no business mail is failing.

Before you touch DNS, run the domain through the free InboxRadar domain scorecard. It shows the live SPF, DKIM, DMARC, and MX state receivers can see.

Publish a monitoring record first

p=none tells receivers to report DMARC results without asking them to quarantine or reject failed mail.

Publish one TXT record at _dmarc.example.com. A plain starting record is:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r

The rua address receives aggregate feedback reports. These reports usually arrive as zipped XML. They can show the source IP, the visible From domain, SPF and DKIM results, alignment results, and the receiver's DMARC disposition. Some receivers report more detail than others, so use reports as strong evidence, not a full audit log. The free DMARC report reader helps turn those XML files into a sender list.

Stay in monitoring until normal sending has happened. A busy domain may show enough in one or two weeks. A low-volume domain may need a full billing or reporting cycle. Look for payroll tools, CRMs, support desks, stores, newsletters, product alerts, calendar tools, and old vendors that still send as your domain.

Fix SPF and DKIM alignment

DMARC does not require both SPF and DKIM to pass. One aligned pass is enough, but DKIM is usually the better long-term anchor.

SPF checks the RFC5321 Mail From domain, often seen as the Return-Path. Publish only one SPF TXT record for that domain. Multiple SPF records can cause a permanent error. Keep only services that really send mail for you. RFC 7208 sets a hard limit of 10 DNS-querying terms during SPF evaluation, including mechanisms such as include, a, mx, ptr, exists, and redirect. Remove stale includes before adding new ones.

~all is a softfail. It is common while you are still finding senders. -all is a fail and gives a clearer authorization boundary once the sender list is known. SPF can still break when mail is forwarded, so do not make SPF your only way to pass DMARC.

DKIM signs the message with a selector such as selector1._domainkey.example.com. Each mail service should sign with a d= domain that aligns with the visible From domain. Ask vendors for custom DKIM. If a vendor can only sign with its own domain, it should not send mail that uses your main From domain once you enforce DMARC.

• Turn on DKIM for Google Workspace, Microsoft 365, and each ESP.
• Use 2048-bit DKIM keys when the provider and DNS host support them.
• Document selectors so key rotation is possible later.
• Keep SPF under the 10-lookup limit.
• Confirm relaxed or strict alignment matches the From domain you use.

Move from none to quarantine

Quarantine asks receivers to treat failed DMARC mail as suspicious, often by sending it to spam. Use it after reports show real mail is clean.

A current DMARC record for testing quarantine can look like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; t=y

RFC 9989 is now the current DMARC standard. It replaced RFC 7489 and moved the old pct sampling tag to historic status because receivers applied partial percentages unevenly. You will still see older guides that say to move through pct=10, pct=25, pct=50, and pct=100. Treat that as legacy advice unless your DMARC provider has confirmed how your target receivers handle it. The current test flag is t=y. With p=quarantine; t=y, the domain owner is saying the quarantine policy is being tested.

Move from testing to real quarantine by removing t=y after fresh reports show that business mail is passing DMARC:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

• No unknown legitimate sender remains in RUA reports.
• Support, billing, sales, product, and marketing mail pass aligned SPF or DKIM.
• Forwarded mail and mailing list traffic are understood.
• Failures are spam, spoofing, or systems you have retired.

Move from quarantine to reject

Reject asks receivers to refuse mail that fails DMARC. It is the right end state for many domains, but it should come after quarantine proves the setup.

A cautious reject test record is:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; t=y

Under RFC 9989, t=y means the domain owner is testing the stated policy and expects failed mail to receive one level lower treatment. For a reject policy, that means quarantine-level handling while you test. After the next clean report cycle, remove t=y:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

If subdomains send mail, set their policy on purpose. The sp tag sets a policy for existing subdomains, and np sets a policy for non-existent subdomains under the current DMARC standard. Do not use subdomains to hide broken senders. Fix the sending path or move that mail to a domain with a clear policy.

Reject helps stop direct domain spoofing. It does not guarantee inbox placement. Gmail, Outlook, and other mailbox providers also look at sender reputation, spam complaints, content, list quality, unsubscribe handling for marketing mail, reverse DNS, IP history, blocklists, and other local signals. MX records do not authorize sending, but broken receiving and bounce handling can hide delivery problems and make operations harder to debug.

Keep AI search crawlability separate

If this DMARC work supports SEO, make sure answer engines can reach the page that explains it.

The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google because AI Overviews ride the normal Search index and there is no separate opt-out crawler, and Applebot for Apple Intelligence. Disallowing these in robots.txt removes you from that engine.

Training and opt-out controls are different. GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not affect live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent.

robots.txt is a site's stated policy, not proof of behavior. Perplexity-User and Bytespider have been reported to ignore it, so do not assert what a bot actually did from policy alone. Also, only Googlebot documents JavaScript rendering. If the main article text appears only after client-side JavaScript runs, treat that as an undocumented risk for the other AI crawlers. Server-render the main article text when you can. To check the basics, use the free AI visibility checker.