Verdict:

Your email address domain is DNSSEC signed.

Technical details:

Test explanation:

We check if your domain is DNSSEC signed. With a DNSSEC signature senders who validate domain signatures can verify the authenticity of the DNS reply that contains your mail server domains (MX). This prevents an attacker from manipulating the DNS answer in order to redirect mails sent to you to the attacker's mailserver domain.

If a domain redirects to another domain via CNAME, then we also check if the CNAME domain is signed (which is conformant with the DNSSEC standard). If the CNAME domain is not signed, the result of this subtest will be negative.

Note: the validity of the signature is not part of this subtest, but part of the next subtest.

Verdict:

Your email address domain is secure, because its DNSSEC signature is valid.

Technical details:

Test explanation:

We check if your domain is signed with a valid signature making it 'secure'.

If a domain redirects to another signed domain via CNAME, then we also check if the signature of the CNAME domain is valid (which is conformant with the DNSSEC standard). If the signature of the CNAME domain is not valid, the result of this subtest will be negative.

Verdict:

All your mail server domains are DNSSEC signed.

Technical details:

Test explanation:

We check if the domains of your mail servers (MX) are DNSSEC signed. With a DNSSEC signature senders who validate domain signatures can verify the authenticity of the DNS reply containing the IP addresses and DANE records of your mailserver(s). This prevents an attacker from manipulating the DNS answer in order to redirect mails sent to you to an IP address controlled by the attacker or to eavesdrop on the secured mail server connection.

If a domain redirects to another domain via CNAME, then we also check if the CNAME domain is signed (which is conformant with the DNSSEC standard). If the CNAME domain is not signed, the result of this subtest will be negative.

Note: the validity of the signature is not part of this subtest, but part of the next subtest.

Verdict:

All your signed mail server domains are secure, because their DNSSEC signatures are valid.

Technical details:

Test explanation:

We check if the domains of your receiving mail servers (MX) are signed with a valid signature making them 'secure'.

If a domain redirects to another signed domain via CNAME, then we also check if the signature of the CNAME domain is valid (which is conformant with the DNSSEC standard). If the signature of the CNAME domain is not valid, the result of this subtest will be negative.

Verdict:

Your domain has a DMARC record.

Technical details:

Test explanation:

We check if DMARC is available for your domain. A receiving mail server may use your DMARC policy to evaluate how to handle a mail with your domain as sender that could not be authenticated with both DKIM and SPF, and it may use your mail address from the DMARC record to provide feedback reports on the authentication to you. Having more than one DMARC record in the same domain is not valid and will lead to a test failure. Note: DMARC requires the SPF domain (envelope sender, i.e. return-path that shows up in MAIL FROM) and the DKIM domain (d=) to align with the mail body domain (From:).

Verdict:

Your domain supports DKIM records.

Test explanation:

We check if your domain supports DKIM records. A receiving mail server can use the public key in your DKIM record to validate the signature in an email with a user from your domain as sender and determine its authenticity.

• Currently we are not able to query and evaluate the public key in your DKIM record, because we would need the DKIM selector (that should be in the mails you send) to do so.
• To pass this test we expect your name server to answer NOERROR to our query for _domainkey.example.com. When _domainkey.example.com is an 'empty non- terminal' some name servers that are not conformant with the standard RFC2308 incorrectly answer NXDOMAIN instead of NOERROR. This makes it impossible for us to detect support for DKIM records.
• For this test we assume 'strict alignment' which is conformant with DMARC. The given domain is considered to be the sender domain in the mail body domain (From:) and this must be identical to the DKIM domain (d=) and the SPF domain (envelope sender, i.e. return-path that shows up in MAIL FROM).

Verdict:

Your domain has an SPF record.

Technical details:

Test explanation:

We check if your domain has an SPF record. A receiving mail server can use your whitelisted sending mail servers and the accompanying policy from your SPF record to determine the authenticity of a received email with your domain as sender. Having more than one SPF record in the same domain is not valid and will lead to a test failure.

Verdict:

Your SPF policy is sufficiently strict.

Test explanation:

We check if the syntax of your SPF record is correct and if it contains a sufficienly strict policy i.e. ~all (softfail) or -all (hardfail) in order to prevent abuse by phishers and spammers. To be effective against abuse of your domain, a liberal policy i.e. +all (pass) or ?all (neutral) is insufficient. If all is missing and a redirect modifier is not present in your SPF record, the default is ?all. We also follow include and redirect for valid SPF records. A maximum of 10 DNS lookups are allowed when following those. If the include or redirect domain consists of macros, we will not follow them as we do not have the necessary information from an actual mail or mail server connection to expand those macros. Note that as a quick win we recommend you to set the most strict policy (-all) for (sub-)domains that you do not use for sending mail in order to prevent abuse.

Verdict:

All your mail servers offer STARTTLS.

Technical details:

Test explanation:

We check if your receiving mail servers (MX) support STARTTLS.

If so, we also check in the below subtests whether STARTTLS is configured sufficiently secure. In case no mail server is defined, we give a notification and we execute other subtests of the mail test that are still relevant.

Note: for performance reasons at most ten mail servers over either IPv6 or IPv4 are checked in the STARTTLS test category.

Verdict:

All your mail servers support secure TLS versions only.

Technical details:

Test explanation:

We check if your mail servers (MX) support secure TLS versions only.

A mail server may support more than one TLS version.

Note: Quite some mail servers only support older TLS versions. If the sending and receiving mail server both do not support the same TLS version, they will usually fall back to unencrypted mail transport. Because of that it could be advisable to keep supporting TLS versions with a 'phase out' status for a while. Make an informed decision based on log data on when to disable these 'phase out' TLS versions.

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.0' from NCSC-NL, guideline B1-1 and table 1 (in English).

---

• Good: TLS 1.3 and 1.2
• Phase out: TLS 1.1 and 1.0
• Insufficient: SSL 3.0, 2.0 and 1.0

Verdict:

All your mail servers support secure ciphers only.

Technical details:

Test explanation:

We check if your receiving mail servers (MX) support secure ciphers (algorithm selections) only. To prevent us from running into rate limits of receiving mail servers, the test result only contains the first found affected algorithm selections.

An algorithm selection consists of ciphers for four cryptographic functions: 1) key exchange, 2) certificate verification, 3) bulk encryption, and 4) hashing. A web server may support more than one algorithm selection.

• Since TLS 1.3, the term 'cipher suite' only comprises ciphers used for bulk encryption and hashing. When using TLS 1.3 the ciphers for key exchange and certificate verification are negotiable and not part of the naming of the cipher suite. Because this makes the term 'cipher suite' ambiguous, NCSC-NL uses the term 'algorithm selection' to comprise all four cipher functions.

• NCSC-NL uses the IANA naming convention for algorithm selections. Internet.nl uses the OpenSSL naming convention. Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B2-1 to B2-4 and table 2, 4, 6 and 7 (in English).

---

Below you find 'Good', 'Sufficient' and 'Phase out' algorithm selections in the by NCSC-NL prescibed order, based on appendix C of the 'IT Security Guidelines for Transport Layer Security (TLS)'. Behind every algorithm selection is the minimum TLS version (e.g. [1.2]) that supports this algorithm selection and that is at least 'Phase out'.

Good:

• ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
• ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
• ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
• ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
• ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
• ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Sufficient:

• ECDHE-ECDSA-AES256-SHA384 [1.2]
• ECDHE-ECDSA-AES256-SHA [1.0]
• ECDHE-ECDSA-AES128-SHA256 [1.2]
• ECDHE-ECDSA-AES128-SHA [1.0]
• ECDHE-RSA-AES256-SHA384 [1.2]
• ECDHE-RSA-AES256-SHA [1.0]
• ECDHE-RSA-AES128-SHA256 [1.2]
• ECDHE-RSA-AES128-SHA [1.0]
• DHE-RSA-AES256-GCM-SHA384 [1.2]
• DHE-RSA-CHACHA20-POLY1305 [1.2]
• DHE-RSA-AES128-GCM-SHA256 [1.2]
• DHE-RSA-AES256-SHA256 [1.2]
• DHE-RSA-AES256-SHA [1.0]
• DHE-RSA-AES128-SHA256 [1.2]
• DHE-RSA-AES128-SHA [1.0]

