Email authentication: Your ID card for sending

What is email authentication?

Email authentication verifies sender identity using multiple methods to separate messages sent by real senders from forged ones. As a Technical Account Manager at Mailgun, I’m constantly talking to my customers about how to protect against fraud, spoofing, phishing scams, and how to stay out of the spam folder. One of best practices is securing with email authentication.

Different providers may require different authentication setups. Required details like which authentication protocols you need and what conditions you need to configure can vary but going without authentications can get you marked as a fake sender even if you’re not.

Establishing brand legitimacy

Email authentication isn’t the most glamorous part of sending email. It’s not as fancy as building templates or copywriting the overall email message, but without it, your emails are more likely to land in the spam folder. Better email deliverability starts all the way at the beginning with initial setup and authentication.

Plus, having the right email authentication in place lets mailbox providers like Gmail catch phishers and fake emails faster – something we can all get behind.

How email authentication works

Email authentication works by using DNS records to verify different aspects of your sender identity. Some records let the receiving server validate the hosts that are allowed to send messages from a specific domain, and others verify sender identity with public-keys and electronic signatures. The policy you set is up to you and the record types you choose.

The authentication process works like this:

1. A business develops a policy to manage how email sent from its domain name is authenticated.

2. The email sender configures its mail servers to implement and enforce the policy.

3. The recipient’s server authenticates the message it receives against the business's authentication policy.

4. If authenticated, the recipient’s server accepts the message. If it fails authentication the message is managed based on the policy in place:

• Deliver it to the inbox anyway

• Allow the message through but send it to the spam folder

• Reject the message (blocking it from deliver)

Email authentication methods

An email authentication method is any technical standard that makes domain-based email authentication possible. The elements that are being verified can vary from method to method, but they were all designed as standards to support Simple Mail Transfer Protocol (SMTP) – the main protocol (other than API) used to send email. SMTP works well, but it doesn’t have built-in security which is why authentication methods exist.

The most common email authentication protocols are SPF and DKIM, and others like DMARC and BIMI are starting to become more widely used.

Sender Policy Framework (SPF)

Sender Policy Framework (SPF) was the first real attempt at an email authentication protocol, devised in the early 2000, SPF utilizes a Domain Name System (DNS) TXT record to specify which email sources are valid email senders for the given domain and what to do with the messages that don’t originate from those sources. It acts as a digital bouncer; if you aren’t cool enough to be on the list, you’re likely to get kicked to the curb (or land in the spam folder).

An SPF record consists of a collection of mechanisms and qualifiers. The mechanisms are methods for identifying email servers while the qualifiers tell us what to do with those mechanisms. Sounds simple, right? SPF records are necessary but that’s not to say they don’t have some limitations. Here are some:

• Only one valid SPF record is allowed per domain. Multiple records can confuse recipient systems.

• SPF implementation MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check. (This does take into account INCLUDE and REDIRECT mechanisms.)

• We recommend using ~all as the final entry in the record, but we certainly accept -all as well.

• We do support SPF recording chaining for whitelisting. See this blog for details.

While SPF works great in most situations, there are some circumstances where it doesn’t quite hold up, like with forwarded messages. Forwarded messages will have the same original sending domain, but it will likely be sent by a server that isn’t specified in the sending domain’s SPF record. The likely outcome is messages being tagged as spam unintentionally or the messages being dropped altogether.

The biggest problem with SPF authentication is that bad actors can exploit it with a fake domain in the Return Path address and forging the From address to make the email look legitimate. That means SPF not the most effective way to stop brand spoofing.

With such a glaring issue within the framework, it wasn’t long before email authentication was looked at from a different angle.

Domain Keys Identified Mail (DKIM)

DKIM authentication is a technique allowing recipients to validate certain digital aspects of the email by matching a public key with a private key to verify the message was authorized by the owner of the domain it was sent from. Once signed cryptographically, the receiving mail server validates the public key against the private key.

In the signature, you can specify specific message header fields and components that you would like to sign against. However, the “From” field is the one message aspect that must be included in the signature.

In plain English, a DKIM record allows a sender to say, “I’ve signed parts of this message digitally and using my public key, you can validate that what I’ve sent you hasn’t been modified in any way, and you can rest assured it was sent from my domain.” A bit of a mouthful, but you get the picture.

DKIM is an excellent resource for ESPs to track a domain’s reputation because signing messages via DKIM is considered authoritative. As an ESP we take care of a lot of the DKIM heavy lifting on your behalf; however, there are some customization options.

At Mailgun, our standard recommendation is to have your sending domain be a subdomain off your main root domain. As such, our customers have the option of setting the DKIM authority to either be that subdomain or the root with the caveat that both domains are setup within your Mailgun account.

