# DMARC from p=none to p=reject in 30 days Canonical: https://brew.new/blog/dmarc-p-none-to-reject-in-30-days Author: Thomas Park Published: 2026-10-04 Updated: 2026-10-04 DMARC is a TXT record at `_dmarc.` 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](https://redsift.com/blog/email-authentication-bespinlabs-redsift), found 14.9% had any DMARC policy and 2.5% enforced `p=reject`. EasyDMARC, another DMARC vendor, [reported in 2025](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/) 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](https://www.rfc-editor.org/rfc/rfc9989.html), a Proposed Standard that also obsoletes RFC 9091, plus [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) 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](https://www.rfc-editor.org/rfc/rfc7208.html#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. ```dns 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 ` 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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) 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 `._domainkey.`. A tool signing with `d=vendor-mail.example` passes DKIM and fails DMARC. [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) says signers must use RSA keys of at least 1024 bits and should use 2048. [Google's sender guidelines](https://support.google.com/mail/answer/81126) 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. ```dns 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](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf) 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: | Mode | Tag | Passing SPF/DKIM domain | From domain | Aligned? | |---|---|---|---|---| | Relaxed (default) | `aspf=r`, `adkim=r` | `bounce.example.com` | `mail.example.com` | Yes, same organizational domain | | Strict | `aspf=s`, `adkim=s` | `bounce.example.com` | `mail.example.com` | No, names must match | | Either | | `vendor.example.net` | `example.com` | No | 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 ![A 30-day DMARC timeline in four stages: days 1 to 7 at p=none with rua reporting, days 8 to 14 fixing senders, day 15 at p=quarantine, day 22 at p=reject, then BIMI from day 30, with the exact TXT record for each stage.](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png) *The record for each stage. Move on only after a clean week of reports.* | Days | Policy | What you do | Gate to move on | |---|---|---|---| | 1 to 7 | `p=none` | Publish with `rua`, list every source | 7 days of reports from Google, Yahoo and Microsoft | | 8 to 14 | `p=none` | Fix DKIM and SPF, retire unused senders | Every legitimate source passes aligned SPF or DKIM | | 15 to 21 | `p=quarantine` | Watch for quarantined legitimate mail | 7 days with no legitimate source failing | | 22 to 30 | `p=reject` | Keep reading reports, add `np=reject` | Stable for a week | | 30+ | `p=reject` | Start BIMI | Certificate issued | 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 ```dns _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.` 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](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) 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: ```xml 192.0.2.123 123 none fail fail bounces.vendor.example example.com vendor.example abc123 pass bounces.vendor.example pass ``` 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: | Pattern in the report | Likely cause | Action | |---|---|---| | Aligned DKIM or SPF pass | Configured correctly | None | | DKIM and SPF pass for vendor domains | SaaS tool using its own identity | Turn on custom DKIM | | Aligned DKIM pass, SPF fail, mailbox provider or list IP | Forwarding or a list | Usually none. Aligned DKIM survives forwarding | | No DKIM, SPF fail, unattributable IPs | Spoofing | None. This is what `p=reject` stops | 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](https://support.google.com/mail/answer/14229414) 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 ```dns _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 ```dns _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: | Requirement | Detail | Source | |---|---|---| | DMARC policy | `p=quarantine` or `p=reject` on the organizational domain and the From domain | BIMI draft | | Subdomain policy | If `sp` is published, not `none` | BIMI draft | | Percentage | Quarantine must not have `pct` below 100 | BIMI draft | | Logo | SVG Tiny PS: `baseProfile="tiny-ps"`, `version="1.2"`, a ``, no scripts or external references, no `x=` or `y=` on the root | BIMI Group | | Certificate | Gmail needs a VMC (registered trademark, checkmark) or a CMC (no trademark, no checkmark) | Google | The [BIMI draft](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/) 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](https://bimigroup.org/creating-bimi-svg-logo-files/) recommends a square, centered logo on a solid background, under 32 KB. Google [added CMC support in September 2024](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html). The record, per the [BIMI Group implementation guide](https://bimigroup.org/implementation-guide/): ```dns 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. | | Gmail | Yahoo | Outlook.com | |---|---|---|---| | Threshold | Close to 5,000 a day to personal Gmail, per primary domain, permanent once reached | Bulk senders, no number | Over 5,000 a day to outlook.com, hotmail.com and live.com, per From domain | | SPF and DKIM | Both | Both | Both must pass | | DMARC | Record required, `p=none` accepted | At least `p=none`, `rua` strongly recommended | At least `p=none` | | Alignment | SPF or DKIM | SPF or DKIM, relaxed is fine | SPF or DKIM | | Failure | Temporary and permanent rejections since November 2025 | Not stated | `550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` | Sources: [Google's sender guidelines](https://support.google.com/mail/answer/81126) and [FAQ](https://support.google.com/mail/answer/14229414), [Yahoo's sender best practices](https://senders.yahooinc.com/best-practices/), and Microsoft's [April 2025 announcement](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) and [5.7.515 support page](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com). 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](/blog/agent-email-deliverability) and our [deliverability guide](/blog/email-deliverability). ## DMARC on a Brew sending domain Brew's [domain setup](https://docs.brew.new/get-started/verify-your-sending-domain) 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: ```dns ; 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](/blog/transactional-emails) 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](https://bimigroup.org/understanding-bimi-certificate-types/) says a few providers, including Yahoo and Fastmail, also show self-asserted logos with no certificate.