DMARC is a TXT record at _dmarc.<your domain> that tells receivers what to do with mail using your domain in the From header that fails aligned SPF and DKIM, and where to send reports. p=none only asks for reports, p=quarantine asks receivers to treat failing mail as suspicious, and p=reject asks them to refuse it.

Gmail, Yahoo and Microsoft accept p=none from bulk senders, so many domains publish it and stop there, reporting on spoofers without blocking them. Red Sift's analysis of 73.3 million domains, cited in April 2026, found 14.9% had any DMARC policy and 2.5% enforced p=reject. EasyDMARC, another DMARC vendor, reported in 2025 that 62.7% of Fortune 500 companies with DMARC used p=reject, against 15.2% of Inc. 5000 companies.

Here is a 30-day plan to p=reject, record by record, for a domain sending from workspace mail, one or two ESPs, a help desk and a billing tool. Thirty days suits a sending subdomain. A domain your staff use for everyday mail needs longer.

Key takeaways

• Publish v=DMARC1; p=none; rua=mailto:... on day 1. Without rua, receivers must not send aggregate reports.
• Every legitimate sender must pass SPF or DKIM aligned to your From domain. For most tools, that means DKIM signing with your domain.
• Keep SPF under 10 DNS-querying terms, nested includes included, or all your mail gets permerror.
• Move to p=quarantine on day 15 and p=reject on day 22, each after a clean week of reports. For a domain staff use for everyday mail, RFC 9989 asks for a month at each of the first two stages.
• RFC 9989 (May 2026) marks pct as historic. Skip the pct=10, pct=50 ramp.
• BIMI needs p=quarantine or p=reject on the organizational domain, no sp=none, an SVG Tiny PS logo and, for Gmail, a VMC or CMC.

What changed in DMARC in 2026

In May 2026 the IETF replaced RFC 7489, an Informational document from 2015, with DMARCbis: RFC 9989, a Proposed Standard that also obsoletes RFC 9091, plus RFC 9990 for aggregate reporting. Three changes matter here:

• pct is historic. Appendix A.6 says it "was usually not accurately applied, unless the value specified was either 0 or 100."
• t=y replaces pct=0. Receivers apply one level below your policy, so p=reject; t=y acts as quarantine. It is a test switch.
• np is new. It covers subdomains that don't exist in DNS, and older receivers must ignore it.

A DNS tree walk also replaces the public suffix list for finding the organizational domain.

The three records DMARC depends on

DMARC passes when SPF or DKIM passes and the passing domain aligns with the From domain. One aligned pass is enough.

SPF and the 10-lookup limit

SPF authorizes servers for the envelope (MAIL FROM or return-path) domain, the only identity DMARC uses, not HELO. RFC 7208, section 4.6.4 caps DNS-querying terms at 10: include, a, mx, ptr, exists and redirect, counted through every nested include. ip4, ip6 and all are free. Over it, the result is permerror. The section also allows at most two "void lookups", usually an include for a hostname that no longer exists.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all"

That spends 4 lookups before counting what each vendor nests, so resolve each with dig +short TXT <name> down the chain. To get under 10, drop dead tools or give each ESP its own return-path subdomain such as bounce.example.com, with its own budget of 10. Microsoft's SPF setup guide recommends ending with -all on domains that also run DKIM and DMARC.

Many ESPs default to their own return-path domain, which doesn't align with yours. Set up a custom return-path or rely on DKIM.

DKIM: 2048-bit keys, selectors and rotation

DKIM signs each message with a domain d= and selector s=; the receiver fetches the key from <selector>._domainkey.<d domain>. A tool signing with d=vendor-mail.example passes DKIM and fails DMARC.

RFC 8301 says signers must use RSA keys of at least 1024 bits and should use 2048. Google's sender guidelines say the same for personal Gmail accounts. A 2048-bit key exceeds the 255-character TXT string limit, so it goes in as several quoted strings in one record, which most DNS hosts split for you.

s202610._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..."
    "...remainder-of-the-2048-bit-key...IDAQAB" )

Give each sending system its own selector and never reuse a name. A date, like s202610, keeps history readable. M3AAWG's key rotation practices say to rotate at least every six months:

1. Publish the new selector and let it propagate.
2. Switch signing to the new key.
3. Keep the old public key in DNS for 7 to 30 days so mail in transit verifies.
4. Retire the old selector with an empty p=. Don't delete it.

Alignment: relaxed or strict

RFC 9989 defines two modes:

RFC 9989 notes that "nearly all Domain Owners have found relaxed alignment sufficient." Leave aspf and adkim out. Strict SPF alignment breaks the usual return-path on a subdomain.

The 30-day plan

The record for each stage. Move on only after a clean week of reports.

If week 2 turns up a source nobody can fix, stay at p=none. Rejecting your own invoices is worse than enforcing late.

Days 1 to 7: publish p=none with reporting

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Reports are gzipped XML, at least daily from each receiver, so point rua at a report processor, not a person. If the address is on another organizational domain, RFC 9990 has receivers ignore it unless example.com._report._dmarc.<report domain> authorizes it. Processors publish that record; for your own domains, add it yourself.

Publish exactly one DMARC record. If setup wizards leave two v=DMARC1 records at _dmarc.example.com, receivers discard both.

Skip ruf. RFC 9989 notes privacy-minded receivers redact failure reports heavily or skip them, and Microsoft's high-volume sender FAQ says it sends rua reports and has no plans to send ruf.

How to read an aggregate report

RFC 9990 describes "daily (or more frequent)" XML reports, one per policy domain. One record, adapted from its sample:

<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounces.vendor.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>vendor.example</domain>
      <selector>abc123</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.vendor.example</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

In policy_evaluated, dkim and spf are alignment results and disposition is what the receiver did. auth_results holds the raw results and their domains. Here both pass for vendor.example, so both fail alignment: a vendor sending as you without signing as you. Turn on its custom DKIM or domain authentication.

Days 1 to 7: find the unknown senders

Group by source_ip, envelope_from and DKIM domain plus selector, sort by count, and bucket:

To attribute an IP, run dig -x 192.0.2.123 +short and check the selector, which often names the vendor. Then ask finance, support and sales what sends as the company: billing, help desk, calendar invites, office scanners.

Forwarded and list mail will fail in ways you can't fix, and Google's sender FAQ doesn't require alignment for it, so don't wait on it.

Days 8 to 14: fix every legitimate source

Work from the highest count down:

1. Workspace mail (Google Workspace, Microsoft 365). Turn on DKIM in the admin console, 2048-bit where offered, and confirm the provider's include is in SPF.
2. ESPs and marketing tools. Set up domain authentication so they sign with your d=, plus a custom return-path if offered.
3. Help desk, billing, CRM. Same as ESPs. If one can't sign with your domain, use a subdomain it can sign for, or its own domain.
4. Dead tools. Remove their includes and selectors.

Recount SPF lookups after.

Day 15: p=quarantine

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

Quarantine usually means spam. Watch for legitimate sources with a quarantine disposition. To rehearse, p=quarantine; t=y asks RFC 9989 receivers to apply none, though the RFC is months old and not every receiver honors t yet.

Day 22: p=reject

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com"

Receivers that honor p=reject refuse failing mail in the SMTP session, but RFC 9989 tells them to quarantine when the policy is their only evidence, so some lands in spam.

The same RFC says a domain at p=reject "MUST NOT rely solely on SPF" and must sign with DKIM, since forwarding breaks SPF but not DKIM. Confirm aligned DKIM on every source first.

Keep rua forever. Next quarter's new tool will show up in your reports before your support queue.

When to stretch the plan

RFC 9989, section 7.4, says domains whose users post to mailing lists "SHOULD NOT" publish p=reject, and those that do should first spend "at least a month" at p=none and "an equally long period" at p=quarantine. That is most company apex domains, so give each of the first two stages a month there. A subdomain used only by your ESP has no list traffic and can keep the 30-day pace.

Subdomain policy: sp= and np=

p covers the domain and its subdomains. sp overrides it for existing subdomains, np for nonexistent ones. A subdomain with its own record uses it, and RFC 9989 ignores sp there.

A dedicated sending subdomain like mail.example.com, used by one ESP with verified SPF and DKIM, can publish p=reject from day one. p=none; sp=reject on the apex protects subdomains while you finish the main domain, but blocks BIMI.

