DMARC Record Format: Syntax, Tags, Examples, and Setup

DMARC record format is the DNS syntax that tells receiving mail servers how to handle messages using your domain in the visible From address. A valid record is short, but a safe deployment depends on understanding SPF and DKIM alignment, reporting, policy rollout, and the third-party services that send mail for you.

What a DMARC record is

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is an email authentication policy published as a DNS TXT record. The policy applies to mail that uses your domain in the RFC 5322 From: header—the address recipients normally see in their inbox.

DMARC does not replace SPF or DKIM. Instead, it evaluates their results against the visible From domain. A message passes DMARC when at least one of these conditions is true:

• SPF passes and the SPF-authenticated envelope-sender domain aligns with the visible From domain.
• DKIM passes and the domain in the DKIM signature’s d= value aligns with the visible From domain.

If neither aligned SPF nor aligned DKIM passes, DMARC fails. Your DMARC policy then expresses a requested disposition for that failure: monitoring only, quarantine, or rejection. Receiving providers still make the ultimate delivery decision, so DMARC is a strong signal rather than a universal guarantee of identical treatment everywhere. (rfc-editor.org)

The current core DMARC standard is RFC 9989, which replaced the older RFC 7489 specification. The record version remains DMARC1, so a domain owner does not need to migrate to a fictional DMARC2 record format. (rfc-editor.org)

The minimum valid DMARC record format

A DMARC record is a TXT record published at this DNS hostname:

_dmarc.example.com

Its smallest useful value is:

v=DMARC1; p=none

In a DNS control panel, that normally maps to these fields:

Some DNS dashboards automatically append your domain name. In that case, enter _dmarc, not _dmarc.example.com. Other providers require the fully qualified hostname. Confirm the resulting public DNS name is exactly _dmarc.example.com.

Two elements are required:

1. v=DMARC1 identifies the record as DMARC.
2. p= sets the policy for mail that fails DMARC.

Put v=DMARC1 first, then put p= immediately after it. Use semicolons to separate tags. Whitespace after a semicolon is generally readable and accepted, but it is safest to keep the value simple and consistent.

A minimal monitoring record is valid, but it gives you little operational visibility because it has no reporting address. For a real deployment, publish an aggregate-report destination with rua=.

Copy-ready DMARC record examples

Start with the smallest record that lets you see authentication results:

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

Use that record when you are inventorying all legitimate systems that send mail as example.com. It asks receivers to send aggregate reports to dmarc-reports@example.com but does not request quarantine or rejection for failures.

After your reports show that legitimate mail is authenticating and aligning correctly, a typical enforcement path is:

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

Then, if your domain has no unresolved sources and you are ready to request the strongest handling:

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

For many organizations, relaxed alignment (adkim=r; aspf=r) is the pragmatic default. It permits a subdomain relationship between the authenticated domain and visible From domain, which is often needed for legitimate vendor and subdomain sending patterns.

Do not copy an enforcement record merely because it looks more secure. If an overlooked service sends invoices, password resets, support replies, or transactional email without aligned SPF or DKIM, a quarantine or reject policy can reduce delivery of legitimate mail.

DMARC record tags explained

A DMARC record consists of tag=value pairs. Most domains need only a handful of them.

Required tags: v and p

The policy values mean:

• p=none: monitor failures and request reports; do not request a specific enforcement action.
• p=quarantine: request that failed mail be treated suspiciously, commonly routed to spam or junk.
• p=reject: request that failed mail be rejected during delivery.

p=none is not “no DMARC.” Receivers can still authenticate mail, generate reports, and use their own anti-abuse systems. It simply does not request quarantine or rejection from the DMARC policy itself.

Reporting tag: rua

rua is the most useful optional tag:

rua=mailto:dmarc-reports@example.com

It requests aggregate reports, often called RUA reports. These reports summarize observed mail streams: source IP addresses, message counts, SPF results, DKIM results, alignment results, and the policy evaluated. Their standardized format is XML, and report volume depends on how much mail your domain sends and which receivers honor the request. (rfc-editor.org)

You can specify more than one destination, separated by commas:

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

Use a dedicated mailbox, group, or DMARC reporting platform. Do not send reports to a personal inbox and assume you will review compressed XML attachments manually forever. Larger senders can receive a substantial number of reports, and the useful signal comes from grouping sources, identifying known vendors, and investigating unknown traffic. (support.google.com)

Alignment tags: adkim and aspf

