How to Read DMARC Checker Results

A DMARC checker reads public DNS and summarises records related to email authentication. It is a useful starting point, but it is not a message-delivery test, a complete DKIM inventory, or a security and compliance assessment.

This guide explains what the Vigil checker’s sections mean and what to verify before changing production DNS.

Start with the scope note

The result is a point-in-time view. DNS can change after the check, and resolver or DNSSEC failures can make a result incomplete.

The checker can inspect:

• the effective DMARC record and policy discovered for the domain;
• the public SPF record and observable lookup chain;
• a supported set of common DKIM selectors;
• MX records; and
• DNS diagnostics that affect confidence in the result.

It cannot see every message sent by the domain. Aggregate reports are required for that behavioural evidence.

DMARC policy result

No record found

The checker did not find an effective DMARC record through the supported discovery process.

Before publishing anything:

1. confirm the domain and DNS zone;
2. identify systems that send using the domain;
3. choose an authorised aggregate-report destination; and
4. plan how reports will be processed and reviewed.

Do not paste a generic record into production without confirming the reporting address and domain ownership.

Monitoring policy — p=none

The domain owner expresses no requested handling for DMARC failures. Participating receivers can still evaluate DMARC and send aggregate reports.

Next step: review reports, identify legitimate sources, and fix alignment gaps. Do not describe the domain as enforcing DMARC.

Quarantine requested — p=quarantine

The domain owner asks participating receivers to treat failures with additional suspicion. Receiver behaviour varies; a failure is not guaranteed to land in a particular folder.

Next step: examine later report evidence and any delivery impact before considering a stronger change.

Reject requested — p=reject

The domain owner asks participating receivers to refuse DMARC failures. Receivers may still apply local policy.

Next step: continue monitoring for new services, authentication drift, forwarding, and local-policy outcomes. Reject is not a guarantee against every spoofed or fraudulent message.

Inherited or public-suffix policy

For a subdomain, the effective policy can be found higher in the DNS hierarchy. The result should show the policy domain and discovery method where available.

Do not assume the record was published directly at the tested name. Review subdomain ownership and sending use before changing a higher-level policy.

SPF result

Record found

The domain publishes an SPF record. This does not prove that every legitimate sender is included or that SPF aligns with the visible From domain.

Review:

• whether exactly one SPF record exists;
• which mechanisms authorise sending sources;
• whether the lookup evaluation stays within the RFC limit;
• how the record ends; and
• whether the authenticated envelope-sender domain aligns for DMARC.

Read SPF Records Explained before editing it.

No record found

First confirm whether the domain sends email. A non-sending domain and an active mail domain need different records and change decisions.

For an active sender, inventory services before creating one SPF record. Guessing or adding a second record can cause a permanent evaluation error.

Lookup count near or over the limit

RFC 7208 limits the DNS-querying terms evaluated during an SPF check. An observable count over the limit requires attention.

The checker can show a partial count when nested records fail to resolve. Treat that as incomplete evidence rather than a precise total.

Do not flatten or delete mechanisms until the authorised senders and full include chain are understood. Read SPF Flattening and the 10-Lookup Limit.

DKIM selector discovery

One or more selectors found

The checker found public keys under supported selector names. Review the selector, provider context, key details, and whether real messages use that selector.

A public record does not prove that provider-side signing is enabled. Send through the service and inspect authentication results.

No supported selectors returned

The current public result cannot distinguish no supported-selector match from unavailable discovery. This is not proof that DKIM is absent. Selectors are chosen by providers and are not globally enumerable.

Check each known sending provider’s current configuration and documentation. Use the DKIM setup guide for a validation workflow.

Revoked or shorter keys

A revoked selector should not validate new signatures. A shorter key should be reviewed against the sending provider’s current guidance and rotation options.

Do not generate a replacement key in an unrelated system or request the private key through a public form.

MX result

MX records identify systems that receive mail for a domain.

