DMARC Record Type: TXT Syntax, Setup, Tags, and Examples

The DMARC record type is TXT. To publish DMARC for example.com, you create one DNS TXT record at _dmarc.example.com containing a semicolon-separated policy such as v=DMARC1; p=none; rua=mailto:dmarc@example.com.

That sounds simple, but a record at the wrong hostname, duplicate DMARC TXT records, an unaligned email sender, or an unprepared move to p=reject can make legitimate mail fail. This guide explains exactly what to publish, how each important tag works, how to test it, and how to progress safely from monitoring to enforcement.

The short answer: what record type does DMARC use?

DMARC uses a DNS TXT record. It does not use an MX record, CNAME record, SPF-specific record type, or DKIM selector record.

For a domain named example.com, the standard DNS entry looks like this:

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

In a typical DNS provider dashboard, enter the equivalent values:

Most DNS dashboards automatically append your zone name. If your DNS zone is already example.com, entering _dmarc normally produces _dmarc.example.com. Some providers instead ask for a fully qualified name. Read the field hint before entering _dmarc.example.com, because entering the full domain in a provider that appends the zone can accidentally create _dmarc.example.com.example.com.

The DMARC protocol identifies the visible From: domain, evaluates SPF and DKIM, then requires at least one passing result to be aligned with that visible From: domain. The published TXT record tells receivers what handling you request when that DMARC evaluation fails and, optionally, where to send reports.

What a DMARC TXT record actually does

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It builds on two underlying mechanisms:

• SPF authorizes infrastructure to send mail for an envelope sender domain.
• DKIM uses a cryptographic signature associated with a signing domain.
• DMARC connects one of those passing identities to the domain a recipient sees in the message's From: header.

This distinction matters. A message can pass SPF but still fail DMARC if the envelope sender's domain does not align with the visible From: domain. It can also pass DKIM but fail DMARC if the d= domain in the DKIM signature does not align with the visible From: domain.

For example, assume a recipient sees this:

From: Acme Billing <billing@acme.example>

The message can pass DMARC in either of these broad situations:

1. SPF passes for an aligned envelope sender, such as bounce@acme.example or, under relaxed alignment, a related subdomain such as bounce@mail.acme.example.
2. DKIM passes with an aligned signing domain, such as d=acme.example or, under relaxed alignment, d=mail.acme.example.

It does not need both SPF and DKIM to pass DMARC. One aligned pass is sufficient. That is why DKIM is frequently the more resilient path for SaaS platforms and transactional email providers: forwarding or mailing lists can alter the SMTP path and make SPF less dependable, while a valid aligned DKIM signature can still satisfy DMARC.

DMARC is therefore not a switch that makes every message inbox-bound. It is a domain-authentication and policy signal. Receiving systems still make their own delivery decisions using many signals, including their local anti-abuse rules.

The required DMARC record format

A DMARC record is made of tag=value pairs separated by semicolons. The version tag must come first, followed by the policy tag.

The smallest useful monitoring record is:

v=DMARC1; p=none

A more practical initial record requests aggregate reports:

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

The two required tags are:

Use ordinary ASCII punctuation. Do not paste smart quotation marks, explanatory labels, HTML, or line comments into the DNS value.

This is valid:

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

These are not valid DMARC policy records:

p=none; v=DMARC1

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

DMARC record: v=DMARC1; p=none

v=DMARC1; p=monitor

monitor appeared in early DMARC drafts but is not a valid policy value. Use p=none for monitoring.

DMARC policy values: none, quarantine, and reject

The p tag is the most important setting in the record because it expresses your requested disposition for messages that fail DMARC.

p=none: monitor without requesting enforcement

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

p=none asks receiving systems not to apply a DMARC-specific enforcement action. It is the correct starting point when you have not yet inventoried every sender that uses your domain.

It does not protect the domain from spoofing by itself. It gives you observation time: aggregate reports can show which IP addresses and mail platforms are sending mail that claims to be from your domain, whether SPF and DKIM pass, and whether the identities align.

p=quarantine: treat failures as suspicious

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

p=quarantine asks receivers to treat failing mail as suspicious. A receiver may route such mail to spam or junk, but DMARC policy is a request rather than a guarantee of identical behavior at every mailbox provider.

Use this when you have validated the major legitimate senders and want a staged enforcement step before requesting rejection. Watch your aggregate reports and support tickets closely after any policy change.

p=reject: request rejection of DMARC failures

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

p=reject asks receiving systems not to accept messages that fail DMARC. It is the strongest standard policy for preventing direct spoofing of the protected domain.

