How to Check Your DMARC Record

Why setting up DMARC isn't enough

DMARC ties SPF and DKIM together with the From header address and tells receivers what to do with emails that fail authentication. But deploying a DMARC record is just the first step. Policies change, new sending services get added, and SPF or DKIM underneath may stop passing alignment — without regular checks, you won't know until deliverability tanks.

A misconfigured DMARC record is worse than none at all. A strict policy (p=reject) with broken alignment causes receivers to reject your legitimate emails. Conversely, p=none without a reporting address gives you zero visibility — you have no idea who's sending on behalf of your domain or whether authentication is working.

This article covers three ways to verify your DMARC record: online analyzers, command-line queries, and email header inspection. For each method, you'll learn what to look for and how to interpret the results.

Where to find your DMARC record

A DMARC record is a TXT record in DNS published on the _dmarc subdomain. For example.com, it lives at:

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

Unlike SPF (published on the domain itself) or DKIM (where you need to know the selector), DMARC always has the same address: _dmarc.{domain}. This makes verification straightforward.

Checking with an online analyzer

The fastest way to get a complete picture. An analyzer queries DNS for the DMARC record, parses individual tags, validates syntax and values, and flags problems.

What an analyzer checks

Check your DMARC record with SPF Monitor's analyzer — enter your domain and instantly see the full record breakdown, tag validation, and any issues detected.

Checking via command line

A DMARC record is a standard TXT record in DNS. You can query it directly from the terminal.

Linux and macOS: dig

dig _dmarc.example.com TXT +short

Output:

"v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:example.com@rua.spfmonitor.com; ruf=mailto:example.com@ruf.spfmonitor.com"

Windows: nslookup

nslookup -q=txt _dmarc.example.com

Windows: PowerShell

Resolve-DnsName -Name _dmarc.example.com -Type TXT

What to look for

1. Does a record exist? If DNS returns NXDOMAIN, the domain has no DMARC record. Receivers will fall back to the organizational domain's DMARC policy — and if that doesn't have one either, emails from your domain have no DMARC protection.
2. Does it start with v=DMARC1? This tag must come first. A record without it is not a valid DMARC record (RFC 7489, Section 6.3).
3. Does it contain p=? The policy is the only mandatory tag (besides v=). Without it, the record is invalid.
4. Does it contain rua=? Without a reporting address, you have no insight into how receivers evaluate your emails. DMARC without rua is like a security camera with no recording.

Command-line queries show you the raw record, but don't perform deep validation — they won't verify external report recipient authorization, check tag values, or validate address formats. That's what analyzers are for.

Checking email headers

A valid record in DNS doesn't guarantee DMARC authentication actually works in practice. The definitive answer comes from inspecting headers of received emails.

How to check

1. Send an email from the domain you want to verify to an address at a major provider (Gmail, Outlook).
2. In the received email, view the source / headers.
3. Find the Authentication-Results header:

Authentication-Results: mx.google.com;
    dmarc=pass (p=REJECT dis=NONE) header.from=example.com;
    spf=pass (google.com: domain of info@example.com designates 198.51.100.10 as permitted sender);
    dkim=pass header.d=example.com header.s=mail2024

Interpreting the results

The dis= (disposition) value shows what the receiver actually did with the message: NONE (delivered), QUARANTINE (spam), or REJECT (bounced). Compare it with your p= policy — if they differ, the receiver may be applying its own rules.

Common problems found during verification

Multiple DMARC records

A domain must have exactly one DMARC record on the _dmarc subdomain (RFC 7489, Section 6.6.3). Two or more cause receivers to ignore the DMARC record entirely — as if it didn't exist.

# Wrong — two records
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:example.com@rua.spfmonitor.com"
_dmarc.example.com TXT "v=DMARC1; p=reject"

# Correct — one merged record
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:example.com@rua.spfmonitor.com"

Missing or invalid v=DMARC1 tag

The v=DMARC1 tag must be first in the record and must have the exact value DMARC1. Common mistakes: v=dmarc1 (lowercase), v=DMARC (missing version number), or placing the tag anywhere other than the beginning.

Missing p= policy

The p= tag is mandatory. Without it, the record is invalid. Valid values:

• none — monitoring mode, receivers don't change behavior
• quarantine — suspicious emails moved to spam
• reject — reject emails that fail authentication

The typo quarentine instead of quarantine is surprisingly common and renders the record invalid.

Invalid reporting addresses

The rua= and ruf= tags must contain URIs with a mailto: prefix:

# Wrong
rua=dmarc@example.com

# Correct
rua=mailto:dmarc@example.com

If the reporting address points to a domain other than the one the DMARC record belongs to, the receiver verifies authorization via the DNS record example.com._report._dmarc.{target-domain} (RFC 7489, Section 7.1). Without this record, receivers won't send reports.

SPF Monitor handles this authorization automatically — just set rua=mailto:example.com@rua.spfmonitor.com and reports start flowing.

Duplicate tags

Each tag may appear in the record only once. Duplicate tags cause unpredictable behavior — different receivers may use different values:

# Wrong — duplicate policy
v=DMARC1; p=none; rua=mailto:example.com@rua.spfmonitor.com; p=reject

p=none without reports

The p=none policy provides no protection on its own — it only signals to receivers not to block emails. Its value lies in the DMARC reports that give you visibility into authentication. Without a rua= tag, p=none is a pointless record — no protection, no visibility.

DMARC without working SPF and DKIM

DMARC builds on SPF and DKIM. If neither protocol passes with valid alignment (domain match with the From header), DMARC authentication fails regardless of how correctly the DMARC record itself is configured. Before verifying your DMARC record, make sure you have working SPF and DKIM.

When to verify your DMARC record

• After initial deployment — verify syntax and confirm reports are arriving
• Before tightening the policy — moving from p=none to p=quarantine or p=reject directly impacts deliverability; verify SPF and DKIM work for all legitimate senders first
• After adding or removing email services — new services can break alignment if they send from a different domain
• After DNS migration — verify the _dmarc record was transferred with the correct content
• Regularly — at least monthly; ideally on an ongoing basis through automated monitoring

DMARC reports serve as continuous verification — every day, you receive feedback from receivers about how your emails are passing authentication.

DMARC verification is part of the bigger picture

A valid DMARC record is essential, but it doesn't work in isolation. DMARC only functions when SPF and DKIM are properly configured underneath it. If your DMARC record checks out, verify your SPF record and DKIM record as well.

Get a complete view of your domain's authentication status with a domain analysis — check SPF, DKIM, and DMARC in one place and identify any weak spots.