DMARC enforcement: move from p=none to quarantine or reject in a controlled way

What an enforcement policy does — and does not do

A message passes DMARC if at least one checking path succeeds and aligns with the visible sender domain: SPF for the domain in the SMTP return path, or a valid DKIM signature with its signing domain d=. The DNS policy tells receivers how you, as the domain owner, view messages that fail this check. RFC 9989 uses enforcement when p=none no longer applies to an organisational domain and all of its subdomains. RFC 9989, sections 3.2.9 and 4.4

The definitions are in RFC 9989, sections 4.7, 5.4 and 7.4. The receiver always decides exactly what happens to a message under its own rules. It may also reject or filter out messages that pass DMARC.

An enforcement policy has clear limits:

• Lookalike domains and display names: DMARC covers only the exact domain in From. Your policy does not help against a similarly spelled domain, a different top-level domain or a misleading display name with an unrelated address. RFC 9989, sections 2.2 and 11.4 The sections on homograph attacks and email spoofing discuss these cases.
• Abuse of authorised paths: A compromised mailbox, an abused account at your sending service or overly broad SPF authorisation produces messages that pass DMARC. A pass means only that the domain’s use for this message appears authorised, not that it is harmless. RFC 9989, sections 1 and 11.1 See also Business Email Compromise.
• Subdomain takeovers: With relaxed alignment, someone controlling a subdomain’s SPF or DKIM records can obtain a DMARC pass for your organisational domain. RFC 9989, section 11.8 Read more under Echospoofing and SubdoMailing.
• Evidence: A published record does not prove that your messages are actually signed and aligned. A failure in a report does not prove an attack. This technical guide does not determine whether your measures meet organisational or legal requirements; the Email compliance chapter addresses that question.

Which target policy suits which domain

p=reject is not a mandatory goal for every domain. The appropriate permanent policy depends on who uses the domain to send mail.

Sources: RFC 9989, section 7.4 and Appendix C.6, RFC 7960, section 4.1.1.1, RFC 7505 on Null MX. The DMARC guide provides a complete example of a domain that neither sends nor receives mail.

Major mailbox providers’ requirements are not enforcement

Google, Yahoo and Microsoft require a DMARC policy for bulk sending to their consumer mailboxes — but the minimum is p=none, not quarantine or reject. The overview below reflects the provider pages read on 27 September 2026. Each applies only to the named service and may change.

Sources: Google Email sender guidelines and Email sender guidelines FAQ; Yahoo Sender Requirements & Recommendations and FAQs; Microsoft Outlook requirements for bulk senders and Error 550 5.7.515.

None of these pages requires an enforcement policy. Yahoo separately recommends one if your domain is being spoofed; Microsoft advises a gradual progression from none through quarantine to reject once legitimate sources align. If your volume is near a threshold, check the current provider page rather than relying on a number from an older guide.

Which identities must align

Before tightening a policy, you must know which domains every sending path actually uses. These identities originate at different points and appear in message headers and reports under their own names.

Sources: RFC 9989, sections 3.2.2–3.2.4, 4.4 and 5.3.1, RFC 9990, section 3.1.1, RFC 8601, sections 2.7.1 and 2.7.2.

The default is relaxed alignment: the domain being compared must belong to the same organisational domain as the From domain, for example bounces.example.com and example.com. Strict alignment (aspf=s or adkim=s) requires identical domains. RFC 9989 determines the organisational domain by searching DNS for DMARC records, not by taking the last two labels; some older receivers still rely on the Public Suffix List. According to RFC 9989, relaxed alignment is sufficient for almost all domain owners. In the corresponding checking path, strict alignment prevents a shared organisational domain alone from being enough for a pass. Both paths must be configured accordingly if you want to exclude this possibility. This does not prevent subdomain or account takeovers; each service must use exactly the From domain for the relevant path. RFC 9989, sections 3.2.10, 4.4, 4.10 and 11.8

Authenticated does not mean aligned. This abbreviated, invented header fragment illustrates a common situation with sending services:

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces.mailer.example.org;
  dkim=pass header.d=mailer.example.org header.s=s1;
  dmarc=fail header.from=example.com

SPF and DKIM pass, but both for the service provider’s domain mailer.example.org. Neither belongs to the visible sender address’s organisational domain example.com, so DMARC fails. The remedy is a service-supported custom return-path domain under example.com, or a DKIM signature with d=example.com or a subdomain of it. Evaluate only results added by your own trusted receiving system; the section on header findings explains how to identify them. RFC 8601, section 5

The path at a glance: decisions, not calendar weeks

