Sender authentication is a cornerstone of good deliverability. Sender auth is an advanced topic, but even beginners need to know enough about it to have a conversation about it because it is foundational to your deliverability. There are a few different forms of sender auth and what you need to know is the basics of how they work. Sender authentication methods are used to track your reputation, increase your company’s security, customer confidence, and reduce phishing and fraud.
When you send email, there is a lot of work happening behind the scenes and a lot of information recorded that you don’t usually see. I’ll share full headers and explain them in a future post, but what you need to know for now is those are the “envelope” for your email. Sender authentication methods validate different parts of the envelope to boost confidence that the email your recipient gets is the same content you sent and is really from you.
It’s about to get confusing, but we’ll have future posts that get more in-depth on each form of sender authentication. I’ve linked to the RFCs (Requests for Comments, or the rules that the internet operates by) that relate to each type of sender authentication for intermediate and advanced learning. If you’re just getting into email and deliverability, skip those for now. They’re very technical and can be confusing even for experts.
DNS usage in Sender Authentication
First, you need to understand some basics about DNS, or Domain Name Service. DNS has multiple different types of records that allows computers to “talk” to each other. While there are many more types of records, these are the ones you need to know for conversations about sender authentication to make sense:
- TXT (text) records provide basic information about your domain.
- A (address) records translate your IP (internet protocol) address. (which is made of all numbers) into words like www.directdeliverability.com.
- MX (Mail eXchange) records say where to deliver email to you.
- CNAME (canonical name) records let you set an alias. This may not apply to you unless your ESP handles your DNS records for you. We won’t be talking about them in detail here, but I’m including them in case they come up in conversation.
SPF, or Sender Policy Framework
SPF stands for Sender Policy Framework and is defined in RFC7208. SPF authenticates your sending IP address using a TXT (or text) record, which is comparable to your street address on a physical envelope. SPF checks your “envelope from” not your friendly from. Your envelope from goes by many names but the most common are Return-path or bounce address. We’ll get into the technical terms for these different from addresses in more advanced posts. Your envelope from is not usually displayed to your recipients. Your friendly from is the address you set up in your email client or ESP’s UI to display to your customers.
You may have a shared IP address, meaning other senders also use the same IP, a single dedicated IP, multiple dedicated IPs, or multiple vendors. All of these IPs need to be included in your SPF record and may be labeled as A, MX, ip4, ip6, or includes based on how they are formatted and grouped together. (There are additional types, but we’ll get into those when we look at SPF more in-depth.) If your SPF record is improperly formatted or does not include all of your originating IPs, SPF will fail which will cause your email to be placed in the spam folder or rejected.
DKIM, or DomainKeys Identified Mail
DKIM stands for DomainKeys Identified Mail and is defined in several RFCs, which can be found linked in the Documents section on the DKIM website. The DomainKeys Identified Mail (DKIM) Services Overview (RFC5585) establishes the protocol and gives an overview of the service. DKIM is comparable to the envelope you put physical mail in. It creates an encrypted “wrapper” around your content and headers like your subject line and From address.
In the full email headers, your mail server will include some information about which headers are included, the hash for the encryption, a selector (indicates different parts of your mailstream), and the domain or subdomain that is authenticating the message. In the image showing the from addresses, you can see which headers are being included by looking at the list after h=. (Text-only version available here.)
It is possible and somewhat common to have multiple different DKIM signatures on the same email. This just means that each signer is authenticating what they’re sending on is what they received from you. The signer may be very different from the original sender.
DKIM requires that the signers have a TXT record in your DNS entries that includes the type of cryptography used and a public encryption key. The recipient mail server makes a query to the signers’ DNS server(s) to ask for the public encryption key and compares its results to the information in your headers. If the results don’t match, DKIM fails. Your email will be marked as failing and placed in the spam folder or rejected.
Note: DomainKeys, as opposed to DKIM, is deprecated.
DMARC, or Domain-based Message Authentication, Reporting, and Conformance
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance and is defined in RFC7489. DMARC relies on DKIM or SPF in a few different ways. While neither SPF nor DKIM require that they align with your friendly from, DMARC requires that at least one does. Remember, SPF has to align with your Return-path or envelope from while DKIM relies on the signer’s domain value in the full headers? That’s a bit confusing, so why is the DMARC requirement different? DMARC is intended to combat online phishing and fraud, so it makes sense that the requirement of the email address you see is the one that has to be aligned to pass authentication.
DMARC requires a TXT record that recommends to a provider how they should place your email if DKIM and SPF do not align with the friendly from or both fail to pass and what percentage of email to apply the policy to. Policy options are none (deliver as normal, used for initial setup and troubleshooting), quarantine, or reject. Many providers will choose to quarantine rather than reject email regardless of the policy set.
BIMI, or Brand Indicators for Message Identification
BIMI stands for Brand Indicators for Message Identification and is the newest protocol. BIMI is still in draft and has not yet reached the point of having an RFC. The draft is available at https://tools.ietf.org/id/draft-blank-ietf-bimi-00.html. Because it is still in draft, implementation is limited, however there are a number of providers who have implemented BIMI as of late July 2020.
BIMI allows DMARC-compliant mail with an enforcement policy (quarantine or reject at 100%) to display a company logo in your subscriber’s mail interface. In order to display your logo, you must produce a Scaled Vector Graphic Tiny PS version of your logo and make it available via a URL. Once that is available, you publish a DNS TXT record that indicates where your logo is.
BIMI is not available at all mailbox service providers or for all senders yet, but it’s an exciting advancement and we’ll keep you updated as its use becomes more common.
All forms of sender authentication use DNS TXT records. To implement sender auth, you may need to pull in your IT team or DNS provider.
Sender auth is used by reputation systems. Not having sender authentication implemented, or having them implemented wrong can decrease your inbox delivery.
SPF conirms your envelope from (or return-path) domain matches an IP you have authorized to send mail on your behalf.
DKIM confirms the content of the email sent is the content your recipient received and uses the domain listed in the DKIM header for authentication.
DMARC requires either DKIM or SPF to pass and also to align with the friendly from address. DMARC lets you tell mailbox providers how you want mail that doesn’t pass authentication to be treated.
BIMI uses your DMARC policy to add a logo next to your email in some web interfaces for email providers. It is the newest protocol and likely to be adopted at a much wider scale in the coming years.