DMARC record syntax looks simple—a semicolon-separated TXT value—but a misplaced hostname, malformed reporting URI, or premature policy can leave your domain spoofable or block legitimate mail. This guide explains the exact syntax, the tags that matter, and a safe path from a monitoring-only record to enforcement.

What a DMARC record does

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is an email authentication policy published in DNS. Receiving mail systems use it to decide what to do when a message claiming to be from your domain fails DMARC authentication, and they can send reports showing what they observed.

DMARC does not replace SPF or DKIM. It builds on them. A message passes DMARC when at least one of these conditions is true:

  1. SPF passes and the SPF-authenticated domain aligns with the visible From: domain.
  2. DKIM passes and the domain in the valid DKIM signature aligns with the visible From: domain.

“Alignment” is the critical extra check. A message can pass SPF for a third-party domain and still fail DMARC if that authenticated domain does not align with the domain a recipient sees in the From header. This is why DMARC makes direct impersonation of your address domain much harder.

A DMARC record has three jobs:

  • tell recipient systems your requested treatment for failing mail (p=none, quarantine, or reject);
  • specify where aggregate reports should go (rua);
  • optionally tune alignment, subdomain policy, percentages, and failure-report behavior.

The DNS record itself is a TXT record placed at a reserved name under the domain you want to protect.

The minimum valid DMARC record syntax

At its smallest, a DMARC record is:

v=DMARC1; p=none

The full DNS entry for example.com is normally:

DNS fieldValue
TypeTXT
Host / Name_dmarc
Value / Contentv=DMARC1; p=none
TTLYour provider default or a value such as 3600 seconds

Some DNS control panels require a fully qualified name rather than just the host label. In that case, use _dmarc.example.com. Check the provider’s preview before saving: many dashboards automatically append example.com to a host entered as _dmarc.

The general grammar is:

v=DMARC1; p=policy; tag=value; tag=value

Each tag-value pair is separated by a semicolon. Whitespace around semicolons and values is generally tolerated by parsers, but it is best to use clean, predictable syntax. For example:

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

Use one TXT record at _dmarc.example.com. Publishing two separate DMARC TXT records at the same name can cause receivers to treat the DMARC policy as invalid. A DNS name may have multiple TXT strings for other uses, but it should not advertise multiple independent records beginning with v=DMARC1.

The two required tags

v=DMARC1 identifies the record as DMARC version 1. It must be present and should be the first tag. Do not write DMARC=1, v=DMARC, or v=DMARC2.

p= is the requested policy for messages that fail DMARC. Its permitted values are:

  • p=none — ask receivers to take no DMARC-specific enforcement action; use this while collecting reports.
  • p=quarantine — ask receivers to treat failures as suspicious, commonly by placing them in spam or junk.
  • p=reject — ask receivers to reject failures during delivery.

The word “ask” matters. DMARC is a receiver-directed policy, and a mailbox provider can make its own final delivery decision. Nonetheless, quarantine and especially reject are the enforcement states that meaningfully reduce spoofed mail accepted as your domain.

DMARC record syntax tag reference

Most domains do not need every available tag. Start with the required tags and reporting address, then add only settings you understand. Here is the practical reference.

rua: aggregate report destination

rua supplies one or more destinations for aggregate (RUA) reports. These are XML summaries, commonly sent daily, of message authentication results observed by a receiver.

rua=mailto:dmarc-reports@example.com

Multiple destinations are comma-separated, with no space required:

rua=mailto:dmarc-reports@example.com,mailto:security@example.net

A useful baseline record is therefore:

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

Aggregate reports are not individual message copies. They contain counts and metadata such as source IP addresses, the visible header domain, SPF result, DKIM result, and disposition. They are the evidence you use before moving to enforcement.

The mailto: URI is the common choice. DMARC also defines HTTPS report URIs, but mailbox-provider support is less universal than email delivery, so use a reporting service’s documented setup if you choose an HTTPS endpoint.

ruf, fo, rf, and ri: reporting controls

ruf asks for forensic or failure reports:

ruf=mailto:dmarc-forensic@example.com

In practice, do not depend on ruf. Many large mailbox providers do not send forensic reports because they can expose message content or metadata. Aggregate rua reports are the reliable operational input.

fo controls the conditions under which a receiver may generate a failure report. Common values include:

  • fo=0 — report if all underlying authentication mechanisms fail to produce an aligned pass; this is the default.
  • fo=1 — report if any underlying mechanism fails.
  • fo=d — report when DKIM fails.
  • fo=s — report when SPF fails.