RFC 9989 describes deployment as a sequence of decisions: set up a report destination, observe with p=none and rua, analyse reports, correct legitimate sending paths, and only then decide whether a stricter policy is appropriate. Gaps affecting legitimate sending must be fixed before an enforcement policy is introduced. Depending on sending patterns, the RFC says that many months of report analysis may be needed before you are confident that all your mail authenticates correctly. RFC 9989, sections 5.1.3–5.1.7

Fixed weekly schedules do not replace this assessment. RFC 9989 specifies concrete minimum periods only for domains whose users might participate in mailing lists and that want to publish p=reject despite its advice: at least one month with p=none first, then the same period with p=quarantine, comparing report data at each stage. RFC 9989, section 7.4

Phase 1: build a sender inventory and observe with p=none

First set up a reachable, managed report destination. Then publish p=none with rua and check that reports arrive and can be analysed. RFC 9989 identifies careful analysis of aggregate reports as essential to any successful deployment and recommends processing them automatically, with your own tools or a service. RFC 9989, sections 5.1.3 and 5.1.5

• Set up the report destination: a dedicated mailbox or a deliberately chosen service with defined access, rather than one individual’s personal mailbox.
• Save the current state: record the existing record, TTL, timestamp and responsible owner. Also check whether a parent policy applies.
• Assign responsibilities: who may change DNS, who reads reports and who is the contact for each sending service.

For an organisational domain without an existing policy, an observation record could look like this. The name and address are documentation examples; the line was not published. Some DNS interfaces expect only _dmarc in the name field and do not expect quotation marks as part of the value.

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

If the report destination is outside your organisational domain, the report recipient must confirm acceptance in DNS; otherwise, compliant report senders ignore that destination. The record belongs in the report recipient’s zone, not yours. For a policy at example.com and destination dmarc@reports.example.net, it looks schematically like this:

example.com._report._dmarc.reports.example.net.  IN  TXT  "v=DMARC1"

The domain from which the policy actually originates is decisive. RFC 9990, section 4; further details are in the DMARC guide.

The sender inventory

The inventory lists every system that sends messages with your domain in From, whether or not it already appears in reports. Reports show only what reporting receivers observed during a period; infrequent mailings are easily missed. Also ask business departments and review contracts: mailboxes, newsletters and marketing automation, CRM and sales, ticketing and helpdesk systems, invoicing and ERP mail, online shops and contact forms, appointment and calendar tools, applicant tracking, alerts and monitoring notifications, scanners and multifunction devices, forwarding rules, automatic replies and non-delivery messages.

This example is synthetic; each row is a sending path, not a provider. The third and fourth rows show typical gaps: the invoicing service authenticates only its own domain, while the contact form passes only through SPF. Before quarantine, every legitimate path needs at least one aligned pass. Before reject, it also needs a valid, aligned DKIM signature, because SPF routinely fails during forwarding. RFC 9989 recommends using both mechanisms anyway; full participation in DMARC requires aligned SPF and aligned DKIM. RFC 9989, sections 4.5, 5.1.1, 5.1.2, 7.4 and 8

Proceed to phase 2 when …

• every source in the reports has been matched to an inventory entry or classified as an indirect path or abuse,
• every legitimate path achieves at least one aligned pass, evidenced by reports and your own test message,
• all relevant sending cycles fell within the observation period or were checked separately — including infrequent ones such as year-end processes or seasonal campaigns,
• forwarders, mailing lists and intervening gateways are known and assessed,
• rollback, responsibilities and communication have been defined.

For legitimate sending paths, RFC 9989 requires authentication and alignment gaps to be fixed before an enforcement policy is introduced. RFC 9989, section 5.1.6 A high overall pass rate is not enough: an infrequent but important path can disappear in the percentage.

Analyse aggregate reports: classify sources, not just percentages

Aggregate reports under RFC 9990 summarise what a reporting receiver observed about messages using your domain during a period, both passes and failures. Receivers should report at least every 24 hours, but are not required to report. Each report concerns exactly one policy domain. RFC 9989, sections 1 and 5.3.8, RFC 9990, section 3.1

The field meanings are defined in RFC 9990, sections 3.1.1, 3.1.6 and 3.3. Analyse reports by source, not just by percentages:

RFC 9989 describes the same progression: fully successful checks confirm your practice; partially successful checks show where something breaks along the path; completely failed checks show unprotected sources or abuse. Overly broad authorisation can allow DMARC passes for messages you did not intend. RFC 9989, section 11.1 and Appendix B.5

Report data can be forged or deliberately malformed. Process compressed XML files with a tool that catches oversized or manipulated files, and treat unusual individual reports with caution. RFC 9990, sections 8.1 and 8.2