r means relaxed alignment. A subdomain can align with the organizational domain. For example, an authenticated domain of mail.example.com can align with a visible From domain of example.com under relaxed alignment.

s means strict alignment. The domains must match exactly. Strict alignment can be appropriate for tightly controlled infrastructure, but it can expose configuration gaps in SaaS platforms, delegated sending domains, and complex mail routing.

A key practical point: SPF alignment often fails for third-party senders because many platforms use their own bounce or envelope domain. DKIM alignment is frequently easier to achieve because reputable email providers commonly support custom DKIM signing for the customer’s domain. Check the actual d= value in delivered message headers rather than assuming a platform is aligned.

Subdomain policy: sp

The sp tag lets you set a policy for subdomains that do not publish their own DMARC record:

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

In that example, mail claiming to be from example.com is subject to the reject policy, while applicable subdomains such as news.example.com are requested to be quarantined unless they publish a more specific DMARC record.

Use sp= only when you understand your subdomain inventory. Marketing, product, support, regional, and transactional subdomains sometimes have separate mail systems. A subdomain-specific DMARC record at _dmarc.news.example.com takes precedence for that subdomain’s policy evaluation.

Failure-report tags: ruf and fo

ruf asks for individual failure reports:

ruf=mailto:dmarc-failures@example.com

fo can refine the failure-report conditions. The options include 0, 1, d, and s, depending on whether the requested report should be tied to overall DMARC failure, any underlying authentication failure, DKIM failure, or SPF failure.

In practice, do not treat ruf as a required part of a modern DMARC deployment. Failure reports can contain sensitive message-level information, reporting support varies by receiver, and privacy controls can limit delivery. Aggregate reports via rua are the standard foundation for monitoring. RFC 9991 separately defines the current DMARC failure-reporting format and emphasizes data-exposure considerations. (rfc-editor.org)

Newer and specialized tags: np, t, and psd

RFC 9989 introduced tags that solve narrower operational problems:

• np= expresses a policy for messages using non-existent subdomains.
• t=y signals that the domain owner is testing and does not want the stated policy applied; t=n is the normal state.
• psd= is for public suffix domain operators and specialized delegated-domain environments.

Most ordinary business domains do not need psd=. Likewise, do not add np= or t= just because a generator includes them. First get standard mail streams correct with p, rua, DKIM, SPF, and alignment.

The updated standard also deprecates legacy tags such as pct, ri, and rf. You may see them in older examples because they were part of RFC 7489-era deployment guidance. Avoid adding them to new records; use the current tag set when editing a record. (datatracker.ietf.org)

How SPF, DKIM, and alignment affect the record

The most common DMARC mistake is thinking that “SPF passes” or “DKIM passes” automatically means “DMARC passes.” It does not. The authenticated domain must also align with the visible From domain.

Consider this message:

From: Billing <billing@example.com>
Return-Path: bounce@vendor-mail.example
DKIM-Signature: d=vendor-mail.example; ...

If SPF passes for vendor-mail.example and DKIM passes for vendor-mail.example, the message can still fail DMARC for example.com. Neither authenticated domain aligns with example.com.

Now consider a correctly branded setup:

From: Billing <billing@example.com>
Return-Path: bounce@mail.example.com
DKIM-Signature: d=example.com; ...

Under relaxed alignment, DKIM aligns because d=example.com exactly matches the From domain. SPF can also align if mail.example.com is an aligned subdomain of example.com and the SPF evaluation passes.

You need only one aligned result. That is why a resilient implementation typically configures both SPF and DKIM but relies heavily on aligned DKIM for third-party sending platforms.

Before enforcing DMARC, identify every system that can send mail with your domain in the visible From address. Commonly overlooked sources include:

• Google Workspace or Microsoft 365 user mailboxes.
• Transactional email APIs and application servers.
• Marketing automation platforms.
• Customer-support and help-desk systems.
• CRM workflows and sales-engagement software.
• Ecommerce order and shipment tools.
• Invoice, accounting, HR, and recruiting platforms.
• Website form plugins, scanners, printers, and legacy appliances.

If you are consolidating application-generated email, check your provider’s email API reference and setup guides for its domain-verification and DKIM instructions before you change your DMARC policy.

A safe DMARC rollout process

The safest DMARC record format is not just syntactically correct—it reflects a verified sending inventory. Use a staged process instead of moving directly to p=reject.

Step 1: Document every sending source

List each platform, the From domain or subdomain it uses, its envelope sender if known, its DKIM signing domain, the team that owns it, and whether it still sends production mail.

