DMARC Record Sample: Copy, Configure, Test, and Enforce Safely

A DMARC record sample is easy to copy into DNS, but publishing one safely requires more than adding p=reject to a TXT record. You need to make sure every legitimate sender can pass aligned SPF or DKIM first—otherwise DMARC can block mail you meant to deliver.

The short answer: a safe DMARC record sample

For a domain named example.com, start with this DNS TXT record:

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

In a zone-file format, the same record is:

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

This asks participating receiving mail systems to send aggregate DMARC reports to dmarc-reports@example.com, while p=none puts the domain into monitoring mode rather than asking receivers to quarantine or reject failures. A DMARC policy record is published as a DNS TXT record below the _dmarc label, and the protocol version is the literal value DMARC1. (rfc-editor.org)

Do not treat this as a final destination. It is the first production-safe record for most organizations because it lets you find unknown senders, broken DKIM signing, and misaligned return paths before an enforcement policy affects delivery.

What a DMARC record does—and does not do

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It connects the visible domain in the RFC 5322 From: header to the domains authenticated by SPF and DKIM, gives domain owners a requested handling policy for failures, and provides reporting mechanisms. The current core DMARC standard is RFC 9989, which obsoletes the older RFC 7489 specification commonly cited in legacy documentation. (datatracker.ietf.org)

At a high level, a receiving server evaluates three things:

1. SPF: Did the server sending the message have permission to use the SMTP envelope sender domain?
2. DKIM: Does a cryptographic signature validate for the message as received?
3. Alignment: Does the domain that passed SPF or DKIM match the visible From: domain under DMARC’s alignment rules?

DMARC passes when either SPF or DKIM passes and aligns with the visible From: domain. It does not require both mechanisms to pass, although configuring both is far more resilient in real mail flows. (datatracker.ietf.org)

DMARC is not an inbox-placement guarantee. A passing message can still land in spam because mailbox providers also evaluate content, recipient engagement, sending behavior, IP and domain reputation, complaint signals, and other abuse indicators. Likewise, DMARC cannot stop a criminal from using a lookalike domain such as examp1e.com; it protects the domain you actually control.

Where to publish the record in DNS

Publish the record at:

_dmarc.yourdomain.com

For example.com, the fully qualified DNS name is:

_dmarc.example.com

Most DNS control panels split the entry into fields. The usual values are:

Some DNS providers expect the full hostname (_dmarc.example.com) in the Name field; others automatically append example.com and expect only _dmarc. Check the preview shown by the DNS provider. If you enter the full name into a panel that appends the domain automatically, you can accidentally publish _dmarc.example.com.example.com.

Use one valid DMARC policy record at a given _dmarc name. Multiple separate DMARC TXT answers at that location are not merged into a stricter policy; receivers can treat the policy as invalid. A single TXT record may be visually split into quoted strings by DNS software for length handling, but that is different from publishing multiple independent DMARC records. (palisade.email)

DMARC record sample progression: monitor, quarantine, reject

A practical rollout uses three policy stages. Each stage uses the same basic syntax but changes the p tag.

1. Monitoring: p=none

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

Use this while you inventory mail sources and inspect reports. Receivers can still use their own anti-abuse systems, but your DMARC record is not requesting special quarantine or rejection treatment for messages that fail DMARC.

2. Partial enforcement: p=quarantine

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

This requests that receivers treat failing mail as suspicious, commonly by placing it in spam or junk. The final behavior remains receiver-controlled; DMARC communicates a domain-owner policy request, not a universal command that every mailbox must apply identically. (support.google.com)

3. Full enforcement: p=reject

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

This is the strongest common policy. It asks receivers to reject mail that claims to be from your domain but fails DMARC. For a domain that sends transactional mail, password resets, invoices, support replies, and marketing through different systems, only reach this stage after reports show that each legitimate stream has aligned authentication.

A good final basic record for many organizations is:

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

The explicit adkim=r and aspf=r are optional because relaxed alignment is the default, but including them can make the intended setup clearer to future operators. RFC 9989 and the IANA DMARC registry define the policy, alignment, reporting, subdomain, and test-mode tags used in current DMARC deployments. (iana.org)

DMARC tags that matter in a real record

A DMARC record contains semicolon-separated tag=value pairs. You do not need every available tag. In fact, a smaller record is easier to audit and less likely to contain copied legacy settings that nobody understands.

Required tags: v and p

v=DMARC1 identifies the record as DMARC. Put it first.

p= supplies the requested policy for mail using the domain:

• p=none — monitoring
• p=quarantine — request suspicious handling
• p=reject — request rejection

A minimal syntactically useful record is therefore:

v=DMARC1; p=none

