What is a DMARC DNS record?

A DMARC record is a DNS TXT record that tells receiving mail systems what to do when mail claiming to come from a domain fails email authentication checks. DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It builds on SPF and DKIM, two older mechanisms that help receivers decide whether a message is authorized by the sending domain.

The record is published at a special DNS name under the domain, usually _dmarc.example.com. A simple record might say that the domain is being monitored only, while a stricter record can ask receivers to quarantine or reject messages that fail alignment. DMARC also lets domain owners request aggregate reports, which are useful for finding legitimate senders that have not been configured correctly.

DMARC does not stop every phishing email. It is specifically about domain authentication and domain alignment. A message from a lookalike domain, a compromised mailbox, or a different legitimate domain may still reach users. Its value is narrower and still important: it reduces unauthorized use of a domain in email headers and gives operators evidence about who is sending mail for that domain.

How DMARC fits with SPF and DKIM

SPF checks whether the sending mail server is allowed to send mail for a domain. DKIM checks whether the message has a valid cryptographic signature from a domain. DMARC asks whether at least one of those authenticated domains aligns with the visible From domain that users see in their mail client.

Alignment is the detail that makes DMARC useful. Without it, an attacker could pass SPF or DKIM using a domain they control while still displaying a different brand in the From header. DMARC ties the authentication result to the domain being represented to the recipient.

A DMARC record includes tags. The v=DMARC1 tag identifies the record type. The p tag sets the requested policy, commonly none, quarantine, or reject. Reporting tags such as rua identify where aggregate reports should be sent. Optional tags can tune alignment strictness, subdomain behavior, forensic reporting, and the percentage of mail to which the policy applies.

Policy choices and what they mean

The none policy is a monitoring mode. Receivers are not asked to change delivery behavior because of DMARC failure, but they can send reports. This is the safest starting point for a domain that has multiple mail senders, marketing systems, ticketing platforms, finance tools, or regional business units.

The quarantine policy asks receivers to treat failing mail as suspicious, often by placing it in spam or another lower-trust folder. This can reduce exposure while leaving room for recovery if a legitimate sender is missed. The exact handling depends on the receiving mail provider.

The reject policy asks receivers to refuse failing mail. This is the strongest posture and is often the long-term goal for domains that send production email. It should be rolled out only after the organization has enough report data to confirm that legitimate senders pass SPF or DKIM alignment reliably.

The pct tag can be used to phase in enforcement. For example, an organization may ask receivers to apply quarantine or reject to a smaller percentage of failing messages while it watches the impact. Not every receiver treats every tag identically, so gradual rollout should be paired with monitoring rather than treated as a guaranteed control knob.

Common configuration mistakes

One common failure is publishing a DMARC record before the organization understands all legitimate senders. Payroll systems, CRM platforms, support desks, invoice tools, survey tools, and outsourced campaign platforms may all send mail using the domain. If those systems are missing SPF authorization or DKIM alignment, enforcement can break business mail.

Another mistake is assuming SPF alone is enough. SPF alignment can fail when mail is forwarded, because the forwarding server may not be listed in the original domain's SPF record. DKIM is usually more resilient through forwarding if the message is not modified in ways that break the signature. Strong mail programs often configure both.

DNS syntax errors are also common. DMARC is a TXT record with semicolon-separated tags, and small mistakes can make the policy unreadable. Multiple DMARC TXT records at the same _dmarc name can cause receivers to ignore the policy. Reporting addresses also need to be monitored; collecting reports without reviewing them leaves blind spots in place.

Operational and security implications

DMARC is both a security control and an operational dependency. It can reduce brand impersonation, protect customers from some phishing campaigns, and make abuse investigation easier. It can also reveal forgotten vendors, shadow IT mail systems, and legacy applications that still send unauthenticated email.

Because DMARC depends on DNS, changes should follow the same discipline as other production DNS updates. Operators should track current records, planned policy changes, TTL values, and expected mail flows before moving from monitoring to enforcement. A rollback plan matters because email failures can be hard for users to distinguish from normal delivery delays.

DMARC aggregate reports are especially useful when reviewed over time. Look for new sending sources, sudden authentication failures, unexpected countries or providers, and changes after vendor migrations. A new source is not automatically malicious, but it should be explained by a business owner or mail administrator.

Rollout checks before enforcement

Start by publishing p=none with aggregate reporting enabled. Let the record run long enough to capture normal business cycles, including newsletters, invoices, support replies, password resets, and regional senders. Inventory every legitimate sender and decide whether it should authenticate with SPF, DKIM, or both.

Next, fix senders that fail alignment. For SaaS platforms, this often means adding a vendor-provided DKIM key, adjusting the envelope sender, or using a dedicated bounce domain. For internal systems, it may mean routing mail through an approved mail service rather than direct delivery from application hosts.

After reports show stable authentication, move cautiously to quarantine, optionally with a partial percentage. Watch support tickets, bounce logs, aggregate report changes, and complaints from business teams. When failures are understood and low, move to reject for the primary domain and decide whether subdomains should inherit the same posture.

Good DMARC operations are not a one-time DNS change. They are a lightweight governance process for who can send mail as the domain, how that authorization is verified, and how unexpected senders are investigated.

Related learning

• What is a DNS DKIM record?
• What is a DNS MX record?
• Common DNS issues and how to diagnose them