DMARC Record Options: Every Tag, Policy, and Setup Choice Explained

DMARC record options determine what receiving mail servers should do when a message claims to be from your domain but fails email authentication. The right DMARC record protects your visible From address from spoofing while preserving delivery for legitimate mail sent by your workspace, transactional-email platform, CRM, support desk, and newsletter tool.

DMARC is not a standalone authentication system. It evaluates whether the visible domain in the From: header aligns with a passing SPF check, a passing DKIM check, or both. A message passes DMARC when either SPF or DKIM passes and the authenticated domain aligns with the domain people see in the From: address. (learn.microsoft.com)

The practical challenge is that a single business often sends email through several systems. Google Workspace or Microsoft 365 may send employee mail, an application may send password resets, a billing platform may send receipts, and a marketing provider may send campaigns. DMARC enforcement can protect the domain only after each legitimate sender is authenticated and aligned.

What a DMARC record is and where it goes

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. For example.com, the DNS host/name field is normally _dmarc, and the TXT value contains semicolon-separated tag=value options:

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

The record uses a tag-value format. v=DMARC1 identifies the record as DMARC, p=none requests monitoring rather than enforcement, and rua asks participating receivers to send aggregate reports to the stated mailbox. The current core DMARC standard is RFC 9989; aggregate-reporting and failure-reporting formats are defined separately in RFC 9990 and RFC 9991. Those standards replaced the older RFC 7489 specification, but the record version remains DMARC1, not DMARC2. (rfc-editor.org)

A DMARC record belongs in DNS for the domain used in the visible From: header. It does not go in your web host, email client, or an individual employee mailbox. If your company sends from both example.com and news.example.com, treat them as separate sending identities until you have deliberately designed the parent-domain policy and subdomain behavior.

The DNS fields to enter

DNS dashboards use different labels, but the mapping is usually straightforward:

Do not create multiple DMARC TXT records at the same _dmarc hostname. Multiple valid-looking records can make the policy unusable to receivers. Also do not publish the record at dmarc.example.com without the underscore: the lookup name is _dmarc.example.com. (rfc-editor.org)

The two DMARC requirements: authentication and alignment

Understanding alignment is the difference between merely publishing a record and successfully enforcing it.

SPF checks whether the server that sent a message is allowed to send for the SMTP envelope domain, often called MAIL FROM or the return-path domain. DKIM checks whether a message signature validates for the signing domain shown in the d= value of the DKIM-Signature header. DMARC then compares either passing SPF domain or passing DKIM domain with the visible From: domain. (learn.microsoft.com)

For example, this message can pass DMARC through DKIM:

From: Acme Alerts <alerts@example.com>
DKIM-Signature: d=example.com; s=mail1; ...

If that DKIM signature verifies, d=example.com aligns exactly with From: ...@example.com. SPF can fail and the message can still pass DMARC because one aligned authentication mechanism is sufficient.

This message can also pass through relaxed DKIM alignment:

From: Acme News <news@example.com>
DKIM-Signature: d=mailer.example.com; s=campaigns; ...

With relaxed alignment, mailer.example.com and example.com share the same organizational domain, so the DKIM identity can align. Strict alignment would not accept this combination because the domains are not identical.

Why the return-path alone does not solve DMARC

A common configuration mistake is to authorize a vendor in SPF while leaving its return-path domain on the vendor's domain. Suppose an email says:

From: invoices@example.com
Return-Path: bounce@vendor-mail.example

The vendor's SPF may pass for vendor-mail.example, but that domain does not align with example.com. DMARC can still pass if the vendor adds a valid DKIM signature with d=example.com or a properly aligned subdomain, but SPF by itself will not provide DMARC alignment in this example.

That is why every sending vendor should be asked two concrete questions:

1. Can the platform DKIM-sign mail with our domain or a subdomain of our domain?
2. Can the platform use a custom return-path or bounce domain aligned with our domain?

A vendor may support one, both, or neither. Configure at least one aligned path before moving beyond monitoring mode.

Core DMARC record options: v and p

Every practical DMARC record begins with v=DMARC1. Put it first. The policy tag, p, states your requested treatment for mail that fails DMARC.

v=DMARC1: the version tag

Use:

v=DMARC1

The version string stays DMARC1 under the current RFC 9989 standard. Do not change it to a year, a software version, or DMARC2. (rfc-editor.org)

p=none: monitor without asking for enforcement

