DMARC p=none Is Not Protection. Here's the Path to Reject

The change request takes four minutes. Someone opens the zone file, adds a TXT record at _dmarc, pastes in v=DMARC1; p=none; rua=mailto:[email protected], and closes the ticket. The security questionnaire asks whether the domain publishes DMARC. It does now. The box gets ticked. The domain moves onto the list of things that have been handled.

Then nothing happens.

Not nothing much. Nothing. The specification requires it:

To enable Domain Owners to receive DMARC feedback without impacting existing mail processing, discovered policies of "p=none" MUST NOT modify existing mail handling processes.

Read the modal verb. Not SHOULD NOT. MUST NOT. A receiver that quarantined a message because it found p=none would be departing from the standard, not enforcing it. Whatever protection a domain has while it publishes p=none comes from somewhere else entirely: the receiver's own spam filtering, its reputation systems, its local policy. None of it comes from the record.

That record still earns its place. It turns on reporting, and nothing further in this rollout is possible without the reports. Starting at none is correct. Stopping there is the part worth fixing.

What p=none Actually Says

DMARC was re-standardised in May 2026 as three documents: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting and RFC 9991 for failure reporting. They obsolete RFC 7489, the 2015 document nearly every published rollout guide was written against. A companion post covers what that transition changed in DNS. This one is about the rollout, and the rollout starts with three definitions from Section 4.7.

Of none, the RFC says: The Domain Owner offers no expression of preference.

Of quarantine: The Domain Owner considers such mail to be suspicious. It is possible the mail is valid, although the failure creates a significant concern.

Of reject: The Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid.

Three positions, and only two of them are positions. Quarantine is a hedge with a stated reason. Reject is an assertion. None is a shrug, written down and published to the internet.

Two more clauses before you audit anything. A syntactically valid record with no p tag at all is not an error: If this tag is not present in an otherwise syntactically valid DMARC Policy Record, then the record is treated as if it included "p=none". And a record with a broken p value degrades quietly rather than failing loudly. RFC 9989 Section 4.10.1 tells receivers that if the record has no valid p tag but does carry at least one syntactically valid reporting URI, they MUST act as if a record containing 'p=none' was retrieved and continue processing.

The third one is the interesting failure. A typo in a policy value does not produce an error anybody sees. It produces monitoring mode, indefinitely, on a domain whose owner believes it is enforcing. The UK's National Cyber Security Centre describes the effect of a none policy in plain terms: A policy of 'none' means this DMARC record won't affect the delivery of your email, but it will provide you with reports on where your outbound email appears to be coming from. That is exactly right, and it is the entire point of the stage.

How Many Domains Stop Here

Less certainty is available on this than you would expect. The most defensible measurement of DMARC's overall footprint comes from the DNS Abuse study commissioned by the European Commission, which examined 247 million domain names in Q2 2021 and reported that more than 60% of domain names are without SPF and 97% of domains are without DMARC records. That is a count of all measured domains, not of DMARC publishers.

For the share of DMARC publishers sitting at none, the only academic figure we could obtain is roughly two-thirds of the Alexa Top 1M, as of May 2020, and it appears as a secondary citation inside Liu et al., IEEE EuroS&P 2023 rather than as that paper's own measurement. Six years old, second-hand, and a population that no longer exists in that form. Every current-year percentage on this topic that we found was published by a company selling DMARC management. Those numbers may well be right. They are not measurements anyone outside the vendor can check, so this article will not lean on one.

What You Actually Get at none: The Report

Aggregate reports start arriving quickly. NCSC's guidance says Within 24 hours of publishing your records you'll start receiving email reports from major email recipient domains. RFC 9990 sets the shape of the reporting period rather than mandating an interval: When generating reports, these reporting periods SHOULD NOT overlap. Typically, the reporting period will encompass a single UTC day, beginning at 0000UTC. There is no tag to request a different cadence. The old ri tag is marked historic in the IANA registry, along with rf, both still pointing at the obsolete RFC 7489. Reporting intervals are the receiver's call.

RFC 9989 is direct about what setting up the mailbox involves: While it is possible for a human to read aggregate reports, they are formatted in such a way that it is recommended that they be machine-parsed, so setting up a mailbox involves more than just the physical creation of that mailbox. The reports are XML documents, one per receiver per reporting period, arriving on whatever schedule each receiver chooses.

Here is the structure you are reading, using the element names from the RFC 9990 schema:

Four fields carry most of the decision weight.

