What is a domain's DMARC policy?

When the published policy changes

Read the visible From domain before deciding which DMARC policy applies. A message from alerts.yourdomain.com can have a more specific DMARC record at _dmarc.alerts.yourdomain.com. If there is no usable record at that name, DMARC discovery can use the organizational domain's record, as specified in RFC 9989 policy discovery rules.

The sp tag can request a separate policy for subdomains. When a record has no sp tag, the organizational domain's p value normally supplies the requested policy for subdomains. A subdomain with its own usable DMARC record can change the result.

Use this decision rule:

• If the visible From domain has its own usable DMARC record, read that record.
• If it does not, identify the organizational domain and read its p value.
• If the organizational-domain record contains sp, use that requested policy for the subdomain.
• If sp is absent, use the record's p value as the requested subdomain policy.

Worked DMARC policy example

The following is illustrative only. Publish the report destination approved for your own domain and reporting service.

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

This record has three relevant parts:

• v=DMARC1 identifies the record as a DMARC policy record.
• p=quarantine requests suspicious treatment for messages that fail DMARC.
• rua=mailto:dmarc-reports@yourdomain.com requests aggregate reports at that destination.

Host: _dmarc.yourdomain.com
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Do not copy another organization's report address, selector, or DNS value into your record. Use values generated and approved for your own domain.

A policy record cannot identify every legitimate sender that uses the domain. Before moving toward quarantine or reject, validate important production paths with delivered-message authentication results and aggregate-report data. The narrower choice between enforcement requests is covered in DMARC reject vs. quarantine.

Check the policy with the evidence you have

If you have a domain name, inspect its public DMARC TXT record first. Query _dmarc.yourdomain.com through authoritative DNS and at least one public resolver, then compare the answer with the intended record in your DNS change history or DNS-as-code source.

A public lookup is the DNS layer of validation. It does not show whether an application is signing mail, whether SPF or DKIM aligns on a live message, or how a receiver handled that message. For those questions, inspect a delivered message's authentication results, then review DMARC aggregate reports after data accumulates.

Check the published DMARC record

If the record says p=none, do not assume enforcement is active. If it says p=quarantine or p=reject, do not assume every sender is ready. The record is the domain owner's request. Real message headers and aggregate reports show whether the production sending paths meet DMARC.

Keep policy changes tied to sender evidence

A one-time DNS lookup cannot reveal which production sources later fail alignment, whether DNS drifts, or whether a new sender begins using the domain. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence indicates readiness, while a human reviews the evidence and applies the DNS change.

Start with Palisade

Palisade does not autonomously change the DMARC policy, prove every future message will authenticate, or determine a receiver's private delivery decision.