Answering the email-authentication questions on a supplier or insurance questionnaire

The form in front of you says something like “Does your organisation enforce DMARC (p=quarantine or p=reject) on all email sending domains?” with a yes or no box beside it, and you don’t know. You can find out in about two minutes with one DNS lookup per domain, because the answer sits in a single tag of a single TXT record. This page takes the questions in the order most questionnaires ask them, says what each one is checking for, and gives you the sentence to write when the answer is yes and the sentence to write when it isn’t yet.

Where the answer turns out to be no, write no and add a date. The buyer’s security team and the insurer’s underwriter can run the lookups you’re about to run, and some of them do, on the day they receive the form.

The lookups to run before you write anything

Nearly all of the email questions on the form come back to three records. Run them against each domain you send from, and against the bare company domain even if you only send from a subdomain.

dig +short TXT example.com
"v=spf1 include:_spf.example.net -all"

dig +short TXT _dmarc.example.com
"v=DMARC1; p=reject; rua=mailto:[email protected]"

dig +short TXT selector1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

On Windows, nslookup -type=TXT _dmarc.example.com returns the same answers without the quotes.

If a lookup returns nothing, that’s your answer for that line of the form. If it returns a record, keep reading, because the questions are about what the record says, and a record that exists while saying the wrong thing is easy to mistake for a yes.

The free scan runs the same lookups per domain in one go and grades the result. Save a copy before you start writing, so the evidence and the answers come from the same moment.

The SPF question

The form usually puts it as “Do you publish a Sender Policy Framework (SPF) record for all domains that send email on your behalf?” The reviewer wants a v=spf1 TXT record at the domain apex, and wants it to end in -all or ~all, with each sending service named inside it.

Read the record you pulled. It should reach, through include: or ip4:, each system that sends mail as you: the ticketing tool, the invoicing platform, whatever else has your domain in its From: field. If one of those systems is missing, the record is incomplete and the truthful answer to “all senders” is no, even though a record exists. A record ending +all authorises the whole internet to send as you and counts as no SPF for the purposes of the form.

Count the lookups as well. SPF allows ten DNS lookups while evaluating a record, and a domain that has bolted on include: after include: over the years can pass it. When that happens receivers log spf=permerror and treat the record as unusable, so a form answer of yes would be wrong in a way you wouldn’t notice from reading the record. The SPF page shows how to count the lookups and trim them.

When it’s in order, write: “Yes. example.com publishes v=spf1 naming all authorised sending services and terminating in -all. Subdomains that send mail publish their own SPF records.”

When it isn’t, write: “A record is published; it is being reconciled against the current list of sending services and will terminate in -all by [date].” A reviewer can check that date with the same lookup, so make it one you’ll meet.

The DKIM question

The wording tends to be “Is outbound email signed with DKIM?” or “Do you cryptographically sign email sent from your domain?” What the reviewer wants is a DKIM-Signature: header on mail leaving each sending system, with a d= value that is your domain, pointing at a public key that resolves in DNS.

You can’t settle this from DNS alone, because the selector name is whatever each sending system chose and there’s no directory of them. The quickest proof is to send a message from each system to a mailbox you control, open the full headers, and look for these two lines:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...
Authentication-Results: mx.receiver.example; dkim=pass header.d=example.com header.s=selector1

The d= may show the sending platform’s own domain rather than yours, which means the mail is signed, though the signature does nothing for your domain and nothing for DMARC alignment. Or the header reads dkim=fail (signature did not verify) because somebody rotated the key at the platform and nobody updated the TXT record. In either case the answer for that system is no until it’s fixed, and the fix is a DNS record the platform will hand you. If you don’t know which selector a system uses, finding your DKIM selector covers where to look.

When it’s in order, write: “Yes. All outbound mail from example.com carries a DKIM signature with d=example.com, and the corresponding public keys are published under _domainkey.example.com.”

When it isn’t, write: “Mail from [system] is signed with d=example.com. Signing for [system] is being enabled and will be verified by [date].” Naming the gap is fine, and it gives the reviewer something they can check, which a bare yes doesn’t.

The DMARC enforcement question

