DMARC Record Example: Copy, Configure, Test, and Enforce

A DMARC record example is easy to copy into DNS, but deploying DMARC safely takes more than publishing a TXT value. You need to know which systems send as your domain, make SPF or DKIM align with the visible From address, review aggregate reports, and only then enforce quarantine or reject.

The short answer: a safe DMARC record example

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

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

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

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

This tells receiving mail systems that example.com has DMARC, asks them to take no enforcement action against messages that fail DMARC (p=none), requests aggregate reports at dmarc-reports@example.com (rua), and uses relaxed alignment for DKIM and SPF. It is the right starting point for most active domains because it gives you visibility before a stricter policy can accidentally block a legitimate sender. (datatracker.ietf.org)

Do not copy the address literally. Replace example.com and the reporting mailbox with domains and inboxes you control. Also make sure the destination mailbox can receive compressed XML attachments: aggregate DMARC reports are machine-readable XML reports, often delivered in compressed files, rather than ordinary human-readable email. (rfc-editor.org)

What a DMARC record does—and what it does not do

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It lets the owner of the domain shown in the message’s visible From: header publish a DNS policy that mail receivers can use when evaluating unauthenticated or misaligned mail. The policy also provides reporting destinations so the domain owner can see how the domain is being used in email. (datatracker.ietf.org)

DMARC is not a third authentication protocol that replaces SPF or DKIM. Instead, it evaluates whether SPF or DKIM passes and aligns with the domain users see in the From: header. A message can pass DMARC when either aligned SPF or aligned DKIM passes; it fails when neither produces an aligned pass. (learn.microsoft.com)

That distinction explains a common surprise. A platform can have a technically valid DKIM signature, or an authorized SPF sending IP, and still fail DMARC if its authenticated domain does not align with your visible From domain. For example, a newsletter sent as From: hello@example.com but DKIM-signed only as vendor-mail.example.net can fail DMARC even though the vendor’s DKIM signature itself verifies.

DMARC also cannot guarantee that every receiver will make the same final delivery decision. The record expresses the domain owner’s requested handling for failing mail; each receiver applies its own anti-abuse and delivery systems as well. Treat p=reject as a strong anti-spoofing control, not as a promise that every genuine message will always land in every inbox. (datatracker.ietf.org)

Where to publish the DMARC TXT record

Publish one TXT record at this DNS name:

_dmarc.yourdomain.com

For example.com, the full lookup name is:

_dmarc.example.com

Most DNS dashboards split the record into fields. Use these values:

Some DNS providers automatically append the zone name. In those dashboards, entering _dmarc.example.com in the Host field could create an incorrect name such as _dmarc.example.com.example.com. Other providers expect the fully qualified name. Check the preview in the DNS UI or query DNS after saving rather than assuming the provider’s convention.

DMARC is enabled by creating that TXT record in DNS; Microsoft’s documentation likewise describes DMARC configuration as a DNS TXT record for the domain. (learn.microsoft.com)

One record, not several competing records

Publish a single valid DMARC policy record for a given _dmarc hostname. Do not create one record for Google Workspace, a second for a transactional email platform, and a third for a marketing platform. DMARC is a policy for the visible From domain, not a per-vendor credential.

Your vendors may each require their own SPF include, DKIM CNAME/TXT records, custom return-path domain, or link-tracking domain. Those are separate authentication configurations. DMARC is where you set the domain-wide policy after those sources are configured to authenticate and align.

DMARC record syntax, tag by tag

A DMARC record is a semicolon-separated list of tag/value pairs. The version tag starts the record:

v=DMARC1; p=none

The current IETF DMARC specification is RFC 9989, which supersedes the earlier RFC 7489 and RFC 9091 documents. The IANA registry lists the active DMARC tags, including v, p, rua, ruf, adkim, aspf, sp, np, psd, and t; some historically common tags are now listed as historic. For practical interoperability, use the widely implemented core tags first and avoid adding an advanced tag unless you understand why it is needed. (datatracker.ietf.org)

v=DMARC1: protocol version

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

v=DMARC1

Do not use v=DMARC, v=DMARC2, or an SPF-style version value. A typo here means receivers may not recognize the record.

p=: policy for DMARC failures

The p tag is the policy request for mail that fails DMARC:

p=none
p=quarantine
p=reject

Use them as follows:

• p=none: monitor. Ask receivers to send reports without requesting enforcement.
• p=quarantine: ask receivers to treat failing mail suspiciously, commonly by placing it in spam or junk.
• p=reject: ask receivers to reject failing mail during delivery.

A safe rollout starts with p=none, then moves to p=quarantine, and finally to p=reject once your authorized sources pass DMARC consistently. Google explicitly permits a bulk sender’s DMARC enforcement policy to be none, while still requiring the sender to set up SPF, DKIM, and DMARC. (support.google.com)

