DMARC Record Lookup: Check, Read, and Fix Your DNS Policy

A DMARC record lookup tells you whether a domain publishes a usable email-authentication policy in DNS—but a visible record alone does not prove that legitimate mail passes DMARC. This guide shows how to query the right hostname, decode the result, identify common DNS mistakes, and validate the SPF, DKIM, and alignment conditions that make DMARC work.

What a DMARC record lookup checks

DMARC—Domain-based Message Authentication, Reporting, and Conformance—is a DNS-based policy system for the domain shown in an email’s visible From: header. It connects that visible domain to SPF and DKIM authentication, lets the domain owner request handling for failures, and can request feedback reports from receiving mail systems. (rfc-editor.org)

A DMARC lookup is therefore a lookup for a TXT record, not an MX record, SPF record, or DKIM key. For example.com, the normal query name is:

_dmarc.example.com

A successful lookup may return a value such as:

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

That string answers four immediate questions:

1. Is a DMARC record published? A record must be available at the _dmarc label for the domain being evaluated, or a policy may be discovered at the organizational domain instead.
2. Is the syntax recognizably DMARC? The record begins with v=DMARC1 and has a policy instruction such as p=none, p=quarantine, or p=reject.
3. What does the owner request for failures? The p tag is the requested policy; receivers can use it in their own handling decisions.
4. Where should aggregate reports go? If rua appears, it supplies one or more destinations for aggregate DMARC feedback.

The lookup is public. You do not need access to the domain’s email account, DNS dashboard, or DMARC vendor to query it. What you do need to remember is that DMARC is evaluated per message. A valid DNS record is only the policy and reporting side of the system; passing mail also needs an aligned SPF or DKIM result. (rfc-editor.org)

How to run a DMARC record lookup

You can use a web-based DMARC checker, your DNS host’s record browser, or a command-line DNS tool. A web checker is convenient for a one-off inspection, while command-line queries are better when you need repeatable evidence, want to specify a resolver, or are troubleshooting a change that has not appeared everywhere yet.

Use dig on macOS, Linux, or systems with BIND tools

Run this command, replacing example.com with the domain you want to inspect:

dig +short TXT _dmarc.example.com

dig is a DNS lookup utility, and BIND documents it as the most versatile of its command-line lookup tools. The +short option keeps the output focused on the returned TXT value. (bind9.readthedocs.io)

To query a particular recursive resolver rather than whichever resolver your computer uses, append its IP address:

dig +short TXT _dmarc.example.com @1.1.1.1

For troubleshooting, omit +short so you can see the DNS status, answer section, nameserver information, and TTL:

dig TXT _dmarc.example.com

Look for status: NOERROR plus an ANSWER SECTION containing a TXT record. NXDOMAIN means the queried name does not exist. NOERROR with no answer means the name may exist but has no TXT record at that label, which is still effectively “no DMARC record at this exact name.”

Use nslookup on Windows

In Command Prompt, use:

nslookup -type=TXT _dmarc.example.com

Windows documents nslookup as a DNS diagnostic command, and its set type or set querytype functionality changes the resource-record type being requested. (learn.microsoft.com)

If your nslookup version does not accept -type=TXT, use interactive mode instead:

nslookup
set type=TXT
_dmarc.example.com

The desired result is a TXT value beginning with v=DMARC1. Do not mistake unrelated TXT results—such as domain-verification strings—for the DMARC policy. The hostname must be _dmarc.example.com, not merely example.com.

Use PowerShell on Windows

PowerShell provides a clearer object-based lookup:

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

To compare what a specific resolver returns, use its server address:

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

Microsoft documents Resolve-DnsName as a cmdlet that performs DNS queries and is functionally similar to nslookup. (learn.microsoft.com)

Use a web lookup tool carefully

A web-based DMARC lookup tool is useful when you want tag explanations, syntax warnings, or an at-a-glance summary. It is not automatically authoritative, however. Different tools may query different recursive resolvers, cache results for different durations, or apply their own validation rules.

For a DNS change you just made, compare a checker’s result with a direct dig, nslookup, or Resolve-DnsName query. If results differ, inspect the record at your authoritative DNS provider first, then check the published result from more than one recursive resolver. DNS caching means a resolver can continue to serve a prior value until the record’s TTL expires.

Read the output from a DMARC lookup

A returned value can look intimidating because it is a semicolon-separated list of tag=value pairs. Start by separating record validity, policy strength, reporting, and alignment settings.