row/count is the volume: The number of messages for which the PolicyEvaluatedType was applied. It is how you tell a production mail stream from a stray test message, and a spoofing campaign from background noise.

policy_evaluated/dkim and policy_evaluated/spf are the aligned results, and their type allows exactly two values: pass and fail. No partial credit, no third state. This is the pair that answers the only question that matters at this stage.

identifiers/header_from and identifiers/envelope_from are the RFC5322.From domain and the RFC5321.MailFrom domain. Their divergence is precisely what alignment tests.

auth_results holds the raw results underneath: zero or more DKIM results, each with a domain, a selector and a result, plus at most one SPF result. The selector tells you which key signed. That makes it the field that exposes a key rotation gap.

One element rewards a second look. disposition can take four values, and two of them read alike at a glance: none means no action was taken, while pass means the message passed DMARC under an enforcing policy. A report full of disposition: none is not a report of success. It is a report of a policy that told nobody to do anything.

So the question you put to a month of reports is narrow, and it is not "how much spoofing is there":

Is every legitimate mail stream producing an aligned pass?

Alignment Is the Entire Test

Alignment is what breaks when you leave none, so it deserves the space. RFC 9989 Section 4.4 defines it in one sentence:

DMARC validates the authorized use of the Author Domain (Section 3.2.2) by requiring either that it have the same Organizational Domain (Section 3.2.14) as an Authenticated Identifier (Section 3.2.1) (a condition known as "relaxed alignment" (Section 3.2.10.1)) or that it be identical to the Authenticated Identifier (a condition known as "strict alignment" (Section 3.2.10.2)).

Two authenticated identifiers can be produced. For DKIM: If the cryptographic signature validates, then the DKIM Signing Domain is the DKIM-Authenticated Identifier. For SPF: If the use of the domain in the MAIL FROM identity is validated by SPF, then that domain is the SPF-Authenticated Identifier. Note the conditional in both. An identifier that failed authentication is not an identifier at all, so it cannot align with anything.

Both alignment modes default to relaxed. adkim is (plain-text; OPTIONAL; default is "r".), and aspf matches it. Under relaxed mode, mail.example.com and example.com share an Organizational Domain and therefore align. Under strict, they do not. Most domains never set either tag and never need to.

The rule that decides everything downstream is in Section 5.3.5: if one or more of the authenticated identifiers align with the Author Domain, the message passes the DMARC mechanism check. One is enough. You do not need both.

That asymmetry is the single most useful thing to know before you enforce. SPF alignment depends on the envelope, and intermediaries rewrite envelopes. DKIM alignment depends on a signature over the message itself, which usually survives a relay. A domain whose passes all come from SPF has a result that holds on the direct path and nowhere else. A domain with aligned DKIM on every stream has one that travels.

No Mailbox Provider Requires p=reject

This is the second correction the topic needs, and it runs the opposite way from the first. A steady stream of articles claims that the 2024 bulk-sender requirements forced senders to enforcement. Read the requirements.

Set up DMARC email authentication for your sending domain. Your DMARC enforcement policy can be set to none.

Google's threshold is stated on the same page: Starting February 1, 2024, email senders who send more than 5,000 messages per day to Gmail accounts must meet the requirements in this section. What the section actually demands, besides the record, is alignment: For direct email, the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain. Either. Plus a deliverability floor: Keep spam rates reported in Postmaster Tools below 0.30%.

Yahoo's sender best practices set the same floor: Publish a valid DMARC policy with at least p=none - DMARC must pass, and Ensure the domain in the From: header is aligned with either the SPF domain or the DKIM domain. This is required for DMARC alignment.

Microsoft's requirement for high-volume senders to its consumer services, published on its 550 5.7.515 error page, applies when You send 5,000 or more email messages to Microsoft consumer email services, and asks for a record containing a valid DMARC policy (`p=reject`, `p=quarantine`, or `p=none`) together with the same alignment condition: The SPF and/or DKIM record (at least one) must align with (effectively, "include" or "match") the domain in the `5322.From` address. The worked example in Microsoft's own documentation is v=DMARC1; p=none.

Three providers, three explicit statements that none is acceptable. The bar they raised was alignment, not enforcement. So if your rollout is being driven by a deadline somebody read in a summary of these rules, the deadline is not what they said it was. That is good news: it means you can advance on evidence instead of on someone else's calendar.

The Staged Path, Driven by Evidence

RFC 9989 Section 5.1 lays out the domain owner's work as eight named steps. These are the RFC's own section titles:

1. Publish an SPF Record for an Aligned Domain
2. Configure Sending System for DKIM Signing Using an Aligned Domain
3. Set Up a Mailbox to Receive Aggregate Reports
4. Publish a DMARC Policy Record for the Author Domain and Organizational Domain
5. Collect and Analyze Reports
6. Remediate Unaligned or Unauthenticated Mail Streams
7. Decide Whether to Update Domain Owner Assessment Policy to Enforcement
8. A Note on Large, Complex Organizations and Decentralized DNS Management

Step seven is a decision, not a date. That is deliberate, and the RFC says why the sequence begins where it does: The reason for starting at "p=none" is to ensure that nothing's been missed in the initial SPF and DKIM deployments. In all but the most trivial setups, a Domain Owner can overlook a server here or be unaware of a third-party sending agreement there.

Step six carries the only unconditional requirement in the sequence. Aggregate reports can reveal to the Domain Owner mail streams using the Author Domain but not passing DMARC validation checks: a mixture of abuse and legitimate mail nobody had inventoried. Where the legitimate streams are concerned, these shortcomings MUST be addressed prior to any attempt by the Domain Owner to publish a Domain Owner Assessment Policy of Enforcement for the Author Domain.

On timing, the RFC declines to give you a schedule and explains its reasoning: Depending on its cadence for sending mail, it may take many months of consuming DMARC aggregate reports before a Domain Owner reaches the point where it is sure that it is properly authenticating all of its mail, and the decision on which "p" value to use will depend on its needs.

One interval does exist in the standard. Exactly one:

Any such domains wishing to publish "p=reject" SHOULD first take advantage of DMARC aggregate report data for their domain to determine the possible impact to their users, first by publishing "p=none" for at least a month, followed by publishing "p=quarantine" for an equally long period of time, and comparing the message disposition results.

A month, then an equally long month. That is a floor, not a plan, and it is the whole of what the specification will tell you about elapsed time. The NCSC adds two operational windows from experience rather than from the standard: monitor for at least 4 weeks after moving to quarantine, and after moving to reject, closely monitor your reports for at least a 2 week period. That guidance is dated 7 October 2019 and parts of it have since been overtaken, as the next section covers.

Everything else in circulation is marketing collateral from companies selling DMARC management, published without a cited basis: nine-to-eighteen-month programmes, ninety-day phases, week-by-week ramps. Treat those numbers as sales aids, not as engineering.

Advancement Criteria, Not Week Counts

None of the following is a quotation. Each is the operational form of a gate RFC 9989 already states, expressed as something you can check in a report rather than on a calendar.

Leave none when every source_ip with meaningful count is identified and owned by someone; every legitimate stream shows policy_evaluated with dkim=pass or spf=pass; and the residual failing volume is either understood abuse or a stream you have consciously decided to lose. A single unexplained sender with real volume is a reason to wait.

Leave quarantine when you have at least a month of quarantine data alongside your none data, the disposition comparison shows no legitimate stream newly quarantined, and the reason elements are not dominated by receivers overriding you.

Do not leave quarantine at all if your domain matches the exception in Section 7.4. That one has its own section below, because it is normative and it is routinely ignored.

The Ramp You Were Taught No Longer Exists

Nearly every DMARC rollout guide written before mid-2026 has the same middle chapter. Move to quarantine at pct=10. Watch. Go to pct=25, then 50, then 100. Repeat at reject.

That tag is gone.

RFC 9989's Appendix A.6 is titled Removal of the "pct" Tag, and Appendix C.5.2 lists pct among the tags removed from the specification. The IANA DMARC Tag Registry now carries pct as historic, referencing only RFC 7489. That is the same status it gives ri and rf, which fell out because reporting moved into RFC 9990 and RFC 9991. The active tags all reference RFC 9989 instead.

Nothing breaks in your zone. RFC 9989 Section 4.7 requires unknown tags to be ignored, so a 2015-era record carrying pct=50 still parses cleanly. The tag is ignored, not invalid. What it no longer does is anything: a conforming implementation is not required to sample your mail at fifty percent because you asked it to.

The scale of the stranded advice is worth stating plainly, and without mockery of the people who wrote it. The NCSC's published guidance, as observed on 1 August 2026, still gives this worked example: An example record – applying a DMARC quarantine policy to 50% of your email - with these modifications applied looks like this: `v=DMARC1;p=quarantine;pct=50;rua=mailto:[[email protected]]`. That page is dated 7 October 2019 and it was correct when it was written; it describes a mechanism the specification has since withdrawn. Vendor material has less excuse and less lag: a rollout roadmap published on 14 April 2026, one month before RFC 9989 appeared, advises readers that Rather than switching directly to p=quarantine for 100% of traffic, use the pct tag to ramp gradually. If your internal runbook says something similar, it is describing a tag that current DMARC does not define.