For each source, answer one question: Will a real message from this tool produce aligned SPF or aligned DKIM for the visible From domain? If the answer is unclear, send a controlled test message to a mailbox you can inspect.

Step 2: Configure SPF and DKIM for each legitimate sender

SPF authorizes sending infrastructure for the envelope-sender domain. DKIM applies a cryptographic signature whose domain appears in the d= tag. Your vendor’s setup screen may show DNS records to add, but confirm that the platform actually signs with your domain or an aligned subdomain.

Be careful with SPF changes. A domain should publish one SPF TXT policy, not multiple independent v=spf1 TXT records. Multiple SPF records can cause SPF evaluation problems. Also remember that SPF has a DNS lookup limit defined by the SPF standard, so blindly adding many vendor include: mechanisms can create a separate failure mode.

Step 3: Publish monitoring with p=none and rua

Start with:

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

Leave it in monitoring long enough to observe your normal sending cycles. For some organizations, that includes weekday mail, monthly billing, event campaigns, scheduled product notices, and automated account workflows. The right duration is based on your own sending calendar, not a fixed number of days.

Step 4: Read the reports and fix unknown or failing sources

Classify every report source into one of four buckets:

1. Known and aligned: expected mail that passes DMARC.
2. Known but failing: legitimate platform that needs SPF, DKIM, or From-domain changes.
3. Unknown but legitimate: a forgotten service that needs ownership verification.
4. Unauthorized: spoofed or unrecognized mail using your domain.

Do not judge reports only by whether SPF says pass. Look for the DMARC disposition and the aligned SPF or DKIM identifiers. A source can be authorized for an unrelated envelope domain and still fail DMARC.

Step 5: Move to quarantine, then reject when evidence supports it

After legitimate sources consistently pass, change the policy to:

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

Continue reviewing reports and delivery feedback. When you are confident that legitimate mail is not failing because of missing alignment, request rejection:

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

This progression protects the domain while preserving a controlled way to discover mistakes. It is especially important for organizations with decentralized marketing teams, multiple business units, or years of accumulated SaaS tools.

Worked example: setting up DMARC for a SaaS company

Assume acme-example.com sends mail from three systems:

• Microsoft 365 for employee messages.
• An email API provider for password resets and receipts.
• A marketing platform for newsletters.

The company wants recipients to see @acme-example.com in all visible From addresses.

Initial DNS record

Create a dedicated mailbox such as dmarc@acme-example.com, then publish:

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

Verify each sender

For Microsoft 365, enable its recommended DKIM configuration and verify the signed message has a DKIM d= domain that aligns with acme-example.com.

For the email API provider, add its custom DKIM DNS records and set the application’s From address to receipts@acme-example.com. Send a real password-reset or test receipt and inspect the delivered headers. The message should show dkim=pass and an aligned signing domain.

For the marketing platform, authenticate the sending domain according to that platform’s instructions. If it signs with d=marketing-vendor.example, it may pass DKIM but fail DMARC. Configure custom-domain DKIM or use an aligned sending subdomain such as news.acme-example.com if the platform supports it.

Read the result

A healthy report eventually shows the recognized Microsoft 365, API, and marketing sources with aligned SPF or DKIM results. If a source appears as unknown, investigate it before enforcing. It may be an abandoned form plugin, a contractor’s mailing system, or an impersonation attempt.

Enforce after cleanup

Once all three legitimate sources pass, publish:

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

After continued monitoring confirms no legitimate failures, use:

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

That final record asks receivers to reject unauthenticated mail claiming to be from acme-example.com, while reporting continues so the team can identify new sending services or attack activity.

External reporting addresses and authorization

You can send aggregate reports to an address outside the protected domain, such as a DMARC-monitoring provider:

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

However, external destinations require authorization. The destination domain must publish a TXT record confirming it is willing to receive reports for your protected domain. This prevents attackers from pointing report traffic at an unrelated victim mailbox.

For a protected domain example.com and an external report domain reports.example.net, the authorization record is published in the external domain’s DNS at:

example.com._report._dmarc.reports.example.net

with a value containing at least:

v=DMARC1

Many DMARC reporting services create this authorization for customers automatically. If you operate the reporting domain yourself, you must add it. If you do not, some receivers can decline to send reports to the external mailbox even though your primary DMARC record is valid. (ietf.org)

Common DMARC record format errors

Publishing the record at the wrong hostname