Here is an example:

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

Read it as follows:

The current IETF DMARC specification is RFC 9989, which supersedes the earlier RFC 7489 and defines DMARC’s policy-record behavior and identifier alignment. Aggregate reporting is defined separately in RFC 9990, and message-specific failure reporting is covered in RFC 9991. (rfc-editor.org)

A “record found” result is not the same as “DMARC passes”

A lookup tool can confirm DNS publication and often validate basic syntax. It cannot, by DNS inspection alone, prove that your CRM, support desk, billing platform, marketing tool, application server, and employee mail service all authenticate correctly.

DMARC passes when at least one of these paths succeeds for the message:

• SPF passes and aligns with the visible From: domain.
• DKIM passes and aligns with the visible From: domain.

In other words, SPF can pass but DMARC can still fail if the SPF-authenticated domain does not align with the domain in From:. The same is true for DKIM. DMARC’s defining added control is this alignment with the author domain, not merely the existence of SPF or DKIM somewhere in the message. (rfc-editor.org)

DMARC record syntax: the tags that matter most

A practical DMARC record usually needs only a few tags. Begin with the mandatory core, add aggregate reporting, and use stricter controls only when your mail inventory supports them.

Required core tags

A basic monitoring record is:

v=DMARC1; p=none

v=DMARC1 identifies the record as DMARC. p sets the requested policy for the domain. The normal values are:

• p=none — monitoring mode; it requests no specific enforcement action while allowing reporting and visibility.
• p=quarantine — asks receivers to treat failing mail as suspicious, commonly by putting it in spam or another quarantined state.
• p=reject — asks receivers to reject mail that fails DMARC.

Google describes the available handling choices as reject, quarantine, or normal delivery, and its DMARC setup guidance gives a record with these policy concepts in practice. (support.google.com)

A receiver ultimately controls its own mail handling. Therefore, p=reject is a strong and important public request, but it is not a mechanical guarantee that every receiver will take an identical action on every message.

Aggregate reporting: rua

For most domain owners, rua is the next tag to add:

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

Aggregate reports are structured XML feedback reports produced by participating receivers. They summarize messages that used your domain, typically grouping information such as source IP, authentication results, policy results, and message counts. RFC 9990 defines aggregate reporting and states that the destination is declared through the associated DNS record. (rfc-editor.org)

Do not route these reports to an employee’s personal inbox. A dedicated mailbox, Google Group, shared inbox, or DMARC reporting service is safer operationally. Google notes that organizations can receive many reports and recommends using a group or dedicated mailbox; larger organizations can receive hundreds or thousands daily. (support.google.com)

If rua points to an address outside the domain being protected—for example, rua=mailto:reports@vendor.example for a policy on brand.example—the external destination needs additional DNS authorization under the reporting destination’s domain. This exists to prevent a domain owner from directing reports about another domain to an arbitrary mailbox. Treat this as a configuration requirement to verify with your reporting provider rather than assuming the rua address alone is sufficient. (rfc-editor.org)

Subdomain policy: sp

The sp tag controls the requested policy for subdomains that do not publish their own DMARC policy record. For example:

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

This asks for rejection for mail using example.com while requesting quarantine for mail using an uncovered subdomain such as news.example.com. If sp is absent, the domain policy is generally the effective fallback for subdomains that do not have their own applicable record. The exact policy-discovery path is governed by the DMARC standard and the organizational-domain relationship. (rfc-editor.org)

Use sp only when you understand all subdomains that send mail. A forgotten transactional subdomain is a common reason an enforcement rollout disrupts valid mail.

Alignment controls: adkim and aspf

DMARC supports two alignment modes:

adkim=r; aspf=r

or:

adkim=s; aspf=s

r means relaxed alignment and s means strict alignment. In relaxed mode, related domains that share the same organizational domain can align; in strict mode, the authenticated domain must exactly match the visible From: domain. RFC 9989 defines these as the two alignment modes that determine whether a passing SPF or DKIM identifier can support a DMARC pass. (rfc-editor.org)

For a new deployment, relaxed alignment is usually the safer starting point because legitimate services often sign with a subdomain. Strict alignment is a valid security choice, but only after you verify every authorized sender’s Return-Path domain and DKIM d= domain.

Tags you may see in legacy records

Older DMARC examples commonly include pct, ri, rf, fo, or ruf. Some remain relevant in deployed records, but the IANA registry now marks pct, ri, and rf as historic, while ruf is active under the current specifications. (iana.org)