What Replaced It

Three mechanisms now do the work percentage ramping was doing, and none of them is a sampling dial.

Quarantine is the intermediate rung. It always was; the percentages made it look as though there were more rungs than there are. Section 7.4's staging instruction has exactly two stages before reject.

sp= stages by name rather than by proportion. This is the safety net most rollouts need, and the reason is in Section 4.7: If both the "sp" tag is absent and the "np" tag is either absent or not applicable, the policy specified by the "p" tag MUST be applied for subdomains. Move p to reject with no sp tag and every subdomain moves with it, including the ones a team you have never met is sending from. Publishing p=reject; sp=quarantine enforces the organizational domain while the subdomain inventory catches up. np follows the same fallback chain for names that do not exist: If the "np" tag is absent, the policy specified by the "sp" tag (if the "sp" tag is present) or the policy specified by the "p" tag (if the "sp" tag is not present) MUST be applied for non-existent subdomains.

t= declares that you are testing. RFC 9989 defines it as DMARC policy test mode (plain-text; OPTIONAL; default is "n"). For the Author Domain to which the DMARC Policy Record applies, the "t" tag serves as a signal to the actor performing DMARC validation checks as to whether or not the Domain Owner wishes the Domain Owner Assessment Policy declared in the "p", "sp", and/or "np" tags to actually be applied. Under t=y, the domain owner is currently testing its specified DMARC assessment policy and has an expectation that the policy applied to any failing messages will be one level below the specified policy.

t=y is not a drop-in replacement for pct=50 and should not be sold as one. pct asked for half your mail to be treated one way and half another. t=y tells the entire receiver population that you are rehearsing, and it is honoured at each receiver's discretion. You can at least see it land: the policy_published block in an aggregate report carries a testing element, and policy_test_mode is one of the five override reasons a receiver can report, alongside local_policy, mailing_list, trusted_forwarder and other.

Three policy values, two enforcement stages, and no percentage in between. Under RFC 9989 the staging levers are the policy itself, sp for subdomains, and t for declared test mode.

Everything else in a staged rollout is evidence: which senders appear in your reports, and whether each one produces an aligned pass.

What Actually Breaks

Enforcement does not fail all at once. It fails one mail stream at a time, in a fairly predictable order, and the IETF catalogued the whole category ten years ago in RFC 7960: DMARC enables potentially disruptive interoperability issues when messages do not flow directly from the author's administrative domain to the final Recipients.

Forwarding

A user sets up a redirect from an old address to a current one. The forwarding server relays your message unchanged, and RFC 7960 describes the result: If the RFC5321.MailFrom is present and the forwarder maintains the original RFC5321.MailFrom, SPF validation will fail unless the forwarder is an authorized part of the originator's email sending infrastructure. The measurement literature agrees; Liu et al. found that forwarded email often break SPF validation because the MAIL FROM domain typically does not list the forwarding server's IP address in its SPF allowlist.

The DKIM signature, meanwhile, generally survives, because it signs the message rather than the connection. RFC 7960 states the consequence directly: In both cases, SPF cannot yield relevant Authenticated Identifiers, and DKIM must be relied upon to produce results that are relevant to DMARC. Which is why aligned DKIM on every stream is the real prerequisite for reject, and why an SPF-only rollout will start losing forwarded mail on the day it enforces.

Mailing Lists

Lists are harder, because they modify the thing DKIM signed. Prepending a tag to the Subject, appending a footer, stripping a MIME part, converting to plain text: RFC 7960's assessment of these is one sentence long. Any such modifications would invalidate a DKIM signature. SPF is already gone at that point, since the list sends from its own infrastructure. Both identifiers fail, and under reject the list traffic disappears.

The standard mitigation lives on the list's side, not yours: Many ReSender issues can be avoided by using an RFC5322.From header field under the ReSender's control, instead of the initial RFC5322.From. That is why your posts to a well-run list arrive with a rewritten From: address. It works, and it costs the author their identity in the header.

ARC, Precisely

RFC 8617 defines the Authenticated Received Chain, which provides an authenticated 'chain of custody' for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling. A receiver holding a message that fails DMARC can look at a valid ARC chain and see that the message authenticated correctly before the list touched it.