Do not treat p=reject as a DNS cleanup task. Treat it as an operational launch. Before publishing it, make sure every real sending path either has aligned DKIM or aligned SPF, including customer-support tools, invoices, CRM sequences, form notifications, recruiting systems, status pages, and applications that send password resets.

The DMARC tags you will use most often

Most domains do not need every possible tag. A concise record is easier to audit, and optional tags should only be added when you understand the operational choice they express.

rua: aggregate report destination

rua requests aggregate DMARC reports.

rua=mailto:dmarc-reports@example.com

Aggregate reports are machine-readable XML summaries, typically compressed, sent by participating receivers. They can include sending source IP addresses, message counts, SPF and DKIM outcomes, alignment results, and the policy disposition applied. They are useful for finding unknown senders and identifying a broken authentication path before it becomes a delivery outage.

You can specify more than one destination as a comma-separated list:

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

A rua address is a request, not a promise that every receiver will send reports or use the same grouping schedule. Still, it is the normal visibility mechanism for a DMARC rollout.

adkim and aspf: alignment mode

These tags choose relaxed or strict alignment.

adkim=r; aspf=r

• adkim controls DKIM alignment.
• aspf controls SPF alignment.
• r means relaxed alignment.
• s means strict alignment.

Relaxed alignment allows domains that share the same organizational domain. For example, mail signed with d=mail.example.com can align with a visible From: domain of example.com under relaxed DKIM alignment. Strict alignment requires an exact domain match.

The default for both tags is relaxed alignment, so you do not need to publish them unless you want to make the choice explicit or require strict behavior. Strict alignment is not automatically more secure in a way that justifies the compatibility risk. It can break legitimate mail from platforms that sign with delegated subdomains or use a related envelope domain.

A pragmatic starting record is therefore:

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

sp: policy for subdomains

sp sets a requested policy for relevant subdomain mail when the organizational domain's DMARC record is the applicable record.

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

In this example, the root domain requests rejection for failures, while applicable subdomain failures are requested to be quarantined. If sp is omitted, p is the fallback policy.

Do not assume that one root-domain record always creates the precise result you intended for every subdomain. A subdomain can publish its own DMARC record at a different lookup name, such as _dmarc.news.example.com, and that more specific record changes the analysis for mail using news.example.com in the visible From: address.

np: policy for non-existent subdomains

The current DMARC standard introduces np, which lets a domain owner express a policy for mail that uses a non-existent subdomain in the visible From: address.

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

This is useful when attackers might invent addresses such as invoice@payments.example.com even though payments.example.com is not an actual domain you operate. np is a newer standards-based tag, so be deliberate about testing and monitoring during the ecosystem transition from older DMARC implementations.

ruf and fo: failure reports

ruf asks for message-level failure reports, while fo expresses the situations in which those reports are requested.

ruf=mailto:dmarc-failures@example.com; fo=1

These reports can contain sensitive information, and many large receiving systems do not send them. For most teams, aggregate reporting through rua is the safer and more predictable first choice. Only enable failure reporting if you have a clear use case, a protected processing path, and people responsible for reviewing potentially sensitive data.

t, psd, and older tags

The standards-track DMARC update introduced t for testing mode and psd for public suffix domain signaling. These are specialized tags, not routine settings for an ordinary company domain. Avoid copying them from a vendor-generated record without understanding why they are present.

Older records may include pct, ri, and rf. The current DMARC specifications deprecate those tags, but older receiver behavior and vendor tooling may still recognize them. Do not add deprecated tags to a new uncomplicated deployment just because a legacy tutorial includes them. If you maintain an existing production record containing them, change it only as part of a controlled review of your sender inventory and reporting requirements.

Worked example: publishing DMARC for a SaaS company

Suppose northstarapp.example sends mail through three systems:

• Google Workspace for person-to-person mail.
• A transactional email API for password resets and receipts.
• A marketing platform for product announcements.

The visible From: addresses are:

team@northstarapp.example
receipts@northstarapp.example
news@northstarapp.example

The goal is to prevent spoofing without stopping legitimate messages.

Step 1: inventory every source that can send mail

Before creating a restrictive DMARC policy, make a source-of-truth list. Include direct systems as well as less obvious workflows:

1. Mailbox provider and employee devices.
2. Transactional email provider and application server.
3. Marketing automation platform.
4. Support desk, CRM, billing platform, and booking tool.
5. Website form notifications and WordPress or ecommerce plugins.
6. Monitoring, incident-status, recruiting, and document-signing tools.
7. Any agency or partner allowed to send using your domain.