Phase out:

• ECDHE-ECDSA-DES-CBC3-SHA [1.0]
• ECDHE-RSA-DES-CBC3-SHA [1.0]
• DHE-RSA-DES-CBC3-SHA [1.0]
• AES256-GCM-SHA384 [1.2]
• AES128-GCM-SHA256 [1.2]
• AES256-SHA256 [1.2]
• AES256-SHA [1.0]
• AES128-SHA256 [1.2]
• AES128-SHA [1.0]
• DES-CBC3-SHA [1.0]

Verdict:

All your mail servers enforce their own cipher preference ('I'), and offer ciphers in accordance with the prescribed ordering ('II').

Technical details:

Test explanation:

We check if your receiving mail servers (MX) enforce their own cipher preference ('I'), and offer ciphers in accordance with the prescribed ordering ('II').

If your mail servers support 'Good' ciphers only, this test is not applicable as the ordering has no significant security advantage.

I. Server enforced cipher preference: The receiving mail servers enforce their own cipher preference while negotiating with sending mail servers, and do not accept any preference of the sending mail servers. (requirement level: Required);

II. Prescribed ordering: Ciphers are offered by the receiving mail server in accordance with the below prescribed order in which safe and fast ciphers are preferred.

A. Prefer 'Good' over 'Sufficient' over 'Phase out' ciphers (requirement level: Required);

B. Within a particular security level, proceed as follows:

1. Ciphers that perform key exchange based on elliptic curves are preferred over those that use finite fields. Both are preferred over ciphers that use a static key exchange (requirement level: Recommended);
2. Ciphers that do bulk encryption based on AEAD algorithms are preferred over alternatives (requirement level: Recommended);
3. Ciphers that do certificate verification based on ECDSA are preferred over RSA (requirement level: Recommended);
4. Ciphers are preferred in descending order of their key and then hash size (requirement level: Recommended);
5. AES-256 is preferred over ChaCha20 (requirement level: Optional).

In the above table with technical details only the first found out of prescribed order algorithm selections are listed, with the violated prescribed ordering rule shown next to it.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B2-5.

Verdict:

All your mail servers support secure parameters for Diffie-Hellman key exchange.

Technical details:

Test explanation:

We check if the public parameters used in Diffie-Hellman key exchange by your receiving mail servers (MX) are secure.

The security of elliptic curve Diffie-Hellman (ECDHE) ephemeral key exchange depends on the used elliptic curve. We check if the bit-length of the used elliptic curves is a least 224 bits. Currently we are not able to check the elliptic curve name.

The security of Diffie-Hellman Ephemeral (DHE) key exchange depends on the lengths of the public and secret keys used within the chosen finite field group. We test if your DHE public key material uses one of the predefined finite field groups that are specified in RFC 7919. Self-generated groups are 'Insufficient'.

The larger key sizes required for the use of DHE come with a performance penalty. Carefully evaluate and use ECDHE instead of DHE if you can.

Besides ECDHE and DHE, RSA can be used for key exchange. However, it is at risk of becoming insufficiently secure (current status 'phase out'). The RSA public parameters are tested in the subtest 'Public key of certificate'. Note that RSA is considered as 'good' for certificate verification.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B5-1 and table 9 for ECDHE, and guideline B6-1 and table 10 for DHE (in English).

---

Elliptic curve for ECDHE

• Good: secp384r1, secp256r1, x448, and x25519
• Phase out: secp224r1
• Insufficient: Other curves

Finite field group for DHE

Sufficient:

• ffdhe4096 (RFC 7919)
  sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3

• ffdhe3072 (RFC 7919)
  sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab

Phase out:

• ffdhe2048 (RFC 7919)
  sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

Insufficient: Other groups

Verdict:

All your mail servers support secure hash functions for key exchange.

Technical details:

Test explanation:

We check if your receiving mail servers (MX) support secure hash functions to create the digital signature during key exchange.

A receiving mail server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The mail server creates this digital signature by signing the output of a hash function.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, table 5.

Requirement level: Recommended

---

