Email test: my-bonnie-lies-over-the-ocean-10.misc.peterjin.org

The domain my-bonnie-lies-over-the-ocean-10.misc.peterjin.org has a test score of 100%.
Congratulations, your domain will be added to the Hall of Fame soon!

Passed : Modern address (IPv6)

Well done! Your mail server can be reached by senders using modern
addresses (IPv6), making it fully part of the modern Internet.

Name servers

Verdict:

Two or more name servers of your domain have an IPv6 address.

Technical details:

Name server IPv6 address IPv4 address
vm6-superhost.srv.peterjin.org. 2602:806:a000:8000::1 23.161.208.240
apps-vm8.srv.peterjin.org. 2600:3c03::f03c:92ff:fe5e:331f 172.104.25.121

Test explanation:

We check if your domain name has at least two name servers with an IPv6 address. This is consistent with the technical requirement of SIDN (.nl TLD registry) that each .nl domain must have at least two name servers.

Verdict:

All name servers that have an IPv6 address are reachable over IPv6.

Test explanation:

We check if all name servers, that have an AAAA record with IPv6 adress, are reachable over IPv6.
Mail server(s)

Verdict:

All receiving mail servers on your domain have an IPv6 address.

Technical details:

Mail server (MX) IPv6 address IPv4 address
m-i6t.srv.peterjin.org. 2602:806:a000:8000::25 23.161.208.241

Test explanation:

We check if there is at least one AAAA record with IPv6 address for every receiving mail server (MX). In case no mail server is defined, we give a notification and we execute other subtests of the mail test that are still relevant.

Verdict:

All your receiving mail servers with an IPv6 address are reachable over IPv6.

Test explanation:

We check if we can connect to your mail servers (MX) over IPv6 on port 25. We test all IPv6 addresses that we receive from the name servers of your mail server domain(s). A partial score will be given if not all IPv6 addresses are reachable. If an IPv6 address is (syntactically) invalid, we consider it unreachable.

Passed : Signed domain names (DNSSEC)

Well done! Your email address domain and your mail server domain(s) are signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are able to reliably query the IP address of your receiving mail server(s).

Email address domain

Verdict:

Your email address domain is DNSSEC signed.

Technical details:

Email address domain Registrar
my-bonnie-lies-over-the-ocean-10.misc.peterjin.org GoDaddy.com, LLC

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:

Email address domain Status
my-bonnie-lies-over-the-ocean-10.misc.peterjin.org secure

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.

Mail server domain(s)

Verdict:

All your mail server domains are DNSSEC signed.

Technical details:

Domain of mail server (MX) DNSSEC existent
m-i6t.srv.peterjin.org. yes

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:

Domain of mail server (MX) Status
m-i6t.srv.peterjin.org. secure

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.


Passed : Authenticity marks against phishing (DMARC, DKIM en SPF)

Well done! Your domain contains all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are able to reliably seperate phishing and spam emails abusing your domain in their sender address, from your authentic emails.

DMARC

Verdict:

Your domain has a DMARC record.

Technical details:

DMARC record
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@email.peterjin.org

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 DMARC policy is sufficiently strict.

Test explanation:

We check if the syntax of your DMARC record is correct and if it contains a sufficiently strict policy (p=quarantine or p=reject) in order to prevent abuse of your domain by phishers and spammers. Even without a strict policy, DMARC can be useful to get more insight in legitimate and illegitimate outbound mail flows through DMARC reports. However to be effective against abuse of your domain, a liberal policy (p=none) is insufficient.

We also check whether the mail addresses under rua= and ruf= are valid. In case they contain an external mail address we check whether the external domain is authorised to receive DMARC reports. Make sure that the DMARC authorization record on the external domain contains at least "v=DMARC1;".

As a quick win we recommend to set the most strict policy (p=reject) for your (sub-)domains that you do not use for sending mail in order to prevent abuse.

DKIM

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.nl. When _domainkey.example.nl 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).
SPF

Verdict:

Your domain has an SPF record.

Technical details:

SPF record
v=spf1 redirect=_spf-i6t.srv.peterjin.org

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.

Passed : Secure mail server connection (STARTTLS and DANE)

Well done! Sending mail servers supporting secure email transport (STARTTLS and DANE) can establish a secure connection with your receiving mail server(s). STARTTLS prevents passive attackers from reading emails in transit to you. DANE protects against active attackers stripping STARTTLS encryption by manipulating the mail traffic.

TLS

Verdict:

All your mail servers offer STARTTLS.

Technical details:

Mail server (MX) STARTTLS
m-i6t.srv.peterjin.org. yes

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:

At least one of your mail servers supports one or more TLS versions that should be phased out deliberately, because they are known to be fragile and at risk of becoming insufficiently secure.

Technical details:

Mail server (MX) Affected TLS versions Status
m-i6t.srv.peterjin.org. TLS 1.1 phase out
... TLS 1.0 phase out

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:

Mail server (MX) First found affected cipher
m-i6t.srv.peterjin.org. None

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. Ipv6.cool 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:

Mail server (MX) First found affected cipher pair
m-i6t.srv.peterjin.org. None

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:

Mail server (MX) Affected parameters
m-i6t.srv.peterjin.org. None

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:

Mail server (MX) SHA2 support for signatures
m-i6t.srv.peterjin.org. yes

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:

Mail server (MX) TLS compression
m-i6t.srv.peterjin.org. no

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:

Mail server (MX) Secure renegotiation
m-i6t.srv.peterjin.org. yes

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:

At least one of your mail servers allows for client-initiated renegotiation, which is not secure.

Technical details:

Mail server (MX) Client-initiated renegotiation
m-i6t.srv.peterjin.org. yes

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:

None of your mail servers support 0-RTT.

Technical details:

Mail server (MX) 0-RTT
m-i6t.srv.peterjin.org. no

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).

Certificate

Verdict:

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

Technical details:

Mail server (MX) Untrusted certificate chain
m-i6t.srv.peterjin.org. None

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:

Mail server (MX) Affected signature parameters
m-i6t.srv.peterjin.org. None

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:

Mail server (MX) Affected hash algorithm
m-i6t.srv.peterjin.org. None

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:

Mail server (MX) Unmatched domains on certificate
m-i6t.srv.peterjin.org. None

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)

DANE

Verdict:

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

Technical details:

Mail server (MX) DANE TLSA record existent
m-i6t.srv.peterjin.org. 3 1 1 9F1CEACD27F28E6C1EE37ED4D337343D1A6CC58BB87310E46AD72179A0DFEE01

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:

Mail server (MX) DANE TLSA record valid
m-i6t.srv.peterjin.org. yes

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:

At least one of your mail server domains does not have an active DANE scheme for a reliable rollover of certificate keys.

Technical details:

Mail server (MX) DANE rollover scheme
m-i6t.srv.peterjin.org. no

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