Email authentication protocols
Email authentication refers to mechanisms or protocols that allow you, or your mail server, to verify that a message using a particular internet domain in the from field was authorized to use that domain. In other words, if you get a message with a from address of sales@BigBank.com, did BigBank.com really authorize that message?
Different email authentication protocols have been introduced over the past decade. The most popular protocols are:
- Sender Policy Framework - SPF
- DomainKeys Identified Message - DKIM
- Domain-based Message Authentication, Reporting and Conformance - DMARC
Many mailbox providers around the world use these protocols to filter incoming messages. Marketers need look no further than Google, Yahoo, and Microsoft to find that more than half of their average lists are being checked for all three protocols.
Many email marketers send messages on behalf of clients, using the client’s domains in the from address, but aren’t sending the messages from the client’s infrastructure. This is essentially what spammers and phishers are doing, so it requires more work from the mailbox providers to distinguish the bad actors from the legitimate marketers.
Email authentication protocols aim to make that task easier, and marketers should be highly motivated to ensure the messages they send can be verified as legitimate. This avoids delays or being diverted to the spam folder accidentally.
Read on for more details on the three most popular authentication protocols.
Sender Policy Framework (SPF)
Sender Policy Framework, or SPF, is a mechanism that allows a domain owner to indicate multiple IP addresses or domains that can send mail on their behalf via a DNS TXT entry. It protects the envelope sender address (known as the return path) by comparing the sending mail server's IP address to their master list of authorized sending IP addresses in a particular DNS record.
Litmus validates that the SPF record added to your DNS is properly implemented and meets specifications. For each test that you send, we report SPF authentication results from multiple inbox providers, to troubleshoot any intermittent issues.
Check your Email Service Provider (ESP)'s guide on SPF: Your ESP should be able to provide the text to create an SPF entry in your domain's DNS record. They may have already set up an SPF record for your domain. Otherwise, this will need to be handled by your DNS administrator or IT department.
DomainKeys Identified Mail (DKIM)
DomainKeys Identified Mail, or DKIM, allows your organization to claim responsibility for your email as part of the authentication process. It plays a role in how an Internet Service Provider, or ISP, knows it's really you that's sending your email. Technically, this means that DKIM validates a domain name identity through cryptographic authentication added to a DNS record. DKIM also allows a sender to identify a domain to be used by receivers to assign a sender reputation. Signing your email using DKIM is a recommended best practice industry-wide, and one of the key ways to ensure Inbox providers develop your domain's sender reputation profile. Basically, DKIM shows that your email is associated with your domain.
Litmus validates that the DKIM record in your domain's DNS zone is properly implemented and meets current DKIM specifications. Litmus also reports external authentication results from multiple inbox providers, to aid in the troubleshooting of intermittent issues in DNS or your sending infrastructure.
Check your Email Service Provider (ESP) for their DKIM guide. Your ESP will either sign the message for you or provide specific instructions to correctly enter the DKIM entry into your domain's DNS zone.
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It serves as a method of authentication for your brand, alongside Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). What sets DMARC apart from the other two authentication methods is its reporting capability.
DMARC is an email authentication technology that protects a domain from being used in phishing and spoofing attempts by using a signing policy to define how receiving inbox providers should handle messages that fail an authentication check. DMARC also allows for a reporting mechanism in which inbox providers can send reports on email that appears to be sent from a certain domain back to the domain owner.
Inbox providers that support DMARC will attempt to validate both DKIM and SPF, and depending on the outcome of those checks, will look to the sending domain's DMARC policy on how to handle emails that fail authentication.
If the inbox provider is able to successfully validate either DKIM or SPF, the email will continue on its normal path. If the message fails both DKIM and SPF authentication checks, however, the inbox provider will enforce the sender’s DMARC policy, which specifies how the email should be handled if it fails authentication and where to send any reports. DMARC has three levels of policy:
- None: If the policy is set to none, the receiving inbox provider monitors and reports on metrics.
- Quarantine: If the DMARC policy is set to quarantine, the inbox provider places messages that fail the required checks into the user's spam folder.
- Reject: If the policy is set to reject, the inbox provider will block any message that fails authentication.
The preferred policy type—once vetted for correct implementation—is 'p=reject' which provides the highest level of protection.
For an even deeper dive into DMARC, see our blog post DMARC: What It Is + How It Helps Protect Your Brand Against Email Fraud.
Litmus validates that the DMARC record in your DNS meets the required DMARC specifications. Litmus also reports the results of the record from multiple external inbox providers to help you troubleshoot intermittent issues.
Check your Email Service Provider (ESP) for their DMARC guide. Your ESP may have detailed instructions for adding the correct DMARC entry as a text entry in your domain's DNS record. Given the impact an incorrect DMARC policy can have, you should consult with your ESP if you are unsure how to proceed.
Domain Name System - DNS
Encryption
Email encryption is an authentication process that prevents messages from being read by an unintended or unauthorized individual. It scrambles the original message and changes it into an unreadable format. At Litmus we check on whether the email coming in is properly encrypted with Transport Layer Security (TLS) and include a check of the Certificate Authority Authorization (CAA). Most emails sent and received are encrypted.
Transport Layer Security (TLS) plays a role in protecting email communications by establishing a secure and encrypted connection between two points. Similar to DKIM, TLS utilizes asymmetric encryption to keep email communications private while in transit. It provides a mechanism for authentication between the sender and recipient.
A CAA record is a DNS Resource Record that allows a domain owner to specify which CAs are authorized to issue certificates for their domain. Generally, you want to set CAA records on your registered domain (such as “Litmus.com”). This way they apply to both that domain and any subdomains you create under it, such as “community.litmus.com”.
List-unsubscribe header
List-unsubscribe is a native unsubscribe option offered by popular inbox service providers (ISP) that gives subscribers a consistent and easy way to opt out of future messages. Clicking the ISP-provided ‘unsubscribe’ link in the inbox or email removes subscribers from a mailing list with a single click or directs them to an unsubscribe landing page.
An email client can only provide a native list-unsubscribe option if it finds list-unsubscribe instructions in the email’s header. (List-unsubscribe links don’t automatically display on each promotional email).
There are two types of instructions a sender can provide to an inbox provider to power list-unsubscribe: a mailto link or an unsubscribe URL.
A mailto unsubscribe
When a recipient triggers the list-unsubscribe in a client that supports unsubscribes via the mailto link, this automatically generates an email notifying the sender that an email address has unsubscribed. The unsubscribe header is set up with the email address that will receive the unsubscribe requests.
An unsubscribe URL
A link that will take the subscriber to a landing page to process the unsubscribe request. In most cases, that’s a subscription center or another type of landing page that asks the user to confirm the unsubscribe. Brands might also choose to offer a one-click list-unsubscribe that doesn’t require additional confirmation on a landing page, in accordance with RFC 8058.
NOTE: Some email service providers do not provide List-unsubscribe headers. For example, Salesforce will not provide one by default on transaction emails.
Google and Yahoo sender requirements
If you’re a bulk sender—which Google defines as anyone sending 5,000 or more emails in a day—you must:
- Verify your sender identity by authenticating using DKIM, DMARC and SPF records
- Implement list-unsubscribe headers and honor opt-out requests within two days
- Maintain a spam complaint rate below 0.3% (no more than three spam reports for every 1,000 messages)
The first thing to note about these “new” requirements is that they aren’t actually new—these standards have existed for years, but have not been enforced. The only change now is that Gmail and Yahoo are enforcing them due to steadily increasing spam.
Even if you think you fall beneath that 5,000 messages mark, it’s still in your best interest to adhere to these guidelines as best practices that will serve you well now and as your list grows.