What ARC does not do is oblige anyone. RFC 8617 is Experimental, published July 2019, not Standards Track. Whether a receiver trusts a given ARC sealer, and whether it lets that trust override your published policy, is a local decision at that receiver. ARC improves the odds for indirect flows. It does not guarantee that your mailing-list mail survives a reject policy, and any plan that treats it as a guarantee has an unmanaged dependency in it.

The Senders Nobody Enumerated

This is what the none stage is for. The invoicing platform, the applicant-tracking system, the marketing tool a department bought on a card, the monitoring appliance that emails alerts from a hostname in your domain. RFC 9989's phrasing is generous about how this happens: a domain owner can overlook a server here or be unaware of a third-party sending agreement there. They surface in identifiers/header_from paired with a source_ip nobody recognises, and each one is either fixed or knowingly abandoned before you enforce.

Two Quieter Failure Modes

An SPF record that needs more than ten DNS lookups to evaluate returns permerror, which shows up as an SPF failure in your reports for reasons that have nothing to do with the sender being unauthorised; our SPF record analysis post covers that limit in full.

The other is key rotation. If a signing key is replaced before the corresponding selector record is published, or the old public key is withdrawn while mail signed with it is still in flight, DKIM verification fails for a window nobody is watching. Under none, that window is invisible. Under reject, it is an outage. The selector field in auth_results/dkim is where it shows up, which is a good reason to read that field even when everything is passing. Selector mechanics are covered in our DKIM explainer.

Subdomains

Covered above, and worth repeating in the failure list because it is the one that surprises people after the change window closes: absent an sp tag, your p value applies to every subdomain. Section 4.10.1 spells out the resolution order — If the DMARC Policy Record to be applied is that of the Author Domain, then the Domain Owner Assessment Policy is taken from the "p" tag of the record, while a record found further up the tree reaches a subdomain through sp if the subdomain exists and np if it does not. One related trap: a policy record published deeper than eight labels is never discovered, so RFC 9989 Section 5.1.8 requires such domains to publish a record at their own location in the namespace.

p=reject Is Not Universally Correct

Most rollout content treats reject as the finish line and quarantine as a rest stop. The current standard does not, and the exception is normative:

It is therefore critical that domains that host users who might post messages to mailing lists SHOULD NOT publish Domain Owner Assessment Policies of "p=reject".

The reasoning sits in the same section: In the case of domains that have general users who send routine email, those that publish a Domain Owner Assessment Policy of "p=reject" are likely to create significant interoperability issues. In particular, if users in such domains post messages to mailing lists on the Internet, those messages can cause significant operational problems for the mailing lists and for the subscribers to those lists. The damage lands on other people's infrastructure. That is exactly why the standard makes it a SHOULD NOT rather than a matter of taste.

The practical division is by what the domain is for. A transactional domain that only ever emits receipts and notifications from systems you control belongs at reject. A domain full of humans who join industry mailing lists and post to community forums has a legitimate permanent home at quarantine. Splitting the two, so that notifications.example.com enforces hard while the people stay somewhere softer, is a better answer than either extreme.

There is a second reason not to treat reject as a switch you throw. Publishing it buys a request, not an outcome:

Mail Receivers MAY choose to accept email that fails the DMARC validation check even if the published Domain Owner Assessment Policy is "reject". In particular, because of the considerations discussed in [RFC7960] and in Section 7.4 of this document, it is important that Mail Receivers SHOULD NOT reject messages solely because of a published policy of "reject" but that they apply other knowledge and analysis to avoid situations such as rejection of legitimate messages sent in ways that DMARC cannot describe, harm to the operation of mailing lists, and similar.

You find out when it happens, if the receiver is well behaved: When Mail Receivers deviate from a published Domain Owner Assessment Policy during message processing, they SHOULD make available the fact of and reason for the deviation to the Domain Owner via feedback reporting, specifically using the "PolicyOverride" feature of the aggregate report defined in [RFC9990]. Those reason elements are the most under-read part of an aggregate report. A run of mailing_list overrides is a receiver telling you, in a machine-readable field, that it declined to do what you asked, and why.

If enforcement goes badly, going back is a legitimate move rather than an admission of defeat. NCSC's guidance says so plainly: If you experience any problems, you can revert to the DMARC policy of p=quarantine until you are ready to progress again.

The Honest Version of "We Have DMARC"

Nobody's domain is wide open because it publishes p=none. Receivers were filtering mail before DMARC existed and they still are. A none policy is not a hole in a wall. It is a survey instrument, and it is doing the job it was designed for.