SHA2 support for signatures

• Good: Yes (SHA-256, SHA-384 or SHA-512 supported)
• Phase out: No (SHA-256, SHA-384 of SHA-512 not supported)

Verdict:

All your mail servers do not support TLS compression.

Technical details:

Test explanation:

We check if your receiving mail servers (MX) support TLS compression.

The use of compression can give an attacker information about the secret parts of encrypted communication. An attacker that can determine or control parts of the data sent can reconstruct the original data by performing a large number of requests. TLS compression is used so rarely that disabling it is generally not a problem.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B7-1 and table 11 (in English).

Verdict:

All your mail servers support secure renegotiation.

Technical details:

Test explanation:

We check if your mail servers (MX) support secure renegotiaton.

Older versions of TLS (prior to TLS 1.3) allow forcing a new handshake. This so-called renegotiation was insecure in its original design. The standard was repaired and a safer renegotiation mechanism was added. The old version is since called insecure renegotiation and should be disabled.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B8-1 and table 12 (in English).

Verdict:

All your mail servers do not allow for client-initiated renegotiation.

Technical details:

Test explanation:

We check if a sending mail server can initiate a renegotiation with your receiving mail servers (MX).

Allowing sending mail servers to initiate renegotiation is generally not necessary and opens a receiving mail server to DoS attacks inside a TLS connection. An attacker can perform similar DoS-attacks without client-initiated renegotiation by opening many parallel TLS connections, but these are easier to detect and defend against using standard mitigations. Note that client-initiated renegotiation impacts availability and not confidentiality.

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.0' from NCSC-NL, guideline B8-1 and table 13 (in English).

Requirement level: Recommended

Verdict:

This subtest is not applicable as your mail servers do not support TLS 1.3.

Technical details:

Test explanation:

We check if your mail servers (MX) support Zero Round Trip Time Resumption (0-RTT).

0-RTT is an option in TLS 1.3 that transports application data during the first handshake message. 0-RTT does not provide protection against replay attacks at the TLS layer and therefore should be disabled. Although the risk can be mitigated by not allowing 0-RTT for non-idempotent requests, such a configuration is often not trivial, reliant on application logic and thus error prone.

If your mail servers do not support TLS 1.3, the test is not applicable. For mail servers that support TLS 1.3, the STARTTLS command is issued and a TLS session is initiated. The amount of early data support indicated by the mail server is checked. When more than zero, a second connection is made re-using the TLS session details of the first connection but sending the EHLO command before the TLS handshake but after the STARTTLS command (i.e. no round trips (0-RTT) needed before application data to the server). If the TLS handshake is completed and the mail server responds, then the mail server is considered to support 0-RTT.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B9-1 and table 14 (in English).

Verdict:

The trust chain of all your mail server certificates is complete and signed by a trusted root certificate authority.

Technical details:

Test explanation:

We check if we are able to build a valid chain of trust for your mail server certificates.

For a valid chain of trust, your certificate must be published by a publicly trusted certificate authority, and your receiving mail server must present all necessary intermediate certificates.

Sending mail servers usually ignore whether a mail server certificate is issued by a publicly trusted certificate authority. Without DNSSEC the lookup of the mail server domain is vulnerable to manipulation. Thus a certificate issued by a publicly trusted certificate authority cannot add any authenticity value. Quite a few receiving mail servers are therefore using self-signed certificates, often issued by an internal (private) certificate authority. For authenticity a mail server should use DNSSEC and DANE.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B3-4 (in English).

Requirement level: Optional

Verdict:

The digital signatures of all your mail server certificates use secure parameters.

Technical details:

Test explanation:

We check if the (ECDSA or RSA) digital signature of each of your mail server certificates uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier. The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.0' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

---

Elliptic curves for ECDSA

• Good: secp384r1, secp256r1, x448, and x25519
• Phase out: secp224r1
• Insufficient: Other curves

Length of RSA-keys

• Good: At least 3072 bit
• Sufficient: 2048 – 3071 bit
• Insufficient: Less than 2048 bit

Verdict:

All your mail server certificates are signed using a secure hash algorithm.

Technical details:

Test explanation:

