Germany's BSI publishes detailed technical guidelines on e-mail authentication

Primary attack vector

"Nowadays, people increasingly rely on and put their trust in digital communication," says the BSI's Florian Bierhoff, who co-authored the guidelines. "And e-mail is one of the most extensively used forms of digital communication. However, e-mail remains vulnerable to man-in-the-middle attacks, such as eavesdropping and message manipulation, and to impersonation attacks, such as spoofing and phishing. Also, an attack like that often serves as the initial vector for a larger-scale attack that compromises an organisation's entire network [1, 2]."

"The new guidelines are aimed at organisations with their own e-mail services and infrastructures, and at mail service providers. The security technologies covered by the guidelines are invisible to the end user. On the one hand, that's a strength, because it means that they can't be negated by user errors. On the other hand, managers tend not to like funding invisible features. The guidelines define a reasonable level of security and offer a way to make these technologies visible by means of labelling and certification."

State of the art

The authors of the TR-03182 guidelines identify SPF, DKIM and DMARC as state-of-the-art e-mail authentication technologies. They also recommend following TR-03108 Secure Email Transport, which provides similar guidelines and a similar certification mechanism for mail transport security based on (START)TLS, DANE, MTA-STS and TLS-RPT.

As you'll see in the mail column of our maturity model for the application of modern internet standards, the structure of our e-mail security stack is very similar. First comes the implementation of SPF and DKIM, followed by DMARC. With those standards implemented, the authenticity of the message, the sending host (a system) and the sender (a person) are all covered. After that, you can implement (START)TLS and DANE, securing mail transport as well.

Note that the end-to-end encryption of mail messages isn't addressed. That is typically done using OpenPGP and S/MIME on an individual basis. The advantage of the authentication and encryption solutions mentioned above is that they are completely transparent for the end user.

TR-03182 requirements

The TR-03182 guidelines contain fairly detailed requirements regarding e-mail authentication. For technical and background information about the relevant standards, see our e-mail security FAQs. On the same page, you'll find links to the hands-on guides to implementation of these security features in Exim and Postfix.

Although the BSI's guidelines often refer to legislation and other matters that are specific to Germany, we see the recommendations as very useful for Dutch organisations as well. In the following list, we have therefore set out the guidelines' requirements that aren't covered by the various documents referred to above.

SPF

No additional SPF specification and validation requirements.

DKIM

DKIM signing:

• The DKIM selector should preferably be unique. (From a purely technical perspective, it's no problem to use the same key pair for multiple domains simultaneously, or even for all the domains on the sending mail server.)

• We are currently transitioning from the RSA cryptographic method to Ed25519, so for now you need to sign your domain using both RSA-SHA256 and ED25519-SHA256 (RFC 8463). For RSA-SHA256, use a key of between 1024 and 2048 bits in length. The RSA-SHA1 method must no longer be used (in line with RFC 8301).

• It's best to replace the DKIM key pair every 3 months (by means of a minor rollover), and the interval between rollovers should definitely not be more than 6 months.

• A DKIM monitor must be set up to receive copies of all outbound messages, check that they are correctly signed, and alert the sender if they are not. The purpose of monitoring is to prevent the sending host's reputation, and therefore the deliverability of mail from the entire sending domain (e.g. an entire organisation), being compromised by a problem with a single sending address (or problems with a small number of addresses).

• The outbound mail server must use (strict) DKIM oversigning, implying that unused (blank) mail headers must be included in the signature. The purpose of that is to prevent DKIM replay attacks, where an attacker adds missing headers.

DKIM validation:

• The receiving mail server must be capable of validating both (RSA-based signatures and modern Ed25519-SHA256-based signatures.

• Signatures based on the now outdated RSA-SHA1 algorithm must not be accepted.

DMARC

DMARC publication:

• If possible, only strict alignment between, on the one hand, the From header and the envelope (SPF) and, on the other hand, the signing domain (DKIM) should be accepted. External service providers must only use a separate subdomain that has been delegated to them for sending messages on behalf of the client organisation.

• Only the 'reject' and 'quarantine' policies are acceptable; in due course, only the 'reject' policy will be acceptable.

• The DMARC record must include at least one RUA address and no RUF addresses.

• The data in the DMARC reports is personal data and, under the GDPR, must not therefore be processed outside the EU. Furthermore, there must be no possibility of the party that processes the reports being required to surrender the data by a foreign government (e.g. under the US Cloud Act or Freedom Act, the successor to the Patriot Act).

DMARC validation:

• Inbound messages must be processed in accordance with the sending domain's DMARC policy. A local override for a problematic sending domain is merely an emergency workaround, which leaves the underlying problem unresolved. Departures in the form of local overrides must be justified and documented.

DMARC reports:

• Regardless of what the sending domain's DMARC policy is, a receiving mail system should never send RUF reports; they include personal data and sending them therefore violates the GDPR.

• The DMARC report sender must include a valid e-mail address, so that the recipient can contact the sender if there is a problem.

• Inbound reports must be processed periodically by automated or other means.

Null MX

Domains without inbound mail portals:

• Must have a Null MX record: domainname.nl IN MX 0 .

• In addition, a corresponding SPF record must be published, in which no servers are authorised to send mail for the domain: domainname.nl IN TXT "v=spf1 -all"

• It's also necessary to publish a DMARC record with the 'reject' option set and an RUA address: _dmarc.domainname.nl IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@dmarc-processor.nl;" Finally, remember that the nominated DMARC report recipient must first publish a DMARC authorisation record for their own domain allowing delivery of the messages: domainname.nl._report._dmarc.example.nl IN TXT "v=DMARC1;"

DNSSEC

The DNS records for all 3 e-mail security standards (set on the sending side) should preferably be secured with DNSSEC. However, the use of DNSSEC isn't strictly necessary, because the corresponding RFCs make a soft requirement (SHOULD), rather than an absolute requirement (MUST), in order to avoid hindering adoption of the standards.

A DNSSEC-validating resolver is nevertheless required on the receiving side. Hence, DNS records signed on the sending side must always be validated on the receiving side.

Non-functional requirements

• A mail processor is required to draw up a security plan consistent with national telecommunications legislation, and must keep the plan updated.

• All processing must be GDPR-compliant.

• Users must be notified of any security problems, as required by national legislation.

• In addition, a mail processor must inform their users if they exchange mail with any other processors, who must also meet the requirements made in the technical guidelines.

• A mail processor can advertise their own compliance with the guidelines using an IT Security Label issued by the BSI, or by means of Certification to Technical Guidelines from a BSI-accredited auditor. The relevant conformity requirements and tests are defined in a separate document: Conformance Tests for Email Authentication in compliance with BSI TR-03182.

Pushing for adoption

"We don't have anything like the Dutch 'use-or-explain' principle in Germany," says Bierhoff. "Our guidelines are only recommendations. However, the adoption of TR-03182 is pushed in other ways: by making compliance with the guidelines a procurement condition, by providing labelling and certification systems that enable compliant service providers to gain a market advantage, and by getting Data Protection Officers to insist on compliance with the guidelines, as they did for TR-03108 [1]."

Dutch organisations can seek IT Security Labels or certification to the technical guidelines from the BSI if they wish. However, the labels can be applied only to products and services supplied to customers in Germany, and are currently available only for TR-03108 (v1). On the other hand, certification is available for TR-03108 (v2). A certification system for TR-03182 is being prepared, and organisations can already pre-apply to the BSI for certification.

Dutch NCSC publications

Here in the Netherlands, the National Cyber Security Centre (NCSC) published its latest ICT Security Guidelines or Transport Layer Security v2.1 (TLS) in 2021. The guidelines consider TLS and DANE in general terms, with the emphasis on configuration of the cryptographic algorithms [Exim, Postfix]. There is also the Factsheet on Secure Connections to Mail Servers, but that is a much briefer document, which dates from 2017. On its website, the NCSC reports that new versions of those 2 documents are being prepared, but the NCSC was unable to say what the current status of the updates is.

SPF, DKIM and DMARC are, however, covered in the recent Guide to Protecting Domains against Phishing, albeit briefly.

Shopping

For now, the German guidelines provide a sound, up-to-date basis for the implementation of e-mail authentication and secure mail transport. For details of the cryptographic algorithms used for TLS, the NCSC security guidelines remain a good source.

As soon as the NCSC publishes new versions of the relevant documents, further information will be provided on this website.