DMARC p=reject: how to move from p=none safely

What p=reject does, and why p=none is not the end#

DMARC is a record in your domain’s DNS that tells other mail servers what to do with mail that claims to come from your domain but cannot prove it. Say a customer pays an invoice that came “from” billing@ your domain, and nobody at your company sent it. With your record at p=none, the customer’s mail server saw the forgery fail DMARC and delivered it anyway, because p=none asks for exactly that.

The record is one TXT record (a line of text in DNS) at _dmarc. plus your domain. Its p= tag picks one of three policies. The current standard is RFC 9989, published in May 2026, which describes reject as “a clear indication that the use of the domain name is not valid”.^[1] It replaced RFC 7489 from 2015, the version most tutorials still quote.^[2] No large mailbox provider has said which version its servers follow, and Google’s and Microsoft’s help pages still describe RFC 7489’s pct tag, so this guide plans for both (see pct and t=y).^[13][6]

p=none already satisfies the Gmail, Yahoo and Outlook.com rules for bulk senders.^[3][4][5] Reject is not needed for delivery. It is what stops the forged invoice.

How DMARC decides: alignment and the organizational domain#

DMARC passes only when a check proves the mail came from your domain, not just from some domain. In practice: SPF or DKIM must pass, and the domain it checked must align with the domain in the From address. One aligned pass is enough; RFC 9989 asks senders for “at least one -- preferably two”.^[1]

• SPF checks the bounce address (the return path), so a service that bounces to its own domain passes SPF without aligning.^[8]
• DKIM vouches for the domain in its d= tag, so a service signing with its own d= passes DKIM without aligning.^[9]

Alignment is relaxed by default (adkim=r, aspf=r): the two domains only have to share an organizational domain, so a From of example.com aligns with d=news.example.com. Strict (s) needs identical names.^[1] Keep relaxed: most sending services put the return path on a subdomain.

Which record governs a subdomain#

A subdomain’s own record always wins. Without one, RFC 9989 has the receiver walk up the name, at most eight lookups, and fetch every record on the way (§4.10). It stops early only at a record carrying psd=n or psd=y. Otherwise the organizational domain is the record with the fewest labels, and its sp= (or p=) applies (§4.10.1, §4.10.2).^[1] So a plain record in the middle is read and passed over. For mail from mail.eu.example.com, which has no record of its own:

The middle row surprises people, so here is the policy-discovery rule itself. The record applied is the one at “the Author Domain”, else “the Organizational Domain of the Author Domain”, else the public suffix domain (§4.10.1); no other location is on the list. And the RFC’s worked example settles which domain is the organizational one: with records at mail.example.com and example.com, “the Organizational Domain for this domain would be ‘example.com’” for mail from a.mail.example.com (§4.10.2).^[1] psd=n is RFC 9989’s way to hand a subtree to another team (§5.1.8); public suffix operators publish psd=y instead. RFC 7489 found the organizational domain from the Public Suffix List and knows neither tag,^[2] so while receivers run both, give each subdomain that sends mail a record of its own.

The rollout, step by step#

Getting to reject takes six steps over at least two sending cycles, often months, and only the last two change what happens to mail. The order is the one RFC 9989 sets out (publish, collect, remediate, then enforce), and Google’s and Microsoft’s rollout guides follow it.^[1][10][6]

1. 1

   List every service that sends as your domain, and give each aligned DKIM

   Your own Microsoft 365 or Google Workspace mailboxes, marketing tool, helpdesk, billing, CRM, the scanner that emails PDFs. In each, turn on DKIM for your own domain (often called custom DKIM or domain authentication). RFC 9989 says domains that publish p=reject “MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages”, because forwarding breaks SPF.

2. 2

   Publish p=none with a report address

   First look up _dmarc on your domain: if a record is already there, edit it rather than adding a second, because receivers discard every DMARC record when they find more than one. Then publish the first record below. Its rua tag is where reports go: a mailbox made for them, not a person's inbox. Delivery does not change.

3. 3

   Read the reports for a full sending cycle and fix what fails

   Match every source IP to a service and fix each legitimate one that fails, using the table further down. Wait until the monthly and quarterly sends have appeared.

4. 4

   Lower the _dmarc TTL before each policy change

   The TTL is how long other servers may cache the record; it usually sits beside the value in your DNS host's editor. Set it to 300 seconds (or your host's minimum), then wait out the old TTL before you change the policy, so a rollback reaches receivers in minutes.

5. 5

   Move to p=quarantine

   The second record. Failing mail now goes to spam, and np=reject already refuses mail from subdomains that do not exist. Watch the reports, bounces and support queue for as long as you spent at p=none.

