DMARC in vendor security questionnaires

What an assessor actually checks

Most boxes in a questionnaire cannot be verified from the outside. Password policy, encryption at rest, awareness training: the assessor records the declaration and has no way to test it. The DMARC line is of a different nature, because the policy is published in the public DNS. One query settles it:

dig TXT _dmarc.example.com +short
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

A competent assessor reads more than the p= tag. The presence of rua= matters — collected reports indicate live monitoring rather than a record published once and forgotten. Subdomain coverage gets checked, along with any quiet sp=none that hollows out the protection. The DMARCbis test mode (t=y), which suspends policy enforcement, gets spotted too — it is the modern equivalent of the old pct=0, which the current standard removed. SPF and the presence of DKIM selectors on the same domains are confirmed, sometimes the existence of an MTA-STS policy as well. And all of it automates: third-party rating platforms score these signals continuously, without sending a questionnaire at all.

Put differently, the DMARC box is probably the only one in the whole spreadsheet whose answer the buyer already knows before reading the declaration. That is what makes it so dangerous for anyone answering fast — and so valuable for anyone answering straight.

Answering honestly, whatever the current state

Three situations, three sound answers.

The policy is at p=reject or p=quarantine. The answer is easy: yes, with the DNS record attached, the list of covered domains, and a sentence on report monitoring. This is a chance to score points cheaply: few respondents document it that cleanly.

Deployment is under way, the policy still at p=none. The temptation of the loose "yes" is strong — "DMARC is in place," technically true since a record exists. It is the worst possible option: the contradiction with the public DNS is obvious to the first tooled-up assessor, and every other answer in the spreadsheet becomes suspect at once. The sound answer is a documented state with a dated trajectory: "policy at p=none with report collection and analysis since March; move to p=quarantine planned for Q4; p=reject targeted for Q1." To a serious assessor, that level of precision beats a bare "compliant": it proves the topic is driven, budgeted and scheduled. An owned p=none with a credible plan clears the filter; a "yes" the DNS contradicts never clears it twice.

Nothing is in place. Admitting it, with a dated commitment attached rather than a vague promise, remains the right move. Questionnaires are rarely eliminatory line by line; overall coherence weighs more than any single box. The 2026 DMARC checklist provides the skeleton of a credible plan to append to the answer — source inventory, report collection, progressive tightening.

The buying side: what to ask, and a thirty-second check

For the organization assessing its suppliers, the DMARC line is a gift: it is the only one whose verification costs less than reading the answer. The question still has to be asked well. "Is DMARC in place" invites a hollow yes; the useful wordings ask for the effective policy (p=) on the primary domain and the brand domains, the team or tool watching the reports, and the treatment of non-sending domains.

The verification then takes thirty seconds: a TXT query on _dmarc. followed by the supplier's domain, from any workstation, or an online analyzer that returns DMARC policy, SPF and DKIM in one pass. The reading grid is direct. A p=reject consistent with the declaration lends credibility to the entire questionnaire. A p=none declared "compliant" is a warning signal that reaches far beyond email: it measures the respondent's sincerity. The gap between the declared answer and the observed DNS state is the single most valuable piece of information in the whole spreadsheet — and it comes free.

A maturity signal beyond email

Why give so much weight to one line among three hundred? Because a DMARC policy at enforcement cannot be improvised. It presupposes an exhaustive inventory of sending flows — including the ones marketing wired up without telling anyone —, a functioning DNS governance, coordination across internal teams and vendors, then continuous monitoring so the policy survives change. An organization that carried that project through demonstrates a cross-functional execution capability that extends well past the mail system.

It is a correlation, not a proof: a domain at p=reject can coexist with an otherwise neglected infrastructure, and the reverse happens too. But in a mass-assessment exercise where nearly everything is declarative, a public, verifiable, hard-to-fake signal is worth gold. Assessors know it — which is precisely why the line is there.

Preparing the standard answer

Rather than rediscovering the question with every spreadsheet, seasoned teams keep a standard answer ready, reviewed on a fixed schedule. A reference paragraph looks like this:

All of the company's sending domains publish a DMARC policy of p=reject, with SPF and DKIM alignment verified source by source. Non-sending domains are locked down (v=DMARC1; p=reject; plus an SPF record with no sending mechanism). Aggregate reports are collected and analyzed continuously through a dedicated platform; any unknown sending source raises an alert. Last review: [date].

The evidence to keep at hand as appendices: a dated export of the DNS records, a capture of the monitoring dashboard, the list of covered domains, and — for a deployment in progress — the milestone calendar. One caution: this answer expires. A domain acquired in a merger, a new emailing tool wired up by a subsidiary, and the paragraph lies. The quarterly review of the paragraph and its evidence is an integral part of the answer.

In summary

The DMARC question settled into vendor questionnaires because third-party assessment became an obligation — NIS2, DORA, ISO 27001 — and because a supplier's email is a direct attack vector against its customers. Its singularity: the answer is verifiable in the public DNS, in thirty seconds, by anyone. The only tenable strategy is documented honesty — a p=none with a dated trajectory beats a "yes" the DNS contradicts — and, on the buying side, the systematic comparison between declaration and observed reality, which says more than every other box combined.

Before the next spreadsheet arrives, running the domain through a free DMARC analysis shows exactly what the assessor will see: effective policy, SPF, DKIM, subdomain coverage. And if the observed state does not yet match the hoped-for answer, creating an account opens the dated, milestone-driven path toward p=reject — enough to turn an awkward box into a demonstration of maturity by the time the next questionnaire lands.