rua=: aggregate report destination

rua requests aggregate feedback reports:

rua=mailto:dmarc-reports@example.com

This is the most useful reporting tag for nearly every organization. Aggregate reports show receivers’ observations of mail claiming to be from your domain, including authentication results and policy outcomes. They help reveal legitimate services you forgot about, unauthorized senders, and sources that authenticate but do not align. The aggregate-report specification describes these reports as XML documents delivered to the destination declared in the associated DNS record. (rfc-editor.org)

You can list more than one URI separated by commas, but start with one controlled destination where someone or a reporting service will actually review the data.

adkim= and aspf=: alignment mode

DMARC alignment compares the authenticated domain with the domain in the visible From address.

adkim=r; aspf=r

The values are:

• r for relaxed alignment.
• s for strict alignment.

With relaxed alignment, a subdomain can align with its organizational domain. For example, mail with From: updates@example.com can align with a DKIM d= domain of mail.example.com, depending on the organizational-domain relationship. Strict alignment requires an exact domain match.

Relaxed alignment is usually the practical default for an organization that uses subdomains, separate mailing systems, or a vendor with a custom DKIM signing subdomain. Strict alignment can be appropriate when you have a tightly controlled sending architecture and have verified every legitimate source. It is not inherently “more secure” if it creates failures that force teams to bypass the domain they intended to protect.

sp=: policy for subdomains

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

p=reject; sp=quarantine

Use it only when you deliberately want a subdomain policy that differs from the parent-domain policy. If you omit sp, the parent policy is the normal starting point for covered subdomains. A subdomain that needs distinct treatment can publish its own record, such as _dmarc.news.example.com.

This matters when marketing mail uses news.example.com, product notifications use notify.example.com, or a subsidiary uses a subdomain. Map those mail streams before changing the parent-domain policy, because a subdomain can have different senders and different authentication gaps.

Tags you usually do not need on day one

You may see ruf, fo, ri, pct, np, t, or psd in guides and generators. They are not required for a basic, durable deployment.

ruf requests message-specific failure reports, but these reports have privacy and operational considerations and are not a replacement for aggregate-report analysis. ri historically requested an aggregate reporting interval, but report timing remains receiver-dependent. The IANA registry marks pct, rf, and ri as historic, so avoid building a rollout plan around them. (iana.org)

The newer np, t, and psd tags solve more specialized cases involving non-existent subdomains, testing, and public suffix domains. They can be useful in advanced deployments, but they are not necessary to publish the core record shown in this guide. A simple, well-monitored record is better than an elaborate record no one can explain or maintain.

SPF, DKIM, and alignment: the part that makes DMARC pass

To understand DMARC results, separate the three identifiers involved in a typical email:

Visible From:        billing@example.com
SPF MAIL FROM:       bounce@mailer.example.net
DKIM signing domain: d=mail.example.com

The visible From address is what recipients see. SPF evaluates the SMTP envelope sender, commonly called MAIL FROM, Return-Path, or 5321.MailFrom. DKIM evaluates the domain in the d= value of the DKIM-Signature header. DMARC compares the visible From domain to the SPF and DKIM domains for alignment. (learn.microsoft.com)

Example 1: DKIM saves a message with an unaligned return path

From: invoices@example.com
MAIL FROM: bounce@vendor-mail.net
DKIM d=example.com (pass)

The SPF domain is vendor-mail.net, so SPF is not aligned with example.com. But DKIM passes with d=example.com, which aligns exactly with the visible From domain. DMARC passes.

This is why properly configured DKIM is often the easiest path for third-party senders. Many email providers let you publish vendor-provided DKIM records so they sign using your domain or a subdomain under it.

Example 2: SPF saves a message without DKIM

From: alerts@example.com
MAIL FROM: bounce@example.com
SPF: pass
DKIM: none

SPF passes and aligns because bounce@example.com and alerts@example.com share the same organizational domain under relaxed SPF alignment. DMARC passes.

Example 3: both authentication methods pass, but DMARC fails

From: hello@example.com
MAIL FROM: bounce@vendor-mail.net (SPF pass)
DKIM d=vendor-mail.net (pass)

Both underlying checks can pass, but neither authenticated domain aligns with example.com. DMARC fails. This is the classic vendor setup that looks healthy in a sending dashboard yet breaks as soon as you enforce DMARC.

A worked DMARC setup example

Assume a small software company owns northstarapps.com and sends email from three places:

1. Google Workspace for person-to-person mail.
2. An application email provider for password resets and receipts.
3. A marketing platform for product newsletters.

The company wants to stop outsiders from spoofing @northstarapps.com without risking a broken password-reset flow.

Step 1: inventory every system that uses the domain in From

Search your application code, CRM, support desk, billing system, marketing tool, recruiter tool, form builder, and status-page configuration. Include systems that only send occasionally, such as invoicing software and website contact-form plugins.

