How to answer the domain-security section of a vendor security questionnaire
· By Arshad Ansari · security-questionnaire · compliance · dmarc · spf · evidence
security-questionnairecompliancedmarcspfevidenceIf you sell B2B software, the vendor security questionnaire is the gate between a signed contract and a stalled deal. Somewhere in the CAIQ, SIG, or bespoke spreadsheet a prospect sends you, there is a block of questions about your domain: email authentication, DNS integrity, transport security. If your company has no GRC function, these questions land on a founder, an engineering lead, or a sales engineer who has forty other things to do that week.
This post is the field guide for that block. For each question, it explains what the reviewer is actually checking, and how to answer it with evidence that survives scrutiny — not a screenshot that could have been taken any time.
What the reviewer is really asking
The domain-security questions look like trivia ("Do you publish SPF?") but they are a proxy for one judgement: is this vendor's public surface managed, or neglected? A spoofable domain is a phishing vector aimed at the reviewer's own employees. A domain with no DNSSEC and a soft-fail SPF record signals a team that ships and forgets. Reviewers cannot audit your internal controls from the outside, but your domain is fully observable — so they read it as a tell.
That is why "Yes" alone is a weak answer. The strong answer is "Yes, and here is dated proof." The proof matters because the reviewer has been burned by vendors who answered "Yes" to everything and turned out to be publishing p=none.
The questions, decoded
Here is the domain block, mapped to what the reviewer wants and the artifact that answers it. Every row below corresponds to one of the 15 checks in the free domain dossier.
| Questionnaire question | What the reviewer is checking | Answer "Yes" means |
|------------------------|-------------------------------|--------------------|
| Do you publish SPF limiting authorised senders? | Envelope-from can't be forged by arbitrary hosts | SPF present with -all hardfail |
| Are outgoing emails DKIM-signed? | Messages are cryptographically attributable to you | A selector published with a ≥1024-bit key |
| Do you enforce DMARC? | SPF/DKIM failures are actually rejected, not just logged | p=quarantine or p=reject, not p=none |
| Is DNSSEC enabled? | DNS answers can't be cache-poisoned | Signed zone with a validating chain |
| Is transport protected by a valid TLS certificate? | Data in transit is encrypted, cert is current | Trusted CA, unexpired, hostname matches |
| Does HTTP redirect to HTTPS? | No plaintext fallback for users | Single-hop 301/308 to HTTPS |
| Are HSTS, CSP, and X-Frame-Options set? | Browser-side hardening against XSS/clickjacking | Core security headers present |
| Do you enforce MTA-STS? | Inbound SMTP can't be TLS-stripped | Policy published in enforce mode |
The pattern is the same every time: the reviewer is not impressed by the record existing — they care whether it is enforcing. SPF with ~all (soft fail) technically exists but blocks nothing. DMARC with p=none publishes a record that stops no spoofing. The difference between a "Yes" and a "Partial" is almost always enforcement, and a good reviewer knows exactly where to look.
How to answer each one with proof
Take DMARC as the worked example. The question reads: "Does your domain enforce DMARC with a quarantine or reject policy?" The lazy answer is "Yes." The defensible answer is:
Yes.
example.compublishesv=DMARC1; p=reject; rua=mailto:[email protected], enforcing rejection of unaligned mail. Verified 2026-08-03; see attached signed report, control SOC 2 CC6.7.
Notice three things: the actual record, a date, and the control it satisfies. You can produce the record yourself with a DMARC record check, and the same logic applies to every row — check SPF for the -all qualifier, check DNSSEC for a validating chain, check your TLS certificate for expiry and chain, and check security headers for HSTS and CSP.
The date is the part most people skip and reviewers most want. A questionnaire answer is a point-in-time attestation. If you write "Yes" today and a reviewer re-runs the check next quarter and finds p=none, your credibility is gone. Anchoring the answer to a dated artifact protects both sides: it says "this was true on this date," which is all any honest attestation can claim.
Why a signed report beats a spreadsheet of screenshots
Most teams answer the domain section by running lookups by hand and pasting results into the questionnaire. It works, but it has two failure modes. First, it is slow and error-prone across a dozen questions. Second, a pasted string or a screenshot carries no proof of when it was captured or whether it was edited — exactly the two things a skeptical reviewer questions.
The signed Domain Audit Report exists for this. It runs the same 15 checks, then wraps them in a PDF plus JSON sidecar that is Ed25519-signed and ISO-8601 timestamped, with each finding mapped to the SOC 2, ISO 27001, and NIST control it supports. Instead of eight pasted strings, you attach one artifact the reviewer can verify against a public key. If a check can't complete, it is flagged inconclusive rather than silently passed — so there are no hidden gaps for a reviewer to find.
At $29 per report it is priced below the consultant hour it replaces, and it carries a signed-or-refunded guarantee: if the report doesn't verify against the public key, or isn't accepted where you needed it, you reply within 30 days for a full refund and keep the report. For teams staring at the SOC 2 evidence questions with no GRC department, it is the fastest way to turn "we think we're fine" into "here is the dated proof."
Answer the section, then move on
The domain-security block is not the hard part of a security review — it just feels hard when you are gathering the data by hand under deadline. Run the checks once, read the actual records, and answer each question with the record, the date, and the control. That is what a reviewer wants, and it is the difference between a section that clears in one pass and one that bounces back with follow-up questions.
Run the free 15-check dossier on your domain →Then, if you want the dated, signed version to attach to the questionnaire, the $29 Domain Audit Report delivers it to your inbox in 10–30 minutes, signed or refunded within 30 days.
Further reading
Frequently asked questions
- What is the domain-security section of a vendor security questionnaire?
- It is the cluster of questions in a CAIQ, SIG, or custom questionnaire that asks how you authenticate email (SPF, DKIM, DMARC), protect DNS (DNSSEC), and secure transport (TLS, MTA-STS, HTTP-to-HTTPS redirects, security headers). Reviewers use it to gauge whether your public-facing domain is spoofable or misconfigured before they trust you with data.
- Do I need a screenshot to answer a questionnaire question?
- A screenshot proves nothing about when it was taken or whether it was edited. Reviewers increasingly want a dated, verifiable artifact — a signed report or a live check result they can reproduce. A screenshot of a passing check is weaker evidence than a link to the check itself or a cryptographically signed record of the scan.
- What if my domain fails some of these checks?
- Answer honestly. Reviewers rarely expect a perfect score; they expect you to know your posture. A "Partial" answer with a remediation date beats a "Yes" that unravels on inspection. Run the checks, fix what you can, and keep a dated record of the state you attested to.
- How long should the domain section take to complete?
- With the raw DNS and TLS data in front of you, ten to fifteen minutes. Most of the delay in practice is hunting for the data — running six separate lookups, pasting results into a spreadsheet, and hoping nothing changed since. A single 15-check scan collapses that into one pass.