A valid example is not your policy: copy the understanding, not the text
A DMARC record can be syntactically correct and still be wrong for your organisation. The reporting address may belong to somebody else, strict alignment may exclude a real platform, or reject policy may expose a hidden invoice route. Copying the text hides those decisions.
The current specification defines a DMARC policy record as a DNS TXT record whose tag-value list begins with v=DMARC1. It is normally queried at a name formed by adding _dmarc before the domain. RFC 9989 defines record discovery, format and registered tags.
Use examples as reading exercises. For each tag, write the owner, purpose, expected evidence and rollback consequence. Publish only after replacing every example domain and mailbox, confirming the exact DNS name, and checking existing records.
If you have ever looked at a DMARC validator and seen “syntax OK” next to a record you do not fully understand, this is the page for you. A record can be perfectly formatted and still wrong for your business: the reporting mailbox may belong to someone else, or a strict tag may exclude the platform that sends your quotes. Understanding the decision each tag represents is what prevents a seemingly simple setup from turning into lost mail.
Read the minimum record before adding options
v=DMARC1; p=none contains the required version and policy tags. Version must appear first. The policy says what handling the domain owner requests for messages that fail DMARC. With none, no special handling is requested; this does not make failing mail pass.
v=DMARC1; p=reject is equally short but operationally different. It requests rejection of failures. Without a sender inventory and route evidence, its simplicity is deceptive. DNS accepts text without knowing whether payroll, contact forms or outsourced support can authenticate.
Do not add punctuation copied from explanatory prose, quotation marks supplied by a zone-file display or a second DMARC record. Your DNS interface may add the domain automatically. Preview the resulting fully qualified name and query it publicly after saving.
The shortest valid record: v=DMARC1; p=none: is also the safest place to start for many businesses, because it asks receivers to do nothing to failing mail while you gather evidence. It is a natural first stop on the path described in moving from p=none towards reject, and it introduces no enforcement risk on day one.
The reporting tag creates an ongoing operation
v=DMARC1; p=none; rua=mailto:dmarc@example.com requests aggregate reports at the listed mailbox. Replace both the domain and mailbox. Confirm the address can receive automated compressed reports, has restricted access and has an owner who can interpret them.
Aggregate feedback is intended to show use of the Author Domain, authentication outcomes and policy evaluation, but receivers are not obliged to send it. RFC 9989 describes aggregate reporting and its limitations. No reports can mean no observed traffic, no participating receiver, a broken destination or an authorisation problem. It is not proof that nobody uses the domain.
Multiple URIs increase delivery and governance work. An external destination can require a confirming DNS record controlled by that destination. Do not direct reports to a free mailbox, former supplier or copied example address. Record retention and deletion rules before collection starts.
aspf and adkim change which domains count as aligned: know the difference
adkim=r and aspf=r select relaxed DKIM and SPF alignment. Relaxed is the default when these tags are omitted. Using s selects strict mode, where the authenticated domain must exactly equal the Author Domain.
Example: v=DMARC1; p=none; adkim=s; aspf=s; rua=mailto:dmarc@example.com. This is valid-looking text, not a recommendation. It can make mail.example.com fail alignment with From example.com even when both belong to the same organisation.
RFC 9989 reports that nearly all domain owners have found relaxed alignment sufficient. The alignment section explains relaxed and strict comparison. Before selecting strict mode, test every route and state the abuse case it addresses. A vague preference for maximum strictness is not evidence.
Subdomain policy needs an inheritance map
The sp= tag can express policy for subdomains when the record applies at an organisational domain. Omitting it generally leaves subdomains under the main policy. An explicit DMARC record at a subdomain can change discovery and handling, so inventory the DNS tree rather than reading one root record in isolation.
A record such as v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com requests reject for the main policy scope while requesting none for subdomains. That may support a planned migration boundary, or it may leave forgotten subdomains less protected. The record cannot tell you which.
Draw the organisational domain, active From subdomains and explicit _dmarc names. Include delegated DNS zones. Stop if you cannot establish who controls a child zone or whether it sends mail.
Subdomain records are where businesses that run several services under one parent domain commonly get caught out. Drawing the DNS tree: your organisational domain, active subdomains and any delegated zones: before choosing an sp= value is the same discipline as reviewing a multi-domain sending set-up, and it prevents a rejecting policy from surprising an unmanaged child zone.
When several domains or subdomains carry different mail streams, the domain and subdomain planning guide helps decide where separate policies are justified.
Current records should not depend on removed behaviour
RFC 9989 removed the former pct tag. Do not copy a gradual-rollout example that relies on pct= to apply policy to a sample of failures. A receiver processing the current specification has no current DMARC percentage mechanism to follow.
Optional reporting and failure options can add complexity and privacy exposure. Per-message failure data may contain addresses, header details or message material. Do not add ruf or related formatting choices without confirming receiver support, a secure destination and a defined need.
Unknown tags are ignored under the protocol’s extensible format, which can make a typing error look harmless while silently removing your intended control. Validate tag names and values against current guidance, then query and parse the published answer independently.
Adapt the record on paper before opening DNS
- Name the policy domain. Write the exact
_dmarcowner and identify inherited subdomains. - Choose the handling preference. Tie
none,quarantineorrejectto observed route readiness and approved risk. - Choose reporting deliberately. Verify each mailbox, external authorisation, access rule and retention period.
- Leave alignment relaxed unless evidence supports strict mode. Record the affected identities before changing the default.
- Compare with live DNS. Preserve the old value, TTL and owner, and confirm there is not another DMARC record.
Have another administrator read the proposed tags aloud as decisions, not characters. If they cannot explain a tag’s effect, remove it or postpone publication until its purpose is clear.
Keep the record worksheet free of copied secrets and addresses
The useful artefact for this job is the tag worksheet: exact owner name, proposed value, reason for each tag, previous public answer, TTL, change owner and rollback. It may also contain a reporting mailbox and sample message domains, so keep it with the DNS change record rather than in an open chat. Use example domains in drafts and insert the real destination only in the controlled approval copy.
If a received header is needed to check alignment before choosing adkim or aspf, extract only From, Return-Path, DKIM domains, selectors and authentication results. The DNS reviewer does not need the body, subject or complete recipient address. A report address outside the policy domain should be recorded together with its external-authorisation owner and retention terms.
No DMARC tag requires a password, recovery code, API token or private DKIM key. Reject any copied template that includes someone else’s mailbox, and stop if you cannot identify who will receive the reports. The data owner should approve any evidence that contains customer or staff details before it leaves the restricted mail system.
Keeping this record worksheet tidy is not just good practice: it is what lets another administrator pick up where you left off. The tag worksheet belongs in your DNS change record rather than an open chat, and the full picture sits naturally alongside a plain-English DMARC overview for anyone new to the topic.
Read back the published record and test its consequences
After publication, query the full _dmarc owner name from the authoritative service and a public resolver. Save the complete TXT answer rather than a tool’s green badge. Check that there is one record, v=DMARC1 comes first, every intended tag appears once, the report URI is exact and the observed value matches the approved worksheet.
Then send authorised messages from the routes the tags can affect. Inspect their From, MAIL FROM, DKIM domains and receiver DMARC results. For sp=, include a real subdomain route and confirm any explicit subdomain record is handled as expected. For strict alignment, test the exact subdomain identities that would stop aligning. A syntax pass cannot reveal either operational consequence.
Attach the queries and received results to the tag worksheet with UTC times. Confirm the reporting mailbox receives expected aggregate data over an appropriate period. If a report destination, inherited policy or route result differs from the proposal, record the discrepancy and reopen the decision instead of editing the example in place.
Check the record again from a second public resolver after the TTL window. This does not replace the receiver test, but it can expose a split answer, stale delegation or provider interface that saved the value under the wrong owner name.
Do not publish a tag you cannot explain
Stop if DNS already contains another DMARC record, the interface would append the domain twice, the report mailbox is unowned, or a delegated child zone has not been checked. A record copied from older guidance that depends on pct= also needs to be redesigned before publication. Preserve the current answer and ask the DNS owner to resolve the ambiguity.
If an example with strict alignment or subdomain policy causes legitimate mail to fail, use the approved rollback and give the DMARC owner the worksheet, before-and-after queries and affected headers. Do not make a hurried second edit to several tags, nor add an unknown source to SPF to quiet the symptom.
The publication rule is deliberately narrow: every character in the proposed record must map to a current protocol meaning, an owner and observed route evidence. If it does not, leave the working record alone until the gap is closed.