For each source, record the visible From: domain, envelope sender domain, DKIM signing domain, sender owner, and whether it is still active. If you use an API provider for application mail, configure its sending domain and DKIM settings before relying on DMARC; your provider's email API setup guides should identify the exact DNS records and verified sender settings required for that platform.

Step 2: make SPF and DKIM work for each sender

For each platform, verify at least one aligned route:

• Preferred route: DKIM passes with d=northstarapp.example or an aligned subdomain, such as d=mail.northstarapp.example when using relaxed alignment.
• Alternative route: SPF passes for a MAIL FROM / Return-Path domain aligned with northstarapp.example.

Do not rely on a platform's claim that it "supports SPF" or "signs with DKIM." Inspect a real message. A SaaS tool might sign mail with its own domain by default, which can produce a passing DKIM result that is not aligned with your visible From: domain.

Step 3: create a reporting mailbox

Create a mailbox or reporting service destination such as:

dmarc-reports@northstarapp.example

Do not send raw aggregate reports into an executive's personal inbox. The files are XML reports, can arrive in compressed attachments, and can expose operational data such as sender IP addresses and message volumes. Give the mailbox a clear owner and decide whether you will use a parser, dashboard, or an internal process to review it.

Step 4: publish a monitoring record

In the authoritative DNS zone for northstarapp.example, publish:

_dmarc.northstarapp.example. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@northstarapp.example; adkim=r; aspf=r"

In a DNS UI, that usually becomes:

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@northstarapp.example; adkim=r; aspf=r

Step 5: verify DNS independently

After the provider has published the change, query the exact DMARC hostname:

dig +short TXT _dmarc.northstarapp.example

A correct response contains one DMARC value similar to:

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

On Windows, use:

nslookup -type=TXT _dmarc.northstarapp.example

The DNS answer proves that the record is publicly visible. It does not prove your mail passes DMARC. That requires inspecting real sent messages and reviewing reports.

Step 6: send real messages and inspect authentication results

Send a message from each system to a mailbox you control at a major mailbox provider. View the full message headers and find an Authentication-Results header. You want to see a result conceptually similar to:

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

The exact header formatting varies by receiver. The important outcome is dmarc=pass for every legitimate stream using your protected visible From: domain.

If the marketing platform shows dkim=pass but dmarc=fail, compare its DKIM d= domain with the visible From: domain. If it is signing only with the platform's own domain, enable custom-domain DKIM in the platform, use an aligned subdomain, or adjust the sender configuration.

Step 7: move to enforcement only after resolving legitimate failures

Once reports and message tests show that legitimate sources pass DMARC, you can move in stages:

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

Then, after continued validation:

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

If Northstar does not intentionally send from subdomains, it can also evaluate an explicit subdomain policy, such as sp=reject, and a non-existent subdomain policy such as np=reject. Those settings are valuable only after you understand the subdomains in use across the business.

How to publish DMARC in common DNS dashboards

The protocol is universal, but DNS user interfaces are not. The labels below vary by provider.

Typical DNS provider fields

Look for an area named DNS, DNS records, Zone editor, or Manage zone. Add a record with:

Record type: TXT
Name: _dmarc
Content: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.example

Common provider-specific pitfalls include:

• Entering @ as the host, which publishes a TXT record at the root domain instead of the required _dmarc subdomain.
• Creating a second DMARC record instead of editing the existing one.
• Copying quotation marks into a UI that already adds them for DNS output.
• Adding the domain name twice because the provider automatically appends it.
• Publishing a TXT record in a registrar dashboard while the domain's authoritative nameservers are managed elsewhere.

Your DNS provider may display a long TXT value in multiple quoted chunks. That can be normal DNS presentation behavior; resolvers concatenate the chunks. It is different from creating two separate DMARC policy records.

The most common DMARC record mistakes

Publishing multiple DMARC policy records

You may have multiple unrelated TXT records at a domain, but you should publish only one DMARC policy record at a particular DMARC lookup name. If receivers find multiple DMARC policy records at the same target, the standard requires them to discard those policy records rather than guess which one you intended.

Broken example:

_dmarc.example.com. IN TXT "v=DMARC1; p=none"
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:security@example.com"

Fix it by merging the intended tags into one record:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:security@example.com"

Publishing the record at the root domain

This does not create a DMARC policy record:

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

The correct location is:

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

Thinking a valid record makes mail pass

DNS syntax is only one layer. A record can be completely valid while your password-reset mail fails DMARC because the application sends through an unconfigured provider, uses an unaligned Return-Path, or lacks aligned DKIM.

