What is a DMARC record?

A DMARC record is a string of semicolon-separated tag=value pairs published as a DNS TXT record. The shortest valid one is v=DMARC1; p=none, and a typical monitoring record is v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. It always begins with v=DMARC1, which is the only required tag and the only one with a fixed position. Everything else is optional, including the policy tag p: a record without one is read as though it said p=none.

Query the TXT records at the _dmarc subdomain of your domain. On the command line that is dig TXT _dmarc.yourdomain.com or nslookup -type=TXT _dmarc.yourdomain.com, and a DMARC checker does the same lookup and parses the result. Looking up the domain itself returns SPF and verification records rather than DMARC, which is why a record often appears missing when it is simply being looked for at the wrong host.

A DMARC record is stored in public DNS, as a TXT record at the host _dmarc, not in your mail platform. That distinction catches people out on Microsoft 365 and Google Workspace: both document DMARC, but neither stores the record. It lives wherever the domain's nameservers point, which may be a different company from the registrar you bought the domain from.

No. A domain must publish exactly one DMARC record. Receivers that find two at _dmarc treat the domain as having no usable policy, so a second record does not add to the first, it disables both. When you need to change something, amend the existing record rather than publishing another one.

Receivers have no instruction, so they fall back to their own filtering and generally deliver mail that fails SPF and DKIM instead of blocking it. Anyone can send mail that appears to come from the domain, you receive no reports about who is doing it, and bulk mail to Gmail, Yahoo, and consumer Outlook can be rejected or filtered under the sender requirements those providers introduced in 2024 and 2025.

The record is the whole TXT string; the policy is the p tag inside it. p=none, p=quarantine, or p=reject tells receivers what to do with mail that fails authentication. So every DMARC record contains a policy, and changing your policy means editing one value inside the record you already publish rather than creating a new record.

No, and new records should leave it out. The pct tag applied an enforcement policy to a percentage of failing mail, but receivers implemented that sampling inconsistently, and RFC 9989 removed it in May 2026 along with the rf and ri tags. Stage a rollout by moving the policy itself from none to quarantine to reject and watching the reports at each step. Where you want a policy published but not yet enforced, RFC 9989 names t=y as the replacement for that part of what pct did.

Publish it as a TXT record. Some DMARC providers hand you a CNAME at _dmarc that points at a record they host, which is a legitimate way to let a vendor manage the value for you, and the record the CNAME resolves to is still a TXT record. What is never valid is a CNAME and a TXT record coexisting at _dmarc, because a CNAME cannot sit alongside other data at the same name.