Let’s say your main root domain name is catzrule.org (because cats indeed rule), but you’ve set your Mailgun sending domain name as mg.catzrule.org. By default, our system will want to set the DKIM authority for both domains to catzrule.org, but by using our API, you can overrule that and have mg.catzrule.org have its own value instead. This value can be changed at any time but be aware that it can have ramifications for your domain reputation.

Domain Message Authentication Reporting and Conformance (DMARC)

There wasn’t anything to tie SPF and DKIM together until DMARC entered the picture.

Domain-based Message Authentication Reporting and Conformance (DMARC) gives domain owners better control over SPF and DKIM and makes these policies easier to handle.

DMARC records:

• Signal whether SPF and/or DKIM authentication is in place for the domain.

• Suggest how to handle messages that fail to align with those protocols.

• Direct how to give feedback to the sender.

A DMARC policy is principally concerned with the alignment of the “From:” field with the authentication mechanisms listed in the SPF or DKIM policy for the domain. In other words, DMARC helps ensure recipients know exactly what to do with a message that fails either SPF or DKIM, while also letting the recipient notify the sender via the reporting function as to how the message performed.

Implementation

Our best words of wisdom regarding DMARC implementation is to start with a p=none policy. A none policy will ensure that messages are scanned according to your DMARC policy alignment specifications, but no action is taken on them. In other words, the none policy tells your recipient’s email provider not to take action against your message if DMARC fails.

There are two other DMARC policy types:

• The p=quarantine policy separates suspicious emails by placing them somewhere like a spam folder, instead of the inbox.

• The p=reject policy tells the provider to block any email that fails DMARC. With the reject policy, a message failing DMARC will never see the inside of the inbox.

The value in using the none policy is that reports will still be generated for those domains. You can use reports to verify the SPF and DKIM alignment policies. Once you confirm DMARC is working as it should, you must update the policy and instruct receiving mail servers to either quarantine or reject failures moving forward. This is critical, because a relaxed p=none policy does nothing to make your authentication stronger or make the inbox a safer place for subscribers.

Reverse DNS/Pointer (PTR) Records

Setting up your reverse DNS/PTR records is step one when implementing DMARC. Reverse DNS works by resolving a domain’s DNS (name) to an IP address, rather than resolving an IP address to a domain name. The last point of authentication comes at the server end of things with Reverse DNS or Pointer (PTR) records.

All mail servers will have a sending IP address that is used to talk to other servers, but we also recommend that a human-friendly name is attached to that IP address. Reverse DNS records and PTR records make it easy to identify the server when looking at mail logs and email headers, so you don’t have to memorize IP addresses.

At Mailgun, all of our shared and dedicated IP space comes with a preconfigured PTR record. So, no matter your account or IP type, you are covered by default.

Reporting

There are two types of DMARC reports that recipients can send to DMARC-authenticated domain owners, aggregate reports and forensic reports.

Aggregate reports will usually be sent daily by recipient servers and collect various statistics for a sending domain. A typical aggregate report will be in XML format and include details on the sending IP, SPF/DKIM alignment passes or failures, and the header FROM domain, along with counts of each message.

Forensic reports, on the other hand, will show real-time DMARC message alignment failures, including a redacted copy of the original message which triggered the failure. Domain owners should utilize these ‘failure reports’ to understand their failures (message failures, not personal/professional) and address any issues uncovered.

Brand Indicators for Message Identification (BIMI)

BIMI allows you to include a branded sender image using your brand’s logo along with your message. Not only does BIMI provide brand recognition at a glance, but it’s a DNS TXT record that provides additional authentication.

Think of BIMI as the icing on the cake. After you’ve jumped through the hoops and configured all your authentication standards, you become eligible for a BIMI record but there is a caveat. For BIMI to work, your DMARC policy must be set to either quarantine or reject.

We still recommend starting with p=none when you implement DMARC – this is a great way to test DMARC configurations and reporting, but it shouldn’t be your ongoing standard as it doesn’t protect against phishing or spoofing. BIMI requires p=quarantine or p=reject as part of a larger movement to enforce stricter DMARC policies.

Email authentication: The last defense

Email authentication encompasses deliverability, reputation, and security. Email authentication isn’t just about securing your identity, it’s a deciding factor in message filtering. At the end of your email’s journey when the ISPs are deciding whether to let your message into the inbox, authentication gets you past the spam filters.

So, there’s really only one question: Is your identity junk? Or is it worth authenticating.

There’s a lot more to implementing and understanding email authentication protocols, and security goes far beyond authentication. Curious about other ways to secure your email program? We are too. So curious, in fact, that we gathered our most dedicated security and deliverability email geeks to put together a comprehensive guide. Check it out for everything you need to know about email security and compliance.