Values can be colon-separated, such as fo=1:d:s. Since forensic reporting support is inconsistent, this setting is rarely essential for a first deployment.

rf=afrf declares the format for failure reports. afrf is the Authentication Failure Reporting Format. It is the only standardized value most administrators will encounter.

ri=86400 requests an aggregate report interval in seconds. 86400 is one day and is the default. This is a request, not a scheduling guarantee: providers may aggregate and send reports on their own cadence.

adkim and aspf: alignment mode

The adkim and aspf tags choose DKIM and SPF alignment strictness:

adkim=r; aspf=r

Their values are:

  • r — relaxed alignment, the default;
  • s — strict alignment.

With relaxed alignment, a subdomain can align with its organizational domain. For a visible From address of alerts@example.com, a DKIM signing domain of mailer.example.com aligns in relaxed mode. With strict alignment, the domains must be identical, so mailer.example.com would not align with example.com.

Relaxed alignment is appropriate for most organizations, particularly those using multiple email vendors or delegated sending subdomains. It still prevents an unrelated domain such as vendor-mail.example.net from aligning with example.com.

Strict alignment can be appropriate when you fully control every sender and intentionally use exact-domain identifiers. It is not automatically “more secure” if it causes legitimate mail to fail. A failed DMARC check under p=reject is an operational outage, not a security win.

pct: apply policy to a percentage of failures

pct applies the requested enforcement policy to a percentage of messages that fail DMARC:

pct=25

The permitted range is 0 through 100; the default is 100. It is mainly useful when testing quarantine or reject in stages:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com

This does not mean 25% of all your mail is quarantined. It means the receiver may apply the policy to approximately 25% of mail that fails DMARC. It also does not make a reliable A/B test because receivers have discretion in implementation. Use it as a risk-reduction lever, not proof that every receiving provider behaves identically.

sp: subdomain policy

sp sets the policy requested for subdomains when they do not publish their own DMARC record:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com

If sp is absent, the parent domain’s p policy applies to subdomains by default. Thus, if example.com has p=reject, news.example.com normally inherits reject unless it has its own DMARC record or an explicit sp changes the inherited policy.

Use sp when the main domain and subdomains need different rollout timing. For example, a company might enforce p=reject on its primary corporate domain while keeping unknown or legacy subdomains at sp=none until it has audited them.

Less-common tags

The original DMARC specification also defines rf and fo, discussed above. You may see additional tags in vendor-generated records. Do not copy unrecognized tags merely because a generator shows them. Unknown tags should be ignored by conforming receivers, but unnecessary configuration makes troubleshooting harder.

For the broadest interoperability, use well-supported tags: v, p, rua, adkim, aspf, pct, and sp. Keep the policy readable enough that another administrator can understand it in an incident.

Where to publish the record in DNS

The DNS location is not optional. For a domain in the visible From header, query:

_dmarc.example.com TXT

For example, this record protects mail that uses addresses such as hello@example.com:

Host:    _dmarc
Type:    TXT
Content: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

It does not go at the root (@) alongside a domain-verification TXT record. It does not go under mail.example.com unless mail.example.com itself is the domain used in the visible From header and you deliberately want a separate subdomain policy.

Root domains, subdomains, and policy discovery

Suppose a message says:

From: Billing <billing@updates.example.com>

A receiver first looks for:

_dmarc.updates.example.com

If no valid record is found there, it may use the organizational domain’s policy at:

_dmarc.example.com

The organizational-domain calculation relies on the Public Suffix List. In plain terms, it distinguishes registrable domains such as example.co.uk from public suffixes such as co.uk. This matters for multi-level country-code domains and for hosted namespaces.

If you want a specific policy for a sending subdomain, publish its own record. For example:

Host:    _dmarc.marketing.example.com
Type:    TXT
Content: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

A subdomain record is often useful when marketing, product notifications, and corporate mail have different owners or authentication arrangements.

DNS interface traps

DNS vendors label fields differently: Host, Name, Record name, Content, Answer, or Value. The semantics are the same, but the required input varies. Avoid these common mistakes:

  • entering _dmarc.example.com.example.com because the interface auto-appends the zone name;
  • surrounding the full TXT value with literal quote characters when the provider already handles quoting;
  • splitting a short record into multiple unrelated records rather than one record value;
  • creating both a CNAME and a TXT record at _dmarc, which DNS rules do not allow at the same name;
  • publishing a record on a parked domain’s DNS provider while the domain’s authoritative nameservers point elsewhere.