Use:

p=none

p=none asks receivers to take no DMARC-specific enforcement action for failures. It is the safest starting point because it lets you discover legitimate senders, unauthorized use, and configuration mistakes through reports before you risk blocking business mail.

Monitoring is not the same as protection. A spoofed message can still fail DMARC, but p=none does not ask the receiver to quarantine or reject it. Receivers retain their own independent spam and abuse controls; DMARC does not guarantee inbox placement or override provider filtering. (rfc-editor.org)

p=quarantine: ask receivers to treat failures as suspicious

Use:

p=quarantine

p=quarantine requests that failing messages be treated as suspicious, commonly by placing them in spam or junk. It is an intermediate enforcement choice when reports show that your normal mail is aligned but you want a less final response than rejection.

Quarantine is not a universal promise that every failure lands in spam. DMARC provides the domain owner's requested policy; the receiving system makes the final handling decision based on its own capabilities and anti-abuse rules.

p=reject: request rejection of unauthenticated impersonation

Use:

p=reject

p=reject asks receivers to reject mail that fails DMARC. This is the strongest ordinary DMARC policy and is usually the intended destination for a domain that sends customer-facing mail. It makes it substantially harder for attackers to send mail using an exact From: person@example.com identity without aligned SPF or DKIM.

Do not treat p=reject as a deliverability shortcut. It cannot make poorly engaged campaigns perform better, bypass spam filters, or fix a weak sending reputation. It is an anti-spoofing policy that works alongside good mail practices and correctly configured SPF and DKIM. (rfc-editor.org)

DMARC record options for alignment: adkim and aspf

The adkim and aspf tags control alignment strictness. Their values are r for relaxed and s for strict.

adkim=r; aspf=r

Relaxed alignment is the default when these tags are omitted. It allows domains that share the same organizational domain to align. Strict alignment requires an exact domain match. (palisade.email)

adkim: DKIM alignment mode

adkim applies only to DKIM.

adkim=r

With relaxed DKIM alignment, a visible From domain of example.com can align with a passing DKIM d=mailer.example.com, assuming both are within the same organizational domain. This is helpful when legitimate tools sign with delegated subdomains.

adkim=s

With strict DKIM alignment, d= must exactly equal the visible From domain. If From: is hello@example.com, d=example.com aligns; d=mail.example.com does not.

aspf: SPF alignment mode

aspf applies only to SPF.

aspf=r

Relaxed SPF alignment permits a passing envelope domain such as bounce.example.com to align with a visible From domain of example.com. This is a common and useful design for transactional and marketing mail.

aspf=s

Strict SPF alignment requires the SPF-authenticated envelope domain to exactly match the visible From domain. That can be hard to maintain because many services use a dedicated bounce subdomain. Strict SPF is therefore more likely to cause unnecessary failures unless your mail architecture deliberately uses matching domains.

Which alignment option should you choose?

For most domains, start with relaxed alignment:

adkim=r; aspf=r

Relaxed alignment still requires a meaningful domain relationship; it is not permission for an unrelated vendor domain to align. Strict alignment is best treated as an advanced control after you have reviewed every sender, custom return-path, and DKIM signing domain. A safer route to stronger protection is often to maintain relaxed alignment while enforcing p=reject, then use separate subdomains for systems that need isolated policies.

Reporting options: rua, ruf, and fo

Reports make DMARC operationally useful. Without them, you can publish a policy but have little visibility into who is sending as your domain and whether your intended senders are passing.

rua: aggregate reports

rua specifies where participating receivers can send aggregate feedback reports.

rua=mailto:dmarc-reports@example.com

A full monitoring record might be:

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

Aggregate reports are structured XML summaries. They typically include source IP addresses, message counts, SPF and DKIM outcomes, the domain seen in the From header, and the disposition applied. RFC 9990 defines the aggregate-report format. (ietf.org)

Use a dedicated mailbox, group, or reporting platform rather than an employee's normal inbox. Report volume depends on how much mail you send and which receivers process it; large organizations can receive very large numbers of reports. Google specifically recommends a dedicated mailbox or group for handling DMARC reports. (support.google.com)

Multiple destinations are allowed, separated by commas:

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

In real deployments, it is usually better to send reports to one owned mailbox or a reporting service than to create multiple unmanaged destinations.

External rua destinations need authorization

This is valid only if the external reporting domain authorizes it:

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