That does not mean you must urgently remove every historic tag from an existing record. It means you should not build an enforcement plan around the assumption that every receiver will implement those historical controls consistently. For a durable setup, center the record on v, p, sp when needed, adkim, aspf, and rua, then use reporting to guide policy changes.

Worked example: look up and evaluate a record

Assume you manage northstar-example.com and want to check whether it is ready for enforcement. Run:

dig +short TXT _dmarc.northstar-example.com

Imagine the response is:

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

Here is the correct interpretation:

1. The query name is correct. You queried _dmarc.northstar-example.com, not the root domain.
2. A DMARC policy exists. v=DMARC1 identifies it as a DMARC policy record.
3. The record is in monitoring mode. p=none means the owner is asking receivers to collect and report results, not to quarantine or reject failures.
4. Aggregate reports have a destination. The rua address is intended to receive aggregate reports.
5. Alignment is relaxed. Both adkim=r and aspf=r permit organizational-domain alignment rather than requiring exact domain equality.
6. The lookup alone does not show readiness for p=reject. You still need to inspect report data and confirm every legitimate sender has aligned SPF or DKIM.

Now imagine the organization sends email from four systems:

Send a test email from each system to a mailbox you control. Open the full message headers and locate Authentication-Results. A good result may look conceptually like this:

Authentication-Results: mx.receiver.example;
  dkim=pass header.d=northstar-example.com;
  spf=pass smtp.mailfrom=mail.northstar-example.com;
  dmarc=pass header.from=northstar-example.com

The exact header formatting differs by receiver, but the decision is simple: look for dmarc=pass and inspect which aligned SPF or DKIM identifier made it pass. If one legitimate source produces dmarc=fail, fix that source before increasing the policy.

A cautious progression is:

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

then, after reports show legitimate traffic is authenticating:

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

and finally:

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

This sequence is operational guidance, not a protocol timer. Stay in each stage long enough to capture normal business cycles: invoices, password resets, support replies, campaign sends, automated alerts, vendor notifications, and any low-frequency application email.

How to tell whether the lookup result is good

Use this checklist after every DMARC record lookup.

Green flags

• The lookup returns exactly one usable DMARC policy record at _dmarc.yourdomain.com.
• The record begins with v=DMARC1 and includes a valid p value.
• rua directs aggregate reports to a mailbox or reporting provider you actively monitor.
• All legitimate sending platforms show dmarc=pass in representative message headers.
• Your reports do not show unknown services sending substantial legitimate volume using your domain.
• Your desired enforcement posture matches the record: p=none for monitoring, p=quarantine for partial enforcement, or p=reject for strongest requested enforcement.

Yellow flags

• The record is valid but has p=none indefinitely. That is valuable for visibility but does not ask receivers to quarantine or reject spoofed mail.
• The record has no rua, so you have much less operational visibility into who is sending with your domain.
• A third-party provider passes SPF but uses its own unrelated Return-Path domain.
• DKIM passes but signs with an unrelated provider domain instead of your domain or an aligned subdomain.
• You only tested employee mail, not application, marketing, support, finance, or vendor mail.

Red flags

• No TXT record exists at _dmarc.yourdomain.com.
• The record has malformed syntax, an unsupported version marker, or no usable policy tag.
• More than one DMARC policy record is returned at the same lookup name.
• You published the record at yourdomain.com rather than _dmarc.yourdomain.com.
• A valid sender returns dmarc=fail after you switch to quarantine or reject.
• Your rua address is external but the required destination authorization has not been configured.

The most common DMARC lookup failures and fixes

A lookup is most useful when it tells you why a record is absent, invalid, or misleading. These are the failures that repeatedly cause confusion.

1. Querying the wrong hostname

Symptom: You run dig TXT example.com and see lots of TXT values but no DMARC policy.

Cause: DMARC is published under _dmarc, not normally at the root name.

Fix: Query:

dig +short TXT _dmarc.example.com

Do not add www, an email address, or a mail server hostname unless you are intentionally checking a subdomain’s policy. The visible From: domain drives DMARC evaluation; From: person@news.example.com may require you to inspect _dmarc.news.example.com as well as understand the organizational-domain fallback.

2. Publishing multiple DMARC TXT records

Symptom: A lookup returns two separate strings that each begin with v=DMARC1.

Cause: Someone added a second record instead of editing the existing one, often during a vendor migration or after copying a setup guide.

