# MXToolbox DMARC: How to Interpret a Public Record Lookup > Interpret an MXToolbox DMARC lookup, choose the right next evidence, and retest a public record without mistaking it for message proof. 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. ## Quick takeaways - A DMARC lookup answers what public DNS returns for a domain at the time of the check. - A missing or malformed record is a DNS repair task, not proof of a delivery failure. - `p=reject` is a policy request for failing mail, but it does not prove every legitimate sender passes DMARC. - Compare the record with a real delivered message before diagnosing an individual failure. - Retest the same domain after a confirmed DNS change and allow for the DNS publication path you use. ## What this tool checks MXToolbox provides a public DMARC lookup for a domain's DMARC policy record. [RFC 9989's DMARC policy-discovery rules](https://www.rfc-editor.org/rfc/rfc9989.html) define how receivers discover that DNS policy. The [MXToolbox DMARC lookup](https://mxtoolbox.com/DMARC.aspx) 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](/learning/what-is-dmarc) 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. ![MXToolbox DMARC Check Tool showing the Domain Name field and DMARC Lookup button before a domain is submitted.](/images/editorial/mx-toolbox-dmarc/mx-toolbox-dmarc-entry-console.png "1728x1069") *Source: [MXToolbox, "DMARC Check Tool - Check DMARC Records for Errors"](https://mxtoolbox.com/DMARC.aspx), captured 2026-07-28. [Open the full-size image](/images/editorial/mx-toolbox-dmarc/mx-toolbox-dmarc-entry-console.png).* ### 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. ![MXToolbox SuperTool result for example.com showing the returned DMARC policy, tag descriptions, and record diagnostic checks.](/images/editorial/mx-toolbox-dmarc/mx-toolbox-dmarc-result-console.png "1280x720") *Source: [MXToolbox SuperTool DMARC result for example.com](https://mxtoolbox.com/SuperTool.aspx?action=dmarc%3Aexample.com&run=toolpage), captured 2026-07-28. [Open the full-size image](/images/editorial/mx-toolbox-dmarc/mx-toolbox-dmarc-result-console.png).* ### 3. Compare a second public lookup when needed Use the [Palisade DMARC checker](https://www.palisade.email/tools/dmarc) 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. ```text 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](https://www.rfc-editor.org/rfc/rfc9989.html) 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](/tools/dmarc-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](/tools/dmarc) 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](https://docs.palisade.email/guides/fixing-authentication-issues/) describes using aggregate-report evidence to identify sending sources and prioritize remediation for human review. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_diagnostics&utm_content=mx-toolbox-dmarc) Palisade does not change your DNS, decide a receiver's delivery outcome, or guarantee that every future message will authenticate. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html) - [MXToolbox DMARC lookup](https://mxtoolbox.com/DMARC.aspx) - [Palisade DMARC checker](https://www.palisade.email/tools/dmarc) - [Palisade DMARC Agent remediation guide](https://docs.palisade.email/guides/fixing-authentication-issues/) ## Frequently asked questions ### Does an MXToolbox DMARC lookup prove my email passes DMARC? No. It shows public DNS evidence for the domain at lookup time. A message passes DMARC only when the receiver's SPF or DKIM evaluation has the required alignment with the visible From domain. ### Should I publish p=reject as soon as the lookup finds a valid record? No. A valid record can still coexist with legitimate senders that fail alignment. Review aggregate reports and representative message evidence before moving to a stricter policy. ### What should I do when the lookup says no DMARC record was found? Confirm that you checked the correct domain and DNS zone, then publish one deliberate DMARC record. Retest the same domain after the DNS change rather than assuming the record is active immediately. ### Can a public lookup explain why one message went to spam? No. A public lookup cannot see the recipient's filtering decision, message content, reputation signals, or the actual authentication results for that delivered message. Inspect the message headers and sender path instead.