What the two guidelines require
The technical guideline BSI TR-03108 “Secure email transport” describes how mail servers exchange messages encrypted: STARTTLS with at least TLS 1.2, valid certificates, a zone signed with DNSSEC for the domain and the mail servers, DANE records so that senders cannot be talked down to plain text, and TLS-RPT for failure reports. MTA-STS is an optional building block next to DANE.
BSI TR-03182 “Email authentication” protects the sender name: exactly one SPF record with a hard ending, DKIM keys for RSA-SHA256 and Ed25519-SHA256, DMARC with quarantine or reject and at least one address for aggregate reports. For domains that do not send email it asks for a null MX, “v=spf1 -all” and DMARC reject.
What the quick check tests
The quick check uses the same checks as DomainWarn’s continuous monitoring and the same criteria as our compliance report. The criteria are based on BSI TR-03108 and TR-03182; only what is visible from the outside through DNS and the mail servers is checked.
- Mail servers (MX): STARTTLS, negotiated TLS version and certificate. The check only opens these connections on port 25 if the check location allows it; otherwise the three criteria show as “not checkable”.
- DNSSEC: is the zone of the domain signed with a valid chain, and do the mail servers sit in a signed zone too?
- DANE: TLSA records for every mail server in a signed zone.
- MTA-STS (SHOULD, optional): a policy in enforce mode covering all MX hosts. Not counted in the summary.
- TLS-RPT: a valid record with a mailto reporting address.
- Mail clients: published endpoints via SRV and Autoconfig, encrypted and with implicit TLS (SUBMISSIONS, IMAPS).
- SPF, DKIM and DMARC under TR-03182, plus the protection of domains that do not send email.
How to read the result
Each criterion names its identifier from the guideline, such as TR-03108-03-M, and the level: MUST or SHOULD. Below it you see the evidence (what the check saw) and, if something is missing, the recommendation.
- Met: the check confirmed the criterion from the outside.
- Partly met: part of it is missing, such as a DKIM key for Ed25519 next to RSA, or TLSA records for only one of two mail servers.
- Not met: the criterion is missing or set up incorrectly.
- Not checkable: the check could not tell, for example because the domain does not receive email, the time limit was reached or port 25 is not enabled.
- Not applicable: does not apply to this domain, such as the rules for domains without email on a domain that sends email.
How it is counted
The summary at the top counts like the compliance report: optional criteria (MTA-STS) and those that do not apply are left out, not checkable ones are counted. “11 of 14 met” means: of 14 criteria that apply to the domain, the check confirmed 11.
What the quick check cannot do
The check is an automated test from the outside. It does not replace an assessment by the BSI or an auditor, nor any certification. It does not see outgoing mail servers, internal systems or the organisational requirements of the guidelines, and the result reflects the moment of the lookup.
Keep an eye on it
A DNS record changes quickly, a certificate expires, a new mail server shows up without a TLSA record. DomainWarn checks your clients’ domains regularly, reports changes, creates the compliance report as a PDF and shows with the “Email security checked” seal that the domain is being monitored.