Mail that arrives: everything internet.nl checks, and why

THE SCORE

How to check the configuration

internet.nl is a free test run by the Dutch government and a group of internet organisations. It has two halves that matter here: one for a website and one for a mail domain. Both are pass or fail per test, and both are public.

You can run the tests against ave17.com yourself; the roadmap describes the intended publication of dated results.

It is worth saying what the score is not. It measures configuration, not conduct: a perfect score proves that a domain cannot easily be forged and that its mail is carried encrypted. It proves nothing about whether the people behind it answer their mail.

WHO SENT IT

SPF, DKIM and DMARC, in the order they matter

These three answer one question between them: is this message really from that domain. They are usually deployed in the wrong order, which is why so many domains have all three and are still forgeable.

SPF

Lists which machines may send for the domain. Cheap, and weak on its own: it breaks the moment a message is forwarded, because the forwarder is not on the list.

DKIM

Signs the message itself, so it survives forwarding. We sign with two keys, RSA and Ed25519, because some receivers still do not understand the second and we would rather not choose.

DMARC

Tells a receiver what to do when the first two fail, and asks for a report when they do. Ours is p=reject: throw it away. Anything softer is a polite request that most senders ignore.

The order that works is DKIM first, then SPF, then DMARC in monitoring mode until the reports are quiet, then reject. Going straight to reject is how an organisation discovers, in public, which of its systems was sending mail nobody knew about.

HOW IT TRAVELLED

Encryption that cannot be stripped

Mail servers have offered opportunistic encryption for twenty years, and opportunistic means an attacker in the middle can simply remove the offer and watch the two servers fall back to plain text. Neither end notices. Two mechanisms close that, and they are the two most domains do not have.

MTA-STS

A policy served over HTTPS saying "always use TLS with these hostnames, and if you cannot, do not deliver". We publish it in enforce mode, which is the only mode that does anything.

DANE

The certificate a receiver should expect, published in DNS and signed by DNSSEC, so the sending server can check the certificate against the domain rather than against a list of certificate authorities. We publish TLSA records on submission, submissions, IMAPS and on the mail exchanger itself.

DNSSEC

Signatures over the DNS answers themselves. Without it every record above is a claim an attacker can rewrite in transit, which is why DANE requires it and why every zone we run is signed.

MTA-STS and DANE overlap deliberately. One is easy to deploy and trusts the web certificate system; the other is harder and trusts DNSSEC. A domain with both is protected whichever of the two an attacker can reach.

THE WEB HALF

What the site test asks for

The web side of the same test is mostly about the same idea: that a connection cannot be downgraded and that the certificate cannot be swapped.

• IPv6 on both the site and its name servers, reachable and answering the same content as IPv4
• DNSSEC on the zone, so the address itself cannot be rewritten
• HTTPS with modern ciphers, HSTS, and no downgrade path
• DANE on the web certificate as well, which almost nothing does
• CAA closed, so only the authority we name can issue for the domain
• Security headers that stop the page being framed or sniffed into something else

THE TWO WORTH UNDERSTANDING

Where the score can mislead you

First: DMARC at p=reject on a domain that never sends mail is trivial, and a domain that carries real traffic gets there only after reading reports for weeks. Same score, entirely different piece of work. If you are comparing suppliers on this number, ask which of the two they did.

Second: DANE requires the receiving side to check it, and much of the world does not. Publishing it protects you against the receivers who do, and costs you nothing with the rest, but it is not a guarantee that any given message travelled encrypted. Nobody can give you that.

And one that is not a trick, just uncomfortable: none of this stops a convincing message from a domain that looks like yours. That is a different problem, and it is answered by people rather than records.

WHAT IT COST

Honestly

A day to get the records right on the first domain, and about twenty minutes each for the rest, because by then it was a template. The part that takes real time is not the configuration: it is the fortnight of reading DMARC reports before you can safely move to reject, and that part cannot be bought or hurried.

We run this ourselves rather than through a mail provider, which is why we can describe it. If you would rather not, that is a completely reasonable decision and the records above are still the ones to ask your provider for.