However, that record gives you no aggregate reports, so it is rarely a good operational endpoint.

Aggregate reporting: rua

rua= tells receivers where to send aggregate feedback reports:

rua=mailto:dmarc-reports@example.com

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

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

Aggregate reports are machine-readable XML reports, typically compressed, describing messages that claimed to use your domain and the authentication results seen by reporting receivers. They are valuable because they reveal authorized services you forgot about, unauthorized use of your domain, and configuration failures that are not obvious from your own sent-mail folder. RFC 9990 defines aggregate reporting separately from the core DMARC protocol. (rfc-editor.org)

Use a dedicated mailbox, group, or reporting service rather than a person’s everyday inbox. Google notes that report volume can be substantial for large organizations, and recommends a dedicated group or mailbox. (support.google.com)

Alignment mode: adkim and aspf

adkim controls DKIM alignment; aspf controls SPF alignment.

adkim=r; aspf=r

The valid values are:

• r — relaxed alignment
• s — strict alignment

Under relaxed alignment, news.example.com and example.com can align because they share the same organizational domain. Under strict alignment, the domains must match exactly. DMARC’s default alignment mode is relaxed. (datatracker.ietf.org)

Start relaxed unless you have confirmed every legitimate stream uses an exact matching SPF or DKIM domain. Strict alignment is useful for some tightly controlled domains, but it is not automatically more deliverable or more correct.

Subdomain policy: sp

sp= controls the requested policy for subdomains that do not publish their own DMARC policy record.

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

That example requests rejection for the root domain and quarantine for inherited subdomain policy. A subdomain such as alerts.example.com can also publish its own DMARC record at _dmarc.alerts.example.com; that explicit record takes precedence for that subdomain.

Advanced current tags: np, t, fo, and ruf

The current IANA DMARC registry also lists np for non-existent subdomains, t for policy test mode, fo for failure-report options, and ruf for message-specific failure-report destinations. These are specialized tools, not required fields in a normal deployment. (iana.org)

Do not add ruf merely because an old template includes it. Failure reports are not a dependable replacement for aggregate reports, may be limited by receivers, and require careful privacy and mailbox handling. Begin with rua, then add specialized tags only when you understand the operational result.

You may also encounter pct, ri, and rf in older DMARC examples. The IANA registry marks those tags historic. Avoid building a new enforcement strategy around them; use a report-driven staged rollout instead of assuming percentage sampling or reporting-interval hints will behave consistently across receivers. (iana.org)

SPF, DKIM, and DMARC alignment explained

The most common DMARC misunderstanding is: “SPF passed, so DMARC must pass.” That is not always true.

DMARC evaluates the visible address people see in the message header:

From: Acme Receipts <receipts@example.com>

It then checks whether a passing SPF or DKIM identity aligns with example.com.

SPF alignment example

Suppose a message contains:

From: receipts@example.com
Return-Path: bounce@mailer.vendor.example

If SPF passes for mailer.vendor.example, SPF may still fail DMARC alignment because mailer.vendor.example does not share the organizational domain example.com.

A better aligned setup might use a custom bounce domain configured with your sending provider:

From: receipts@example.com
Return-Path: bounce@bounces.example.com

With relaxed SPF alignment, bounces.example.com aligns with example.com. With strict SPF alignment, it does not, because the names are not identical.

DKIM alignment example

Suppose the message contains a valid signature such as:

DKIM-Signature: v=1; d=example.com; s=mail2026; ...
From: receipts@example.com

A passing DKIM signature using d=example.com aligns with receipts@example.com under relaxed alignment. It does not strictly align, because the domains are not exactly the same.

If you require strict DKIM alignment for that From address, the signing domain needs to be:

DKIM-Signature: v=1; d=receipts.example.com; s=mail2026; ...

The key operational lesson is simple: configure a custom DKIM signing domain with every email provider, and make sure its d= domain is aligned with the domain used in the visible From address. Many transactional providers expose this as “domain authentication,” “authenticated domain,” or “custom DKIM.” Consult your provider’s email API setup guides for the exact DNS records it requires.

Worked example: protect a SaaS domain without breaking mail

Assume a SaaS company owns northstarapp.com and sends mail from:

• Google Workspace for employee mail
• An application email provider for password resets and receipts
• A marketing platform for newsletters
• A customer-support platform for ticket replies

The company wants to stop spoofed mail from reaching recipients while preserving legitimate delivery.

Step 1: choose the From-domain plan

Use a controlled, consistent domain structure:

Employees:       person@northstarapp.com
Transactional:   receipts@northstarapp.com
Marketing:       updates@northstarapp.com
Support:         help@northstarapp.com

