Is the dmarcian DMARC checker working now?

No. The public page displayed a maintenance notice when this article was checked on 29 July 2026. Recheck the page before relying on that availability state, because the tool may return to service.

Can a DMARC record checker prove a message passed?

No. A public checker can show a DNS policy record and related record-level findings. A delivered message's authentication results and alignment evidence are needed to assess that message's DMARC result.

Does a missing record mean no one sends mail from the domain?

No. A missing DMARC record says public DNS did not supply that policy record for the queried domain. It does not inventory senders, establish authorization, or describe mail already in transit.

Should I change a DMARC policy after a syntax warning?

Only after you confirm the exact authoritative TXT answer, identify the record owner, and understand the intended correction. Do not replace a record from a generic example or change enforcement without sender and message evidence.

Can Palisade's DMARC checker replace aggregate reports?

No. It can inspect the public policy record for a domain. Aggregate reports add receiver-reported evidence across senders and time, which a one-time DNS lookup cannot provide.

DMARCian DMARC checker: what the public result can tell you

The dmarcian DMARC Record Checker currently displays a maintenance notice, so it cannot provide a live public-DNS result at this time. Its page still documents the record, missing-record, and syntax-error states it is designed to show. Treat any future checker output as DNS evidence for the domain you entered, then use delivered-message headers or aggregate reports before deciding whether a sender passes DMARC or a policy change is safe.

At a glance

Quick takeaways

dmarcian's public checker page currently says its tools are under maintenance.
The documented checker states concern a published DMARC record, not a specific delivered message.
A found record can establish what public DNS returned for one domain at one point in time.
A missing or malformed record needs authoritative DNS evidence before anyone changes it.
Message headers and aggregate reports answer different questions from a DNS lookup.

What this tool checks

The dmarcian DMARC Record Checker describes itself as a diagnostic for inspecting a domain's DMARC policy and potential issues. On 29 July 2026, its public page showed the maintenance notice along with an Enter domain input and Inspect the domain control. It also contains copy for a valid record, no record found, and syntax errors. That is real interface evidence, but it is not a submitted-domain result.

RFC 9989 defines DMARC as a receiver evaluation of authenticated identifiers, alignment, and a domain policy. A public record lookup can help with the policy-record part. It cannot show whether a particular message had aligned SPF or DKIM, whether a receiver applied local handling, or whether mail reached an inbox.

How to run the check

1. Record the current dmarcian state

Open the DMARC Record Checker and record whether it is available or displays the maintenance notice. If the checker becomes available, enter only the domain you are authorized to inspect and retain the returned public record state. Do not treat the page's prewritten state descriptions as a result for your domain.

2. Capture the exact record evidence

If a result says a record is present, save the returned record and domain. If it says the record is missing or malformed, confirm the result with an authoritative DNS query before changing anything. The checker page itself places DMARC at the _dmarc DNS location, while RFC 9989 defines how receivers discover a policy record.

Terminalbash

dig +short TXT _dmarc.example.com

3. Separate DNS from message evidence

For a sending-path or delivery question, collect a real delivered message and inspect receiver-added authentication results. For fleet evidence, review DMARC aggregate reports, whose record format is defined in RFC 9990. Do not infer a message result from the public policy alone.

How to interpret the results

Maintenance notice

The current notice means no dmarcian checker result was obtained. It does not mean the domain lacks DMARC or that its configuration is broken. Preserve the notice and use a second public-DNS lookup only if you need the record now.

Record found

A record-found result establishes that a public resolver returned a DMARC policy for the entered domain. It does not establish that every sender aligns, that every receiver follows the requested policy, or that a specific message passed. Use what DMARC evaluates to separate a policy record from message authentication.

Record missing or syntax warning

dmarcian's page documents separate messages for a missing record and syntax errors. Confirm the exact TXT answer in authoritative DNS, identify the DNS owner, and make the smallest approved correction. A missing record is not evidence that no email is sent from the domain, and a syntax warning is not a reason to replace an existing record with an unrelated example.

Four-stage evidence map for a dmarcian checker maintenance notice or record state, from public DNS evidence to message evidence and retesting. — Source: Original Palisade evidence map based on the dmarcian DMARC Record Checker and RFC 9989. It shows the boundary between a public-record result and message evidence. Open the full-size evidence map.

How to act on the result

Start with the narrowest action the evidence supports. For maintenance, run the same domain through an independent public lookup and keep the result with the date. For a missing or malformed record, verify the TXT answer with the DNS owner before proposing a change. For a record that is present, avoid changing p=, alignment tags, or report addresses until known senders and their message evidence have been reviewed.

When external report addresses are involved, validate their authorization rather than assuming the policy is complete. The external reporting authorization guide explains that separate DNS relationship. If the question is whether a mail stream passes, use a delivered message and aggregate reports, not the checker alone.

How to retest

After an approved DNS correction, wait for the responsible DNS provider and public resolvers to return the intended record. Rerun the same domain in the dmarcian checker when it is available, or use the same-domain alternative while maintenance continues. Then send a message from the affected production path and review its headers. DNS confirmation, a message result, and aggregate-report evidence are separate validation layers.

Confirm the published record with the same domain

If the dmarcian checker is under maintenance or its output needs an independent public-DNS reading, run the same domain through Palisade's DMARC checker. It can inspect the published record, policy, and visible tags before you propose a DNS change. If the result reveals a recurring sender-visibility problem, Palisade's DMARC Agent feature documentation describes analysis of DMARC aggregate-report data and prioritized remediation tickets for sender, SPF, DKIM, alignment, and policy issues. A human reviews the evidence and approves any DNS, sender, or policy change.

Start with Palisade

A public checker cannot repair DNS, prove a particular message passed DMARC, control receiver handling, or guarantee delivery.

Evidence