When reports are sent outside the domain that published the DMARC policy, receivers can require a DNS authorization record at the reporting domain. This prevents someone from using your domain's DMARC record to direct report traffic to an unrelated third party. Google also notes that an external report address requires an additional DNS record at that other domain. (dmarc.org)

If you use a commercial DMARC reporting provider, follow that provider's exact authorization hostname and value. Do not guess the record; the source domain, destination domain, and report type affect the required authorization name.

ruf: failure reports

ruf requests failure, sometimes called forensic, reports:

ruf=mailto:dmarc-failures@example.com

Failure reports can offer more event-level detail than aggregate reports, but they should not be your main monitoring method. Sending behavior varies by receiver, privacy constraints can limit content, and many large mail systems provide few or no such reports even when requested. RFC 9991 defines failure reporting separately from aggregate reporting. (rfcinfo.com)

Use ruf only when you have a secure process for receiving, retaining, and reviewing potentially sensitive data. For most teams, rua reporting plus email-header testing is more useful and predictable.

fo: failure-reporting options

fo controls the situations for which failure reports are requested. Common values include:

fo=0

Request a report if any underlying authentication mechanism fails, even if another mechanism lets DMARC pass.

fo=1

Request a report only when all authentication mechanisms that could produce DMARC alignment fail.

fo=d

Request a report when DKIM fails.

fo=s

Request a report when SPF fails.

Values can be colon-separated, such as fo=1:d. However, the setting is only a request; receiving providers may limit or decline failure reports. Avoid adding ruf and fo merely because a generator offers them. Add them only if you know why you need them and have secured the destination.

Subdomain options: sp and np

A parent-domain record can influence subdomains, but the details matter. The sp and np options express different intent.

sp: policy for existing subdomains

sp sets a requested policy for existing subdomains when the applicable policy is discovered at the organizational domain.

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

In that example, mail visibly from example.com is subject to p=reject, while mail from an existing subdomain such as billing.example.com is requested to be quarantined if it fails DMARC and no more-specific policy record applies.

If sp is omitted, the parent p policy is the fallback for existing subdomains. A subdomain with its own DMARC record uses that record's policy rather than inheriting the parent policy.

np: policy for non-existent subdomains

np is a newer option defined by the current DMARC standard. It sets the requested policy for non-existent subdomains:

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

Why distinguish them? An attacker can invent an address such as ceo@payments.example.com even when payments.example.com has no DNS or mail service. np=reject lets a domain owner explicitly request rejection for that non-existent subdomain case.

Use np only after understanding whether your organization creates sending subdomains dynamically. A specific, active sending subdomain should publish its own DMARC record and correctly configured SPF/DKIM rather than relying on inherited behavior.

psd: a public-suffix operator control

The psd tag is for public-suffix domain operators, not ordinary businesses publishing a DMARC record for their company domain. Leave it out unless you operate a public suffix and have a standards-driven reason to mark the record accordingly. (dmarc.ai)

The t test option and older tags to avoid in new records

Current DMARC standards include a t test-mode option, while several older record options have been retired from the current core model. This is an area where standards compliance and real-world receiver compatibility may differ during ecosystem transitions.

t=y: test-mode signaling

The t tag can signal test mode:

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

Treat t=y as an advanced, standards-specific tool rather than a substitute for a controlled rollout. It should not be your only safety mechanism because receiver support and behavior can vary. The operationally reliable method remains: start at p=none, inspect reports and real messages, then deliberately change policy after legitimate traffic is accounted for.

Do not rely on pct, ri, or rf in new designs

Older DMARC guides commonly show these tags:

• pct= for the percentage of failing mail to which a policy should apply.
• ri= for requested aggregate-report interval.
• rf= for requested report format.

They appeared in the historical RFC 7489-era model, but the newer RFC 9989 standards work retired them from the core record model. Do not build a new rollout plan around pct=25 or assume ri=86400 forces a reporting schedule. Use monitoring and a policy change you can reverse instead. Existing records containing legacy tags may continue to be processed by some receivers, but that does not make those tags dependable controls for a durable configuration. (dmarc.org)

Recommended DMARC records for common situations

These examples are templates, not substitutes for validating your actual senders.

1. First DMARC record for a domain that sends mail

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

Choose this when you have SPF and DKIM enabled but have not yet audited all mail streams. It explicitly requests relaxed alignment and collects aggregate reporting.