• MX records returned: confirms that public inbound-routing records were returned, not the health or security of the mailboxes.
• No MX records returned: the current result cannot distinguish confirmed absence from an unavailable lookup. Review any DNS diagnostic and the domain’s intended use.

MX does not tell you which services send mail using the domain.

DNSSEC and inconclusive results

A validating resolver can fail when a DNSSEC chain is broken, for example when parent DS data and child DNSKEY data do not match.

If the checker reports a suspected or confirmed DNSSEC issue:

• do not treat fallback data as fully validated;
• review registrar DS records and authoritative DNSKEY data;
• confirm the domain’s DNS operator; and
• resolve validation before relying on the authentication assessment.

An inconclusive diagnostic is not proof of a DNSSEC fault. It means the checker could not establish a reliable answer from the available checks.

Read the primary DMARC state first

The primary result first considers any DMARC discovery error, then the returned has_dmarc and policy fields. A discovery error takes precedence and must not be presented as confirmed absence. The result is not a grade for the organisation and does not summarise SPF, DKIM selector discovery, MX, or every DNS condition.

No effective DMARC policy found

When the lookup completed without a discovery error, the check did not find an effective DMARC policy for the domain. Confirm domain ownership and intended mail use, then identify legitimate senders and an approved aggregate-report destination before publishing.

DMARC monitoring policy observed

The effective policy is p=none. It requests no enforcement handling for failures. Use aggregate reports to identify legitimate senders and alignment gaps before considering a stronger policy.

DMARC quarantine policy observed

The effective policy asks participating receivers to treat failures with additional suspicion. Receiver handling varies, so review later report evidence and legitimate-mail impact before considering reject.

DMARC reject policy observed

The effective policy asks participating receivers to reject DMARC failures. Receivers may apply local policy. Continue monitoring aggregate reports, legitimate senders, and provider changes.

DMARC policy inconclusive

The checker returned a discovery error, contradictory fields, or a policy state it could not map safely. Review the DMARC record and DNS diagnostic before relying on the result.

Keep the other observations separate

An SPF record can be present without aligning for DMARC. A supported DKIM selector can be returned even when production messages are not signed or aligned. The current public result does not distinguish zero selector matches from unavailable discovery, or zero MX records from an unavailable MX lookup. MX records describe inbound routing and do not identify every outbound sender.

Read each result card on its own terms. A reject policy does not prove that SPF, DKIM, MX, and diagnostics are all clear, while a monitoring policy does not by itself mean those other signals have material gaps.

What the checker cannot tell you

• whether every legitimate service is sending and aligned;
• whether every DKIM selector has been found;
• whether messages reach the inbox;
• whether a receiver will honour policy in every case;
• whether a source is malicious from its IP alone;
• whether the organisation meets POPIA or another legal requirement; or
• whether lookalike domains or compromised accounts are being abused.

What to do next

1. Save the observed records and date.
2. Confirm the sending inventory with the domain owner.
3. Correct clear DNS errors through the approved change process.
4. Establish and review aggregate reporting.
5. Progress policy only when report evidence supports it.

Read Understanding DMARC Reports for ongoing evidence and DMARC Policy Progression for policy decisions.

Frequently asked questions

Does a good checker result guarantee inbox delivery?

No. Authentication is one input. Reputation, content, receiver policy, engagement, and other factors also affect delivery.

Why does the checker show no DKIM when mail passes DKIM?

The active provider may use a selector the checker does not test. Inspect a real message or consult the provider configuration.

Should I fix SPF, DKIM, or DMARC first?

Start with the actual sending estate. SPF and DKIM provide authentication; DMARC evaluates alignment and policy. Use monitoring while legitimate sources are being corrected.

Does the checker change DNS?

No. It reads public DNS and returns observations. Production changes require an authorised DNS operator.

Run the free DMARC checker for the current public view, then use reports rather than repeated point-in-time checks as the evidence for ongoing management.