A DMARC record is a DNS TXT record published at the applicable _dmarc name. It states the domain owner's policy and can request authentication feedback. Creating one requires an intended policy, a working DNS publishing path and a way to verify what happens to real mail.
This guide follows the setup from preparation to acceptance. It uses a new monitored deployment as its example. If the domain already has a stronger approved policy, review that existing state before making changes. The example is a teaching record, not an instruction to replace every domain's configuration.
Establish how the domain is used
Before approving a policy, ask whether the domain sends employee mail, application notifications, campaigns, or no legitimate mail at all. Include outsourced services and periodic flows. A domain's purpose determines what the team needs to discover and test.
The first useful deliverable is an owner and a service list, not an enforcement percentage. If the business already uses a restrictive policy, ask what evidence justifies changing it. A beginner's monitoring example should not automatically replace an operating control.
Assign someone to receive and review reports. A configuration that requests feedback nobody collects leaves the business without the evidence the deployment was meant to create.
Check sending identities and DNS access
Protocol references: RFC 9989 §4.4.1, RFC 9989 §4.4.2, RFC 9989 §5.3.5, RFC 9989 §8. Operational checklists and decisions below are editorial guidance.
Identify the visible sending domain, its authoritative DNS provider, the person permitted to edit the zone and the approved recovery process. Save the current record set.
For each legitimate sending route, establish the SPF-evaluated envelope identity and DKIM signing identity. DMARC needs a passing aligned SPF or DKIM path. Full participation requires both aligned SPF and DKIM under RFC 9989 §8, even though one passing aligned path can satisfy the message-level rule.
Use the Microsoft 365 or Google Workspace instructions when those are the actual sending services. Include any application using a different provider.
Build the intended record
Protocol references: RFC 9989 §4.5, RFC 9989 §4.7, RFC 9990 §4. Operational checklists and decisions below are editorial guidance.
For a domain beginning a monitored deployment, the following is an illustrative starting record:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comPublish that value as a TXT record at _dmarc.example.com. In a DNS editor that accepts relative names for the example.com zone, the owner may be entered as _dmarc. Other editors expect a full name. Verify the provider's entry model rather than assuming one form works everywhere.
- Part: v=DMARC1; Meaning in this example: The DMARC version marker; it belongs first
- Part: p=none; Meaning in this example: No domain-owner handling preference for DMARC failure
- Part: rua=mailto:...; Meaning in this example: A request for aggregate reports to the approved destination
The example uses a same-domain report address and assumes that collection there works. Replace it with the actual approved destination. A destination outside the relevant domain relationship can require a separate permission record controlled by the receiving domain.
Do not copy example.com into a production record. Do not add a second DMARC policy record when one already exists. Review and update the existing record set.
Verify the authoritative DNS answer
Protocol references: RFC 9989 §4.5, RFC 9989 §4.10.1, RFC 2308 §5, RFC 8767 §4. Operational checklists and decisions below are editorial guidance.
Command syntax and options follow ISC’s dig reference. The direct query disables recursion; inspect the authoritative-answer flag and complete response context.
Start with the exact owner name:
dig _dmarc.example.com. TXT +noall +comments +answer +authorityIdentify the delegated authoritative servers for the zone, then query a relevant authority directly. For example, using the actual authoritative server in place of the illustrative one below:
dig @ns1.example.net. _dmarc.example.com. TXT +norecurse +noall +comments +answer +authorityCheck the name, record type, complete value and record-set boundaries. A TXT record may contain multiple character strings; that differs from several separate candidate policy records. Compare recursive answers after confirming authority, while accounting for positive and negative caching.
If the expected answer is absent, follow the missing-record diagnosis. Avoid repeatedly adding the same policy to different control panels.
Test real messages through important routes
Protocol references: RFC 9989 §5.3.5, RFC 8601 §7.1. Operational checklists and decisions below are editorial guidance.
Send a controlled message to a separate recipient and preserve the original there. Inspect the receiving system's trusted results, the visible From domain, the SPF identity and each relevant DKIM signature.
Assume an applicable valid policy and completed authentication checks. This synthetic example shows why a successful record check is not sufficient:
- Observation: DMARC TXT record; Result: Present at the intended name
- Observation: SPF; Result: Pass for an unrelated provider domain
- Observation: DKIM; Result: No aligned passing signature
- Observation: DMARC passing path; Result: Not established
Repair the supported sending configuration rather than treating DNS presence as success. Repeat the test after correction and retain both the change and observed result. The alignment guide explains the identity comparison.
Confirm that reports reach the collection system
Protocol references: RFC 9989 §5.3.8, RFC 9990 §3.1. Operational checklists and decisions below are editorial guidance.
Check that the collection destination accepts mail and that reports can be processed. Observe representative traffic to reporting receivers and retain reporter identity and reporting periods.
Requested reports are not guaranteed from every receiver, and they do not represent every message the organisation sent. Missing feedback can reflect participation, traffic, destination, filtering or processing issues. Investigate those stages rather than declaring the domain quiet.
Set the acceptance criteria
Require evidence for configuration, critical-message authentication, collection and ownership. Review indirect mail and unresolved exceptions before changing the requested policy.
Capture an exact change, its approver, the prior state and the verification result. Define when to restore the prior approved configuration if legitimate communication breaks. A rollback should preserve the investigation trail.
For an initial deployment, monitoring is an evidence-gathering stage. It is not an automatic calendar countdown to reject. Use the monitoring decision guide to define the findings needed for the next policy decision.
The practical takeaway
Treat the DNS record, authentication tests and reporting path as one implementation. When those checks are complete, retain the configuration, owners and unresolved exceptions. Any later enforcement decision should follow the domain's actual use and evidence.
Apply the evidence without overstating it
Retain the recursive and authoritative responses separately. An empty answer requires status and authority context; it is not automatically absence. TTL expiration is not a global revocation deadline because qualifying serve-stale behavior can retain data beyond freshness. The commands are unexecuted teaching examples; report collection and message tests remain acceptance work for the operator.