6. 6

   Move to p=reject and close names that do not exist

   The third record. Without an sp= tag, every existing subdomain that has no _dmarc record of its own moves to reject at the same moment, so finish the subdomain audit first, or add sp=quarantine to this record and raise subdomains a cycle later. Keep rua in it for good, and raise the TTL again after a clean sending cycle at reject.

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

After each change, check that every authoritative nameserver serves exactly one DMARC record and the new policy, then check a public resolver. A stale nameserver or a second record shows up here, not in the reports:

dig +short NS example.com
dig +short TXT _dmarc.example.com @ns1.example.net   # repeat for each NS above
dig +short TXT _dmarc.example.com @8.8.8.8

How long each stage should last#

Google suggests a week at p=none as “usually enough time for the daily reports to contain data representative of all your mail streams”.^[10] The standard is more cautious for a domain whose people write to mailing lists:

A monthly invoice run will not appear in a week of reports; RFC 9989 warns it “may take many months” to be sure all your mail authenticates.^[1] Measure each stage in sending cycles instead: long enough for every kind of mail you send, quarterly runs included, to go out once. Move up when a cycle shows no legitimate source failing, not when a calendar says so.

Reading aggregate reports, and spotting a forged invoice#

Once your record has a rua= address, receivers send it a summary of every server that used your domain.^[1] These aggregate reports, defined in RFC 9990, are daily (or more frequent) XML files listing each sending IP, how many messages it sent, and how SPF, DKIM and DMARC came out.^[11] One record, trimmed to what matters:

<record>
  <row>
    <source_ip>192.0.2.10</source_ip>
    <count>142</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>mail.example.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

<policy_evaluated> is the DMARC view: its dkim and spf are pass or fail after alignment, and disposition is what the receiver did. <auth_results> is the raw view: what SPF and DKIM said, and for which domain.^[11] Here SPF passed for mail.example.net, which does not align, and DKIM passed for example.com, which does, so the message passes on DKIM alone. If a source passes on SPF alone, forwarding will break it, so add aligned DKIM before you climb. A source aligned on neither leg is a stream to fix or spoofing; the table under fixing the senders that fail tells them apart.

What a forged invoice looks like#

<record>
  <row>
    <source_ip>203.0.113.77</source_ip>
    <count>3</count>
    <policy_evaluated>
      <disposition>reject</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>invoices.example.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

An address you cannot match to any service, a handful of messages, no DKIM result at all, and an SPF pass for invoices.example.net: the forger’s own domain, which proves nothing about yours. At p=none the disposition would read none and those three invoices would have been delivered.

Reading them without paying for a service#

Nobody reads this XML by eye for long; RFC 9989 recommends it be “machine-parsed”.^[1] If no one on your team will run a script, a paid DMARC reporting service turns the reports into a dashboard, and Microsoft points to its partner catalog for one.^[6] Two free ways:

• parsedmarc, an open-source (Apache-2.0) Python tool, reads a report mailbox over IMAP, Microsoft Graph or the Gmail API, handles the RFC 9990 and older schemas, and writes CSV or JSON, feeds dashboards, or posts to a webhook.^[12]
• A short script for a few reports a week, below.

For developers: a short report reader#

Save the attachments in one folder and run this on them (Python 3, standard library only). It adds the counts up across reports, prints failing senders first, and skips a file it cannot read rather than stopping.

# Usage: python3 dmarc_sum.py reports/*   (.xml, .xml.gz or .zip report files)
import gzip
import sys
import xml.etree.ElementTree as ET
import zipfile
import zlib
from collections import Counter
from pathlib import Path


def load(path):
    if path.endswith(".gz"):
        return gzip.decompress(Path(path).read_bytes())
    if path.endswith(".zip"):
        with zipfile.ZipFile(path) as archive:
            return archive.read(archive.namelist()[0])
    return Path(path).read_bytes()


def get(node, where):
    found = node.find(where)
    return found.text if found is not None and found.text else "-"


totals = Counter()
for path in sys.argv[1:]:
    try:
        root = ET.fromstring(load(path))
    except (ET.ParseError, OSError, EOFError, IndexError, zlib.error, zipfile.BadZipFile) as error:  # unreadable: skip it
        print("skipped", path, error, file=sys.stderr)
        continue
    for node in root.iter():  # drop RFC 9990's namespace: one set of paths reads old and new reports
        node.tag = node.tag.rsplit("}", 1)[-1]
    for record in root.iter("record"):
        passed = "pass" in (get(record, "row/policy_evaluated/dkim"), get(record, "row/policy_evaluated/spf"))
        dkim = " ".join(get(d, "domain") + ":" + get(d, "result") for d in record.findall("auth_results/dkim"))
        sender = (
            "PASS" if passed else "FAIL",
            get(record, "row/source_ip"),
            "from=" + get(record, "identifiers/header_from"),
            "dkim=" + (dkim or "none"),
            "spf=" + get(record, "auth_results/spf/domain") + ":" + get(record, "auth_results/spf/result"),
        )
        count = get(record, "row/count")
        totals[sender] += int(count) if count.isdigit() else 0