2. Monitoring a domain that should never send email

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

Use this for a parked domain or a defensive domain that genuinely does not send mail. Confirm that no forgotten support tool, legacy application, forwarding workflow, or employee process uses the domain first.

3. Enforcing a fully authenticated primary domain

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

Use this after reports and message-header tests show that all legitimate mail has at least one aligned passing path. sp=reject extends the requested failure treatment to existing subdomains that do not publish a more-specific policy, while np=reject addresses invented, non-existent subdomains.

4. Separating marketing mail from corporate mail

Parent domain record:

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

Marketing subdomain record at _dmarc.news.example.com:

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

This design lets example.com retain strong anti-spoofing protection while giving news.example.com an independent policy and reporting path. It is useful when marketing operations need separate vendor management, reputation monitoring, or a more cautious enforcement ramp.

Worked example: move from monitoring to p=reject

Imagine a company called Northstar Labs that sends these types of email:

• Employee messages through Google Workspace.
• Password resets and receipts through its application mail service.
• Product announcements through a newsletter platform.
• Customer-support replies through a help desk.

Northstar's visible From addresses all use @northstarlabs.com. The team wants spoofing protection but does not want to block password resets or support replies.

Step 1: create an inventory of senders

Start with an inventory, not a DNS record. Ask finance, support, marketing, product, and IT which systems send mail using the company domain. Search inboxes for real messages from each system and note:

The goal is not necessarily to make every service pass both SPF and DKIM. The goal is to make each service pass at least one aligned mechanism consistently.

Step 2: configure SPF and DKIM for every sender

Northstar configures each provider's DNS instructions. It uses custom DKIM signing where available and, where practical, assigns a custom bounce domain such as bounce.northstarlabs.com.

The engineering team does not paste every vendor's SPF include into separate TXT records. SPF has its own syntax and lookup limitations, so it maintains one valid SPF record for the domain and verifies changes carefully. For application mail, use your provider's domain-authentication instructions and confirm the sending domain matches what your product actually places in From:. If you need implementation details for a sending platform, consult the email API setup documentation rather than assuming that all providers publish identical DNS records.

Step 3: publish a monitoring policy

Northstar creates a dedicated group, dmarc-reports@northstarlabs.com, then publishes:

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

The team then sends test messages from every platform to test inboxes at multiple providers. In each received message, it inspects the authentication results headers for results resembling spf=pass, dkim=pass, and dmarc=pass. The exact header presentation differs by mailbox provider, but the key question is always whether an aligned SPF or DKIM identifier produced the DMARC pass.

Step 4: read reports by sender, not just by pass rate

When aggregate reports arrive, Northstar groups entries by source IP address and authenticated domain. A report row showing an unfamiliar source may be a legitimate vendor nobody documented, an old tool still in use, or unauthorized activity.

Suppose the report identifies three expected senders with aligned passing DKIM, but the help desk shows SPF pass for helpdesk-vendor.example and DKIM pass for the vendor's own domain. That stream fails DMARC because neither identity aligns with northstarlabs.com. Northstar fixes this by configuring the help desk to DKIM-sign as northstarlabs.com or to use an aligned custom bounce domain.

Step 5: enforce only after legitimate failures are resolved

Once Northstar sees that expected senders pass DMARC, it changes the record to:

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

The team continues to monitor reports and support tickets. If a legitimate stream fails, it corrects that sender rather than weakening unrelated systems.

After the quarantine stage has demonstrated stable alignment, Northstar changes to:

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

The project worked when three conditions are true: public DNS returns the intended record, real messages from every approved sender show DMARC pass, and aggregate reports no longer reveal unexplained legitimate failing sources. The record being visible in a checker is necessary, but it does not prove the mail flow is correct.

How to test whether your DMARC record works

Use three layers of verification.

1. Validate DNS publication

Query the exact hostname:

dig TXT _dmarc.example.com +short

You should see one coherent DMARC TXT value beginning with v=DMARC1. DNS propagation and caching timing depend on the authoritative DNS setup and resolver cache behavior, so test using more than one resolver if you have just changed a record.

2. Send real mail and inspect headers

Send from every approved platform to a mailbox you control. Look for an Authentication-Results header and confirm:

spf=pass
DKIM=pass
dmarc=pass

Exact capitalization and formatting vary. More importantly, verify the identities: an SPF pass for an unrelated vendor domain does not meet DMARC alignment, while a DKIM pass for your domain or an aligned subdomain can.