Fix: Consolidate your tags into one DMARC policy record at that hostname. A DMARC record is one policy expression; splitting p into one TXT record and rua into another is not a valid substitute for a single complete record.

This problem is especially easy to create in DNS dashboards that show each TXT record on its own row. Review the host/name column as well as the value column before saving.

3. Confusing DNS quotation marks and split strings

Symptom: dig prints a record in multiple quoted pieces, such as:

"v=DMARC1; p=reject; rua=mailto:dmarc@exa" "mple.com"

Cause: DNS tooling may display long TXT data as multiple character strings. TXT strings have size constraints, but applications can join multiple strings when treating them as a single TXT record. (cloudflare.com)

Fix: Do not assume the DMARC value is broken just because the output has adjacent quoted segments. Check whether the segments concatenate into one syntactically correct record. In your DNS provider’s editor, enter the record according to that provider’s interface: some want the plain value without outer quotes, while others show quotes automatically.

4. Using the full domain in a DNS host field that already appends the zone

Symptom: You intended to create _dmarc.example.com, but your provider actually published _dmarc.example.com.example.com.

Cause: Many DNS dashboards expect only a relative host label such as _dmarc; others expect a fully qualified domain name. The correct input is provider-specific.

Fix: Check the provider’s “record name” preview or published-zone view. The final DNS name must be exactly _dmarc.example.com. Then verify externally with a command-line lookup.

5. Expecting a policy change to fix an authentication failure

Symptom: You change p=none to p=reject, but a legitimate app’s messages still fail DMARC.

Cause: A policy tag cannot make SPF or DKIM pass, and it cannot create alignment. It only tells receivers how the domain owner requests they handle messages that fail DMARC.

Fix: Configure the sending platform’s custom authentication domain. In practical terms, that often means enabling the vendor’s DKIM setup, adding the vendor-provided DNS records, and using an aligned bounce or Return-Path domain where appropriate. Then resend a test and inspect Authentication-Results again.

DMARC policy, SPF, DKIM, and alignment: what a lookup cannot see

The DNS record is the public instruction set. Email headers and DMARC reports show whether real messages comply with it.

SPF path

SPF evaluates an envelope-sender-related domain, often visible as smtp.mailfrom or Return-Path in message headers. For DMARC to pass through SPF, SPF must pass and that SPF domain must align with the visible From: domain under the selected alignment mode.

Example:

From: updates@northstar-example.com
Return-Path: bounce@mailer.vendor-example.net
spf=pass

SPF may pass for mailer.vendor-example.net, but it is not aligned with northstar-example.com. Unless aligned DKIM passes, DMARC can fail.

DKIM path

DKIM adds a signature and declares a signing domain in the d= value. For DMARC, the DKIM signature must pass and its d= domain must align with the visible From: domain.

Example:

From: updates@northstar-example.com
DKIM-Signature: d=northstar-example.com; s=mail1; ...
dkim=pass

That is an aligned DKIM result for From: northstar-example.com. With relaxed alignment, a signing domain such as mail.northstar-example.com can also align with northstar-example.com; strict alignment requires an exact match. (rfc-editor.org)

Why DKIM is often the durable option for third-party senders

Many third-party platforms cannot make SPF align by default because they use a shared provider-owned bounce domain. Their custom DKIM capability is often the cleaner route to DMARC alignment. That is not a universal rule—some providers support custom return-path domains too—but it is a strong reason to verify both authentication paths instead of assuming an SPF “pass” solves DMARC.

Google’s guidance likewise emphasizes enabling SPF and/or DKIM before DMARC and warns that enabling DMARC without those foundations can cause delivery problems. (support.google.com)

Using DMARC reports after a lookup

A DMARC record lookup tells you the requested reporting destination. The reports themselves tell you whether your rollout is safe.

Aggregate reports are not designed for casual reading in a mail client. They are XML documents, sometimes compressed, and can arrive from multiple receiving organizations. RFC 9990 defines their XML format and report-delivery model. (rfc-editor.org)

When you examine reports—directly, through a parser, or in a DMARC monitoring platform—focus on these fields:

1. Source IP address: Which infrastructure sent the messages?
2. Count: How much volume did that source send?
3. Header From domain: Which domain did recipients see?
4. SPF result and domain: Did SPF pass, and for which domain?
5. DKIM result and domain: Did DKIM pass, and for which domain?
6. DMARC disposition: What policy was found and what action did the reporting receiver record?

Classify each source before changing enforcement:

• Known, legitimate, and aligned: Keep monitoring it.
• Known, legitimate, but failing: Fix its DKIM, SPF, or visible From configuration.
• Unknown and failing: Investigate. It may be unauthorized use, a forgotten system, or spoofing.
• Unknown but passing: Investigate carefully; it may indicate an authorized service you did not inventory, delegated infrastructure, or a configuration that deserves review.

Message-specific failure reports may contain more granular information, but they have privacy and operational implications. Do not rely on their universal availability or use them as your only monitoring method. Aggregate reports are the standard baseline for a DMARC deployment. (rfc-editor.org)

A safe DMARC lookup and rollout workflow

Use this repeatable process for your own domain or when auditing a client’s domain.

1. Inventory every sender. List human mailbox providers, transactional-email services, marketing platforms, CRM tools, support desks, payment systems, forms, monitoring tools, and infrastructure alerts. Include every domain and subdomain used in visible From addresses.
2. Run the DNS lookup. Query _dmarc.yourdomain.com and every sending subdomain that may have a separate policy.
3. Validate the single policy record. Confirm the record begins with v=DMARC1, contains the intended p value, and has a monitored rua destination.
4. Start with observability. If the domain does not have a trustworthy inventory, publish p=none with aggregate reporting rather than immediately enforcing.
5. Test real systems. Send representative mail from each platform, not just a single mailbox. Read the received headers for dmarc=pass or dmarc=fail.
6. Review report sources. Map IP addresses and signed domains back to your vendors, systems, and authorized infrastructure.
7. Fix alignment failures. Turn on custom DKIM, configure custom return-path domains where supported, and make the visible From domain consistent with your authenticated domains.
8. Move toward enforcement. Consider p=quarantine and then p=reject only when the legitimate sources identified in reports pass DMARC reliably.
9. Keep monitoring. New SaaS tools, agency campaigns, acquisitions, domain changes, and DNS edits can introduce new failures after enforcement.

For senders with material Gmail volume, this work is also a delivery requirement, not merely a brand-protection project. Gmail’s sender guidelines state that senders sending more than 5,000 messages per day to Gmail accounts must set up SPF, DKIM, and DMARC, with a DMARC policy that may be set to none. (support.google.com)

When to use a lookup tool, a DNS query, or email headers

Each method answers a different question.

A mature audit uses all five. Start with a DMARC record lookup because it is fast and public. Then move outward: confirm published DNS, test message headers, and review reports before deciding that the domain is protected.

Conclusion

A DMARC record lookup should take seconds, but interpreting it correctly prevents expensive mistakes. Query _dmarc.yourdomain.com as a TXT record, make sure one valid policy record is present, read p, rua, adkim, aspf, and sp in context, and avoid treating DNS publication as proof of mail authentication.

The practical goal is not merely to display v=DMARC1. It is to reach a state where every legitimate sender has aligned SPF or DKIM, unauthorized use is visible in reports, and your policy can safely request quarantine or rejection for failing mail. That is when the lookup has become a real email-security control rather than a DNS checkbox.

FAQ

How do I look up a DMARC record?

Query the TXT record at _dmarc.yourdomain.com. For example, run dig +short TXT _dmarc.example.com on systems with dig, nslookup -type=TXT _dmarc.example.com in Windows Command Prompt, or Resolve-DnsName -Name _dmarc.example.com -Type TXT in PowerShell. (bind9.readthedocs.io)

What does no DMARC record found mean?

It means no usable DMARC TXT record was returned from the name you queried. First verify that you queried _dmarc.domain.com, not the root domain. If that is correct, publish a record such as v=DMARC1; p=none; rua=mailto:dmarc-reports@domain.com, then verify it through public DNS.

Is p=none a valid DMARC record?

Yes. p=none is valid monitoring mode and can request aggregate reporting, but it does not ask receivers to quarantine or reject mail that fails DMARC. It is commonly used while you identify and fix legitimate sending sources. (support.google.com)

Why does SPF pass but DMARC fail?

DMARC requires alignment as well as authentication. SPF can pass for a provider-owned Return-Path or envelope domain that does not align with the visible From: domain. In that case, an aligned passing DKIM signature can still make DMARC pass; otherwise, the message fails DMARC. (rfc-editor.org)

How long should I stay at p=none before using p=reject?

There is no universal number of days. Stay in monitoring until reports and header tests cover every legitimate sender and normal sending cycle, including low-frequency billing, support, application, and vendor messages. Move to enforcement only after you can explain and resolve legitimate failures.