Long TXT values may be displayed as quoted chunks by DNS lookup tools. That is normal DNS presentation behavior when a value exceeds a single character-string limit. It is not necessarily evidence that the DMARC record is split incorrectly; validation should inspect the combined TXT answer.

A worked DMARC record example

Assume a small software company owns northstar.example. It sends:

  • employee mail through Google Workspace or Microsoft 365;
  • password-reset and receipt mail through an application email provider;
  • newsletters through a marketing platform;
  • no intentional email from subdomains yet.

The company wants spoofing visibility first, without risking delivery of receipts or support replies. It creates a dedicated inbox, dmarc-reports@northstar.example, or connects a DMARC reporting service that supplies an address.

Step 1: publish monitoring mode

Create this DNS record:

Host:    _dmarc
Type:    TXT
TTL:     3600
Content: v=DMARC1; p=none; rua=mailto:dmarc-reports@northstar.example; adkim=r; aspf=r

The adkim=r and aspf=r settings are explicit but match the defaults. Including them can make the intended configuration clear; omitting them is also valid.

At this stage, the policy does not ask receivers to quarantine or reject failures. It does request aggregate reports. Those reports reveal, for example, whether the newsletter platform signs with d=northstar.example or a related subdomain, whether the application provider uses an aligned return-path domain, and whether unknown IP addresses are attempting to send as the company.

Step 2: fix every legitimate sender

For each sender found in reports, verify both its technical configuration and the From address used in production.

For an application email provider, the ideal outcome is normally one of these:

From: receipts@northstar.example
DKIM d=northstar.example  pass

or:

From: receipts@northstar.example
MailFrom: bounce@mail.northstar.example  SPF pass

Under relaxed alignment, mail.northstar.example aligns with northstar.example. The provider’s setup wizard may require you to add DKIM CNAME records and a custom return-path or MAIL FROM domain. Follow its vendor-specific DNS instructions rather than assuming an SPF include alone will make DMARC pass.

Marketing tools often default to a shared DKIM domain owned by the vendor. If the visible From address is news@northstar.example, shared signing such as d=marketing-vendor.invalid can produce a DMARC failure even if the tool is authorized to send. Configure the platform’s branded DKIM or authenticated sending domain so that the signing domain aligns.

Step 3: move to quarantine gradually

Once reports consistently identify all legitimate traffic as DMARC pass, change the record to:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@northstar.example; adkim=r; aspf=r

Continue checking aggregate reports and real-world support signals. Look specifically for legitimate streams that started failing after a new vendor integration, an IP change, or a From-address change. If the organization has a help desk or customer-success team, give it a way to flag missing invoices, invitations, and account emails.

When the configuration remains stable, increase pct in deliberate steps, such as 50, then 100. There is no universal number of days that proves a domain is ready; the correct duration depends on how frequently each sender operates. A monthly billing sender can be absent from a week of reports but still be business-critical.

Step 4: enforce reject

A mature policy can be:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@northstar.example; adkim=r; aspf=r

If the company has ungoverned subdomains, it might temporarily use:

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc-reports@northstar.example; adkim=r; aspf=r

That protects the primary domain while avoiding an accidental enforcement change for inherited subdomain policy. It is a transitional decision, not a reason to forget subdomains forever.

How SPF and DKIM alignment affect DMARC syntax

A syntactically perfect DMARC record cannot rescue broken SPF or DKIM. Before enforcement, understand what DMARC actually evaluates.

SPF is about the envelope sender, not just the From header

SPF authenticates the SMTP envelope sender, also called MAIL FROM or Return-Path. Recipients see the header From: address separately. Consider:

Header From:      support@northstar.example
Envelope From:    bounce@mailer.vendor.example
SPF:              pass

SPF may pass for mailer.vendor.example, but it does not align with northstar.example. SPF therefore cannot make DMARC pass in this example. It can still pass DMARC through aligned DKIM if the vendor signs with d=northstar.example or an aligned subdomain.

This distinction explains a frequent support ticket: “SPF is passing, so why does DMARC fail?” The answer is usually non-alignment, not bad SPF syntax.