for sender, count in sorted(totals.items(), key=lambda item: (item[0][0] == "PASS", -item[1])):
    print(count, *sender)

If rua points at another domain, such as a reporting service, that domain must publish a <your-domain>._report._dmarc.<their-domain> TXT record or receivers will not send the reports.^[11]

How many reports to expect, and what to keep#

Each receiver sends a separate gzipped report per policy domain for each period, usually a day, and RFC 9990 warns the quantity “could be fairly high” for some domains.^[11] So the count grows with the number of receiving organisations you mail and the number of subdomains with their own record, not with your send volume. Give rua a mailbox no person reads, and feed it to a parser rather than a shared inbox. The RFC says the raw files have “little value” once parsed: keep the parsed rows for at least a cycle at each policy step, and drop the XML. The RFC also says the reports carry no personal information; they do carry the IPs of sending servers, which your privacy team may want to rule on.

Play video: DMARC Training-4: DMARC Reporting

Fixing the senders that fail#

Most failing sources in a first report are your own tools, not forgers. RFC 9989 says legitimate streams “not passing due to Authenticated Identifiers being unaligned or missing entirely” “MUST be addressed prior to” enforcement.^[1]

A receiver that overrode your policy, say by delivering failing mail, says why in the record’s <reason>, with types such as mailing_list, trusted_forwarder and local_policy: a hint that the source is a relay, not a forger.^[11] Microsoft documents the first row: “Currently, no DKIM signing occurs for outbound mail from custom domains”.^[19] Google Workspace has its own DKIM set-up page.^[20] A return path on your own subdomain is what makes the SPF leg align; how it works is in custom return path, explained. When a service cannot sign with your domain at all, send its mail from a subdomain with its own DMARC record rather than holding the whole domain at p=none for one tool.

Keep the apex SPF record inside its limits#

SPF allows 10 DNS-querying terms (include, a, mx, ptr, exists, redirect), and receivers “SHOULD limit ‘void lookups’ to two”: terms whose lookup finds nothing, such as an a: or mx: naming a host you retired. An include of a vendor domain that no longer publishes SPF is worse: it is a permanent error (permerror) on its own. A permerror means no SPF pass, so DMARC counts no SPF leg.^[8] But evaluation runs left to right and stops at the first match, so a sender matched before the fault still passes while later ones get permerror: a broken record fails only part of your mail, which makes it easy to miss. Two v=spf1 records at one name also give permerror, usually after a vendor’s setup wizard adds its own instead of editing yours; merge them into one. A return path per service on its own subdomain gives each its own SPF record and keeps the apex short.^[8]

Ending the apex record in -all has a cost at reject. Some receivers check SPF before DMARC and refuse a hard fail outright, so forwarded mail that aligned DKIM would have carried through is refused, and never appears in your reports because the refusal comes before the From address is read. RFC 9989 asks domain owners using -all to be aware of exactly this.^[1] ~all leaves the decision to DMARC.

pct, t=y and which receivers still apply pct#

pct= was meant to apply a policy to only part of your failing mail. Whether it still does depends on the receiver. RFC 7489 defined it: apply the policy to that share and treat the rest one step softer.^[2] RFC 9989 removed it because “the ‘pct’ tag was usually not accurately applied, unless the value specified was either 0 or 100”, and replaced it with t=, a testing flag whose y and n are meant to behave like pct=0 and pct=100. Unknown tags “MUST be ignored”.^[1] So the same record reads differently on each generation of receiver:

Microsoft 365 still documents pct: its rollout guide steps through pct=10 to pct=100, and its headers mark sampled mail action=pct.quarantine or action=pct.reject.^[6] Google’s DMARC help still recommends including pct during a rollout.^[13] Yahoo’s sender page does not mention it.^[4] RFC 9989 receivers ignore it, and you cannot tell which kind you are mailing, so treat every pct step as possibly 100%. To rehearse reject, p=reject; pct=0; t=y means quarantine to both generations.

Subdomains: sp= and np=#

Your DMARC record covers your subdomains too, unless you say otherwise. sp= sets the policy for existing subdomains and np= for subdomains that do not exist in DNS. np= was first defined experimentally in RFC 9091 (2021)^[24] and is part of the core standard since RFC 9989. Without np=, non-existent names get sp=, or failing that p=.^[1]