For each source, write down:

This inventory prevents the dangerous “we only send from one service” assumption. DMARC enforcement affects mail based on the visible From domain, no matter which internal team selected the sending tool.

Step 2: configure authentication at each sender

For each provider, complete its domain-authentication setup. That normally means publishing the provider’s DKIM records and, where supported, configuring a custom envelope/return-path domain so SPF can align too.

Do not indiscriminately add every provider to one SPF record. SPF has lookup and maintenance constraints, while DKIM can give each platform an independently verifiable signature. The important DMARC outcome is that at least one of SPF or DKIM passes and aligns for each legitimate stream. (learn.microsoft.com)

For application mail, use your provider’s authentication setup guide and test from the exact production From address—not merely from a provider preview screen. If you are integrating an email API, the relevant implementation details should live alongside your email API setup documentation, including the From domain, DKIM records, and bounce-domain configuration.

Step 3: publish a monitoring policy

Create this TXT record:

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

Create and protect the dmarc-reports@northstarapps.com mailbox, or use a reporting service that can receive and parse reports for you. Avoid sending these reports to an individual employee’s ordinary inbox; report volume, staff changes, and access control make that fragile.

If you send reports to a domain other than your own, the external destination needs to authorize report receipt through DNS. This safeguard prevents a domain owner from directing reports about its mail to an arbitrary third party. (rfc-editor.org)

Step 4: send controlled test mail and inspect headers

Send one message from each legitimate system to a test inbox you can inspect. In Gmail, open the message menu and choose Show original; Gmail displays separate SPF, DKIM, and DMARC results. Gmail documentation specifically notes that these authentication mechanisms appear as separate lines in Show original. (developers.google.com)

For each message, record:

SPF: PASS / FAIL and domain evaluated
DKIM: PASS / FAIL and d= domain
DMARC: PASS / FAIL
From: visible domain

A successful test is not simply “the message arrived.” The successful result is DMARC: PASS, with evidence that an aligned SPF or DKIM identifier caused the pass.

Step 5: analyze aggregate reports before enforcement

Aggregate reports will show receiver observations grouped by source IP and authentication outcome. Look for sources you recognize, then investigate sources you do not.

Classify each entry:

• Authorized and aligned: keep monitoring.
• Authorized but failing alignment: repair the sender configuration.
• Authorized but failing SPF/DKIM: correct DNS or provider configuration.
• Unknown or unauthorized: assess whether it is abuse, a forgotten vendor, forwarding behavior, or an internal system that must stop sending.

Do not approve an unknown IP just because it appears repeatedly. A consistent spoofing source is still unauthorized. Conversely, do not assume every DMARC failure is malicious: mail forwarding and mailing lists can alter a message after it was authenticated, which is a known interoperability challenge for DMARC. (dmarc.org)

Step 6: move toward enforcement

Once legitimate mail streams consistently pass, change the record in stages:

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

Then, after continued review:

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

Do not treat a calendar deadline as proof that you are ready. Move when your reports and direct tests demonstrate that your authorized sources are aligned. For a brand that does not send mail at all, a p=reject policy may be suitable sooner—but first verify that no legitimate service uses the domain silently.

How to check that the record is published correctly

Use a public DNS query after saving your record:

dig +short TXT _dmarc.example.com

On Windows, use:

nslookup -type=TXT _dmarc.example.com

You want to see the full DMARC value beginning with v=DMARC1. DNS tools sometimes display a long TXT value as multiple quoted strings. That does not necessarily mean you have multiple DMARC records; DNS resolvers concatenate TXT character strings within one record. What matters is the final resolved text and whether there is only one usable DMARC policy at that name.

Then validate it at three levels:

1. DNS level: _dmarc.example.com resolves to the intended TXT record.
2. Message level: real test email shows DMARC pass in the recipient’s authentication results.
3. Report level: aggregate reports identify expected sources and do not reveal unresolved legitimate failures.

A DNS validator can help catch syntax mistakes, but it cannot prove that every mail stream is aligned. You still need live-message header checks and report review.

Common DMARC record mistakes and their fixes

Publishing the record at the root domain

Wrong:

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

Right:

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

The root-domain TXT record is used for other purposes too, including SPF. DMARC discovery uses the _dmarc label.

Using the wrong visible From domain

A marketing platform may authenticate mailer.example.com, while your campaign From address says brand.com. If brand.com is the visible From domain, publish and evaluate DMARC for brand.com, not just the platform’s sending domain.

Assuming SPF pass automatically means DMARC pass

SPF needs alignment with the visible From domain. Check the envelope sender/Return-Path domain, not just whether the SPF line says “pass.” Microsoft’s DMARC guidance explicitly distinguishes the MAIL FROM identity from the visible From identity and explains the alignment requirement. (learn.microsoft.com)

