The Email Security Question Vendor Questionnaires Get Wrong

Open any standard vendor security questionnaire, SIG or CAIQ or a bank’s internal template, and find the email section. It asks three things:

• Do you publish an SPF record?
• Do you sign outbound mail with DKIM?
• Is DMARC at enforcement?

Answer yes three times and the section is complete. The buyer’s control is satisfied. And nothing in that exchange established whether mail containing their data crosses the internet encrypted.

Why the questionnaire has this gap

The three questions all come from the same era and the same concern: brand impersonation. Attackers were sending mail that claimed to be from your domain, and SPF, DKIM and DMARC were the answer. They work, and they are worth having.

They authenticate the message. None of them touch the connection.

SMTP negotiates encryption through an unauthenticated advertisement. A network-positioned attacker removes the STARTTLS offer from the receiving server’s greeting and the sender, seeing no encryption available, delivers in plaintext. DMARC still passes, because the message is still signed and still from an authorised sender. It is simply readable.

The questionnaire has no question for this, so it does not get assessed, so almost nobody deploys the control. Published measurements put MTA-STS adoption across the top million domains below one percent.

How to answer the question they meant

When a questionnaire asks “describe your email security controls”, the weak answer lists SPF, DKIM and DMARC. The strong answer separates the two problems explicitly, because doing so demonstrates you understand a distinction the form itself failed to make.

Something close to this:

Sender authentication. SPF, DKIM and DMARC are published, with DMARC at p=reject. These prevent third parties from sending mail that appears to originate from our domain.

Transport encryption. Separately, MTA-STS (RFC 8461) is published in enforce mode, requiring senders to use authenticated TLS when delivering to our domain. This prevents a network-positioned attacker from stripping STARTTLS and forcing plaintext delivery, which sender authentication does not address. TLS-RPT (RFC 8460) is enabled and we monitor the daily reports.

Both are externally verifiable: dig TXT _mta-sts.<domain> and curl https://mta-sts.<domain>/.well-known/mta-sts.txt.

Three things make this land. It names the attack the first group does not stop. It cites the RFCs. It gives the reviewer a command to check it themselves without trusting you, which is the same reason an external report carries weight a self-assessment does not.

If you do not have it yet

Do not claim it. A reviewer can check in ten seconds and a false claim in a questionnaire is materially worse than a gap, because it recontextualises every other answer.

The honest version, if the work is scheduled:

Transport encryption for inbound mail is deployed in testing mode and moves to enforce on [date] once TLS-RPT reports confirm all MX hosts negotiate correctly.

Then actually do it. The deployment is two DNS records and a static file.

The reciprocal question worth asking

If you are the one assessing vendors, this is a cheap and unusually informative question to add:

Does your domain publish an MTA-STS policy, and in which mode?

It costs nothing to verify, and the answer separates teams that treat security as a checklist from teams that read the underlying standards. A vendor in mode: testing who says “enforce” is telling you something useful. A vendor who knows the difference and explains why they are still in testing is telling you something better.

It also feeds directly into supply chain obligations under NIS2 Article 21(2)(d), where you are expected to assess your providers rather than accept assertions.

The adjacent controls nobody asks about either

While in this section of the form, two more gaps are worth pre-empting, because the questions are starting to appear:

DANE. Stronger than MTA-STS, authenticated by DNSSEC rather than by a CA. Deploy it after MTA-STS, since it depends on a signed zone.

BIMI. Brand indicators. Marketing value rather than security value, and it requires DMARC at enforcement first. Mentioning it in a security response is not a strength.

Where this maps

• NIS2 Article 21(2)(h) cryptography, 21(2)(e) network security.
• ISO/IEC 27001:2022 A.5.14, information transfer, which covers transfer rules and not just sender identity.
• DORA Article 9 for financial entities.
• BSI TR-03108 if you sell into Germany, where this is expected rather than optional.

The short version

The questionnaire asks who wrote the message. It does not ask whether the message was readable in transit.

Answer both. Name the gap the standard questions leave, cite the RFC, and hand the reviewer the command to verify it. That answer is memorable precisely because almost no other vendor gives it.