Monitoring is your operational responsibility

Reports arrive at the destination you specify in rua. Analyse them yourself or through a service; no particular external tool is required by the protocol. Decide who reads reports and how often, which changes trigger investigation — such as a new source with substantial volume or a falling aligned share for a known service — and how new sending services enter the inventory before launch. The report mailbox needs access rules suited to your organisational requirements. RFC 9989, sections 5.1.5 and 10.1 The Email Security Check does not receive or analyse reports and does not monitor your domain.

Request failure reports only for a clear purpose

Failure reports (ruf) describe individual failed messages and may contain headers or entire messages with personal data. Many receivers do not send them; Microsoft states that neither Microsoft 365 nor Outlook.com does. You do not need them to introduce a policy. If you still request them, first establish the purpose, recipients, access and retention. RFC 9991, sections 1 and 7, RFC 9989, section 10.2

Phase 2: p=quarantine — observe the effects deliberately

With p=quarantine, you consider DMARC failures suspicious. The receiver decides what that means in practice: a spam folder, administrative quarantine, tagging or some other treatment. Microsoft describes the Junk Email folder as the default in Microsoft 365 when the setting to honour the DMARC policy is enabled; this can be changed to quarantine. There is no guarantee that a legitimate message remains retrievable by its recipient. RFC 9989, section 4.7, Microsoft Learn

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

You do not need an additional sp=quarantine: without sp, p also applies to subdomains without their own record. Set sp only when subdomains should deliberately receive different treatment.

During this phase, pay particular attention to:

• report rows for your inventory sources showing quarantine treatment,
• reports of missing newsletters, invoices or invitations, helpdesk tickets and feedback from partners,
• non-delivery messages sent to your return-path addresses,
• infrequent sending cycles that did not occur during phase 1,
• your users’ messages distributed through mailing lists or forwarding.

If legitimate failures occur, correct the sending path first. If that cannot be done quickly and important messages are affected, roll back the policy as described under Rollback.

Test mode t=y: exact effect and limits

RFC 9989 introduces the t tag. With t=y, you indicate that you are testing your policy: DMARC evaluators should not apply the published policy, but may instead apply their own special rules, such as a mailing list rewriting From. Treatment one level below the published policy is expected. t=y does not affect report generation and has no effect on none. RFC 9989, section 4.7

t=y replaces the earlier practice with pct=0: some intermediaries and mailbox providers treated pct=0 as a signal to rewrite From. Comparing reports before and after such a change allowed an estimate of traffic passing through intermediaries that do not rewrite From. In practice, implementations applied pct values between 0 and 100 imprecisely, so the tag was removed. RFC 9989, Appendix A.6

A receiver implementing only the earlier RFC 7489 ignores unknown tags and does not recognise t. RFC 7489, section 6.3 DNS does not reveal how many receivers already evaluate t; this was not measured for this guide.

How to identify the effect: aggregate reports record the published value under policy_published/testing; different treatment due to test mode may appear with the reason policy_test_mode. In a message header, the receiver may indicate the applied policy as policy.dmarc. Both depend on the receiver actually recording them. RFC 9990, sections 3.1.1.5 and 3.1.6, RFC 9989, section 9.1

pct is historical. Receivers implementing RFC 9989 do not evaluate it; pct=10 does not limit the policy to ten per cent there. Under the earlier RFC 7489, pct specified the share of failures to which the policy should apply; remaining messages were to be treated as quarantine for a reject policy, and normally for a quarantine policy. Older implementations may still behave this way. Some provider help pages still describe pct stages, such as the Microsoft Learn DMARC page dated 3 July 2026. This is a documentation discrepancy, not a statement about receivers’ current behaviour. RFC 9989, Appendix C.5, RFC 7489, section 6.6.4

Phase 3: p=reject only for suitable domains

Under RFC 9989, anyone publishing p=reject must not rely solely on SPF and must apply valid DKIM signatures to their messages. For a signature to provide the DMARC pass when SPF fails after forwarding, its domain must align with the From domain. RFC 9989, sections 7.4 and 8

Domains whose users might send messages to mailing lists should not publish a reject policy; RFC 9989 expressly directs this advice at domains used for general-purpose email. Those still wishing to publish it should assess the effects using report data first — at least one month with p=none, followed by the same period with p=quarantine — and either prohibit users from using Internet mailing lists or warn that their participation may be affected. RFC 9989, section 7.4 and Appendix C.6

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

