E-mail security

DANE, short for DNS-based Authentication of Named Entities, is a generic protocol for the secure publication of public keys and certificates. The standard utilises the cryptographically secured DNS infrastructure provided by DNSSEC.

To enable DANE, the DNS protocol has been extended by the addition of a TLSA record. That can be used to link key information – e.g. a hash code (digital extract) – to an address-protocol-port combination. It is then possible to verify the authenticity of an encrypted internet service's server certificate via the DNS (+ DNSSEC). If the hash code of the server certificate doesn't match the hash code in the TLSA record, the client knows that the connection is not trustworthy, despite the encryption.

Although DANE is more widely (i.e. generally) deployable, the protocol was initially used mainly in the world of web certificates (HTTPS) and mail transport security (SMTP). Although implementation of that first application remains sluggish, use DANE for mail has been very much on the rise in recent years. Both Postfix and Exim mail server software – which together account for 80 per cent of the MTA market – now support DANE authentication [1, 2] and validation. Support for DANE by OpenSSL (from version 1.1) has made such implementations much easier.

In March 2017, the National Cyber Security Centre (NCSC) published the factsheet Securing Mail Server Connections. The factsheet recommends enabling STARTTLS and DANE to secure mail transport. In the same month, the government and the business community started the Secure E-mail Coalition. The coalition's members have committed to progressing the implementation of protocols such as DNSSEC, DANE and STARTTLS within their own organisations and amongst their associates.

Six months earlier, the Forum for Standardisation added STARTTLS and DANE to the 'use-or-explain' list. The effect of that move was to more or less oblige government organisations to implement the 2 security standards in their mail infrastructures. A Joint Ambition Statement was subsequently agreed, in line with which all Dutch government organisations should have implemented DANE for mail no later than the end of 2019.

In March 2017, the National Cyber Security Centre (NCSC) published the factsheet Securing Mail Server Connections. The factsheet recommends enabling STARTTLS and DANE to secure mail transmissions. In the same month, the government and the business community started the Secure E-mail Coalition. The coalition's members have committed to progressing the implementation of protocols such as DNSSEC, DANE and STARTTLS within their own organisations and amongst their associates. Six months earlier, the Forum for Standardisation added STARTTLS and DANE to the 'use-or-explain' list. The effect of that move was to more or less oblige government organisations to implement the two security standards in their mail infrastructures.

DANE for mail is what's known as an 'opportunistic protocol'. In other words, a client that already supports DNSSEC, DANE and StartTLS has to encrypt its connections with a server that supports StartTLS and makes TLSA records available. However, if any of those elements is missing, client and server fall back to TLS without DANE or even to insecure transport. In the context of e-mail, message delivery has always been prioritised over transport security.

Nevertheless, the presence of a TLSA record implies that the mail server does support TLS, so a downgrade attack on the server's StartTLS capability is prevented.

Both Postfix and Exim mail server software – which together account for 80 per cent of the MTA market – can be configured to perform DANE validation before delivering mail to an MX gateway. Creating a TLSA record for the MX gateway on port 25 (the receiving side) therefore yields an immediate and definite improvement to security.

For their HTTPS connections, web browsers are currently completely dependent on security at the 100-plus Certificate Authorities (CAs). However, the DigiNotar fiasco, which involved a hacker generating more than 500 authenticated certificates, demonstrated that the system is only as secure as the most insecure CA. Smaller but comparable incidents have occurred at Comodo (Tweakers.net), Flame (Tweakers.net), Trustwave (Heise Online), MCS and Turktrust.

DANE for web provides a parallel security infrastructure (chain of trust) for X.509, to give the PKI certificate system its formal name. For many applications, the system will soon be able to fully replace X.509, rather than merely supplement it. If DANE for web had been in use, the DigiNotar affair would not have happened.

The TLSA record was added to the DNS protocol specifically for DANE. It links key information – e.g. a hash code (digital extract) – to an address-protocol-port combination. It is then possible to verify the authenticity of an encrypted internet service's server certificate via the DNS (+ DNSSEC).

A TLSA record does not contain much more than a digital fingerprint (hash code) and information about the cryptographic protocols used. The only parameter that requires some explanation is the so-called 'usage'. The 'usage' parameter indicates how the fingerprint should be interpreted:

