How to authenticate email (DKIM, DMAR, SPF)
The following requires someone with admin access to your domain to complete. It is highly recommended you do this to reduce likelihood of ending up in the spam folder.
What is email authentication?
Email authentication is a daunting subject. There’s often an alphabet soup of acronyms and initialisms. But the core concepts are not complicated, and most everyone will be able to quickly understand them. Email authentication is a process used to verify the legitimacy and integrity of an email message. It establishes trust between senders and recipients by ensuring your identity is verified. Email authentication relies on several methods and standards, including the following:
Sender Policy Framework (SPF)
DomainKeys Identified Mail (DKIM)
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Brand Indicators for Message Identification (BIMI)
Quick Steps:
Open your domain host (e.g. GoDaddy, Route53, NameCheap, Hover, etc.) and go to DNS settings
Use a tool like EasyDMARC to check if you currently have any DMARC, SPF, DKIM records set up already. If they're not setup correctly, go to your DNS settings and add these records.
A SPF record should look like this (varies depending on what services you use):
v=spf1 include:_spf.smtp.com include:sendgrid.net include:_spf.google.com ~allA DMARC record should look like this (varies depending on what settings you want):
"v=DMARC1; p=none; rua=mailto:dmarc-reports@gethyperscale.com; pct=10"Hyperscale sends directly from your Google and Outlook account, so we will not need DKIM.
Setup BIMI (Brand Indicators): Create a TXT record referring to a public link with your logo (.svg format). It should look something like this:
"v=BIMI1;l=https://hyperscale-frontend-prod.s3.eu-west-2.amazonaws.com/hyperscale_icon_black.svg"
Detailed Steps
Credit to SendGrid for creating the following guide:
1. Use consistent sender addresses
Be consistent with the from addresses and friendly from names you use. It can be tempting to have subscribers open a message out of curiosity, but trust in a message starts with a recipient easily recognizing the sender as a brand they trust. Constantly changing from names and from addresses makes your recipients more susceptible to phishing. Similarly, avoid using cousin domains or domains that are slight variations of your standard brand's domain, as this also erodes trust in your messages and trains recipients to be more susceptible to phishing attacks. For example, if your domain is example.com, you'll want to avoid using a similar domain like examplemail.com.
2. Authenticate your IP addresses with SPF
SPF stands for Sender Policy Framework and compares the email sender’s actual IP address to a list of IP addresses authorized to send mail from that domain. The SPF record is added to a sender's domain name system (DNS) and contains a list of authorized IP addresses. SPF records are TXT type DNS records that look like this:
3. Configure DKIM signatures for your messages
DomainKeys Identified Mail (DKIM) is an authentication standard that cryptographically signs the messages you send so that receiving servers are confident there was no altering of the message in transit.
To find your DKIM TXT record, click Generate New Record in your Google Admin Panel. Add this to your DNS records as a TXT file. The Host Name and TXT record should look something like below:
4. Protect your domain with DMARC authentication
Domain-based Message Authentication, Reporting & Conformance (DMARC) is a protocol that uses SPF and DKIM to further prevent phishers from spoofing messages. A DMARC record is published alongside your DNS records and requires both SPF and DKIM to pass. It also requires the from address domain and the domain used in the message's authentication to match. The DMARC record allows the owner of the domain to both instruct receiving servers what to do with messages that appear to be spoofed (such as block them outright or put them in the spam folder) as well as receive forensic reports regarding failed messages and potential spoofing of the domain.
Post on how to implement DMARC.
5. Prepare for BIMI
Brand Indicators for Message Identification (BIMI) is an extra bit of goodness atop the authentication cake that provides an even better inbox trust experience for your recipients. For senders with a good sending reputation, DMARC in place and at enforcement, and a published BIMI record, BIMI will allow them to provide their brand's logo in the inbox so that subscribers can quickly and easily identify their message as trusted. In terms of authentication, BIMI is the only visual clue a typical email user can use to identify a message’s source and authenticity.
Google details how to create a BMI record here.
Further explanations
Sender Policy Framework
SPF allows a sender to verify their authenticity. Let’s think about it this way: if you receive a letter in your mailbox printed on official letterhead, you can be reasonably sure that it’s authentic. So another way to think of an email that passes SPF is a certified letter from the post office. There is a tracking number provided, and you can verify who the sender is by calling the post office. SPF is also similar to confirming a return address. If you received a letter where the business name didn’t match any businesses listed at the letter’s return address, you would be rightly skeptical of that letter. This kind of check is usually unnecessary for physical mail, but it’s necessary for email messages, too, because it’s easy to send a message claiming to be from someone else. During SPF, a receiving email server can ask the domain that the email claims to be from for a list of IP addresses that are allowed to send email on that domain’s behalf. If the domain doesn’t list the originating server as a valid sender, then the email is most likely not genuine and the SPF check will fail.
DomainKeys Identified Mail
DKIM is like a wax seal on a letter. Before reliable postal infrastructure, letters were authenticated with a sealing wax embossed with a signet ring belonging to the sender. The hardened wax bonded with the parchment and made it nearly impossible to tamper with the letter without leaving evidence. Let’s imagine another way to ensure the authenticity of the sender. Think of a box with a locking drawer and a locking lid. The drawer can only be locked with the sender’s key. We’ll call this key the sender’s private key. The lid can be locked and unlocked by a key that is freely available. Anybody can request a copy of the key. In fact, the sender has provided all of the post offices along the delivery route with a copy of this key. We’ll call this the public key. Under the lid is a pane of glass. By unlocking the lid anyone can inspect the package through the glass, but cannot tamper with it without breaking the glass and leaving evidence. Upon inspection, an interested party can confirm the official letterhead, see that the glass is intact, and verify that the drawer is locked with the key that only the sender has. Each post office along the way opens the lid to make sure that the package is still intact. DKIM works in a similar way to this box. The sender has a cryptographic private key that is used to encode the message headers. The public key is made available on a decentralized public internet registry called the DNS or Domain Name System. Any of the servers involved in passing the message along to the final destination can retrieve the public key and decrypt the headers to verify that the message is valid.
Domain Message Authentication Reporting and Conformance
Imagine that someone sends you one of these fancy double lockboxes. The courier bringing the package performs one final check before delivering it. She looks up the delivery conformance policy for the sender of the package. Their policy says that the package should have originated from a trusted address (SPF). The package should also have been in a locked box from a trusted source holding a private key and should be verifiably unaltered in transit (DKIM). The policy further stipulates that if the SPF and DKIM conditions are not met, the courier should quarantine the package and inform the sender of the violation. This policy is analogous to a Domain Message Authentication Reporting and Conformance policy. DMARC is the latest authentication tool, built on both SPF and DKIM. It’s a way for senders to inform recipients which authentication methods to check for and what to do if a message claiming to be from them does not pass the required checks. Instructions might include marking the message as quarantined and therefore likely to be suspicious or rejecting the message completely. You might wonder why senders would ever want to allow messages that don’t pass DMARC to be delivered. DMARC also provides a feedback loop so senders can monitor whether emails that appear to be originating from their domains are conforming with the policy or not.
What email authentication means for senders
With DMARC, domain owners finally have full control over the “from” address over that appears in a recipient’s’ email client. Large mailbox providers like Yahoo! and AOL have already implemented strict policies. Emails that appear to originate from these domains but that fail authentication checks will get dropped. You can view updates on Gmail here and on Microsoft here. What this means is that you should never send from domains that are not configured to allow your server via DKIM and SPF. If you send emails on behalf of clients, you’ll want to ensure your clients have the correct DNS entries in place to enable this. For recipients, the increased popularity of these technologies means a reduction in phishing and spam emails that get delivered. And that’s always a good thing.
Last updated