Validate both DNS and delivered messages. DNS checks confirm the policy is discoverable; message headers confirm a particular sender's mail is authenticating and aligning as expected.

Enforcing before finding shadow senders

Teams often remember their main mailbox provider and forget an old CRM, finance system, form plugin, or outsourced marketing tool. A p=reject policy can make those legitimate messages fail at receivers that honor the requested policy.

The remedy is not to weaken DMARC permanently. It is to identify every legitimate sender, configure aligned DKIM or SPF, retire unused tools, and keep monitoring after each infrastructure change.

Using a third-party reporting address without authorization

If example.com sends aggregate reports to an address at another domain, such as reports@dmarc-vendor.example, external reporting authorization may be required. The receiving report domain publishes a DNS TXT authorization record in this form:

example.com._report._dmarc.dmarc-vendor.example. IN TXT "v=DMARC1"

The report destination service normally provides this authorization automatically or gives you precise setup instructions. If it does not, some receivers may decline to send reports to that external destination. When in doubt, start with a mailbox on the same domain as the DMARC policy, then move to an external destination using the vendor's documented authorization method.

How to tell whether DMARC is working

A correct DMARC deployment has three separate proofs.

1. The DNS lookup returns one valid DMARC record

Query _dmarc.yourdomain.example, not just yourdomain.example. Confirm the answer contains a single policy record beginning with:

v=DMARC1; p=

2. Real legitimate mail shows DMARC pass

Send messages through every active system and inspect headers at a receiving mailbox. Look for dmarc=pass and confirm the header.from domain is the domain you intended to protect.

Do not test only one employee mailbox. Test an application receipt, password reset, marketing campaign, support reply, and any sender that has a distinct mail stream or vendor configuration.

3. Aggregate reports match your inventory

A healthy reporting review answers these questions:

• Which IP addresses and platforms are sending mail that claims your domain?
• Which sources are legitimate and which are unknown?
• Are legitimate messages passing DKIM or SPF with alignment?
• Are failures tied to a misconfigured platform, forwarded mail, a mailing list, or apparent spoofing?
• Did a new vendor, domain, subdomain, or sending path appear after a product or marketing change?

A report showing DMARC failures is not automatically a problem. It is evidence to investigate. A failure from an IP address that belongs to no approved platform may be a spoofing attempt; a failure from an approved vendor is a configuration task.

Choosing a safe record for your situation

Use the simplest record that matches your present maturity.

A useful long-term pattern is to isolate different business functions onto purpose-built subdomains, such as mail.example.com for application mail and news.example.com for marketing. That can simplify vendor ownership, authentication troubleshooting, and blast-radius control. It also requires deliberate DMARC, DKIM, and SPF configuration for each visible From: domain.

DMARC record type changes and standards compatibility

The foundational answer does not change: the DMARC record type remains TXT, the hostname uses _dmarc, and the record begins with v=DMARC1.

The current core standard is RFC 9989, which replaced the older RFC 7489 and moved DMARC onto the IETF Standards Track. RFC 9990 defines aggregate reporting, and RFC 9991 defines failure reporting. The update adds and clarifies behavior around non-existent subdomains, testing, public suffix domains, and DNS-based policy discovery.

For ordinary domain owners, this is not a reason to rebuild a working record overnight. A valid, concise record using v=DMARC1, p, and rua remains the practical foundation. The important operational rule is to avoid blindly adding newer or deprecated tags from an article or vendor wizard without knowing how they affect your real sender ecosystem.

FAQ

What is the DMARC record type in DNS?

The DMARC record type is TXT. Publish it at _dmarc.yourdomain.example, not at the root domain.

Is a DMARC record an SPF record?

No. Both are usually published as DNS TXT records, but they have different hostnames and functions. SPF is normally published at the sending domain, while DMARC is published at the _dmarc subdomain and evaluates SPF or DKIM alignment with the visible From: domain.

Do I need SPF and DKIM before adding DMARC?

Yes, in practice you should configure SPF and DKIM for all legitimate senders before enforcing DMARC. DMARC needs at least one aligned SPF or DKIM pass for legitimate mail to pass.

Can I publish two DMARC TXT records?

No. Publish one DMARC policy record at each DMARC lookup hostname. If duplicate DMARC policy records exist at the same hostname, receivers can discard them instead of applying either policy.

What is the best first DMARC record?

For most domains, start with v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.example. Review reports and real message headers, fix all legitimate failures, then move deliberately to quarantine and eventually reject if appropriate.