There are 316,6 billion email exchanges every day around the world (2021 figures, source Statista), most of which is spam. As a company or public organisation, you’ve obviously set up an antispam system to protect your users from this endless flow of junk messages. So far, so good.
Until one day you realise that the messages you send no longer reach their destination. Your emails go out but don’t make it to their recipients. Your IT Department is adamant: everything is set up properly, all your systems are go, the issue isn’t on your end. Your recipients are the ones not accepting your emails, and that’s to do with authentication, which can be fixed easily.
Let’s have a look at the ins-and-outs of email security and what your options are.
Email authentication: what for?
Email authentication is the process through which your recipient’s mail server verifies the authenticity of your messages. It’s a little like a digital passport: it’s what enables your mail server and spam filters to confirm that your emails are indeed yours.
Organisations need email authentication because it’s what ensures email deliverability. Without it, messages may be filtered out automatically, and they will no longer reach their recipients.
Three main authentication standards are used to confirm that an email message does come from the person it claims to be: SPF, DKIM and DMARC.
SPF: Sender Policy Framework
SPF is used to specify what IP addresses are authorised to send emails on behalf of a given domain and therefore prevents other servers from using your domain as a sender address. The IP addresses authorised to send emails on behalf of a domain are published in a DNS TXT record.
But SPF isn’t always enough.
Emails validated by SPF may be forgeries
Emails have two sender addresses:
- The envelope address, used by servers to route emails,
- The address in the actual email message (in the message header), which is the address email clients show.
SPF looks at the envelope email address only. The sender address visible in an email header may therefore have been edited or forged despite the email having been verified at the SPF level!
For instance, a spammer can use a server to send a message whose envelope-from address is spam@spammer.com but whose header address is ceo@mycompany.com. If this email is sent from a server listed in the spammer.com SPF to the mycompany.com server, SPF will authenticate it and the recipient will see a seemingly legitimate email from ceo@mycompany.com.
Issues with email redirection
SPF can also cause trouble with email redirection if an SRS (Sender Rewriting Scheme) hasn’t been added.
Note that the SRS functionality is included in BlueMind from version 4.7.
In one word, SPF alone quickly proves inadequate as it doesn’t prevent domain name spoofing in email headers, i.e. the email address users see. The limitations of SPF is one of the reasons why DKIM was created.
DKIM: DomainKeys Identified Mail
DKIM affixes a digital signature to outgoing messages so that the recipient can verify that the email hasn’t been tampered with.
The outgoing mail server or the mail transfer system (which can be an antispam if the email flow goes through an antispam) sign the messages with a private key linked to the sender domain. The public key, on the other hand, is published in the DNS server and is accessible to all.
The destination mail server (or the receiving system) recognises a signed email and checks whether the DKIM signature is valid. To do this it has to retrieve the public key from the sender domain and use it to authenticate the message.
This ensures that the message has been sent by the sender’s official domain servers and confirms that the message is an untampered original.
DKIM verifies that:
- Email headers have not been modified since the message was sent by the original sender.
- The email sender owns the DKIM domain, or is authorised by the domain owner.
Typically, DKIM signatures are not visible to end users – incoming emails are validated at the server level or are handled by the incoming mail antispam.
If your outgoing mail antispam doesn’t take DKIM into account (or if you don’t have an outgoing mail antispam), BlueMind allows you to integrate a solution such as openDKIM on the main server or on an Edge server (relay).
DMARC: Domain Based Message Authentication, Reporting & Conformance
DMARC is designed to stop phishers, spammers and other illegitimate actors from forging a sender domain or impersonating someone else (spoofing).
DMARC unifies the SPF and DKIM authentication mechanisms into a common framework and allows domain owners to declare how they would like email from that domain to be handled if it fails SPF or DKIM authorisations. This is done through a policy, which is defined in the DNS DMARC record. The policy can accommodate three options:
- None: treat the email the same way as without DMARC authentication.
- Quarantine: accept the email but place it somewhere other than the recipient’s inbox (typically the spam folder).
- Reject: reject the message outright and discard it.
Note that even if an email passes the DMARC test, it is not guaranteed to end up in your inbox. Before it reaches its final destination, an email will probably go through other verifications, such as a search for junk content or the sender’s reputation check.
A successful DMARC implementation involves gradually ramping up quarantine percentage tags up to 100% rejection. It also requires that you regularly check your DMARC reports. These reports tell you about phishing attempts on your domain, or that an email you sent has been rejected due to failed DKIM or SPF authentication.
Is implementing all three standards absolutely necessary?
Absolutely necessary, no, but it is highly recommended.
While SPF and DKIM are increasingly widespread, the uptake of DMARC is lagging. That being said, cautious mail administrators are setting up all three on the domains they manage as more and more ISPs and mail providers are starting to apply all three standards systematically.
Implementing all three authentication standards ensures that your emails get sent and improves deliverability by confirming that your mail domains are who they are purporting to be. It also shows that you are following best practice and that you are doing your part to fight spam, phishing and other email security issues.
Conclusion
An authenticated email is an email you can trust, because its sender and contents have been verified as valid through SPF and DKIM.
Authentication has no incidence on users or email uses, there’s no reason not to build it into your system!
Implementing email authentication is not only good practice for your emails to get delivered successfully, it’s also instrumental in protecting your brand reputation as it limits the possibility for unauthorised senders to use your domain without your consent or knowledge.
