Email authentication methods – the basics behind SPF, DKIM, DMARC, and BIMI
Izabela is a leading contributor to the Bouncer’s blog. She is inspired to help companies all around the world to get emails into their recipients’ inboxes
There’s a lot more to email security than first meets the eye. We’re all well aware that email is one of the hardest-hit areas for phishing for personal data and sensitive information.
Hackers are becoming far better at creating authentic-looking messages that fool so many into clicking a call-to-action and providing spoofers with the information they’re looking for—often login details and financial access.
Email Authentication – what is it?
Email authentication is the system designed to protect your reputation by checking when you send an email campaign that you’re who you say you are. The four concepts are simple enough, yet setting each of the methods can be tricky. However, the protection offered when combined is as good as you can put in place under our current systems.
What are the possible methods?
The four typical email authentication methods today are as follows:
- SPF – Sender Policy Framework
This standard performs the original check to make sure each email comes from a trusted IP address. - DKIM – DomainKeys Identified Mail
Another identity check, but this time using an encryption key as a digital signature. - DMARC – Domain Message Authentication Reporting and Conformance
DMARC ensures that the email meets both SPF and DKIM before they’re delivered. - BIMI – Brand Indicators for Message Identification
BIMI delivers one final check, focussing on sender credibility and displaying the sender’s brand image in the recipient inbox (where currently supported).
We’re going to take a deeper look at each of these a little further along, but first, we’re going to explain why they’re so important and explain a little about how they work.
How does email authentication work?
Each of the authentication methods (SPF DKIM DMARC BIMI) applies a layer of security to your emails using your email domain to verify you’re who you claim to be.
- The sender defines the policy/rules of how their domain is authenticated.
- They then configure the domain DNS and email servers to implement those rules.
- Recipient servers verify incoming email by checking it against the rules fixed to the domain’s DNS.
- When authenticated, the recipient server processes the email safely; where authentication fails, the message is blocked or quarantined or managed in line with the authentication ruling.
What are the benefits?
As you can see, if you don’t set up your email authentication, you’re running a risk of rejected emails, higher spam rates, and lower delivery rates.
Your painstakingly considered, beautifully designed, and created messages stand far less chance of landing in the inboxes they’re intended for.
Worse still, without your email authentication methods in place, your brand is far easier to spoof, leaving you and your clients wide open to email attacks, hacks, and phishing.
Setting up email authentication
To set up your domain to manage each authentication method, you need access to the DNS settings (Domain Name System) through your domain registration service.
Once you access the DNS settings, you’ll add various TXT and CNAME records to your domain.
To find out your domain settings’ values, you’ll need to check with your email hosts. They’ll provide you with the settings for your SPF records, generate your DKIM selector from within their hosting area, and show you how to implement your DMARC policy, as hosts often differ in how they’re configured.
You’ll add another TXT record to include a BIMI record, including the path to your brand image file.
SPF – Sender Policy Framework
SPF is the standard authentication created in the early days of email development. Where it was once suitable for early email systems, it holds several issues for modern mail methods. That’s why it’s necessary to utilize all four methods to deliver a form of complete cover.
SPF records are stored in plain text within the domain DNS and dictate the IP addresses with permission to send from the domain.
When the recipient’s email server performs a DNS lookup to retrieve the SPF record, it uses the value in the message’s return path.
Issues with SPF authentication
Syntax – Despite being text records, the syntax can get tricky when entering the DNS records. If they’re not precise, then authentication will fail, even if the message and sender are genuine.
Identifying approved IP addresses – Shared systems, such as cloud platforms, can host multiple services with dynamically assigned IP addresses. Although the IP can be determined and authorized, it can also allow anyone else to use the same shared IP by using your SPF record.
SPF can be spoofed – SPF uses the hidden return path field for authentication—not the ‘from’ field, which recipients can clearly view. A hacker, phishing for information, can present a valid looking domain and email address in the ‘from’ field, yet have their own email as the return-path, using their own authentication system to get through server checks.
SPF doesn’t support email forwarding – A recipient server will fail to validate a forwarded message because the identifying domain appears to be that of the forwarding server and not the original domain.
As you see, what was once an acceptable method is now significantly flawed. It provides the basics to build on for greater all-around security. As a standalone method, however, it just doesn’t cut it in today’s technology.
DKIM – DomainKeys Identified Mail
DKIM uses public/private key encryption to sign email messages. It verifies emails were sent from the domain and that the email hasn’t been modified in transit.
It’s a more secure authentication method, as it assures the message hasn’t been altered during delivery. Another benefit is that DKIM authentication survives email forwarding.
The domain owner creates cryptographic keys in pairs: public and private. The public key is placed as a TXT record on the domain’s DNS. When an email is sent, a ‘hash’ is generated based on the contents of the message. This hash is encrypted with the domain’s private key and attached to the header of the email.
The recipient’s email server reads the encrypted information using the public key hosted in the DNS, and if everything matches, authentication is granted.
DKIM selectors
Each domain can utilize several selectors. These values are used to identify unique properties, for example, subdomains, users, locations and services. Each selector operates using its own public key, relinquishing a single, shared key for all eventualities.
Issues with DKIM authentication
Mismatched signatures – A valid DKIM signature could use a completely different domain than that shown in the ‘from’ field. It makes phishing from another email domain a simple process.
Key security – A hacker signing messages using another user’s domain could have their emails validated perfectly using that domain’s private key.
Implementing and managing keys – Lengthy, more secure keys can be problematic when applying to the domain DNS. These long strings of data are easily misapplied, even when copy and pasting.
To get the best from DKIM, it needs to be partnered with DMARC, bringing the domain used in the ‘from’ field into play. You can see now how each system depends on its previous method to create a complete and effective authentication system.
DMARC – Domain Message Authentication Reporting and Conformance
As already mentioned, DMARC enforces the use of the domain set in the from field to prevent hackers and attackers from using alternate domains to bypass safety checks.
It also includes a reporting mechanism that allows the sender to decide what to do with authentication results. The DMARC record controls where and how recipient servers send reports.
In effect, DMARC plugs the gaps between SPF and DKIM and boosts email deliverability. Spammers can no longer misuse these protected domains; therefore, the domain reputation builds, all the time improving deliverability rates.
DMARC Enforcement
The DMARC record dictates what to do with emails failing to authorize. The policy has three outcomes: do nothing, quarantine, or reject. A DMARC report alerts the domain holder to where such failed messages have come from, providing critical information about the violation and what they can do to take further protective steps.
BIMI – Brand Indicators for Message Identification
It’s hoped that including BIMI email authentication will provide around a 10% boost in engagement through deliverability—that’s not a number to be taken lightly.
Given this authentication method is in its infancy and still awaiting introduction by many email providers, there are several steps users can take to make sure they’re ready for a grand roll-out when it finally hits our servers.
One thing’s for sure, given that Google is including BIMI integration with G Suite, it should only be a matter of time before the rest of the world catches up.
How to get ready for BIMI?
To activate BIMI email authentication, you must first authenticate your emails with SPF, DKIM, and DMARC, ensuring alignment (the domain is the same throughout). DMARC policy must be enforced at either quarantine or reject, and the domain DNS must have the correct BIMI record.
You’ll also need to host an appropriate logo file as a link for the resulting authentication to show in your recipient’s inboxes. Your logo will need to be in the correct SVG format and possibly a VMC (Verified Mark Certificate) to authenticate the file.
Complete authentication for your email campaigns
We’ve learned that each one of these methods on its own won’t provide any kind of one-stop solution to make life simple. However, with a little work to bring each of the systems together as one, you’ll be far more secure in the delivery of your email campaigns and messages than you could ever be without them.
It’s worth the time and effort it takes if it ensures the protection of your service, your subscribers and boosts the connectivity and returns on your marketing.
Most popular on our Blog
