MXToolbox DMARC: How to Interpret a Public Record Lookup

An MXToolbox DMARC lookup is useful for checking the public DMARC policy that a domain publishes. It can reveal a missing record, a syntax problem, or a policy such as p=none, p=quarantine, or p=reject. It cannot show whether a particular message passed DMARC, whether a sender is aligned, or where a recipient delivered that message. Use it as DNS evidence, then collect message or report evidence before changing policy.

What this tool checks

MXToolbox provides a public DMARC lookup for a domain's DMARC policy record. RFC 9989's DMARC policy-discovery rules define how receivers discover that DNS policy. The MXToolbox DMARC lookup lets you submit a domain and inspect the record and diagnostic checks it returns.

That result is narrower than a message-authentication diagnosis. It can show the published policy and record-level issues, but it cannot reveal the authenticated identity used by a specific production message. Read what DMARC checks before assuming that a valid record alone means every sender is covered.

How to run the check

1. Enter the organizational domain

Use the domain that appears in the visible From address of the sending stream you are investigating. On the current MXToolbox page, enter that domain in the Domain Name field and select DMARC Lookup. Do not paste a full email address, a URL, or a mail server name into a domain lookup. The question is what policy DNS publishes for that domain.

2. Record the returned policy and warning

Save the lookup time and the exact policy or warning it returns. Note whether the result says that no record was found, whether the policy is monitoring or enforcing, and whether the result identifies a syntax issue. A public lookup can change after a DNS update, so an undocumented result is difficult to compare later.

The current result view below is a real public lookup of example.com, captured on 2026-07-28. It shows a returned policy record, tag descriptions, and diagnostic checks. It is an example of a returned public state, not a result for your domain.

3. Compare a second public lookup when needed

Use the Palisade DMARC checker with the same domain if you need another public-record view. The checker accepts a domain and displays the policy fields it can resolve. Do not change DNS merely because two tools format the same record differently.

Lookup input: example.com
Evidence returned: published DMARC policy and record fields
Not established: production-message alignment, receiver delivery, or inbox placement
Retest rule: repeat the same domain lookup after one confirmed DNS change

How to interpret the results

No DMARC record found

A missing record means the lookup did not find a published DMARC policy at the expected DNS location. Confirm the DNS zone and record owner before creating anything. A record lookup cannot tell you whether a sender is already signing with DKIM or whether recipients are filtering a particular message.

A record exists but the policy is not the whole answer

p=none asks receivers to monitor, while p=quarantine and p=reject request progressively stronger handling of mail that fails DMARC. RFC 9989's alignment rules still require a relevant SPF or DKIM identifier to align with the visible From domain for a message to pass. That is why a public p=reject result is not proof that all production mail will pass.

Syntax or multiple-record warning

Treat a syntax or multiple-record warning as a reason to inspect the actual DNS response and the change history. Correct only the record owner or value that the evidence supports. Do not loosen the policy as a shortcut for an unresolved sender problem.

How to act on the result

Work from the evidence the lookup gives you.

• If the lookup finds no policy, confirm the authoritative DNS zone and publish a deliberately chosen record. The DMARC record generator can help construct a record, but it does not identify every legitimate sender for you.
• If the record is malformed, compare the returned text with the intended DNS value and correct the smallest confirmed error.
• If the policy is p=none, use aggregate-report data to identify legitimate sources before tightening enforcement.
• If a delivered message is failing, inspect that message's receiver-added authentication results and the sender configuration. A record lookup is not enough to attribute the failure.

How to retest

After a confirmed DNS edit, repeat the MXToolbox lookup with the same domain and record the new time and returned policy. Then send a representative message through the production path and inspect its authentication evidence if the change was intended to repair mail flow. Keep the DNS result and message result separate: the first shows published configuration, while the second tests one sending path.

Compare the published record before editing DNS

If an MXToolbox result is missing, malformed, or unexpected, run the same domain through the Palisade DMARC checker before editing DNS. A second public check can help you compare the published record with the lookup result you already have.

A record check cannot establish why a specific delivered message passed or failed, control a receiver's delivery decision, or guarantee inbox placement.

Keep recurring sender evidence in view

If a public record looks correct but new or existing senders keep failing alignment, the remaining task is to identify the sending sources and prioritize the repair work. Palisade's DMARC Agent remediation guide describes using aggregate-report evidence to identify sending sources and prioritize remediation for human review.

Start with Palisade

Palisade does not change your DNS, decide a receiver's delivery outcome, or guarantee that every future message will authenticate.