This does not require separate DMARC policies. One root-domain policy can protect the visible northstarapp.com domain, provided the individual senders authenticate correctly.

If the company uses a separate subdomain such as news.northstarapp.com in visible From addresses, publish and monitor a specific DMARC record at _dmarc.news.northstarapp.com as well. Explicit records make subdomain intent clear and reduce dependence on inherited policy behavior.

Step 2: authenticate every sender before changing DMARC policy

For each system, record these fields:

Do not guess these domains from a provider dashboard. Send a real test message from each system to a mailbox you control and inspect the raw headers. The important values are the actual smtp.mailfrom value used for SPF and the actual header.d= value used by DKIM.

Step 3: publish a monitoring record

Create a mailbox or group named dmarc-reports@northstarapp.com, then publish:

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

This record starts collecting evidence without asking receivers to block failures. Google’s DMARC setup guidance similarly recommends ensuring SPF and/or DKIM are configured before enabling DMARC, then using reports to identify authentication problems and unauthorized activity. (support.google.com)

Step 4: review reports by stream, not only by total pass rate

When reports arrive, group records by:

• Source IP address or sending service
• Header From domain
• SPF result and SPF-authenticated domain
• DKIM result and DKIM d= domain
• DMARC disposition and policy evaluation
• Message volume

A high overall pass percentage can hide a critical failure. For example, employee mail and transactional mail might pass perfectly while a low-volume support platform fails every message. That low-volume platform can still create lost ticket replies once you publish p=reject.

For every failing source, decide whether it is:

1. A legitimate service that needs DKIM/SPF domain alignment fixed.
2. A legitimate service that should stop using your root-domain From address.
3. An obsolete or unauthorized integration that should be removed.
4. Spoofing or unsolicited mail that enforcement should block.

Step 5: test a real delivered message

After each provider’s DNS authentication is complete, send a message and inspect its authentication results. The exact header layout differs by receiver, but look for a result conceptually like this:

Authentication-Results: receiver.example;
  spf=pass smtp.mailfrom=bounces.northstarapp.com;
  dkim=pass header.d=northstarapp.com;
  dmarc=pass header.from=northstarapp.com

For a visible From address at northstarapp.com, either the aligned SPF result or the aligned DKIM result is enough for DMARC to pass. Prefer having both in place, because forwarding, message modification, and vendor changes can affect one mechanism differently.

Step 6: move to enforcement only after failures are understood

Once recurring reports show that all legitimate sources pass aligned DMARC, change the record to:

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

Continue monitoring. If the same legitimate sources remain clean and the remaining failures are unauthorized, move to:

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

That final record provides meaningful domain-impersonation protection while preserving the visibility you need to catch later vendor changes.

How to verify your DMARC record after publishing

DNS publication and actual email authentication are different checks. Do both.

Check the DNS lookup

On macOS, Linux, or a system with dig, run:

dig +short TXT _dmarc.example.com

On Windows, run:

nslookup -type=TXT _dmarc.example.com

You should see one TXT value containing your DMARC policy, such as:

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

If you see no result, check the DNS host field and whether the record was published in the authoritative DNS zone. If you see more than one separate DMARC policy value, merge them into a single record.

Check authentication on sent mail

Send mail from every source: application, support desk, marketing platform, employee mailbox, billing system, CRM, and any automated workflow. Then inspect the received message source for:

spf=pass
 dkim=pass
 dmarc=pass

The important word is not merely pass; confirm the associated domains align with the visible From: domain. Google’s sender guidance explicitly states that, for direct mail, the domain in the From header must align with either the SPF domain or the DKIM domain for DMARC alignment. (support.google.com)

Check reports and delivery symptoms

A working rua setup should eventually produce aggregate reports from participating receivers, but report timing and participation vary. Treat the reports as operational telemetry, not as a complete ledger of every message sent.

Also watch actual business outcomes: password-reset delivery, support reply delivery, invoice notifications, marketing send results, bounce rates, and customer complaints. DNS can be perfect while a sender is still using a misaligned domain in production.

External DMARC report addresses: the DNS authorization many teams miss

This record works cleanly because the reporting address is in the same domain:

rua=mailto:dmarc-reports@example.com

If you send reports to a different domain—such as a DMARC analytics provider—you usually need external reporting authorization. This protects third-party domains from being named as unwanted report destinations.

For example, if example.com publishes:

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

the external destination domain can authorize it with a TXT record shaped like:

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

Many reporting vendors publish this authorization themselves as part of onboarding. Verify it rather than assuming the rua address alone is enough. RFC 9990 defines aggregate reporting and the mechanisms used to validate external report destinations. (rfc-editor.org)