The supplier or vendor version asks “Do you enforce DMARC?” The cyber insurance version asks “Is your DMARC policy set to quarantine or reject on all domains?” and often sits next to the box that decides the premium or the cover limit, though both versions come down to the value of one tag.

Look at p= in the record you pulled from _dmarc.example.com. A record at p=none exists, so “do you publish DMARC” gets a yes, and “do you enforce DMARC” gets a no, because p=none instructs receivers to deliver mail that failed authentication as normal and send you a report afterwards. p=quarantine asks receivers to junk failures. p=reject asks them to refuse the message during the SMTP conversation, and whoever tried to send a forged message sees a bounce along these lines:

550 5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy

Read past p= before you answer, because pct= and sp= can both change it. pct= throttles enforcement, so p=reject; pct=10 applies the policy to one failing message in ten and the truthful answer says so. sp= sets the policy for subdomains, so p=reject; sp=none leaves them unprotected and “all domains” is a no. A record with no sp= tag applies p= to subdomains as well, which is what you want. The DMARC page walks the record tag by tag if you need it.

Watch the spelling too. A receiver reads p=quarentine as an unreadable tag, and an unreadable policy falls back to monitoring at best. That particular misspelling shows up in the census’s malformed records, so give your own record a second look before you sign anything.

The form may also ask about domains that never send email: the old brand or the defensive registration you renew each year without thinking about. Each of those needs v=spf1 -all and v=DMARC1; p=reject so that nobody can send as it. Without those two records an attacker can send as the dormant domain and nothing on the receiving side will object.

When it’s in order, write: “Yes. example.com publishes v=DMARC1; p=reject with no pct= reduction, and the policy applies to all subdomains. Domains that send no mail publish v=spf1 -all and p=reject.”

When it isn’t, write: “example.com publishes DMARC at p=none with aggregate reporting enabled. Reports are being reviewed against the sender list; the policy moves to p=quarantine on [date] and to p=reject on [date].” That is a plan a reviewer can hold you to, which is what they’re after.

The reporting question

“Do you monitor DMARC aggregate reports?” is checking for a rua= tag with a mailbox behind it that somebody reads. The record above has rua=mailto:[email protected], and the question is whether the reports that arrive there go anywhere.

A record with no rua= is enforcing blind if it’s at p=reject, and monitoring nothing if it’s at p=none. Adding the tag costs one DNS edit; the reports are XML, and any of the free parsers will turn a week of them into a list of sending sources you can compare with your SPF record. If the rua= points at a mailbox that was deleted when someone left, the answer is no, and a reviewer who asks for a sample report will find that out quickly.

When it’s in order, write: “Yes. Aggregate reports are delivered to [mailbox or service] and reviewed [weekly] against the authorised sender list.”

What to attach as evidence

A reviewer wants something they didn’t have to take your word for. Attach the raw output of the lookups above and the dated scan result for each domain. For each sending system, add one full header block from a test message in which the Authentication-Results: line reads dmarc=pass.

The scan result is useful because it comes with a benchmark the reviewer can read without a call. Of the 316,600,902 graded domains in the September 2026 census, a set that includes dead domains, 80,995 hold an A+ and 546,149 hold an A. At the other end, 234,955,475, or 74.2%, hold an F. Once the records on this page are in place, your domain sits above most of that distribution, and the reviewer reads that off one letter.

The grade is a benchmark against that distribution and nothing else. It isn’t a certificate, it doesn’t map to any insurer’s rating scale, and you shouldn’t describe it as either on the form. Call it an independent, dated scan of your public DNS and mail configuration, which the reviewer can rerun for free to confirm.

If the truthful answer today is no

None of the fixes on this page cost money; each is a TXT record, and the order matters because DMARC enforcement punishes mail from senders you haven’t listed.

Start with SPF: list every sending service, reconcile the record, cut the lookups under ten, end in -all. Then DKIM: turn on signing at each platform, publish the key it gives you, send a test message and read the header. Then DMARC: publish p=none with rua=, wait for a week or two of reports, and check that nothing legitimate is failing. Move to p=quarantine, wait again, move to p=reject. The reporting windows are where the calendar time goes, and the record edits between them are small.

Put those dates in the form, then run the scan again on each one, attach the new result and send it to the reviewer without being asked, along with the header block from a fresh test message showing dmarc=pass.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.