0: PKIX-TA: Certificate Authority Constraint: anchors a particular CA certificate in the TLS chain of trust (in addition to conventional validation)

1: PKIX-EE: Service Certificate Constraint: anchors a particular server certificate (in addition to conventional validation)

2: DANE-TA: Trust Anchor Assertion: anchors a particular CA certificate in the TLS chain of trust, which then acts as a trust anchor

3: DANE-EE: Domain Issued Certificate: anchors a particular server certificate, which has to match the certificate offered by the server

Usages 0 and 1 anchor the certificate of, respectively, a CA and a server, to supplement conventional validation on the basis of trust anchors provided in the client (the browser). The effect of usage 0 is to localise the hacked CA problem, while usage 1 completely neutralises it. Both usages also highlight any discrepancies between the 2 chains of trust.

Usages 2 and 3 operate independently from conventional TLS validation, making them suitable for self-signed certificates. They also enable clients without trust anchors, e.g. SMTP clients, to be served.

Although DANE for web and DANE for mail appear very similar, there are also significant differences. Starting a URL with 'https' indicates that TLS must be used, but there is nothing comparable for mail. Neither the mail address used nor the associated MX records indicate anything about the security of transport. Nevertheless, the presence of a TLSA record does imply that the SMTP gateway does support TLS, so a downgrade attack on the gateway's STARTTLS capability is prevented. However, the use of TLS by the client is optional, meaning that DANE for mail is a so-called 'opportunistic protocol'. In other words, a client that already supports DNSSEC, DANE and StartTLS has to encrypt its connections with a server that supports StartTLS and makes TLSA records available. However, if any of those elements is missing, client and server fall back to TLS without DANE or even to insecure transport. The system works that way to ensure that message delivery can proceed without human intervention wherever possible.

DANE usages 0 and 1, where the TLSA record is used to provide additional anchorage for a server certificate, cannot be used in DANE for mail. In a mail context, PKI-anchoring has no advantage over a self-signed certificate with a TLSA anchor. The reason being that, if the DNS has been compromised, the attacker can modify the TLSA records (with usage 2 or 3) so that validation of the PKI chain of trust is not required.

Although a similar argument may be made in relation to DANE for web, the authors of RFC 7672 assume the current situation, where mail clients (unlike web browsers) do not have a broadly standardised set of trust anchors. Furthermore, HTTPS and SMTP+TLS play different roles: for web transactions encryption is crucial, but with mail reliable delivery is normally more important than secure transport. Hence, opportunistic security fallback is preferable to the message bouncing. DANE for mail is designed to add transparent security that requires no additional configuration, trust anchors or user interaction. Its designers do not therefore regard DANE as a supplement to PKI-anchoring, but as the successor to and replacement for that technology.

The DANE standard stipulates that, with usages 0 and 1, both chains of trust must be validated. That can be problematic if one chain can be validated but the other cannot. In the future, the internet user may be shown a pop-up warning and given the option of continuing, as currently happens if there is an issue with a TLS certificate.

Although DANE for web is regarded as the successor to and replacement for the flawed CA system with its known security issues, the EV certificates in particular still have added value. Also, because browsers that don't support DANE and show warnings about self-signed certificates are likely to remain in use for years to come, CA certificates are not expected to fall out of use in the near future.

The DANE protocol is defined in RFC 6698 (TLSA), RFC 7218, RFC 7671 and RFC 7672 (for SMTP).

RFC 7673 defines the use of DANE for SRV records (to support various communication protocols). Similarly, RFC 7929 defines OpenPGP (for anchoring public keys by means of OPENPGPKEY records). And RFC 4255 defines the SSHFP record, in which the public key of an SSH server can be anchored.

In principle, a TLSA record can be created for any mail server that offers connections secured by means of TLS or StartTLS. Both Postfix and Exim mail server software – which together account for 80 per cent of the MTA market – can be configured to perform DANE validation <link> before delivering mail to an MX gateway. Creating a TLSA record for the MX gateway on port 25 (the receiving side) therefore yields an immediate and definite improvement to security.

Detailed information about configuring DANE for mail is provided in the following hands-on guides:

• Implementing DANE in Exim

• Implementing DANE in Postfix

