DMARC RFC Updates: Production Impact for Operators

DMARC is now covered by three current RFCs rather than the earlier single policy-and-reporting document. For operators, the important result is not a mass DNS change. It is a review of policy discovery, record guidance, report processing, privacy controls, and customer wording.

Standards status was checked against the RFC Editor on 14 July 2026:

RFC 9989 obsoletes RFC 7489 and RFC 9091. Existing DMARC records still use v=DMARC1.

Existing records do not need a new version tag

The version value remains:

v=DMARC1

Do not publish DMARC2 or change a valid record merely because the policy specification has a new RFC number.

The first operational step is review:

• Is the record discoverable at the expected policy domain?
• Do its tags reflect the domain owner’s intended policy?
• Are report destinations still authorised and monitored?
• Does the operator understand subdomain and non-existent-domain use?
• Are tools parsing current and legacy aggregate data safely?

DNS Tree Walk changes policy discovery

Current DMARC policy discovery uses DNS Tree Walk to find the applicable policy domain. This matters for multi-label subdomains and boundaries where administrative control changes.

An operator should distinguish:

• the Author Domain shown in the message’s From field;
• the DMARC Policy Domain where the applicable record was found;
• the Organisational Domain determined by the current discovery process; and
• a Public Suffix Domain managed by a public-suffix operator.

The walk is bounded by the specification. It is not an invitation to search an unlimited DNS hierarchy.

Why inherited policy matters

A subdomain may not have its own DMARC record. In that case, discovery can lead to a policy higher in the hierarchy. A checker or management platform should show where the effective policy was found rather than presenting it as if it were published directly on the tested subdomain.

Before changing an organisational-domain policy, inventory subdomains that send mail or have separate administrative ownership.

Advanced policy tags require deliberate use

The current policy specification includes options that ordinary domains should not enable by default.

np — non-existent subdomain policy

np expresses the requested policy for mail using a non-existent subdomain. It can help distinguish that case from existing subdomains, but it requires confidence in DNS status and subdomain use.

Values follow the policy set: none, quarantine, or reject.

t — policy test mode

t=y signals that an enforcing policy is being tested. It should be visible in assessments and customer explanations. Do not describe a domain as fully enforcing without acknowledging the test-mode signal.

psd — public-suffix-domain flag

psd is relevant to public-suffix handling and administrative boundaries. Ordinary customer domains should leave it unset unless a qualified operator has a specific, evidence-backed reason to publish it.

These tags belong in an advanced-options area, with helper text and safe defaults. They should not clutter the ordinary monitoring-to-enforcement workflow.

Historic pct guidance needs review

Older DMARC deployments used pct for percentage-based handling. Operators will still encounter the tag in legacy records and older report data.

Do not rely on it as the default control for a new rollout. Use evidence-led changes between none, quarantine, and reject, or controlled domain/subdomain scope, with a clear rollback process.

When a legacy record contains pct:

1. confirm what the domain owner believes it does;
2. check how current tools display it;
3. review the record against RFC 9989; and
4. plan a controlled change rather than silently deleting it.

Aggregate-report processing must tolerate real-world variation

RFC 9990 defines current aggregate reporting. A report consumer should:

• validate the report structure without discarding useful data unnecessarily;
• preserve unknown fields for investigation where safe;
• handle duplicate or replayed reports idempotently;
• distinguish policy-domain data from the tested Author Domain;
• enforce size and resource limits;
• verify external reporting destinations; and
• treat source-identification output as evidence, not certainty.

Aggregate reports are periodic summaries. They do not reproduce messages or identify the individual behind a source IP.

External reporting verification

When the rua destination belongs to a different domain, receivers can require the destination domain to publish authorisation for the reporting relationship. A valid DMARC record can therefore produce no reports at a particular external destination if the verification record is missing or wrong.

Read Why Your DMARC Reports Are Empty for a diagnostic workflow.

Failure reports need privacy-first handling

RFC 9991 covers failure reports, commonly associated with ruf. These reports can contain message-level or business-sensitive information.

Collect them only when there is:

• a defined diagnostic purpose;
• an authorised destination;
• data-minimisation and access controls;
• an approved retention and deletion process; and
• a clear understanding of which receivers actually provide them.

Do not enable failure reporting across a customer portfolio simply because the tag exists.

Receiver discretion remains important

A DMARC policy is a domain-owner handling request. A receiver can apply local policy. A DMARC pass also does not guarantee that delivery is safe or desirable; it validates authorised use of the From domain, not message content or intent.

Customer copy should therefore avoid:

• “DMARC guarantees rejection”;
• “DMARC proves the message is safe”;
• “reject stops all phishing”; or
• “100% compliance” based on one metric.

Use precise language about exact-domain authorisation, observed authentication results, and requested handling.

Operator review checklist

Policy and DNS

• Confirm v=DMARC1 and one discoverable record at the applicable policy domain.
• Review policy discovery for subdomains.
• Inventory subdomain and non-existent-domain use before sp or np changes.
• Keep psd unset for ordinary domains unless specifically justified.
• Make test mode visible if t=y is used.

Reporting

• Verify aggregate-report destinations and external authorisation.
• Test current report parsing with fixtures and malformed input.
• Preserve safe diagnostic evidence when a report cannot be fully processed.
• Do not assume every receiver reports or follows the same schedule.

Privacy

• Treat aggregate source data as operational evidence with controlled access.
• Treat failure reports as more sensitive.
• Avoid collecting message-level data without a defined need and approved controls.

Customer communication

• Explain receiver discretion.
• Separate authentication results from delivery outcomes.
• Avoid broad phishing, fraud, deliverability, or compliance guarantees.
• Update internal templates before changing DNS in bulk.

Frequently asked questions

Do I need to change every DMARC record?

No. Review existing records and operational processes. Change DNS only where the current evidence and intended policy justify it.

Has DMARC2 replaced DMARC1?

No. Existing and new records continue to use v=DMARC1.

Should ordinary businesses publish np, t, or psd?

Not by default. np and t need a specific rollout or subdomain purpose. psd is specialised and normally left unset on ordinary customer domains.

Are failure reports required for managed DMARC?

No. Aggregate reports are the main operational evidence source. Failure reports are optional, less consistently available, and more privacy-sensitive.

Does the RFC update prove that a product is compliant with the standard?

No. A product or operator needs implementation evidence and testing. An article or version claim alone is not proof.

Use the free DMARC checker to review a public record, then read the policy-progression guide before changing production policy.