• Close non-existent names early. Nobody legitimately sends from invoices-secure.example.com if it does not exist, so np=reject costs nothing, which is why the quarantine record above already carries it.
• Audit subdomain records. A subdomain’s own record wins (see which record governs a subdomain), so a forgotten p=none at _dmarc.news.example.com is a hole in an otherwise enforced domain.
• Move a difficult stream aside. If one tool cannot align yet, send it from a subdomain with its own softer record and take the apex to reject. The trade-offs of doing that on purpose are in should you use an email subdomain for marketing?

Forwarding, mailing lists and ARC#

Forwarding and mailing lists are where legitimate mail most often fails DMARC. When mail is forwarded through an alumni address or a role alias, the forwarder’s IP is not in your SPF record, so SPF fails, while “DKIM signatures will generally remain valid”.^[1] Mailing lists that add a subject tag or a footer break DKIM too.^[14] That is why RFC 9989 says domains “that host users who might post messages to mailing lists SHOULD NOT publish” p=reject, and why it notes that list software has “all adopted workarounds”, rewriting the From so it aligns, often to the list’s own address.^[1]

ARC (Authenticated Received Chain) lets each hop record what authentication looked like when the message reached it. It is an Experimental RFC from 2019,^[15] and RFC 9989 says that as of its publication none of the methods for keeping lists working “have become widely used”.^[1] Where it is documented, it is the forwarder’s and the receiver’s job, not yours: Yahoo asks senders who forward to “implement ARC”,^[4] and Microsoft 365 lets an admin name trusted ARC sealers whose pass can override a DMARC failure (shown as compauth=pass reason=130).^[16] Nothing in your own DMARC record turns ARC on.

If enforcement breaks a stream: rolling back#

A broken stream shows up as bounces from mail you meant to send. Gmail’s 550 5.7.26 reads “Unauthenticated email from domain-name is not accepted due to domain’s DMARC policy.”^[7] Exchange Online’s list of bounce codes gives 5.7.509, “Access denied, sending domain [$SenderDomain] does not pass DMARC verification and has a DMARC policy of reject.”^[25] Microsoft’s DMARC page shows 550 5.7.1 for the same case,^[6] and Outlook.com uses other codes, such as 550 5.7.515 for high-volume senders that fail its authentication rules.^[5] Read the text after the code rather than matching one number. Then:

• Step down one level; do not delete the record. Deleting it stops the reports you need to find the fault, and bulk senders need a DMARC record for Gmail, Yahoo and Outlook.com.
• Expect it to take one TTL, sometimes longer. A TTL is “the time interval (in seconds) that the resource record may be cached before it should be discarded”,^[17] and the one that counts is the TTL receivers already cached, which is why step 4 lowers it a full old TTL before each change. At 300 seconds most receivers see the softer policy within five minutes, but a resolver can be set to keep records longer than their TTL (Unbound’s cache-min-ttl, for one), so allow an hour before concluding the rollback failed.^[29]
• Send the refused mail again once it passes. A 5xx is permanent, so the sending server will not retry it.^[30] The recipients’ addresses are fine, so lift any suppressions the refusals caused. Rasket adds an address to suppressions on any permanent bounce,^[22] and the guide to tracing emails that were not delivered shows how to find and lift those after an authentication incident.
• Do not use t=y as the rollback. Receivers still on RFC 7489 ignore tags they do not know and keep rejecting.^[2]
• Fix, then climb again after a clean cycle of reports.

After p=reject: keep watching#

Keep reading the reports after reject. RFC 9989 calls consuming them “essential to any successful DMARC deployment”,^[1] and a new vendor added without DKIM shows up there before it shows up as a complaint. Enforcement is also the first condition for BIMI, the brand logo beside your name in Gmail: it needs p=quarantine or p=reject with pct at 100, plus a Verified Mark Certificate or Common Mark Certificate for the logo.^[18]

Rotating DKIM keys without breaking reject#

At p=reject, a message signed with a selector receivers cannot look up yet fails DKIM, and with SPF broken by a forward it is refused. M3AAWG’s rotation practice avoids that window. It asks for a rotation at least every six months:^[28]

• Publish the new public key under a new selector, such as s202611._domainkey, and wait until it resolves. Never reuse a selector name.
• Switch signing to the new private key.
• Leave the old public key unchanged for 7 to 30 days, so mail already in transit still verifies.
• Retire the old key by publishing its selector with an empty p=, which RFC 6376 defines as revoked, rather than deleting the record.^[9]
• Check that next week’s aggregate reports show the new selector passing.

When a service signs for you through selector CNAMEs that point at its own DNS, it can rotate behind them without you touching your zone; M3AAWG describes three CNAMEs so one key signs while the others rotate. Ask each service which model it uses before you reach reject.^[28]

If you send through Rasket#

Rasket’s API reference gives a starting DMARC record, v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com for example.com, and the domain page offers a guided record whose reports go to an address of yours.^[23][21] Reading the reports stays your job, and every other tool that sends as your domain needs its own DKIM set-up.