The Platform for Internet Standards has also published a thorough guide:

• DANE for SMTP how-to

Although TLSRPT was defined together with MTA-STS and by the same actors, it works just as well with DANE for mail. Therefore, if you've already implemented DANE [in Exim or Postfix], you can easily use TLSRPT without MTA-STS. In fact, DANE provides better security than MTA-STS, and the publication of a TLSA record is far less work than implementing MTA-STS (assuming that you've implemented DNSSEC anyway).

Both Postfix and Exim mail server software – which together account for 80 per cent of the MTA market – can be configured to perform DANE validation before delivering mail to an MX gateway. Creating a TLSA record for the MX gateway on port 25 (the receiving side) therefore yields an immediate and definite improvement to security.

Detailed information about configuring DANE for mail is provided in the following hands-on guides:

• Implementing DANE in Exim

• Implementing DANE in Postfix

The Platform for Internet Standards has also published a thorough guide:

• DANE for SMTP how-to

You can check the validity of a DANE configuration on the Internet.nl portal or using sys4's DANE SMTP Validator.

At the time of writing (March 2023), we are not aware of any mail clients that validate the server certificates for their POP, IMAP or SMTP connections.

In principle, a TLSA record can be created for any web server that offers a secure connection based on HTTPS.

Detailed information about configuring DANE for web is provided in the following (Dutch) articles:

• Two-part DANE feature, part I: TLSA records for the web

• Tips and tricks for DANE TLSA

At the time of writing (March 2023), we are not aware of any widely used web browsers that offer out-of-the-box DANE validation of the certificates for their HTTPS connections (the DNSSEC/TLSA Validator plugin is no longer under development). However, you can check the validity of a DANE configuration on the Internet.nl portal or using our own DANE Validator.

MTA-STS stands for MTA Strict Transport Security, as defined in RFC 8461. MTA-STS is a security standard that enables a mail domain's owner to let people know that the domain's inbound mail servers (MX gateways) support TLS encryption. That's done by publishing a special TXT record in the domain's DNS zone, pointing to an MTA-STS policy file.

The policy file is cached by clients (sending mail servers) and retained for a considerable time (typically weeks or months). Any client that has cached the file then knows that something is wrong if the receiving mail server suddenly says that it doesn't support TLS encryption, or no longer does so. As long as the policy file remains valid, the client mustn't fall back to an unencrypted connection. The protocol therefore protects the mail domain's owner against downgrade attacks (STRIPTLS).