The failure is one of bookkeeping. A domain publishes a record that says nothing, files the fact of publication as an achievement, and stops reading the reports the record was published to collect. Six months later the answer to "which of our senders authenticate" is the same as it was on day one, because nobody looked.

The work has not changed since 2015. Find every sender. Make at least one identifier align on each of them, preferably DKIM. Read the reports until nothing in them is a surprise. Then say what you mean, in the tag that carries meaning, and keep reading the reports afterwards.

Four minutes gets you the record. The rest takes as long as your mail takes to explain itself.

Sources

1. RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Sections 4.4, 4.7, 4.10.1, 5.1, 5.3.5, 5.4 and 7.4 — RFC Editor / IETF, 20 May 2026. https://www.rfc-editor.org/rfc/rfc9989.txt
2. RFC 9989, HTML rendering (Appendix A.6, "Removal of the 'pct' Tag", and Appendix C.5.2) — RFC Editor / IETF, 20 May 2026. https://www.rfc-editor.org/rfc/rfc9989.html
3. RFC 9990: DMARC Aggregate Reporting, Section 3.1.1.4 — RFC Editor / IETF, 20 May 2026. https://www.rfc-editor.org/rfc/rfc9990.txt
4. RFC 9990, HTML rendering (Appendix A, XSD report schema) — RFC Editor / IETF, 20 May 2026. https://www.rfc-editor.org/rfc/rfc9990.html
5. RFC 9991: DMARC Failure Reporting — RFC Editor / IETF, 20 May 2026. https://www.rfc-editor.org/rfc/rfc9991
6. RFC 7960: Interoperability Issues between DMARC and Indirect Email Flows, Sections 2.2, 3.2.3 and 4.1.3.1 — RFC Editor / IETF, September 2016. https://www.rfc-editor.org/rfc/rfc7960.txt
7. Information on RFC 8617 (The Authenticated Received Chain Protocol, Experimental) — RFC Editor / IETF, July 2019. https://www.rfc-editor.org/info/rfc8617
8. Information on RFC 7489 (obsoleted by RFC 9989) — RFC Editor, March 2015. https://www.rfc-editor.org/info/rfc7489
9. RFC 7208: Sender Policy Framework (SPF), Section 4.6.4 — RFC Editor / IETF, April 2014. https://www.rfc-editor.org/rfc/rfc7208.txt
10. DMARC Parameters — DMARC Tag Registry — IANA. https://www.iana.org/assignments/dmarc-parameters/dmarc-parameters.xhtml
11. Email sender guidelines — Requirements for sending 5,000 or more messages per day — Google (Google Workspace Admin Help). https://support.google.com/a/answer/81126
12. Sender Best Practices — Yahoo Inc. https://senders.yahooinc.com/best-practices/
13. Fix NDR error "550 5.7.515" in Outlook.com — Microsoft. https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com
14. Implement a DMARC policy of 'none' — National Cyber Security Centre (UK), 7 October 2019. https://www.ncsc.gov.uk/collection/email-security-and-anti-spoofing/implement-a-dmarc-policy-of-none
15. 4. Mark spoof emails as spam — National Cyber Security Centre (UK), 7 October 2019. https://www.ncsc.gov.uk/collection/email-security-and-anti-spoofing/mark-spoof-emails-as-spam
16. 5. Reject spoof emails — National Cyber Security Centre (UK), 7 October 2019. https://www.ncsc.gov.uk/collection/email-security-and-anti-spoofing/reject-spoof-emails
17. Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy — Liu, Akiwate, Jonker, Mirian, Ho, Voelker, Savage; 8th IEEE European Symposium on Security and Privacy, 14 February 2023. https://arxiv.org/abs/2302.07287
18. Forward Pass, HTML rendering — arXiv / ar5iv, 14 February 2023. https://ar5iv.labs.arxiv.org/html/2302.07287
19. Study on Domain Name System (DNS) Abuse: Technical Report — Bayer, Nosyk, Hureau, Fernandez, Paulovics, Duda, Korczyński for the European Commission (VIGIE 2020/0653), December 2022. https://arxiv.org/abs/2212.08879
20. DMARC Enforcement Timeline: Realistic Roadmap from p=none to p=reject (vendor marketing, cited as an example of pre-RFC 9989 advice) — DMARC Report (DuoCircle LLC), 14 April 2026. https://dmarcreport.com/blog/dmarc-enforcement-timeline-none-to-reject-roadmap/

Share this article