SPF also has an evaluation limit of 10 DNS-triggering lookups. An overgrown SPF record can return a permanent error, often called PermError, instead of pass. Consolidate vendors, remove unused includes, or use subdomains for distinct sending streams rather than endlessly appending services to one root SPF record.

DKIM is often the most durable alignment path

DKIM applies a cryptographic signature to selected message headers and body content. The important domain for DMARC is the d= value in a DKIM-Signature header. For a visible From domain of northstar.example, these align under relaxed mode:

d=northstar.example
d=mail.northstar.example
d=transactional.northstar.example

This does not:

d=vendor.example

DKIM can survive forwarding better than SPF because forwarding commonly changes the sending IP and can break SPF. However, DKIM can fail if an intermediary modifies signed content or headers. Setting up both aligned SPF and aligned DKIM gives your mail more resilience.

For application-generated mail, use your sending provider’s domain-authentication flow, add the exact DNS records it provides, and confirm the actual production headers after sending a test. If you are integrating sending in code, consult the provider’s email API setup guides for the sending-domain verification and DKIM records required by that provider.

Safe rollout plan from p=none to p=reject

DMARC is not a “paste this record and forget it” control. The risk is rarely the DMARC text itself; it is undiscovered mail sent by a department, SaaS product, copier, CRM, recruiting platform, or legacy server.

Use this rollout sequence:

  1. Inventory every sending source. Ask finance, marketing, HR, support, engineering, and IT about systems that send with your domain. Include calendar tools, ticketing systems, web forms, status pages, and cloud applications.
  2. Publish p=none plus rua. This gives receivers a policy and creates a data stream without requesting enforcement.
  3. Read aggregate reports by source and identifier. Distinguish legitimate services from unauthorized sources. A source IP by itself is not enough; inspect header-from, SPF domain, DKIM domain, volume, and disposition.
  4. Configure aligned SPF and/or DKIM for each legitimate stream. Prefer vendor-provided custom DKIM and custom return-path setup over shared vendor identity.
  5. Test actual mail. Send to accounts at several major mailbox providers and inspect Authentication-Results headers. Test normal messages, replies, password resets, attachments, and any routing or forwarding paths you operate.
  6. Set p=quarantine, optionally with pct. Monitor reports and business feedback; fix exceptions instead of permanently weakening all authentication.
  7. Set p=reject. Continue monitoring. DMARC enforcement is a maintained security control because senders and vendors change over time.

You can receive a high volume of compressed XML report attachments. A dedicated mailbox, a DMARC analytics provider, or an automated parser is much more practical than manually reading every file. Treat reports as security telemetry: unexpected high-volume sources can indicate spoofing, but first rule out an unrecognized legitimate application.

Common DMARC syntax errors and how to fix them

Incorrect host name

Broken: publishing the record at example.com / @.

Correct: publish it at _dmarc.example.com for the root domain.

A root TXT record can be valid for other purposes, such as domain verification or SPF, but it is not where DMARC is queried.

Missing semicolons or wrong delimiters

Broken:

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

Correct:

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

Tags use semicolons, not spaces or commas. Commas are reserved for multiple URIs within rua or ruf.

A malformed reporting address

Broken:

rua=dmarc-reports@example.com

Correct:

rua=mailto:dmarc-reports@example.com

The URI scheme is required. Use mailto: and make sure the destination can accept reports.

Two DMARC records at the same name

Broken:

v=DMARC1; p=none

and separately:

v=DMARC1; rua=mailto:reports@example.com

Correct: merge tags into one record:

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

Multiple DMARC records can lead to an invalid result rather than a combined policy.

Setting reject before auditing third parties

Broken operational approach: publish p=reject because a checker says the syntax is valid.

Correct approach: validate the DNS syntax, then validate real sending behavior through aggregate reports and test messages. A DNS checker can tell you whether the record parses; it cannot know whether your payroll platform, CRM, or application mail is properly aligned.

External report destinations without authorization

If your record for example.com sends reports to a different domain, such as:

v=DMARC1; p=none; rua=mailto:reports@dmarc-service.example

the receiving domain may need to publish an authorization record. For the example above, dmarc-service.example would publish a TXT record at:

example.com._report._dmarc.dmarc-service.example

with this value:

v=DMARC1

This mechanism prevents a domain owner from using someone else’s mail domain as an unwilling report sink. Reputable DMARC reporting services document the exact authorization record, and some use a unique destination address that changes the required hostname. Follow their instructions precisely.

How to validate a DMARC record and prove it works

