DMARC Check for B2B Teams: Every Warning Explained

Run your domain through any free DMARC checker and you get a verdict in about a second. What that verdict grades is the syntax of one DNS record. It cannot see whether your mail passes, which sources are failing, or whether the policy you published is the one you meant, and several of the warnings it prints are graded against a specification that was replaced in May 2026.

MXToolbox's DMARC check page still explains the mechanism "According to RFC 7489", and RFC 7489 was obsoleted by RFC 9989 on 20 May 2026. That is not a criticism of the tool, which does the lookup it says it does. It is the reason to read the warnings rather than the score.

What a checker is actually doing

A DMARC record check queries _dmarc.yourdomain.com, retrieves the TXT record, parses it into tags, and tests each tag against a set of rules. Everything it reports is derived from that one string.

So the questions a checker can answer are: does a record exist at the right name, is it syntactically valid, does the policy request enforcement, and is there an address for reports. The questions it cannot answer are the ones that decide whether your outbound lands: which systems are sending as you, which of them fail alignment, and what proportion of your real mail is affected. Those live in the aggregate reports, and reading a DMARC report without a parser is the other half of this job.

A DMARC check answers

• Is a record published at _dmarc
• Is the syntax valid
• Does the policy enforce
• Is a reporting address set

Only reports answer

• Which systems send as you
• Which of them align and which do not
• How much real mail each source represents
• Whether enforcement would break something

The warnings, and what each one is worth

No DMARC record found. Usually true, occasionally a lookup at the wrong name. Confirm the record is at _dmarc.yourdomain.com rather than at the root domain, which is the most common publication mistake and produces exactly this message.

Multiple DMARC records found. Always real and always worth fixing. A name answering with two records is ambiguous and receivers are entitled to treat the domain as having no valid policy at all. This usually happens when a second team publishes a record without checking for the first.

DMARC policy not enabled. This is the p=none warning, and how much it matters depends entirely on what you are trying to achieve. It satisfies bulk sender requirements, it produces reports, and it stops nobody from spoofing you. We take the full case apart in DMARC policy not enabled, including when staying there is a deliberate choice rather than an unfinished rollout.

No reporting address specified. Real, and more consequential than it sounds. A policy published without rua= is enforcement with no evidence, so you learn what you broke from a colleague rather than from a report.

Percentage tag deprecated, or missing. Read this one carefully, because checkers disagree about it and the specification moved. RFC 9989 lists pct as historic. A checker that warns you the tag is deprecated is current; a checker that suggests adding pct=25 for a staged rollout is repeating advice the standard has retired. The replacement is the t= test-mode tag, and the DMARC record tag by tag covers what it does instead.

No subdomain policy specified. Low value on its own. Leaving sp= out means subdomains inherit p=, which is usually what you want. It becomes worth attention when you send outbound from a subdomain of a domain sitting at reject.

External reporting destination not authorised. Real, specific, and the single most common reason an otherwise correct setup receives nothing. If the rua mailbox is on a different domain from the one being monitored, that other domain has to publish a record authorising it. DMARC aggregate reports covers the exact record and where it goes.

Alignment mode not strict. Rarely worth acting on by itself. Relaxed alignment is the default in the standard and it is what lets a subdomain satisfy a policy published on the parent, which is the arrangement most companies with several sending systems actually run. Strict alignment is a deliberate hardening step taken after you know every legitimate source, not a box to tick because a tool coloured it amber.

Unknown tag. Almost always harmless. Receivers ignore tags they do not recognise, so an unrecognised tag does not invalidate a record. Worth a glance in case it is a typo in a tag you meant to set.

Triage for a checker report

• ✓Yes: Multiple records at _dmarc: fix today, the domain may have no usable policy
• ✓Yes: External destination not authorised: fix today, you are receiving nothing
• ✓Yes: No rua address: fix today, you are enforcing blind
• ~Depends: Policy not enabled: a decision to make, not a defect to clear
• ✕No: No sp= specified: usually correct as it stands
• ✕No: Suggestion to add pct= for a staged rollout: advice the current standard retired

Why two checkers disagree about the same domain

Running one domain through three tools and getting three different verdicts is ordinary, and the reasons are worth knowing so the disagreement stops being alarming.

The first reason is caching. A checker that queried your domain an hour ago may serve you that answer rather than a fresh lookup, and a record you edited fifteen minutes ago will not have reached every resolver anyway. When two tools disagree immediately after a change, the newer answer is usually the correct one and both will agree tomorrow.

The second is that the rule sets are hand-maintained, and they were written at different times against different versions of the standard. The percentage tag is the clearest case: on the same record, one tool reports it as deprecated, another suggests adding it, and a third says nothing at all. All three are running correctly against the rules they were given.

The third is commercial. Free checkers are lead capture for monitoring platforms, which is a legitimate business model and does shape what gets flagged. A warning that resolves by publishing a tag is advice; a warning that resolves by signing up for a dashboard is marketing. Both can appear in the same report, in the same typeface. The test is whether the recommended action is a DNS edit you could make yourself in five minutes.

None of that makes the tools untrustworthy. It makes the record itself the source of truth: read the record, understand each tag you find, and treat the checker as a fast way to spot that something is missing rather than as an authority on what should be there.

Checking the rest of the chain

A DMARC verdict rests on SPF and DKIM, so a green DMARC record with a broken chain underneath it is common. Two checks are worth running at the same time.

For SPF, the number that matters is the DNS lookup count. RFC 7208 sets an "overall limit of 10 mechanisms/modifiers that cause DNS lookups", and crossing it makes SPF evaluation return permerror, which contributes nothing to DMARC. A domain that has accumulated senders over a couple of years crosses it quietly, and SPF records for cold email covers how to count and fix yours.

For DKIM, a checker needs a selector to query, and the selector is not discoverable from the domain alone. Read it from the DKIM-Signature header of a real message rather than guessing. A record can be present, valid and still be disabled by a testing flag, which the DKIM record in practice walks through.

What a B2B outbound team should actually check

If you send from a portfolio of domains, the useful version of this task is not running one domain through one checker. It is confirming that every domain you send from has the same intended configuration, and noticing the one that does not.

Three checks cover most of it. Every sending domain has a DMARC record at the right hostname. Every one of them reports to a mailbox you can actually read, with the cross-domain authorisation published so the reports arrive. And every one has DKIM signing on its own domain rather than on the sending platform's, because that alignment is what a DMARC pass depends on once SPF stops contributing.

The failure this catches is the domain added three months after the others, by someone reading a runbook that had drifted. It shows up in no single-domain check, because each individual check passes.

We treat this as launch work rather than maintenance work. Campaigns run one message per campaign, so a domain that fails authentication does not get another attempt at the same person later, and there is no recovery path that involves writing to them again. That is also why we carry more sending infrastructure than a campaign consumes: a domain that has to be pulled is replaced rather than repaired mid-flight.

If checking this across a domain portfolio is not work you want to own, we run the sending infrastructure as part of the engagement.

The short version

A DMARC checker grades one DNS record's syntax, which is worth doing and is not the same as knowing your mail passes. Act on multiple records, a missing or unauthorised reporting address, and anything that stops reports arriving. Treat the policy warning as a decision rather than a defect. Ignore suggestions built on the retired percentage tag. Then go and read an actual aggregate report, because every question about which of your senders is failing is answered there and nowhere else.

Specification behaviour verified as of August 2026 against RFC 9989 and RFC 7208, and vendor descriptions against the published pages named. Verify current tool behaviour with the vendor before relying on it.