Because MTA-STS only provides protection once the client has fetched the policy file for the first time and cached it, it's referred to as a Trust On First Use (TOFU) mechanism. In that respect, it's conceptually similar to HSTS for the web. However, MTA-STS differs from HSTS in one important respect. In order to circumvent MTA-STS, a malicious actor needs to first intercept the MTA-STS record, and then strip the StartTLS capability (two distinct channels). By contrast, HSTS provides no protection until the HSTS header has been sent to a web client that the server has interacted with before (because the same channel is used for in-band transport.

StartTLS is what's known as an 'opportunistic protocol'. In other words, a client that already supports TLS has to use StartTLS to encrypt its connections with a server that supports StartTLS if possible. If either the client or the server doesn't support TLS, or if neither of them do, data transport necessarily takes place over a completely insecure connection. In the context of e-mail, message delivery has always been prioritised over transport security. However, since the publication of RFC 8314 in 2018, unencrypted transport by means of SMTP, POP and IMAP has been formally classed as 'obsolete'.

By publishing an MTA-STS record and policy file, a mail domain's owner is telling the outside world that the domain's receiving mail servers (MX gateways) require the use of TLS encryption by all clients (sending mail servers) that support it. The client saves the policy file for an extended period (typically weeks or months). That prevents downgrade attacks (STRIPTLS) on the StartTLS capability of the MX gateways, because a client that supports MTA-STS is not allowed to fall back to an unencrypted connection if fallback is excluded by the server's policy file.

DANE for mail safeguards secure transport more effectively than MTA-STS. While MTA-STS requires only that a TLS certificate (implying StartTLS capability) is available on the server, DANE additionally specifies the particular certificate or trust anchor that the server must provide (pinning). The use of MTA-STS is therefore advantageous only as temporary protection against downgrade attacks (STRIPTLS) before a domain is DNSSEC-enabled. Furthermore, a client must never use MTA-STS to overrule a failed DANE validation. Microsoft therefore describes DANE as the gold standard for mail transport security.

The big mail service providers Google and Microsoft have been the prime movers behind the development of MTA-STS (and TLSRPT). Both providers offer full MTA-STS (and TLSRPT) support with their main services (Gmail and Exchange Online, respectively).

However, Microsoft describes DANE as the gold standard for mail transport security. Once you've implemented DNSSEC, DANE for mail provides much more effective (and easily implemented) security than MTA-STS.

The first step in implementing MTA-STS is publication of an MTA-STS policy file. If your mail is handled for you by an external service provider – in other words, if your MX records point to someone else's mail systems – you'll usually rely on your service provider's policy file. In that case, you just need an MTA-STS record referring to the service provider's policy file.

If you handle your own mail, you need to compile a policy file with the following contents:

version: STSv1
mode: testing
mx: mx1.example.nl
mx: mx2.example.nl
max_age: 86400

The specimen policy file above states that both of the named MX gateways support TLS. While you have the mode set to 'testing', if the TLS connection fails, a client will fall back on insecure transport. The configured 'max_age' of 86400 seconds (1 day) is a safe value to use in 'testing' mode.

If you've also configured a TLSRPT record for your domain – strongly recommended with the use of MTA-STS – you'll start getting error messages from sending mail servers in the event of TLS encryption failing, without impairing the deliverability of your mail.

The policy file must be accessible using HTTPS, and must be saved to the following location:

https://mta-sts.example.nl/.well-known/mta-sts.txt

That implies creating an additional A/AAAA record or CNAME record pointing to the web server where the policy file is hosted (the policy host). The purpose being to prevent any clash between the policy host and your general web server, and to enable you to point to an external mail service provider's policy.

Although the record identifying the policy host can point to your general web server (if it supports virtual hosts), you will nevertheless need to generate a separate TLS certificate for the name in question (because of the mandatory HTTPS connection).

Once you've published your MTA-STS policy file, you need to tell sending mail servers about it by publishing a special TXT record (in parallel with the MX records), as follows:

_mta-sts.example.nl. IN TXT "v=STSv1; id=2024072200;"

The stated 'id' is your policy file's version number. By looking at the version number, a mail client knows whether your policy file has changed, and consequently needs to be fetched. The 'id' stated in the record therefore has to be updated after every change to your policy file. The most convenient approach is to use a serial number, the same as you do for your zone file.

If your record previously pointed to your mail service provider's policy host, it's best to include a CNAME reference for your MTA-STS record as well:

_mta-sts.example.nl. IN CNAME _mta-sts.mailprovider.example.

That ensures that old version numbers can't be left in your zone file in the event of your service provider updating their policy file.

Note that, although they're very similar, the two names that come before the policy host (mta-sts.example.nl) and the MTA-STS record (_mta-sts.example.nl) are not the same: the policy host is the address of a web server (host), while the '_mta-sts' label (with an underscore character at the start) refers to a service.

As soon as you publish your MTA-STS record, MTA-STS is enabled. Once it's been operating smoothly for a while, you can change the mode in the policy file from 'testing' to 'enforce' (and update the 'id' in the MTA-STS record accordingly).

In order to check whether everything is working properly, you should always implement TLSRPT alongside MTA-STS. TLSRPT is a mechanism that enables you to receive error messages from clients (sending mail servers) in the event of TLS encryption failures when connecting to your MX gateway.

DANE for mail safeguards secure transport more effectively than MTA-STS. While MTA-STS requires only that a TLS certificate (implying StartTLS capability) is available on the server, DANE additionally specifies the particular certificate or trust anchor that the server must provide (pinning). The use of MTA-STS is therefore advantageous only as temporary protection against downgrade attacks (STRIPTLS) before a domain is DNSSEC-enabled. Microsoft therefore describes DANE as the gold standard for mail transport security.

We therefore recommend using DNSSEC and DANE if possible. To help you do that, we've produced a number of comprehensive hands-on guides. Once you've successfully enabled DNSSEC, it's usually very straightforward to implement DANE validation; all it involves is setting a configuration option. At the receiving end, enabling DANE simply involves the publication of a TLSA record.

If you nevertheless want to implement MTA-STS validation on your sending mail server, you'll need to configure it to take place after DANE validation. because you can't accept mail that passes MTA-STS validation, but not DANE validation. For Postfix, the postfix-mta-sts-resolver daemon is available, although it currently overrules DANE and therefore isn't compliant with the specification. Exim doesn't support MTA-STS at all. However, you could consider using Mox, a modern MTA implementation that fully implements both DANE and MTA-STS.

TLSRPT (defined in RFC 8460) is a mechanism that enables a mail domain's owner to receive error messages from clients (sending mail servers) in the event of TLS encryption failures when connecting to the owner's MX gateway. The TLSRPT mechanism works in a similar way to the DMARC mechanism.

In order to receive TLSRPT reports about your mail domain, you need to publish a special TXT record (in parallel with the MX records), as follows:

_smtp._tls.example.nl IN TXT "v=TLSRPTv1; rua=mailto:tls-rua@example.nl"

As you can see, the record consists of little more than an e-mail address to which standardised error messages can be sent for automated processing. The TLSRPT mechanism works in a similar way to the DMARC mechanism.

Automated TLSRPT report processing services are provided by the same organisations that offer DMARC report processing.

Hoewel TLSRPT tegelijkertijd met MTA-STS is gedefinieerd en door dezelfde partijen, werkt dit mechanisme net zo goed voor DANE voor mail. Heb je DANE al geïmplementeerd [Exim, Postfix], dan kun je TLSRPT dus ook prima zonder MTA-STS gebruiken. Sterker nog: DANE biedt een betere bescherming dan MTA-STS, terwijl de publicatie van een TLSA-record veel minder werk is dan de implementatie van MTA-STS (er vanuit gaande dat je DNSSEC sowieso geïmplementeerd hebt).

StartTLS is what's known as an 'opportunistic protocol'. In other words, a client that already supports TLS has to use StartTLS to encrypt its connections with a server that supports StartTLS if possible. With both MTA-STS and DANE for mail, if either the client or the server doesn't support the protocol, the connection isn't encrypted unless the server provides a valid TLS certificate. In the worst-case scenario, data transport necessarily takes place over a completely insecure connection. In the context of e-mail, message delivery has always been prioritised over transport security. However, since the publication of RFC 8314 in 2018, unencrypted transport by means of SMTP, POP and IMAP has been formally classed as 'obsolete'.

By publishing an MTA-STS record and policy file or a TLSA record, a mail domain's owner is telling the outside world that the domain's receiving mail servers (MX gateways) require the use of TLS encryption by all clients (sending mail servers) that support it. A client that supports MTA-STS is therefore required to set up a secure connection every time it sends mail to a server that has an MTA-STS policy. Similarly, a client that supports DANE always has to encrypt any connection to a server with a published TLSA record. That prevents downgrade attacks (STRIPTLS) on an MX gateway's StartTLS capability. In combination with DNSSEC (which is required for DANE anyway), such digital announcements are themselves cryptographically secured.

The difference between MTA-STS and DANE for mail is the extra security that DANE provides for the TLS certificate. While MTA-STS requires only that a TLS certificate (implying StartTLS capability) is available on the server, DANE additionally specifies the particular certificate or trust anchor that the server must provide (pinning). It does that by tying the certificate to the DNSSEC chain of trust by means of a TLSA record. If the certificate or the chain provided by the receiving mail server doesn't match the attribute (a digital fingerprint) stated in the TLSA record, the client (a sending mail server) can't use the connection.

Because it involves a particular TLS certificate or trust anchor being pinned and cryptographically tied to the DNSSEC chain of trust, DANE for mail can also be used with a self-signed certificate. Indeed, that is what most mail operators do, since mail systems traditionally don't have CA trust anchors installed the way that web browsers do.

The advantages of MTA-STS over DANE for mail are that MTA-STS doesn't require DNSSEC (the reason for its development), that you can use MTA-STS in 'testing' mode, and that you can enable it on some MX ports, but not others.

DANE for mail safeguards secure transport more effectively than MTA-STS. Also, the publication of a TLSA record is far less work than implementing MTA-STS (assuming that you've implemented DNSSEC anyway). The use of MTA-STS is therefore advantageous only as temporary protection against downgrade attacks (STRIPTLS) before a domain is DNSSEC-enabled.

You might nevertheless want to implement MTA-STS alongside DANE for mail in order to serve mail clients that support MTA-STS but not DANE validation.

The DKIM, SPF and DMARC protocols protect against phishing, spam and virus/malware distribution by securing the sender (the sending e-mail address), the host (the sending e-mail system) and the contents of the message. Enabling the standards involves adding records to the domain name's DNS details. Although signing with DNSSEC isn't strictly necessary (i.e. required by the standard), it's a valuable additional procedure.

The DKIM/SPF/DMARC protocols represent the first practical application of the cryptographically secured infrastructure provided by DNSSEC.

The 3 protocols are normally used together, but they don't have to be. You can use DKIM or SPF on its own, or DKIM and SPF together without DMARC.

With DKIM, a digital signature is attached to the body and header of each outbound message. The public key is published via the DNS, so that a receiving MX gateway can verify the digital signature. The system prevents a fraudster sending a message as if it came from someone else (mail spoofing) or interfering with the contents of a message in transit (message integrity).

SPF enables MX gateways to refuse e-mail messages from unauthorised servers. A list of valid sending addresses is published via the DNS. The listed addresses are typically the SMTP gateways that end users use for their outbound messages, but may also include the addresses of external service providers that send marketing mail for the organisation. Receiving systems can check inbound messages against the published list and refuse any that come from unlisted servers.

DMARC is a supplement to the other 2 mail security standards, namely DKIM and SPF. DMARC lays down a policy (i.e. instructions) telling receiving MX gateways what to do with any inbound messages that cannot be validated in accordance with DKIM or SPF. That might involve discarding or quarantining all non-validated mail, for example.

The policy is published via the DNS. It may also include a mail address to which mail systems can report rejected messages. The mail domain's operator can then monitor the delivery of both genuine and falsified messages.

DMARC Advisor offers a subscription service where incoming DMARC reports can be processed to yield well-presented statistics and diagrams.

Companies such as DMARC Advisor and DMARC Analyzer offers a scubscription service where incoming DMARC reports can be processed to yield well-presented statistics and diagrams.

https://images.ctfassets.net/yj8364fopk6s/vKIjbML8VVuW3YJJC0gxwg/99031812c5c5df1e9cf5f9637d0c6412/Screenshot_DMARC_Advisor_20231101.png

Screenshot of the application the DMARC Advisor application.

But there are now also various (low-level) open source tools available for the processing and analysis of DMARC reports:

• parcedmarc

• TA-dmarc

The DKIM-SPF-DMARC combination enables much more efficient mail processing. Large-scale mail processors can divide inbound messages into 2 general categories: those from unauthenticated domains or previously unencountered authenticated domains and those from known benign mail domains.

Processing of the second category is straightforward: the messages can be delivered without more ado. Messages from insecure and unfamiliar domains require thorough checking. Resources can therefore be concentrated where they are needed. It also pays to delay the decision briefly, since a zero-day will not appear on any blacklist. It is very likely that the classification of such a message will be much easier a short while later. SpamAssassin doesn't yet offer out-of-the-box support for that approach. However, the Trusted Domain Project did provide all the tooling required to set it up yourself.

The rapid adoption of DKIM/SPF/DMARC has been driven mainly by the big mail processors, who had a serious problem with phishing mail. Being relatively young businesses, social media companies such as Facebook (by far the biggest mail processor in the world) generally have well-consolidated mail infrastructures. It was therefore relatively easy for them to implement DMARC.

Another group that uses e-mail on a large scale are mail marketing companies – 'legitimate spammers', if you like. They have a strong interest in ensuring that their messages arrive safely. And, inevitably, such companies have well-defined, modern mail infrastructures.

The more mail processors implement DKIM/SPF/DMARC, the more important it becomes for domain name registrants to publish DNS records. Because failure to follow the trend means risking the non-arrival of your mail.

Detailed information about configuring DKIM, SPF and DMARC is provided in the following hands-on guides:

• Implementing SPF, DKIM and DMARC in Exim

• Implementing SPF, DKIM and DMARC in Postfix

We can also recommend the following test portal:

• Learn and test DMARC Using the portal, you can test mail domains' support for and correct implementation of SPF, DKIM and DMARC. Explanatory information about the protocols and an attractive visualisation are also available.

In the past, it wasn't possible to indicate explicitly that a domain didn't have a mail service. A sender with mail for such a domain had to first ask for an MX record, triggering fallback to the A/AAAA records. The sender had to establish that the (web) server had no inbound mail port (SMTP on port 25) before they could deduce – after repeated fruitless queries and considerable delay – that the domain had no mail service.

However, RFC 7505 introduced a way of using the DNS to explicitly indicate that a domain had no mail service: the Null MX record. A Null MX record is formatted as follows (note the full stop at the end):

domainname.nl IN MX 0 .

Because the concept is relatively new (the RFC was published in 2015), many no-mail domains don't yet have Null MX records. (At the time of writing (April 2024), nearly 50,000 .nl domains do have such records.) For reasons of both efficiency and security, we advise adding Null MX records to no-mail domains that don't yet have them.

You should also publish a corresponding SPF record in which no servers are authorised to send mail for the domain:

domainname.nl IN TXT "v=spf1 -all"

Plus a DMARC record with the 'reject' option set and an RUA address (at another domain, of course):

_dmarc.domainname.nl IN TXT "v=DMARC1; p=reject; sp=reject;

adkim=s; aspf=s; rua=mailto:dmarc-reports@example.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;"

BIMI stands for Brand Indicators for Message Identification. It's a security mechanism that enables organisations and other users to have their logos displayed to recipients in authenticated e-mail sent from their domains.

A receiving mail client will display a logo only if the incoming message has passed DMARC validation. Google and Apple additionally require that the sending domain's registrant can demonstrate ownership of the (registered) logo by means of a Verified Mark Certificate (VMC). A tick is then shown with the logo to confirm verification. The main mail processors also take the reputation of the sending domain into account when assessing incoming mail [1].

If an incoming message passes the various checks, the recipient can be confident that it does indeed come from the organisation whose ticked logo is displayed.

In order to use BIMI a domain name's registrant has to add a special TXT record to their DNS zone, stating where their logo and its Verified Mark Certificate (VMC) can be found.

At the receiving end, the MX gateway (or the final MTA in the mail chain) is responsible for performing all the security checks: BIMI validation is performed immediately after SPF/DKIM/DMARC validation. Following successful DMARC validation, the MTA checks whether a BIMI record is also available for an inbound message's sending domain. The check is performed on the basis of the address in the 'From' header, so that alignment with the sending domain in the envelope (SPF) and the signing domain (DKIM) in the (DMARC) validation is taken into account. If a BIMI record is indeed available, the MTA fetches the specified logo and VMC. If the certificate confirms that the logo does belong to the sending domain, validation is successful.

The results of the BIMI validation process and, if validation is successful, the logo itself are added to the e-mail message as headers. The receiving mail client (MUA) then uses the information in the headers to decide whether to display the logo, together with a tick.

A receiving MTA that supports BIMI begins by using DMARC to check the authenticity of an inbound e-mail message. It then checks the Verified Mark Certificate (VMC) to make sure that the specified logo does indeed belong to the sending domain [1]. The mail client (MUA) will display the logo, together with a tick, only if the message passes all the checks.

The recipient can then be confident that the incoming message does indeed come from the organisation whose ticked logo is displayed. The process therefore contributes to the fight against malicious activities such as mail spoofing, typosquatting and phishing.

BIMI helps an organisation to reassure recipients that mail from the organisation is genuine, while also raising the organisation's brand profile.

At the time of writing (July 2024), BIMI is an Internet Draft. It hasn't yet obtained RFC status. The specification [1] is being developed by the BIMI Group, whose members include Google, Fastmail, Yahoo, Mailchimp, SendGrid and various mail security companies.

On the client side, BIMI is now supported by Google (Gmail), Fastmail, Apple (Mail) and Yahoo (Mail). Microsoft (Exchange/Outlook) explicitly doesn't support BIMI, however.

In the Netherlands, sender-side organisations that support BIMI now include the police (whose top-level domain, .politie, is operated by SIDN), as well as PostNL, the Tax and Customs Administration Service and Rabobank. For the police, BIMI implementation forms part of a wider strategy of implementing modern internet standards.

A survey by Freddie Leeman in May 2024 revealed that only 0.76 per cent of the world's top million domains had so far published BIMI records. Of those that had, roughly a quarter also provided Verified Mark Certificates (VMCs).

The following Phishing Scorecard shows current global levels of DKIM, SPF, DMARC and BIMI adoption.

BIMI is based on the DMARC e-mail security standard (and therefore on SPF and DKIM, the standards that underpin DMARC). Consequently, those standards have to be fully implemented on your mail domain before you can get to work with BIMI. Your DMARC policy also has to be set to 'reject' or 'quarantine'.

Check out our maturity model for modern internet standards for an overview of (amongst other things) the various e-mail security standards and the their interrelationships and interdependences. On that page, you'll also find links to our detailed, step-by-step guides to the implementation of SPF, DKIM and DMARC in Exim and Postfix.

Once that's all taken care of, you can start implementing BIMI [1] by publishing your logo in SVG(Z)P/S vector format [1, 2, 3] on an HTTPS web server. Although the BIMI specification doesn't currently require the use of a Verified Mark Certificate (VMC), logos that aren't backed by VMCs ('self-asserted BIMI') aren't displayed by Gmail or Apple Mail. In practice, therefore, you'll need to get your logo registered and then apply for a VMC in order to realise full BIMI support ('certified BIMI').

Finally, you publish a special TXT record in your main domain's zone:

default._bimi IN TXT "v=BIMI1; l=https://example.nl/bimi/logo.svg; a=https://example.nl/bimi/vmc.pem;"

If you don't have a VMC, leave out the link at the end, so that your TXT record is something like this:

default._bimi IN TXT "v=BIMI1; l=https://example.nl/bimi/logo.svg; a=;"

The 'default' label refers the selector (as in DKIM). That enables you to specify various logos for various senders or types of sender. However, that requires you to make some adjustments to your mail server: if a selector other than the default is used, the server (or mail client) has to add a (DKIM-signed) header to each outbound message, as follows:

BIMI-Selector: v=BIMI1; s=<selector>

You can publish BIMI records on a subdomain as well. Validation begins with the complete sending domain and, as long as no BIMI record has been found, continues all the way back to the root domain.

The BIMI Group provides an online tool for testing BIMI configurations:

https://bimigroup.org/bimi-generator/

Another, more up-to-date tool is available here:

https://www.uriports.com/tools?method=bimi

As you can see, we've configured our own domain, sidn.nl, for (self-asserted) BIMI.

It's probably a little too soon for smaller e-mail processing firms to implement BIMI. However, the BIMI Group has made various libraries available, including a Perl module for BIMI validation and an extensive milter module for mail authentication, which incorporates the BIMI module.

The biggest drawback with BIMI is the cost of obtaining a Verified Mark Certificate (VMC). Certification Authorities typically charge 1,300 to 1,500 dollars a year to issue a VMC [1], and that comes on top of the cost of registering your logo. Furthermore, the need for annual VMC renewal adds to your administrative burden, and introduces the risk that any failure to renew promptly could lead to problems with your mail.

Another problem is undesirable competition between the BIMI logo (which is domain-specific) and the individual sender's profile photo (avatar). You could perhaps deal with that by assigning a personal selector to each sender, but that would be very cumbersome and is only possible in the context of self-asserted BIMI. The same can be said regarding, for example, ticks and other end-to-end encryption indicators based on OpenPGP and S/MIME.

Finally, there is the issue that self-asserted BIMI isn't currently supported by Gmail or Apple Mail. Those mail providers will display a logo (with a tick) only if a valid VMC is available. One way forward might be to use ticks only for certified BIMI, while allowing logos without ticks to be displayed in the context of self-asserted BIMI. An unticked logo would then act as an indicator of successful DMARC validation. However, the BIMI Group appears committed to pushing the use of certified BIMI.

As its name suggest, BIMI appears to be designed mainly for marketeers, brand managers and corporates that have sufficient budgetary scope for can afford to invest in the deliverability of their mail and the visibility of their brands.