DMARC Record Syntax: TXT Examples and Checks

Publish a record receivers can read

A DMARC record can be one line long and still break mail decisions if the host name, policy, or report address is wrong.

Publish DMARC as a DNS TXT record at _dmarc.example.com. The value starts with v=DMARC1, followed by semicolon-separated tags. Put the policy tag next. A safe monitoring record is:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

The p tag is required for a policy record. It tells receivers what you ask them to do with mail that fails DMARC. none means monitor only. quarantine asks the receiver to treat failing mail as suspicious, often by placing it in spam. reject asks the receiver to reject failing mail. Receivers can still apply local rules, so DMARC does not guarantee inbox placement.

• Use one DMARC TXT record at _dmarc.yourdomain.com.
• Start with v=DMARC1.
• Set one policy: p=none, p=quarantine, or p=reject.
• Use rua=mailto: for aggregate reports, such as rua=mailto:dmarc@yourdomain.com.
• Separate tags with semicolons. Spaces after semicolons are fine.

Common DMARC tags

Most domains should start simple, read reports, then tighten the policy after every real sender is aligned.

• v=DMARC1: required version tag.
• p=none: collect reports without asking receivers to filter failing mail.
• p=quarantine: ask receivers to send failing mail to spam or another suspicious-mail path.
• p=reject: ask receivers to refuse failing mail.
• rua=mailto:dmarc@example.com: aggregate report destination. These reports are XML, so use a mailbox or service that can process them.
• sp=reject: optional subdomain policy. If you omit it, the main p policy also applies to subdomains under RFC 7489.
• adkim=s and aspf=s: optional strict alignment for DKIM and SPF. If you omit them, relaxed alignment is used.
• pct=50: optional sampling tag in RFC 7489. It was used for staged rollouts, but support and newer DMARC work vary, so do not rely on it as your only safety control.

For the published rules, use RFC 7489 for the widely deployed DMARC syntax, RFC 7208 for SPF, and RFC 6376 for DKIM. The IETF datatracker now lists RFC 7489 as obsoleted by RFC 9989, with reporting split into RFC 9990 and RFC 9991, so check your validator if it names a newer RFC.

Alignment is the pass condition

Clean syntax is only the first check. DMARC passes when the message authenticates with the domain in the visible From address.

DMARC can pass with aligned SPF or aligned DKIM. SPF checks whether the sending IP is allowed by the envelope sender domain. DKIM checks a signature from the signing domain in the d= tag. DMARC compares one of those authenticated domains with the domain users see in the From header.

SPF has its own failure points. Keep one SPF TXT record for a sending domain, start it with v=spf1, and stay within the 10 DNS-lookup limit for mechanisms and modifiers in RFC 7208. Use ~all as a soft fail while testing. Use -all only after every legitimate sender is included. DKIM needs each sender to sign mail with a selector, such as selector1._domainkey.example.com, where the public key can be found in DNS.

What to check before enforcement

Move from monitoring to enforcement only after the reports match your real sending sources.

• Confirm the host is _dmarc, not the root domain.
• Confirm every report address uses mailto:.
• Make sure SPF and DKIM pass for Google Workspace, Microsoft 365, your CRM, support desk, billing tool, and marketing platform.
• Check MX records, reverse DNS, TLS, blocklists, complaint rate, and sender reputation. Gmail and Outlook use more than DMARC when they route mail to inbox or spam.
• Read Google's sender guidelines and Microsoft's DMARC setup guidance if you send at volume or use Microsoft 365.
• Run a fresh domain check at InboxRadar after DNS has propagated.