Parked domains should publish v=spf1 -all, per Microsoft's SPF guide, plus v=DMARC1; p=reject; at _dmarc.

Day 30 and after: BIMI

BIMI shows your logo next to authenticated mail in supporting inboxes:

The BIMI draft is at revision 14 (May 2026), still an Internet-Draft written against RFC 7489, hence pct. Leave pct out and don't set t=y.

The organizational domain rule catches subdomain senders: with mail.example.com at p=reject and example.com at p=none, receivers must not show the logo, so the apex has to finish the plan too.

The BIMI Group's SVG guidance recommends a square, centered logo on a solid background, under 32 KB. Google added CMC support in September 2024. The record, per the BIMI Group implementation guide:

default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem"

Trademark registration takes months, so start any VMC work now.

What Gmail, Yahoo and Microsoft require

None of the three requires enforcement, only a DMARC record and alignment.

Sources: Google's sender guidelines and FAQ, Yahoo's sender best practices, and Microsoft's April 2025 announcement and 5.7.515 support page. Microsoft began enforcing on May 5, 2025, after an April 29 update changed the action from junk-foldering to rejection.

Google's FAQ says alignment with both SPF and DKIM "will eventually be a sender requirement," so align both in week 2. On unsubscribe and spam rates, see what still applies when an agent sends your email and our deliverability guide.

DMARC on a Brew sending domain

Brew's domain setup asks for:

• DKIM, a TXT record at a ._domainkey selector under your sending domain. Required.
• SPF, an MX and a TXT record on send.<your sending domain>, Brew's return-path. Required.
• DMARC, a TXT record at _dmarc.<your sending domain>. Optional, and recommended.
• A CNAME for click tracking, only with a custom tracking subdomain.

The domain sends once SPF and DKIM verify, and Brew suggests a DMARC value to match:

; dedicated sending subdomain, e.g. mail.example.com
_dmarc.mail.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com"
 
; apex domain, or a domain Brew can't prove is dedicated
_dmarc.example.com.       TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

A dedicated subdomain gets p=reject because nothing sends from it before Brew's SPF and DKIM verify. An apex gets p=none because your other tools likely send as it too, so run the plan above. Alignment stays relaxed because the send.<domain> return-path only aligns in relaxed mode.

Brew reads the live _dmarc.<sending domain> record on add, verify and every recheck. Settings > Domains shows the result, as do get_domain_health over MCP and GET /v1/domains/{domainId}/health:

• dmarc_missing, a warning with the exact record to add.
• dmarc_invalid, for two DMARC records at the name, or a bad version, policy or duplicate tags. It names the record to delete.
• Verified, once exactly one valid record is found.

Automatic DNS setup writes DMARC only when no record exists, so it never duplicates one. The check runs at the sending domain, not its parent, so give each sending subdomain its own record, including one for transactional mail if you split the two as the docs advise. Your rua processor is where you read reports and decide when to move to reject.

Frequently asked questions

How long should I stay at p=none before moving to quarantine?

Until a full week of reports shows every legitimate source passing aligned SPF or DKIM, usually one to two weeks for a sending subdomain. For a domain staff use for everyday mail, RFC 9989 asks for at least a month. Two years at p=none with nobody reading reports counts for nothing.

Is the DMARC pct tag deprecated?

Yes. RFC 9989 lists pct as "historic" and replaces its only reliable values with t: t=y behaves like pct=0, t=n like pct=100. Older receivers may still read pct, but never applied middle values consistently, so move in whole steps.

Will p=reject block my forwarded email?

Plain forwarding usually breaks SPF but not DKIM, so aligned DKIM still passes. Lists that edit the subject or footer break DKIM, and some rewrite the From header to compensate. Aligned DKIM everywhere is your best protection.

Do Gmail and Yahoo require p=reject?

No. Both require bulk senders to publish DMARC and accept p=none, as does Microsoft above 5,000 messages a day to Outlook.com. Enforcement stops spoofing and is required for BIMI, but none of the three require it.

Do I need a VMC for BIMI?

For Gmail, you need a VMC, which requires a registered trademark and shows a checkmark, or a CMC, which shows the logo without one. The BIMI Group says a few providers, including Yahoo and Fastmail, also show self-asserted logos with no certificate.