S/MIME, BIMI, VMC, SPF, DKIM, DMARC, TLS?
Home / Media / Who can see the forest for the trees in the land of S/MIME, BIMI, SPF, DKIM & TLS?

S/MIME, BIMI, VMC, SPF, DKIM, DMARC, TLS?
08 Dec ‘21

Can’t see the forest for the trees?

Everyone agrees that email security is important. A user name and password are used in order to secure access to email, or preferably a Multi-Factor Authentication (MFA), whereby the connection runs via Transport Layer Security (TLS) by means of an SSL certificate. TLS is also used when sending email between mail servers.

But how can the incoming network, and more importantly the email recipient, be sure that the incoming email was actually sent by the original sender?  To check this, there are various standards that complement each other and each has its own specific use.

Secure Multipurpose Internet Mail Extensions (S/MIME) have been around since 2002 and this is a de facto standard for end-to-end secured/verifiable email.

Although Sender Policy Framework (SPF), DomainKeys Identified Email (DKIM) and Domain-based Message Authentication, Reporting & Conformance (DMARC) have been around for a number of years, they have only been extensively applied since 2018.

Since 2021, a new standard has been added: Brand Indicators for Message Identification (BIMI), which requires a Verified Mark Certificate (VMC)

 

What’s the use for all these terms?

All the standards that are mentioned above have their own specific use and application, so they do not replace or exclude each other:

S/MIME Requires a separate S/MIME certificate, which is usually installed on a user’s device, for each email address. This ensures that:

  • The recipient is certain of who sent the email
  • The recipient is certain that the content of the email has not been changed (body and attachments)
  • Both of these options require an S/MIME certificate for the sender only
  • For both recipient and sender, the email message is encrypted in transit and on the device on which the email can be read, so that only the sender and recipient can read the message.

 
TLS Requires one or more SSL certificates for every separate email programme that is connected to the network. This ensures that:

  • From the moment it is sent from the email client, the email is encrypted until it reaches the recipient (encryption in transit).

 
SPF Only requires a DNS record. This ensures that:

  • Email is authenticated, allowing for validation at network level to confirm that it was sent from an identified email server for a specific domain.

 
DKIM Only requires a DNS record. This ensures that:

  • Each email sent at domain level (so not at email address level) will have a digital signature, to prove that the email was actually sent from the correct outgoing domain.

 
DMARC Requires only a DNS record. This ensures that:

  • The incoming email server knows how to react to an email that does not comply with SPF and DMARC validation. For example: quarantine the incoming email.

 
BIMI Only requires a DNS record. This ensures that:

  • The incoming email service provider can equip incoming emails with a presentable and validated logo belonging to the company that sent the email.

 
VMC Requires a verifiable protected logo, whereby 1 Verified Mark Certificate must be purchased per logo (valid for 1 year). This ensures that:

  • When BIMI is set, it can refer to a logo
  • If the incoming email service provider supports BIMI, the sender’s logo is displayed on an incoming email

 

 

Frequent confusions

 Now that the different standards have been explained, it is easy to answer frequently asked questions:

  •  If I use DKIM, do I still need S/MIME for digital signatures?

DKIM provides a digital signature at email level that is only used by, and visible to, the recipient’s email service provider. This DKIM digital signature is not visible or usable by the actual recipient.

An S/MIME-based signature is visible to the genuine recipient. Due to this S/MIME-based digital signature, the email client will immediately give an indication whether an email has been changed, regarding body and attachment, after it was sent AND it allows the recipient to validate who actually sent the email.

  • If I send email that is encrypted via TLS anyway, then do I still need S/MIME email encryption?

TLS ensures that email is encrypted from the moment “send” is pressed in the email client until the email arrives at the recipient. In short, data in motion encryption, also called point-to-point encryption.

S/MIME ensures that the outgoing email is encrypted at rest on both the outgoing and incoming side. Also called end-to-end encryption. No one can read the attachments and body text of the email unless they have the recipient’s private key. So even someone who can log into an email account illegally cannot read the emails.

And what’s more, even the email provider cannot scan the content of the emails, for example to deliver specific advertisements.

  • Surely, as standards, BIMI and VMC provide extra email security worldwide?

BIMI and VMC ensure brand recognition, and are therefore primarily intended for marketing.

In addition, on a global scale at the time of writing, BIMI and VMC are only supported by GMail and Yahoo! Mail

Microsoft has indicated that it has no intention of supporting BIMI and VMC, nor does it currently support them. Microsoft does not participate in the BIMI initiative. Instead, they have their own approach called “brand cards,” which serve much the same purpose without using DNS.

Checking BIMI/VMC and DMARK/DKIM/SPF online

Do you want to check whether a company has set up DMARK, DKIM, SPF, BIMI, and VMC (correctly) for its domain? This can be done easily via: https://bimigroup.org/bimi-generator/

If you would like to know more on this subject, just contact us here and we’ll contact you!

The KeyTalk Team