Email Authentication: Your ID Card For Sending

As a Technical Account Manager at Mailgun, I’m constantly talking to my customers about various deliverability and good sender best practices — one of those being email authentication. 

Email authentication is comprised of various methods for taking ownership and accountability of your email and serves as a basic foundation of quite a few of those conversations. 

Think about it this way; Email Authentication lets ISPs know that you really are who you say you are, and your emails are coming from you and not a spammer. It’s kind of like a driver’s license or an ID card — legit ones, that is.

*cracking voice* yeah I’m Thomas from Malegun

That being said, different customers will require different authentication setups. Different details like various authentication protocols, different caveats, and implementations all need to be considered in order to look like a legitimate sender. If you implement these methods correctly, you’ll adhere to a better sending practice and help improve your deliverability.

Plus, it makes it a little harder for spammers to look like you. What’s not to love?  

Let’s get to it:

SPF

Sender Policy Framework (SPF) was the first real attempt at an email authentication protocol, devised in the early 2000s.  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 version of a bouncer at a dance club; 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). 

How it feels with an SPF record

An SPF record will consist 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. Still, here are some SPF caveats some of our customers have run into:

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

• SPF implementations 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.

Problems with SPF

While SPF works great in most situations, there are some circumstances where it doesn’t quite hold up — like 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. 

This can likely end with messages being tagged as spam unintentionally or the messages being dropped altogether. With such a glaring issue with the framework, it wasn’t long before email authentication was looked at from a different angle…

DKIM

Domain Keys Identified Mail (DKIM) was born from the idea of using a digital signature to sign certain aspects of a message, thus guaranteeing their authenticity. In the signature, you can specify numerous specific header fields and message components that you would like to sign against. However, the “From:” field is the one message aspect that must be included in the signature.

Once signed cryptographically, a recipient server can validate those fields using the public key contained in a DNS record for the sending domain. In plain English, DKIM 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 email service provider, we take care of a lot of the DKIM heavy lifting on your behalf; however, there are some customization options.

DKIM Authority

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, 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.

Key Size

Our current default key size is 1024 bits, but we have recently updated our system to be able to generate and utilize 2048 bit keys as well. Upon creation of your domain with Mailgun, you can set this in our control panel or via the API. 2048 bit keys offer stronger encryption but will generate a larger TXT record as a result, so you may need to consult with your DNS provider about formatting.

To recap what I’ve covered so far, SPF records tell the internet who should be sending mail on your domain’s behalf, and DKIM ensures that recipients can validate certain digital aspects of your messages. However, there still wasn’t anything that tied these two policies together or made them easier to handle. That is until —

DMARC

Domain Message Authentication Reporting and Conformance (DMARC) allows domain owners better control over their SPF and DKIM. Overall, DMARC…

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

• How to handle messages that fail to align with those protocols.

• 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. 

Reporting

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

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.

Implementation

Our best words of wisdom in regards to DMARC implementation is to start with a p=none policy. A p=none policy will ensure that messages are scanned according to your DMARC policy alignment specifications, but no action is taken on them. 

The value in the none setting is that reports will still be generated for those domains, which should then be evaluated to verify the SPF and DKIM alignment policies. Once you are satisfied regarding sent messages meeting their requirements, you can start to update the policy and instruct recipients to either quarantine or reject failures moving forward.

Reverse DNS/Pointer (PTR) Records

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 with other servers, but it is also recommended that a human-friendly name is attached to that IP address. 

Reverse DNS and PTR Records make it easy to denote the server when looking at mail logs and email headers so you don’t have to memorize IP addresses of your favorite service providers. Otherwise, there would be a lot of this:

We're good, thanks.

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

However, for accounts with dedicated IPs, we do offer assistance with setting up a custom PTR record with your sending domain. This allows for a final form of authentication at the IP level and is a nice touch of ownership to your sending IPs. For help with this setup, reach out to our support folks.

Remember: Authentication Establishes Brand Legitimacy

Email authentication isn’t the most glamorous part of sending email like 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 when you’re setting up, so set up the right way by doing the due diligence and authenticating where you can. 

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