RFC 9989 also sets rules for receivers: they must not reject solely because of p=reject and, without further information, must handle failures as quarantine. At the same time, the RFC notes that messages forwarded by mailing lists without rewriting From are often rejected in practice. Providers document their own rules: Google says it generally applies the sender domain’s policy to DMARC failures; Yahoo describes rejecting messages without a matching DKIM signature or SPF alignment when p=reject is set; Microsoft 365 rejects such messages during the SMTP session when the setting to honour the DMARC policy is enabled. RFC 9989, section 7.4, Google FAQ, Yahoo FAQ, Microsoft Learn

Ready for reject when …

• remaining failures have been investigated for every legitimate sending path,
• representative sending cycles have been observed under quarantine without unexplained legitimate failures,
• every legitimate path carries a valid, aligned DKIM signature and does not pass through SPF alone,
• mailing lists and forwarding have been assessed and affected users informed,
• the effective subdomain policy has been checked,
• rollback is ready.

Technical guidance and organisational evidence

A technical policy alone does not demonstrate compliance with a guideline or fulfilment of legal duties. Email compliance distinguishes technical guidelines, organisational requirements and the evidential limits of a scan. Establish the required state applicable to your organisation separately from the interoperability decision described here.

Subdomains and non-existent names: sp, np and their own records

A policy at the organisational domain also applies to subdomains without their own record. Which value applies depends on whether the name exists:

• The organisational domain itself: p.
• An existing subdomain without its own record: sp; if sp is absent, p applies.
• A non-existent subdomain: np; if np is absent, sp applies, otherwise p. A name is non-existent if DNS returns NXDOMAIN for it. Any other existing record at that name is sufficient to establish existence.
• A subdomain with its own valid record: that record’s p.

Sources: RFC 9989, sections 4.7 and 4.10.1, and Appendix A.4. The following zone example is synthetic and was not published:

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

The table shows schematic results of policy discovery under RFC 9989, not measured receiver treatment. Further rules often overlooked for subdomains:

• A separate subtree with psd=n: If a subtree should have its own rules for its subdomains, its record can declare it a separate organisational domain with psd=n. This has a side effect: relaxed alignment between names below news.example.com and example.com no longer passes, because they belong to different organisational domains. RFC 9989, sections 4.10.2 and 5.1.8
• A record at the organisational domain: Publish a record there too, even if you plan policies only for individual subdomains. Otherwise, no DMARC policy applies to the main domain. RFC 9989, sections 5.1.4 and 8
• Very long names: Discovery queries at most eight names. For sender domains with more than eight labels, you must publish a record directly at that name. RFC 9989, sections 4.10 and 5.1.8
• Wildcard records: If a wildcard actually produces an answer for the queried name, the result is not NXDOMAIN; np then does not apply. A wildcard does not automatically cover every deeper name: existing names and closer subtrees affect its application. RFC 9989, Appendix A.4, RFC 4592, section 2.2.1
• Older receivers: Receivers implementing RFC 7489 determine the organisational domain using a Public Suffix List and may reach a different result. Explicit records for every sender domain in use avoid this difference. RFC 9989, Appendix C.3
• Orphaned or delegated subdomains: Remove unused DNS records and review delegations. With relaxed alignment, a taken-over subdomain can produce DMARC passes for your organisational domain; strict alignment limits this path, while explicit records define the intended policy for names in use. Neither replaces removing orphaned records or controlling delegated DNS zones. RFC 9989, section 11.8

A subdomain policy does not prevent abuse of an already authorised sending service.

Prepare rollback and safeguards

Plan rollback before tightening the policy. A DNS change does not take effect everywhere simultaneously: resolvers may cache an answer until its TTL expires. If you lower the TTL before a planned change, you must first wait out the previous TTL so normal caches can expire the old answer. TTL controls normal cache use but does not promise a worldwide update; a TTL of 300 seconds is therefore not a worldwide five-minute guarantee. A newly created record can also remain invisible for a while if resolvers have cached its previous absence. RFC 1035, section 3.2.1, RFC 2181, section 8, RFC 2308, section 5

The source of the effective policy is decisive: p=none at the main domain does not roll back an explicit sp=reject, np=reject or a subdomain’s own p=reject record. Identify and change each affected value.

Further safeguards:

• Document every change with the old and new records, TTL, timestamp and responsible owners.
• Do not skip a stage while reports are missing or unclear.
• Do not add unknown IP addresses to SPF indiscriminately just to make failures disappear. You may be authorising other senders. RFC 9989 says that if an overly broad sender must remain in SPF, you can exclude it from DMARC evaluation with the qualifier ?. RFC 9989, section 11.1

Find and fix typical failures