Common DMARC record mistakes and their fixes

Publishing the record at the root domain

Wrong:

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

Right:

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

A root-level TXT record may be useful for other purposes, but receivers discover DMARC policy below _dmarc.

Setting p=reject before provider authentication is complete

A strict policy does not fix misconfigured sending systems. It exposes them. Finish DKIM setup, configure custom return-path or bounce domains where appropriate, inspect live headers, and review aggregate reports before enforcing.

Adding two DMARC records after two teams configure DNS

Marketing might publish one record while IT publishes another. Combine all required tags into one policy record instead. Multiple records do not provide fallback or redundancy. (palisade.email)

Confusing SPF authorization with DMARC alignment

An SPF result can pass for a vendor-owned bounce domain and still fail DMARC. Use a custom aligned envelope domain, or ensure the provider signs DKIM using an aligned domain you control.

Enabling strict alignment because it sounds stronger

adkim=s and aspf=s require exact-domain matches. That can break legitimate mail from subdomain-based streams. Use strict mode only when your reports and header tests demonstrate that every approved sender meets it.

Forgetting indirect mail flows

Forwarding and mailing lists can change a message in ways that make SPF or DKIM fail after the original sender sent it. This is why sending both SPF and DKIM authentication is more robust than relying on only one method, and why your rollout should be based on observed report data rather than an assumed perfect mail path.

DMARC and major mailbox-provider requirements

DMARC is a security control, but it is also part of modern sender expectations. Google’s published Gmail sender guidelines require bulk senders—defined there as senders of more than 5,000 messages per day to Gmail accounts—to use SPF, DKIM, and DMARC; Google permits a DMARC policy of p=none for that requirement. (support.google.com)

Yahoo’s published bulk-sender guidance likewise calls for SPF and DKIM, a valid DMARC policy of at least p=none, and DMARC alignment with either SPF or DKIM; it says relaxed alignment is acceptable. Vendor requirements can change, so use their current documentation as the source of truth for thresholds and enforcement behavior. (senders.yahooinc.com)

The practical implication is that a monitoring record is not merely a security experiment. It establishes the reporting and authentication foundation you need before you can safely enforce a policy and before higher-volume mail programs encounter authentication-related delivery problems.

Recommended final records by use case

A small company starting DMARC

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

Use this when you are still discovering all senders.

A company that has validated all senders

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

Use this when every authorized stream has an aligned SPF or DKIM pass.

A company with distinct subdomain handling

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

Use this when the root domain is fully controlled but subdomains are still being evaluated.

A domain that does not send email

v=DMARC1; p=reject

This is a reasonable baseline for a domain that genuinely sends no mail. Confirm that no forgotten systems use it for support, password resets, calendar invitations, form notifications, or employee mail before publishing it.

Final checklist before you publish p=reject

Before moving from monitoring to full enforcement, confirm all of the following:

• You have a single DMARC TXT record at _dmarc.yourdomain.com.
• The record starts with v=DMARC1 and contains a deliberate p= policy.
• Every legitimate sender has working SPF and/or DKIM.
• Every legitimate sender has aligned SPF or DKIM with its visible From domain.
• You have tested live mail headers from every sender, not just dashboard status pages.
• Aggregate reports identify no unexplained legitimate failures.
• Your rua mailbox or reporting provider is receiving and processing reports.
• External report destinations have the required authorization record where applicable.
• You have documented ownership for each mail stream so a later vendor change does not silently break authentication.

DMARC works best as an operational program, not a one-time DNS task. Keep the record simple, keep a sender inventory, monitor reports after every major email-provider change, and let verified mail flow—not a copied template—determine when the domain is ready for enforcement.

FAQ

What is the minimum valid DMARC record sample?

The smallest practical record is:

v=DMARC1; p=none

For real operations, add an aggregate-report destination:

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

Should I use p=none or p=reject?

Start with p=none while you identify all legitimate senders and fix alignment. Use p=reject only after reports and real-message tests show that authorized mail passes DMARC consistently.

Does DMARC require both SPF and DKIM?

No. DMARC passes if either SPF or DKIM passes and aligns with the visible From domain. In practice, configure both because different mail paths can cause one mechanism to fail.

Why does SPF pass but DMARC fail?

The SPF-authenticated envelope-sender domain probably does not align with the visible From-domain. Configure an aligned custom bounce domain, or configure aligned DKIM signing with your mail provider.

How do I know my DMARC record is working?

Verify the DNS TXT lookup, inspect headers from actual messages for dmarc=pass, and review aggregate reports sent to the rua destination. All three checks matter: DNS proves publication, headers prove individual-message authentication, and reports reveal system-wide behavior.