BSI TR-03108: Why German Buyers Ask About Your Mail Transport

Vendors selling into Germany often meet a question that surprises them: how is transport encryption enforced for mail sent to your domain?

It surprises them because their email security is, by their own assessment, in good order. SPF is published, DKIM signs outbound mail, DMARC is at p=quarantine or better. Every mainstream checker reports green.

The question is about something else entirely, and it comes from BSI TR-03108.

What the guideline requires

TR-03108 is the German technical guideline for secure email transport. Its distinguishing feature is that it does not treat transport security mechanisms as a menu. It expects DANE, MTA-STS and TLS-RPT together, and the reasoning is worth understanding because it explains why “we have DMARC” is not a response.

The three answer different questions:

Mechanism	Question it answers
SPF / DKIM / DMARC	Is this message genuinely from the claimed sender?
MTA-STS	Must senders use authenticated TLS to reach me?
DANE	Same, but authenticated by DNSSEC rather than by a CA
TLS-RPT	Did TLS delivery actually succeed, and if not, why?

Sender authentication and transport encryption are orthogonal. A domain can have perfect DMARC and still accept mail over a connection an attacker downgraded to plaintext, because the STARTTLS advertisement itself is unauthenticated.

DANE and MTA-STS are not alternatives

This is the part most teams get wrong when they first read the guideline.

DANE publishes a TLSA record in DNS, authenticated by DNSSEC. It has no dependency on the certificate authority system, which makes it cryptographically stronger. It also requires DNSSEC on your zone, which remains the main reason adoption is low.

MTA-STS publishes a policy over HTTPS, authenticated by the CA system. No DNSSEC required, which makes it deployable on essentially any domain today.

Senders that support both prefer DANE and fall back to MTA-STS when DNSSEC validation is unavailable. Deploying both is therefore defence in depth rather than redundancy, which is precisely why the guideline expects both.

For a SaaS vendor with no DNSSEC on the zone, the practical sequence is: MTA-STS and TLS-RPT first, because they can ship this week, then DNSSEC and DANE as a separate project.

Why it appears in NIS2 assessments

Germany’s NIS2 implementation puts the BSI in the supervisory role, and BSI supervision draws on BSI technical guidelines for what “state of the art” means in practice.

NIS2 Article 21(2)(h) requires policies on cryptography and encryption. The directive does not enumerate mechanisms. TR-03108 is what fills that gap for email in a German context, which is how a guideline that is not itself binding on you ends up shaping the question you are asked.

If you have received a BSI letter, transport security for mail is a finding that closes quickly and demonstrates responsiveness, which is worth more than its technical weight in that conversation.

The deployment, concretely

Three DNS records and one static file.

; 1. Advertise the MTA-STS policy
_mta-sts.example.com.  IN TXT "v=STSv1; id=20260919120000"

; 2. Reporting channel
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Then serve this at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

The subdomain needs a valid certificate, which any static host provides. Microsoft 365 tenants use the *.mail.protection.outlook.com pattern in the mx field.

Start in mode: testing, read TLS-RPT reports for a few weeks, then move to enforce. Switching straight to enforce with an incomplete mx list is the one way this causes an outage.

What the German market rewards

Adoption of MTA-STS across the top million domains sits below one percent. The asymmetry that creates is the practical argument: the control costs an afternoon, almost no competitor has it, and it is externally verifiable by anyone assessing you.

For a vendor positioning against German Mittelstand buyers or answering a BSI IT-Grundschutz aligned questionnaire, that combination is unusual: most differentiators are expensive and invisible. This one is cheap and checkable.

How to verify

dig +short TXT _mta-sts.example.com
curl -s https://mta-sts.example.com/.well-known/mta-sts.txt
dig +short TXT _smtp._tls.example.com
dig +short TLSA _25._tcp.mx1.example.com   # DANE, needs DNSSEC

A SaaSFort scan reports the MTA-STS mode rather than merely the presence of a record, because a policy in testing satisfies a checkbox and protects nothing.

The short version

German buyers ask about mail transport because their national guideline treats it as a distinct control from sender authentication, and it is.

MTA-STS plus TLS-RPT is deployable now on any domain. DANE is the stronger mechanism and waits on DNSSEC. Doing the first pair immediately is the right sequence.