Start from a specific message or report row. Compare the identities and establish whether authentication or alignment is missing.

Sources: RFC 7960, sections 2.1.2, 2.2, 2.3 and 4.1, RFC 7208, section 4.6.4 and Appendix D, RFC 9989, sections 4.4.1, 4.10, 7.1 and 7.4, RFC 9990, section 4, Yahoo FAQ. Google also recommends DKIM for forwarding to Gmail, because forwarded messages often fail SPF. Google: Forwarding to Gmail

ARC: a receiver’s trust decision

ARC lets forwarders and list servers pass on signed authentication results they obtained. The receiver decides under its local policy whether to use those claims; ARC is neither a trust framework nor a repair for broken signatures. RFC 8617 is Experimental. RFC 9989 notes that such mechanisms for lists that do not rewrite From had not achieved widespread adoption by its publication. Some receiving systems allow trusted ARC seals to be configured, such as “trusted ARC sealers” in Microsoft 365; Yahoo recommends that forwarders use ARC. As a sender, you cannot force other receivers to evaluate it. RFC 8617, sections 7.2.1 and 9.3, and Appendix A.2, RFC 9989, section 7.4 Read more in ARC and email gateways.

Synthetic planning example: separate the mailbox domain from sending subdomains

The following example is invented. It describes neither a customer domain nor a measured result; its periods are assumptions for a monthly invoicing cycle.

Starting point: Employees use individual mailboxes under example.com, and some participate in professional mailing lists. A newsletter service, an invoicing provider and the website’s contact form also send using this domain. The goal: quarantine as the permanent policy for the mailbox domain, and reject for dedicated sending subdomains.

1. Observe: example.com publishes p=none with rua. Reports and enquiries to business departments build the inventory. Findings in the model: the invoicing service authenticates only its own domain, the contact form passes only through SPF, and a multifunction device remains unresolved. At least two month-end cycles are observed.
2. Correct: Invoice sending moves to rechnung.example.com; the service signs with d=rechnung.example.com and uses a custom return-path domain below it. Newsletters use news.example.com with their own signature. The contact form signs with DKIM, and the device sends through an authenticated submission service.
3. Quarantine for the mailbox domain: First p=quarantine; t=y, then p=quarantine, supplemented with np=reject. No unexplained legitimate failures occur over another month-end cycle. Because of the mailing list users, quarantine remains the permanent policy.
4. Rejection for the sending subdomains: Once reports and your own test messages show aligned DKIM signatures for both services, news.example.com and rechnung.example.com receive their own records with p=reject.
5. Operation: Reports are reviewed weekly during the transition, then at the agreed frequency. New services enter the inventory before launch.

The model’s final state, neither published nor tested in practice:

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

Even in this final state, not every rejected message is an attack, and the configuration protects against neither similarly spelled domains nor compromised accounts.

What the Email Security Check shows — and does not show

The Email Security Check reads publicly available DNS data as a snapshot. For DMARC, it shows:

• the policy found for the entered name, including discovery of a parent policy under RFC 9989 and selection of sp or np; if the name’s existence is unresolved, the selection remains open,
• an enabled test mode under RFC 9989: p=reject; t=y appears as requested quarantine, and p=quarantine; t=y as none,
• any historical pct as a hint with no effect on the assessment,
• published rua destinations and whether DNS contains the authorisation record required by RFC 9990 for an external destination,
• as an unweighted hint, whether DKIM selector names matching known SPF provider targets were found in DNS.

It does not check message signatures, SPF and DKIM results of real messages, alignment, treatment by receivers, report receipt or contents, or the completeness of your sending paths. The check does not monitor your domain or report changes.

The check treats p=none as a valid observation policy, not a failed mechanism; it derives no fixed deadline for changing it. The fact that reject receives more points than quarantine in the product’s weighting is not a recommendation to set every domain to reject. If unambiguous DNS data places a domain in the “no sending” profile — Null MX or an absent MX together with v=spf1 -all, with no additional SPF record — the check assesses a separate, smaller hardening scope. This classification does not prove that no mail is actually sent. The assessed scope is SPF -all, a reject policy without test mode at the entered name, and Null MX. A parent policy is not used in this case.

The domain check described here does not include message analysis. The What the check examines page defines the offered scope.

Provider instructions and next chapters

Previous chapter: DMARC: alignment, policy and reports. Next chapter: MTA-STS and TLS-RPT. Related topics: SPF, DKIM, ARC and email gateways, BIMI (participating providers require an enforcement DMARC policy among other things, but this does not guarantee logo display), Interpreting header findings and Email compliance.