This is wrong for the apex domain:

example.com TXT "v=DMARC1; p=none"

This is correct:

_dmarc.example.com TXT "v=DMARC1; p=none"

DMARC receivers look under the _dmarc label. An otherwise perfect string at the root domain is not the DMARC policy record.

Using more than one DMARC TXT record

Publish one DMARC TXT record at _dmarc.example.com. Multiple independent DMARC policy records at the same hostname can make the result invalid or unreliable. Consolidate all desired tags into one record.

Forgetting the mailto: prefix

This is malformed:

rua=dmarc@example.com

This is correct:

rua=mailto:dmarc@example.com

Treating From: and Return-Path as interchangeable

DMARC evaluates the visible From domain for alignment. SPF evaluates the envelope sender domain, often surfaced as Return-Path after delivery. A platform can therefore have a valid SPF result but still fail DMARC if its envelope domain is unrelated to the visible From domain.

Publishing a strict policy before discovering every sender

A syntactically valid p=reject record can still be operationally unsafe. The failure is not in the TXT syntax; it is in an incomplete inventory of systems that send as your domain.

Copying legacy tags from old guides

Older examples commonly contain pct=, ri=, or rf=. The current DMARC standard deprecates these tags. Do not make them part of a new baseline record merely because a legacy generator includes them. (proofpoint.com)

How to test whether your DMARC record works

Validation has two parts: verifying DNS publication and verifying real mail authentication.

Check the DNS lookup

From a terminal, query the TXT record:

dig +short TXT _dmarc.example.com

A successful result should return your DMARC value, for example:

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

You can also use a DMARC lookup tool. Confirm all of the following:

• The hostname is _dmarc.example.com.
• The record begins with v=DMARC1.
• A valid p= tag is present.
• There is only one DMARC policy record at that hostname.
• rua addresses use valid mailto: URIs.
• An external reporting destination has the required authorization record.

Send real messages and inspect headers

A DNS validator only proves the record can be found and parsed. It does not prove your email streams pass DMARC.

Send test messages from every platform to a mailbox where you can view raw headers. Look for an Authentication-Results header similar to:

spf=pass ...
dkim=pass ...
dmarc=pass header.from=example.com

The exact header wording varies by receiver. The important result is dmarc=pass and an aligned domain. If a sender fails, fix that sender before increasing enforcement.

For domains that send high volumes to Gmail personal accounts, email authentication is also a delivery requirement. Gmail states that senders sending more than 5,000 messages per day to Gmail accounts must set up SPF, DKIM, and DMARC; its DMARC policy may be p=none for that requirement. (support.google.com)

Choosing a practical long-term record

For most domains, the right long-term record is intentionally boring:

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

That is not automatically the right record for every domain. A domain with multiple subdomains may need sp=, a dedicated transactional subdomain may need its own policy, and a reporting vendor may require external destination authorization.

The durable operating model is more important than an impressive-looking string:

• Keep an owner for every sending platform.
• Require new vendors to support authenticated, aligned sending before launch.
• Review DMARC reports after marketing, help-desk, or application-email changes.
• Remove DNS authorizations and vendor configurations when tools are retired.
• Recheck alignment after changing the visible From domain or moving email providers.

DMARC helps prevent unauthorized use of your domain in email, but it does not create an inbox-placement guarantee. Content, recipient engagement, complaint rates, IP and domain reputation, and receiving-provider filtering continue to affect delivery.

FAQ

What is the basic DMARC record format?

The basic format is a DNS TXT record at _dmarc.yourdomain.com with v=DMARC1 first and a policy tag such as p=none. A practical starter record is v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com.

What should I put in a DMARC record for the first time?

Start with p=none and an rua aggregate-report mailbox. Configure SPF and DKIM for every legitimate sender, inspect reports, then move to quarantine and reject only after your real mail consistently passes DMARC.

Is p=none a valid DMARC policy?

Yes. p=none is valid and useful for monitoring. It requests reporting without asking receivers to quarantine or reject mail solely because of DMARC failure.

Do I need both SPF and DKIM for DMARC?

DMARC can pass when either SPF or DKIM passes and aligns with the visible From domain. In practice, configure both: they provide redundancy, and aligned DKIM is especially valuable for third-party email services.

Why does my email pass SPF but fail DMARC?

SPF can pass for the envelope-sender domain while the visible From domain is different. DMARC requires the SPF-authenticated domain to align with the visible From domain, unless aligned DKIM passes instead.