Failed : IPv6

Too bad! Your mail server can not be reached by senders using modern IPv6 addresses, or improvement is possible. Therefore your mail server is not part of the modern Internet yet. You should ask your email provider to fully enable IPv6.

Mail server(s)

Verdict:

At least one receiving mail server on your domain does not have an IPv6 address.

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.

Technical details:

Mail server (MX) IPv6 address IPv4 address
mx01.emig.gmx.net. - 212.227.17.5
mx00.emig.gmx.net. - 212.227.15.9

Verdict:

This test did not run, because a parent test that this test depends on already gave a negative result (’fail’).

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.

Name servers

Verdict:

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

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.

Technical details:

Name server IPv6 address IPv4 address
ns-gmx.ui-dns.de. 2001:8d8:fe:53:0:d9a0:50c7:100 217.160.80.199
ns-gmx.ui-dns.biz. 2001:8d8:fe:53:0:d9a0:51c7:100 217.160.81.199
ns-gmx.ui-dns.org. 2001:8d8:fe:53:0:d9a0:53c7:100 217.160.83.199
ns-gmx.ui-dns.com. 2001:8d8:fe:53:0:d9a0:52c7:100 217.160.82.199

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.


Passed : DNSSEC

Well done! Your email address domain and your mail server domain(s) are signed with a valid signature. 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 domain is DNSSEC signed.

Test explanation:

We check if your domain is DNSSEC signed. Note: the validity of the signature is not part of this subtest, but part of the next subtest.

Technical details:

Domain Registrar
gmx.de -

Verdict:

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

Test explanation:

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

Technical details:

Domain Status
gmx.de secure
Mail server domain(s)

Verdict:

All your mail server domains are DNSSEC signed.

Test explanation:

We check if the domains of your mail servers (MX) are DNSSEC signed. Note: the validity of the signature is not part of this subtest, but part of the next subtest.

Technical details:

Domain of mail server (MX) DNSSEC existent
mx00.emig.gmx.net. yes
mx01.emig.gmx.net. yes

Verdict:

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

Test explanation:

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

Technical details:

Domain of mail server (MX) Status
mx00.emig.gmx.net. secure
mx01.emig.gmx.net. secure

Failed : DMARC, DKIM and SPF

Too bad! Your domain does not contain all authenticity marks against email forgery. Therefore receivers are not able to reliably seperate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.

Verdict:

Your domain does not have a DMARC record.

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 this to you. Currently we do not evaluate the DMARC policy. Even without an active policy DMARC can be useful to get more insight in legitimate and illegitimate outbound mail flows through DMARC reports. However in order for DMARC to be effective against abuse of your domain for phishing and spam, you need to set an active policy (quarantine or reject). As a quick win we recommend to set a reject policy for (sub-)domains that you do not use for sending mail to prevent abuse by others. 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:). Having more than one DMARC record in the same domain is not valid and will lead to a test failure.

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 evaluate the public key in your DKIM record, because we would need to receive an email from your domain 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.

Verdict:

Your domain has an SPF record.

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. Currently we do not evaluate the SPF policy. In order for SPF to be effective against abuse of your domain for phishing and spam, you need to set an active policy i.e. ~all (soft fail) or -all (hard fail). As a quick win we recommend to set a ‘hard fail’ policy for (sub-)domains that you do not use for sending mail to prevent abuse by others. Having more than one SPF record in the same domain is not valid and will lead to a test failure.

Technical details:

SPF record
v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/27 -all

Passed : STARTTLS

Well done! Sending mail servers supporting STARTTLS can establish a secure connection with your receiving mail server(s). Passive attackers will therefore not be able to read emails in transit to you. Note: we additionally recommend to publish DANE records to counteract active attackers from stripping STARTTLS encryption by manipulating the mail traffic.

TLS

Verdict:

All your mail servers offer STARTTLS.

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

Technical details:

Mail server (MX) STARTTLS
mx00.emig.gmx.net. yes
mx01.emig.gmx.net. yes

Verdict:

All your mail servers support sufficiently secure TLS versions.

Test explanation:

We check if your receiving mail servers (MX) support secure TLS versions. See ’TLS guidelines from NCSC-NL’, guideline B1-1 (in Dutch).

Technical details:

Mail server (MX) Secure TLS versions
mx00.emig.gmx.net. yes
mx01.emig.gmx.net. yes

Verdict:

All your mail servers support sufficiently secure cipher suites.

Test explanation:

We check if your receiving mail servers (MX) support sufficiently secure cipher suites. A cipher suite is a combination of algorithms used for authentication and encryption that is conformant to the TLS standard. A mail server may support more than one cipher suite. See ’TLS guidelines from NCSC-NL, guideline B2-1 to B2-4 (in Dutch).

Technical details:

Mail server (MX) Secure cipher suites
mx00.emig.gmx.net. yes
mx01.emig.gmx.net. yes
Certificate

Verdict:

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

Test explanation:

We check if we are able to build a valid chain of trust for your mail server certificate. For a valid chain of trust, your certificate must be published by a trusted certificate authority, and your receiving mail server must present all necessary intermediate certificates. See ’TLS guidelines from NCSC-NL’, guideline B3-6 (in Dutch).

Technical details:

Mail server (MX) Untrusted certificate chain
mx00.emig.gmx.net. -
mx01.emig.gmx.net. -

Verdict:

All your mail server certificates contain a public key with a sufficiently secure length.

Test explanation:

We check if the bit-length of the public key of your mail server certificate is sufficiently secure. Note: it is also important that the bit-length of the secret key is sufficiently secure. However, due to its secret nature we are not able to check this. See ’TLS guidelines from NCSC- NL’, guideline B3-3 to B3-5 (in Dutch).

Technical details:

Mail server (MX) Public key with insufficient length
mx00.emig.gmx.net. -
mx01.emig.gmx.net. -

Verdict:

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

Test explanation:

We check if the signed fingerprint of the mail server certificate was created with a secure hashing algorithm. See ’TLS guidelines from NCSC- NL’, guideline B3-2 (in Dutch).

Technical details:

Mail server (MX) Insecure hash algorithm
mx00.emig.gmx.net. -
mx01.emig.gmx.net. -

Verdict:

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

Test explanation:

We check if the domain name of your receiving mail server (MX) matches the domain name on the certificate. See ’TLS guidelines from NCSC- NL’, guideline B3-1 (in Dutch).

Technical details:

Mail server (MX) Unmatched domains on certificate
mx00.emig.gmx.net. -
mx01.emig.gmx.net. -
DANE

Verdict:

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

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. DNSSEC is preconditional for DANE. Note: cases where we detect a valid TLSA record but no DNSSEC support or where we get an error while retrieving the TLSA record, are also considered failures for this test.

Technical details:

Mail server (MX) DANE valid
mx00.emig.gmx.net. yes
mx01.emig.gmx.net. yes