# MXToolbox DMARC check: interpret a DMARC record lookup

> MXToolbox DMARC check: run a public record lookup, interpret its DNS-visible result, correct the published record, and retest safely for your domain.

An MXToolbox DMARC check looks up the DMARC TXT record published for a domain, then parses and diagnoses that public DNS record. Use it to confirm what is visible at lookup time and to find record-level issues before changing DNS. It cannot prove that a production message passed DMARC, that every sender is authorized, or that a receiving mailbox provider accepted a message.

## Quick takeaways

- MXToolbox's DMARC Record Lookup checks the public DMARC record for the domain you submit.
- A public record lookup establishes DNS-visible configuration, not delivered-message authentication.
- DMARC evaluation depends on SPF or DKIM authentication and identifier alignment with the visible From domain.
- Correct a record only after confirming the exact DNS owner and the current intended policy.
- Retest after the authoritative DNS answer changes, then validate a real message and review aggregate reports.

## What this tool checks

The [MXToolbox DMARC Check Tool](https://lookup.mxtoolbox.com/dmarc.aspx?source=dmarcsetupno6) accepts a domain name. MXToolbox says its DMARC record check parses, displays, and diagnoses the domain's DMARC record. Its [DMARC Email Tools documentation](https://mxtoolbox.com/dmarc/dmarc-email-tools) describes the same public-record workflow.

A DMARC record is a TXT record at `_dmarc.yourdomain.com`. [RFC 9989 defines DMARC record discovery, policy handling, and identifier alignment](https://www.rfc-editor.org/rfc/rfc9989.html). The lookup can show the record currently visible through public DNS and any record-level diagnostic response returned by the service.

A public lookup has a strict evidence boundary. It cannot see:

- Which application, ESP, or gateway sent a particular production message.
- Whether that message carried a valid DKIM signature or SPF-authenticated return path.
- The receiver's `Authentication-Results` evaluation.
- Aggregate-report coverage, later DNS changes, or a mailbox provider's private delivery decision.

For a second DNS-visible view, use the [Palisade DMARC checker](/tools/dmarc). It checks a public record, but it also cannot prove the production sending path, continuous state, message signing, or why one receiver rejected one message.

![DMARC record lookup evidence map](/images/editorial/mxtoolbox-dmarc-check/mxtoolbox-dmarc-check-record-map.webp "1200x600")

*Source: Palisade.*

## How to run the check

### 1. Identify the visible From domain

Use the domain that appears after the `@` sign in the visible From address of the mail you are investigating. For example, a message from `billing@yourdomain.com` needs a DMARC lookup for `yourdomain.com`.

Do not substitute a return-path domain, an SMTP HELO domain, or a DKIM selector. Those identifiers matter during DMARC evaluation, but the published DMARC policy is discovered from the visible From domain under RFC 9989.

### 2. Run the MXToolbox DMARC lookup

Open the [MXToolbox DMARC Record Lookup](https://lookup.mxtoolbox.com/dmarc.aspx?source=dmarcsetupno6), enter the visible From domain, and submit the check. Record the domain, lookup time, parsed TXT record, and any diagnostic information before making a DNS change.

The result is evidence about the published record at that time. Keep it separate from message evidence and sender configuration.

### 3. Confirm the public answer independently

Query the expected DMARC record owner with a public resolver. Use your real domain when testing.

```bash
dig +short TXT _dmarc.yourdomain.com
```

If you manage the zone, also query the authoritative DNS service before treating a resolver response as final. Resolver caches can delay what public tools show after a change.

> Do not replace a DMARC record by copying an example from another domain. The `rua` destination, policy, alignment settings, and rollout choice must match your own approved reporting and sending configuration.

### 4. Preserve the lookup result with the change request

For a record-level issue, save the exact returned record and the domain queried. Pair that evidence with the intended replacement record from the team that owns DMARC policy. This prevents an unrelated sender, subdomain policy, or reporting address from being changed during a repair.

## How to interpret the results

### The lookup displays a DMARC record

A displayed record means the lookup found a public DNS answer it can parse for the queried domain. Read each tag as published configuration, not as proof of operational success.

A structural example looks like this:

```text
Illustrative only. Publish values generated and approved for your own domain.

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

Under RFC 9989, `v=DMARC1` identifies the DMARC record. The `p=` tag tells receivers what policy to apply when DMARC fails for mail using the organizational domain. `rua=` requests aggregate reports at the listed URI. A record can be syntactically present while the real sending path still fails SPF or DKIM alignment.

### The lookup's diagnostics require record review

MXToolbox describes its output as including diagnostic information. Treat a diagnostic response as a prompt to compare the public TXT value with RFC 9989 and your intended configuration. Do not infer a message-level failure solely from a record-level diagnostic.

Check the exact DNS owner first. Then confirm that the intended policy, reporting destination, and any alignment settings are deliberate. A malformed or misplaced TXT record can prevent receivers from using the DMARC policy you expected, but a corrected record still needs message-path validation.

### The lookup does not establish that DMARC is working

A passing public DNS view means only that a lookup found a record it can evaluate. DMARC authentication for an individual message requires a passing, aligned SPF result or a passing, aligned DKIM result, evaluated against the message's visible From domain. RFC 9989 defines those conditions.

Move to a delivered message when the operational question is "Why did this email fail?" Inspect the receiver-added `Authentication-Results` header. [RFC 8601 defines the Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html), including the result properties that identify the evaluated domains.

## How to act on the result

Start with the narrowest repair supported by the evidence.

- If the public record differs from the approved configuration, have the DNS owner correct the TXT record at `_dmarc.yourdomain.com`. Verify the authoritative answer before changing policy.
- If the record is visible but a real message fails DMARC, collect the raw delivered message and compare the visible From domain with the SPF and DKIM domains reported in `Authentication-Results`. The [DMARC check tool guide](/learning/dmarc-check-tool) explains how to separate a record check from message-path evidence.
- If a message has an authentication failure, trace the exact sender application, ESP, or gateway that produced it. The [email authentication failure guide](/learning/email-authentication-failure) helps frame that investigation.
- If the record and one message look correct but sender ownership remains unclear, review DMARC aggregate reports after they accumulate. Aggregate reports are the evidence for recurring sending-source inventory, not a one-time public lookup.

Do not raise a DMARC policy from `p=none` to a more restrictive value solely because an MXToolbox lookup displays a valid record. A policy change can affect legitimate mail that has not yet been identified or aligned.

## Investigate this with your coding agent

Use this after the lookup identifies a public-record discrepancy and you have a redacted TXT response plus the intended DNS change. Do not include report addresses, message headers, account tokens, or customer data.

```agent
Problem: The public DMARC lookup for yourdomain.com shows a record that differs from the approved DMARC configuration.
Evidence: Redacted MXToolbox lookup result, redacted authoritative TXT response for _dmarc.yourdomain.com, and the intended example-shaped record values.
Repository scope: DNS infrastructure configuration and deployment files that manage yourdomain.com.
Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not expose secrets, tokens, private keys, unredacted report addresses, or customer data. Do not change DMARC policy unless the approved target record explicitly requires it.
Requested output: Diagnosis, minimal proposed change, rollback, and unknowns.
Verification: Query the authoritative DNS service and rerun the MXToolbox DMARC lookup for yourdomain.com after the approved change propagates.
Stop if: Credentials, private data, production mutation, or missing evidence is required.
```

## How to retest

Repeat the MXToolbox lookup with the same visible From domain after the DNS owner confirms the change. Query `_dmarc.yourdomain.com` independently as well. The expected change is that the public TXT response and the parsed lookup output match the approved record.

Then test the same production sender path with a new delivered message. Check the receiver's `Authentication-Results` for SPF and DKIM results and their aligned domains. Finally, use aggregate reports or [Palisade's DMARC learning hub](/learning/dmarc) to review whether other sources use the domain.

A changed public record does not guarantee delivery. It does not prove that every sender authenticates correctly, and it does not determine a receiver's private spam or inbox-placement decision.

## Inspect sender inventory after the record check

A public DNS lookup can identify a record problem, but it cannot show which production systems continue to send as the domain. Palisade is agent-first DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets.

When a team needs recurring evidence across domains, Palisade can propose the next DMARC policy step after the evidence is reviewed. A human reviews the evidence and applies the DNS change. Palisade does not automatically change the DMARC policy, guarantee delivery, or prove every future message will authenticate.

[Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_tools_validation&utm_content=mxtoolbox-dmarc-check)

## Sources and further reading

- [MXToolbox DMARC Check Tool](https://lookup.mxtoolbox.com/dmarc.aspx?source=dmarcsetupno6)
- [MXToolbox DMARC Email Tools](https://mxtoolbox.com/dmarc/dmarc-email-tools)
- [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html)
- [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html)
- [Palisade DMARC checker](/tools/dmarc)

## Frequently asked questions

### How do I check if my DMARC is working?

No, a public DMARC lookup alone cannot confirm that DMARC is working for production mail. Check the published record first, then inspect a newly delivered message's `Authentication-Results` header for aligned SPF or DKIM, and review aggregate reports for recurring sender coverage.

### What is a DMARC check?

A DMARC check is a test of DMARC-related evidence. A DNS lookup checks the public TXT record at `_dmarc.yourdomain.com`. A message check examines whether a delivered message passed aligned SPF or DKIM. Aggregate reports help identify the sources that send using the domain over time.

### Is DMARC really necessary?

Yes, DMARC gives domain owners a published policy and reporting framework for mail that uses their visible From domain. Its value depends on correctly configured SPF or DKIM authentication and alignment. Start with observation and evidence before applying a restrictive policy.

### How to authenticate DMARC?

Only SPF or DKIM can authenticate the underlying message for DMARC. Configure the sender to pass SPF or DKIM, ensure the authenticated identifier aligns with the visible From domain, publish a valid DMARC record, then validate a real delivered message under RFC 9989.

### Can MXToolbox tell me why Gmail rejected a message?

No. MXToolbox's DMARC lookup checks public record evidence. A receiver rejection needs the receiver's error response, the delivered message's headers when available, and the sender configuration for the exact path that sent the message.

### Should I change `p=none` after a successful MXToolbox DMARC check?

Not automatically. A successful public lookup does not show whether all legitimate senders pass aligned SPF or DKIM. Review real message evidence and aggregate reports before proposing a more restrictive DMARC policy.