Validation has two distinct layers: DNS correctness and mail-authentication behavior. You need both.

Check DNS publication

After saving the record, query public DNS. On macOS or Linux:

dig +short TXT _dmarc.example.com

On Windows PowerShell:

Resolve-DnsName -Name _dmarc.example.com -Type TXT

You should see a value equivalent to:

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

DNS propagation depends on authoritative DNS updates, resolver caches, and the record TTL. Querying a public resolver can help distinguish a saved-but-unpublished record from a local caching delay. Do not make repeated changes while waiting; it becomes difficult to know which version a receiver observed.

A DMARC inspector can detect duplicate records, malformed tags, missing required fields, and invalid policy values. It is also useful to inspect SPF and DKIM at the same time, but regard a “valid” score as a starting point rather than confirmation of deliverability.

Check a real message’s headers

Send a message from each actual platform to a test mailbox. In the received message source, find an Authentication-Results: header. A healthy result might resemble:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce@mail.northstar.example;
  dkim=pass header.d=northstar.example;
  dmarc=pass header.from=northstar.example

The exact formatting varies by receiver. What matters is dmarc=pass and, for debugging, the SPF and DKIM domains shown beside their results.

If you see dmarc=fail, determine whether SPF or DKIM passed, then compare the authenticated domain with header.from. A passing DKIM result for the wrong domain is the most common third-party-sender issue. A SPF neutral, softfail, or permerror result points to a different class of configuration problem.

Check reports and enforcement outcomes

During monitoring, successful deployment means more than seeing XML files arrive. You should be able to account for the significant legitimate traffic in reports and see it pass DMARC with an aligned identifier. Unknown traffic may continue to fail; that is often evidence the control is working.

After setting quarantine or reject, monitor for:

  • sudden legitimate DMARC failures from a known platform;
  • a new provider signing with an unaligned d= domain;
  • SPF lookup-limit failures after someone adds a vendor;
  • unexpected use of a subdomain in the visible From address;
  • changes in message volume that correspond to an application release or campaign.

Recommended records for common stages

Use these examples as templates, replacing the domain and report destination.

Monitoring-only baseline:

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

Monitoring with explicit relaxed alignment and a subdomain policy:

v=DMARC1; p=none; sp=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Gradual quarantine rollout:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Full enforcement:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Do not add pct=100 unless you need to be explicit; 100 is the default. Do not add adkim=r or aspf=r solely for compliance; they are defaults. A shorter record has fewer moving parts, while an explicit record can be clearer for teams managing many domains. Both choices are valid.

The practical standard for a successful DMARC deployment

A correct DMARC record is not simply one that parses. It is one that reflects your intended security policy and matches the authentication behavior of all legitimate senders.

For most domains, the durable target is an understandable p=reject record, aggregate reporting, and aligned DKIM on every material email source. SPF should also be correct and aligned where practical, but DKIM gives essential resilience for forwarded mail and vendor-managed infrastructure.

Keep an owner for the domain’s email authentication settings. Any new SaaS tool allowed to send as your domain should go through an approval checklist: which From domain will it use, does it support custom DKIM, does its envelope sender align, what DNS records are required, and how will you test its headers? That process turns DMARC from a one-time DNS task into reliable protection against spoofing.

FAQ

What is the simplest valid DMARC record?

The minimum is v=DMARC1; p=none. In production, add rua=mailto:... so you can receive aggregate reports and understand your legitimate sending sources before enforcing a policy.

Does p=none protect my domain from spoofing?

It enables DMARC evaluation and reporting but does not request enforcement against failing messages. It is the right discovery stage, not the final anti-spoofing posture. p=quarantine and p=reject are enforcement policies.

Should I use strict or relaxed alignment?

Use relaxed alignment (adkim=r; aspf=r) unless you have a deliberate reason and complete control over exact-domain authentication. Relaxed alignment permits aligned subdomains, which is commonly necessary for legitimate email services.

Can I have more than one DMARC record?

No. Publish one DMARC TXT record at each _dmarc hostname. Put all desired tags into that single record. You can publish separate records for separate subdomains, such as _dmarc.example.com and _dmarc.marketing.example.com.

Why does my email fail DMARC when SPF passes?

SPF must pass and align with the visible From domain to satisfy DMARC. If SPF passes for a vendor’s return-path domain rather than your domain or an aligned subdomain, it does not provide DMARC alignment. Configure aligned DKIM or a custom aligned return-path domain.