We check if the signed fingerprint of each of your mail server certificates was created with a secure hashing algorithm.

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.0' from NCSC-NL, guideline B3-2 and table 3 (in English).

---

Hash functions for certificate verification

• Good: SHA-512, SHA-384, SHA-256
• Insufficient: SHA-1, MD5

Verdict:

The domain names of all your mail servers match the domain names on your mail server certificates.

Technical details:

Test explanation:

We check if the domain name of each of your receiving mail servers (MX) matches the domain name on the presented certificates.

Sending mail servers usually ignore the domain in the certificate. Without DNSSEC the lookup of the mail server domain is vulnerable to manipulation. Thus matching the domain on the certificate against the mail server domain does not add any authenticity value. Quite a few receiving mail servers are therefore using self-signed certificates, often issued by an internal (private) certificate authority.

For authenticity a mail server should use DNSSEC and DANE. A certificate with a domain that matches the domain of the mail server is only required when DANE 'trust anchor assertion' (DANE-TA, 2) is used.

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.0' from NCSC-NL, guideline B3-1 (in English).

Requirement level: Optional / Required (only when DANE-TA is used)

Verdict:

All your mail server domains provide a TLSA record for DANE.

Technical details:

Test explanation:

We check if the name servers of each of your receiving mail servers (MX) provide a TLSA record for DANE.

As DNSSEC is preconditional for DANE, this test will fail in case DNSSEC is missing on the mail server domain(s).

Furthermore the test will lead to a fail if there is no DNSSEC proof of 'Denial of Existence' for TLSA records. If a signed TLSA record exists but at the same time there is an insecure NXDOMAIN for the same domain (due to faulty signer software), the test will also show a fail. The latter two failure scenario's could lead to non-delivery of emails addressed to you by DANE validating mail senders.

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.0' from NCSC-NL, Appendix A, under 'Certificate pinning and DANE' (in English).

Verdict:

The DANE fingerprints on your mail server domains are valid for all your mail server certificates.

Technical details:

Test explanation:

We check if the DANE fingerprints presented by your mail server domains are valid for your mail server certificates.

DANE allows you to publish information about your mail server certificates in a special DNS record, called TLSA record. Sending mail servers can check the authenticity of your certificates not only through the certificate authority but also through the TLSA records. A sending mail server can also use the TLSA record as a signal to only connect via STARTTLS (and not unencrypted). When the DANE fingerprint of a receiving mail server is checked by the sending mail server, an active attacker who is able to manipulate the mail trafic cannot strip STARTTLS encryption.

Verdict:

All your mail server domains have an active DANE scheme for a reliable rollover of certificate keys.

Technical details:

Test explanation:

We check if there is an active DANE scheme to reliably handle certificate rollovers on your receiving mailservers (MX).

Such a scheme will be proven useful when there is a need to update your mail server certificate(s). It can prevent that DANE becomes invalid during the transition period which could endanger mail deliverability at your domain. A rollover scheme is not expected to be 'active' all the time.

Below you will find two possible DANE rollover procedures (source: slides by Viktor Dukhovni). In each procedure two DANE TLSA records need to be present which is checked by this subtest.

Requirement level: Optional

---

DANE rollover procedures

1. Current + Next

• Generate next key when deploying current key and cert

• Deploy new chain, and publish new TLSA records:

• _25._tcp.mx.example.com. IN TLSA 3 1 1 curr-pubkey-sha256

• _25._tcp.mx.example.com. IN TLSA 3 1 1 next-pubkey-sha256

• Weeks later, obtain certificate for pre-generated next key

• But first, make sure TLSA record is already in place

• Repeat!

2. Current + Issuer CA

• Publish TLSA RRs for server key & issuer CA key:

• _25._tcp.mx.example.com. IN TLSA 3 1 1 ee-pubkey-sha256

• _25._tcp.mx.example.com. IN TLSA 2 1 1 ta-pubkey-sha256

• Deploy certificates from same CA, if EE key changes:

• Promptly update 3 1 1 hash to match new EE key

• If CA key changes, keep same EE key

• Obtain cert from new CA

• Promptly update 2 1 1 hash to match new CA key