Enforcing before authenticating vendors

Changing immediately to p=reject can protect the domain from spoofing, but it can also reject transactional, support, or campaign mail from services that have not been configured for aligned SPF or DKIM. Start at p=none, fix the data, and then enforce.

Sending reports to an unprepared external address

If rua points outside your own domain, report delivery may require external-destination authorization. Use the reporting provider’s exact DNS authorization instructions rather than assuming the mailbox address alone is enough. (rfc-editor.org)

Treating reports as a one-time setup task

Your sending stack changes when a team adds a CRM integration, support tool, billing provider, or new mail API. Review DMARC reporting after material changes, especially before launching a campaign or changing a visible From domain.

DMARC examples for common situations

Monitoring an active domain

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

Use this while discovering and correcting authorized mail streams.

Protecting a fully audited sending domain

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

Use this after reporting and tests show legitimate sources reliably pass.

Applying a different policy to subdomains

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

This keeps strong protection for the parent domain while requesting quarantine for uncovered subdomains. Use it only if that difference matches your actual subdomain inventory.

A separate marketing subdomain

At _dmarc.news.example.com:

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

This can be a useful transitional design when marketing uses From: newsletter@news.example.com and needs independent monitoring. It does not remove the need to protect example.com; it scopes the policy to the subdomain’s visible From addresses.

Why DMARC matters for deliverability as well as spoofing protection

DMARC is primarily an identity and anti-spoofing control, but it also intersects with sender requirements at major mailbox providers. Gmail requires bulk senders—those sending more than 5,000 messages per day to Gmail accounts—to set up SPF, DKIM, and DMARC, and it allows a DMARC policy of none for that requirement. Gmail also requires bulk senders to keep reported spam rates below 0.30%. (support.google.com)

That does not mean a DMARC record alone guarantees inbox placement. Inbox placement also depends on content, recipient engagement, complaints, list quality, sending behavior, IP/domain reputation, and receiver-specific filtering. But a correctly aligned authentication setup removes a major technical cause of distrust and gives you the reporting data needed to detect unauthorized use of your domain.

For senders changing email providers, plan domain authentication as part of the migration rather than after launch. The operational question is not merely whether the platform can send email; it is whether the exact production From domain, DKIM domain, envelope sender, and tracking domains fit your authentication and reputation plan.

A practical DMARC deployment checklist

Before publishing:

• List every product, vendor, and mailbox system that sends with your domain in From:.
• Configure SPF and/or DKIM at every legitimate sender.
• Confirm that at least one passing identifier aligns with the visible From domain.
• Create a monitored aggregate-report destination.
• Decide whether parent and subdomains need separate policies.

After publishing p=none:

• Query _dmarc.yourdomain.com to confirm DNS resolution.
• Send real test mail from each source and inspect authentication headers.
• Review aggregate reports for recognized and unrecognized sources.
• Fix vendors that pass SPF/DKIM but fail alignment.
• Document who owns each authorized mail stream.

Before using p=quarantine or p=reject:

• Confirm transaction, support, billing, product, and marketing messages all pass DMARC.
• Review infrequent senders, not only high-volume systems.
• Confirm forwarding or mailing-list edge cases that matter to your users.
• Keep monitoring after enforcement, because systems and vendors change.

Conclusion

The best DMARC record example for most organizations is not the most aggressive one—it is the one you can verify. Start with v=DMARC1; p=none, request aggregate reports, make every legitimate sender pass aligned SPF or DKIM, and use message-header tests to prove the result.

When the data shows that authorized mail is covered, move deliberately to p=quarantine and then p=reject. That sequence turns DMARC from a copied DNS string into a maintained control that protects your domain from impersonation without breaking the messages your business depends on.

FAQ

What is the simplest DMARC record example?

Use v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. Add adkim=r; aspf=r when you want to state the normal relaxed alignment choices explicitly. Publish it as a TXT record at _dmarc.yourdomain.com.

Should I start DMARC with p=reject?

Usually no. Start with p=none if the domain sends mail, review aggregate reports, and confirm that every authorized sender has aligned SPF or DKIM. A domain that truly never sends mail can often move to enforcement sooner, after checking for forgotten services.

Does DMARC require both SPF and DKIM to pass?

No. DMARC passes if either SPF or DKIM passes and aligns with the visible From domain. Both can technically pass but DMARC can still fail if neither domain aligns. (learn.microsoft.com)

Where do I put a DMARC record in DNS?

Create a TXT record at _dmarc.yourdomain.com. In many DNS dashboards, enter _dmarc as the host/name field because the dashboard appends your domain automatically.

How do I know my DMARC setup worked?

Check that the TXT record resolves, send real mail from every approved sender, inspect headers for DMARC: PASS, and review aggregate reports to confirm your legitimate traffic is aligned and unknown traffic is investigated.