Email Authentication

Custom domain authentication

Benefits of custom domain authentication

At the most basic level, properly authenticating your domain makes it more difficult for malicious spoofing or hijacking of your brand’s identity. Using authentication in conjunction with a custom domain requires bad actors to create a vanity URL to match and mimic your domain. They don’t have the ease of simply mimicking a general domain like Gmail, which requires little to no effort.

Do I need custom domain authentication?

The following email authentication information assumes the use of a custom domain.

How does email authentication work

Email authentication is a collection of activities created to confirm and verify the identity of an email sender. These techniques include Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting & Conformance (DMARC). By confirming the sender is who they claim to be, email authentication is a key component of protecting both the brand and email recipients from spoofing and phishing.

This protection extends to your mail recipients as well. You’re blocking as much spam and dangerous mail to their inbox as you can. While you can’t fully inoculate subscribers from phishing attempts, you can be more confident your email isn’t contributing to the problem.

Finally, you’re providing overall brand protection beyond email. Many high-profile companies fell victim to email scams over the last few years. When email is successfully used to extract customer information, your business could be responsible for monetary damages. Beyond the financial impact, brand reputation, trust, and loyalty quickly erode without consumer confidence.

Three primary email authentication methods

There are three core methods of email authentication: SPF, DKIM, and DMARC. These are foundational and can be built upon with newer, more nuanced technologies. Without employing DKIM and SPF, you cannot add the benefits of DMARC. This tiered and layered approach multiplies the security of your domains and, consequently, your brand.

1. SPF

At its most basic level, SPF is used to prohibit email forgery. It involves code called an SPF record, which is placed in the sender’s Domain Name Server (DNS). Your DNS record is public, but only relevant to players in the email space. The record allows mail servers receiving the mail to verify the content is truly from the sender.

If the server does not confirm the records match or detect there was manipulation in transmission, the server can reject the message.

That being said, SPF is a relatively simple trust indicator and works better in tandem with other, more secure protocols. Put frankly, it’s a can’t-skip step in building an effective email program.

2. DKIM / DomainKeys

Where SPF is a straightforward step toward security, DomainKeys Identified Messaging (DKIM) is just as crucial but significantly more complex. DKIM requires a series of setup steps and, later, several checks during message transmission.

A major differentiator from SPF, DKIM uses encryption. This involves building encryption tokens for both the sent email and the receiving server. First, as a sender, you’ll need to identify which components of your emails you want to use for verification. This could be the entire message or just an element of the header. Once you determine this, you can encrypt those portions. This is what will be checked to ensure there was nothing manipulated in transmission from sender to receiver.

DKIM uses several “keys.” These keys include a pair of keys for encryption itself, a public key living on your DNS, and a private key residing on your mail servers.

The receiver sees the DKIM signature, then does a DNS lookup to find the public key. It then decrypts the key and creates its own hash of the information it sees. Finally, as the message arrives at the MBP, it will verify both keys match. If it does, nothing was changed in transmission as determined by the keypair match. At this point, the email message is considered valid and is an additional data point for MBPs to consider when choosing to deliver.

3. DMARC

Domain-based Message Authentication, Reporting & Conformance (DMARC) is the finishing touch on a well-authenticated email program. This validation system detects and prevents domain spoofing and phishing. Because DMARC leverages both SPF and DKIM, it directs MBPs what exactly to do when both authentication steps fail.

• p=none: Take no action at all.
• p=quarantine: Filter messages into a quarantine folder and do not deliver to the inbox.
• p=reject: Do not accept the mail to any box.

Beyond setting up the standard for full protection, it’s imperative to analyze and understand the DMARC reports generated at each policy level. Additionally, you’ll need to have an implemented DMARC policy to qualify to use BIMI, a new authentication standard being adopted by some of the largest mailbox providers.

There’s much more nuance to DMARC than just covered, but you can read more about it here.

BIMI

When set up, BIMI places a small graphic next to a sender’s From name, which is a vanity name rather than the sender’s email address. Most companies select a version of their recognizable logo to use as the graphic image. This visually reinforces your brand identity, and provides reassurance for the recipient to trust the email message.

But BIMI isn’t readily available to any sender. Instead, the sender must implement the recommended authentication protocols. This is how it’s closely related to email authentication but doesn’t necessarily provide any technical protection. Instead, it is a sign to the recipient the mail is truly from the company rather than a spammer.

BIMI requires the use of a strict DMARC policy, which in turn requires SPF and DKIM. While BIMI is more marketing-oriented for brand impressions, it’s a nice perk of being thorough in your email authentication.

Other methods

Sender ID

While Sender ID seems almost identical to SPF, they differ in how they detect fraud. How? They each check different headers to perform different functions. Yet, because Sender ID requires a published SPF record to operate successfully, it enhances the protection afforded by SPF.

Sender ID codes are nuanced to indicate the type of issue detected, if there is any.

• Pass: Everything matches and the mail is clear for delivery.
• Neutral: The findings are inconclusive, so it doesn’t necessarily indicate fraud, but is not clear enough to pass.
• Soft fail: The purported responsible address (PRA)’s signals don’t match, but there’s only evidence the IP might not exist.
• Fail: The IP address is definitively not permitted. Either there is no PRA incoming at all or the sender domain isn’t real.
• None: There’s simply no SPF data published in the sender’s DNS.
• TempError: The DNS failed but it’s temporary, due to an unavailable DNS server or similar.
• PermError: There is an error not related to a temporary problem, and instead the DNS record has something truly wrong, such as a record format error.

ADSP

VBR

iprev

DNSWL

FAQ

How do I authenticate my email?

What are some alternatives to email authentication?

How do I ensure my email authentication is working?