3. Review aggregate reports over time

Reports reveal senders that one-off testing misses: scheduled billing jobs, regional tools, legacy apps, employee-created SaaS workflows, and traffic that attackers send using your domain. DMARC reports also show that a message failed; they do not automatically identify the internal business owner of the sending system. Match IP addresses and domains to your inventory before deciding whether a source is legitimate.

Common DMARC record mistakes and how to fix them

Publishing DMARC before SPF or DKIM is ready

A domain can publish DMARC without both mechanisms, but enforcement before legitimate mail has an aligned authentication path can create delivery problems. Google advises enabling SPF and/or DKIM before DMARC and allowing time for those configurations to take effect. (support.google.com)

Fix: Configure and test SPF and DKIM first, then begin with p=none and aggregate reports.

Treating SPF pass as an automatic DMARC pass

SPF validates the envelope domain, not necessarily the visible From domain.

Fix: Check whether the SPF domain aligns with the visible From domain, or ensure DKIM signs with an aligned domain.

Using a vendor DKIM signature without custom domain signing

A vendor may sign as d=vendor.example, which can validate DKIM but cannot align with From: ...@yourdomain.com.

Fix: Enable the vendor's custom-domain DKIM configuration. This commonly requires adding CNAME or TXT records supplied by that vendor.

Adding multiple _dmarc TXT records

Splitting tags across records or leaving an old policy in place can cause receivers to treat the record set as invalid.

Fix: Maintain one DMARC TXT record per policy hostname. Combine desired tags into a single value separated by semicolons.

Using p=reject as the first record

This can block legitimate mail from systems the organization forgot about.

Fix: Use monitoring, identify sources, correct alignment, then apply enforcement in a planned change.

Expecting every receiver to send reports

rua asks receivers for reports; it does not compel every receiver to send them. Failure reports are especially inconsistent.

Fix: Treat reports as strong telemetry rather than complete global logs. Combine them with mail-provider logs, application logs, and controlled message tests.

Forgetting subdomains

A protected root domain does not eliminate the need to think about marketing.example.com, mail.example.com, or invented subdomains used in spoofing attempts.

Fix: Decide whether each legitimate sending subdomain needs its own record. Use sp and, where appropriate, np to state parent-domain intent for subdomain cases.

Choosing the right DMARC record options

For most organizations, the durable baseline is simple:

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

Then follow a disciplined sequence:

1. Inventory every source that sends with your visible From domain.
2. Configure aligned SPF, DKIM, or both for each legitimate sender.
3. Publish p=none with an owned rua mailbox.
4. Review reports and message headers until expected mail passes.
5. Move to p=quarantine if your risk tolerance calls for an intermediate stage.
6. Move to p=reject when legitimate failures are resolved.
7. Add explicit subdomain options only after deciding how active and non-existent subdomains should behave.

This approach is more reliable than copying a long “maximum security” record from a generator. DMARC is successful when its policy matches your real sending architecture, your reports are received and understood, and legitimate mail continues to authenticate under the same rules that block impersonation.

FAQ

What are the minimum DMARC record options?

The smallest practical record is v=DMARC1; p=none. In production, add an aggregate-report destination such as rua=mailto:dmarc-reports@example.com so you can see authentication results and identify senders before enforcing a stronger policy.

Should I use p=none, p=quarantine, or p=reject?

Use p=none while discovering and fixing legitimate mail streams. Use p=quarantine when those streams are stable and you want an intermediate enforcement request. Use p=reject when every legitimate sender has at least one aligned SPF or DKIM path and you are ready to request the strongest anti-spoofing treatment.

What is the difference between sp and np in DMARC?

sp sets the requested policy for existing subdomains when a parent policy applies. np sets the requested policy for non-existent subdomains, which helps express how receivers should treat attacker-invented subdomain identities.

Do I need strict adkim=s and aspf=s for DMARC protection?

No. Relaxed alignment is the normal starting point and can still support p=reject. Strict alignment is appropriate only when your DKIM signing and SPF envelope-domain design can support exact matching without breaking legitimate services.

Why do my emails pass SPF and DKIM but fail DMARC?

Usually because neither passing identity aligns with the visible From domain. Check the SPF envelope domain and DKIM d= domain, then compare each with the From: domain. Configure a custom DKIM signing domain or custom return-path domain through the relevant sending provider if needed.