TLDR
If you’re using your own domain name for email and want Gmail and Yahoo Mail users to continuing receiving your messages, you must have SPF and DMARC records in place. You can also add DKIM records as an additional level of authentication if your email service supports it. This is required by Google and Yahoo as of February 2024 and is best practice to help improve deliverability for all email services.
Introduction
Both Google and Yahoo have recently announced new requirements for email senders to help protect their users. If you’re using a custom domain for your email, like johndoe@yourdomain.com, you need to make sure you’ve made the proper tweaks to keep your messages from being rejected or quarantined by these services, which between the two, account for more than a 30% market share of email clients in January 2024.
The primary focus of these new requirements is ensuring messages being received are actually being sent by the real sender, and not a scammer. Due to decentralized nature of email and the way it was originally developed during the early days of computer networking and the Internet, it’s traditionally been pretty trivial to impersonate, or spoof, a email address, meaning you change the “from” address to whatever you’d like. As the Internet has grown and email has become essential, email systems needed to be retrofitted with new tools to fight against the flood of email spoofing and scams.
Similar to modern web browsers’ transition to enforce SSL certificates (HTTPS) for all websites, email services are now starting to enforce additional requirements to ensure the legitimacy of the message they receive, all to protect end users.
Email Authentication
There are three primary tools currently used to authenticate an email is coming from a legitimate source: 1) SPF, 2) DKIM, and 3) DMARC. All three involve setting DNS records, which are generally set through your domain registrar. While this seems very technical, the actual steps to complete are pretty simple.
SPF
SPF (Sender Policy Framework) let’s you list which services you use to send emails using your domain name. For example, if your company uses Microsoft 365 email for individual email accounts and Mailchimp for email marketing, you’d need to add the domains for both of these services to your SPF record.
An example of such a record would be:v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all
Let’s break that down a bit:
v=spf1: Denotes this DNS entry as an SPF record, version 1 (this is to future-proofing when the spec is updated in the future)include:spf.protection.outlook.com: All services you use to send email should be listed in an include rule. You can add as many as you need, and they can be listed by domain or IP address.-all: The enforcement rule. -all means receiving email services should reject, or hard fail, all messages that don’t come from one of the sources listed with include rules. ~all means email services should mark a message not coming from a listed source as a soft fail, meaning it probably isn’t legitimate (this depends how confident you are that you’ve properly included every service/server you use in your include rules).
You can look up the SPF include records for your email service(s) with a quick Google search of “SPF” and the service name. Once you’ve got those, just add “v=spf1” to the beginning, prepend “include:” before each service’s domain, and set your enforcement rule.
To set your SPF record, login to your DNS provider (typically the same company where you purchased your domain name), look for DNS records (sometimes listed under an advanced menu option), and add a TXT record. If it asks for a subdomain, type “@” (this means it’s set to the root domain and not a subdomain), then paste in your record. Set the TTL (time-to-live) to around 3600 seconds or 1 hour.
DKIM
DKIM (DomainKeys Identified Mail) let’s you sign messages using public-key cryptography (a topic for another post) and is another way to ensure an email came from a legitimate source. This must be supported by your email service, and that service will provide you with the records you’ll need to add at your DNS provider.
In a nutshell, your email service creates a private key and a public key pair. You add the public key to your DNS and they use the private key to sign every email they send, which is just adding a little bit of encrypted code to the message. Receiving email servers can check this code against the public key you published in your domain records, and then take action depending if it matched or not.
Here’s an example DKIM record:v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCx3qdWjqg6jJYAf/DgyH5EPAF5OfUxSctOeXnMbFa+GThiSRnntCxUT5Rk7sIp9vVxmVC29/1ZlgpZMoZncdaE51SJ1wLTgPlHUN7jgxNE2CYN+qCQKU69395Txn3fDMn1i6LLuHccWAXCy6eKK5rMHPdtpe96PynN/5uIWs095QIDAQAB
Breaking that down:
v=DKIM1: a DMARC record version 1p=76E629F…: the public key, and is various lengths depending on the strength of the generated private key
DKIM records are typically set as CNAME or TXT records on a subdomain, like emailservice._domainkey.yourdomain.com, and your email service will provide specific instructions for how to enable it.
DMARC
DMARC (Domain-based Message Authentication, Reporting and Conformance) allows you to tell receiving email servers how they should handle messages that fail authentication, and where to send summary reports. This works in concert with SPF and DKIM, as both are tools email services use to evaluate the messages they receive. Once these services have classified a message based on content and how it compares to SPF and DKIM rules, they check the DMARC record to see what steps to take next.
For example, if a user has a Gmail account and receives a message supposedly coming from hello@yourdomain.com. Gmail can see the from address is set to hello@yourdomain.com, but it was sent from Constant Contact. By comparing the message to the yourdomain.com SPF and DKIM records, Gmail marks the message as unauthenticated because Constant Contact is not listed as an include rule in the SPF record and the DKIM signature does not match. Then Gmail looks at the DMARC record to determine if it should completely reject or just quarantine the message and what email address to send a summary of these actions to.
Here’s an example DMARC record:v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com
Breaking that down:
v=DMARC1: This is a DMARC version 1 recordp=reject: Ask the receiving server to reject all messages that don’t pass authentication (which is typically determined by checking against SPF and DKIM records, among other signals)rua=mailto:dmarc@youdomain.com: This is the email address that should receive summary reports, which includes information about the messages it rejected and why. This is helpful to ensure email authentication is working properly and to troubleshoot if legitimate messages are being caught.
Because setting your DMARC policy can have a direct impact on email deliverability, Google recommends rolling out DMARC in a controlled manner to catch any issues before jumping to full enforcement of the rule. You can read more about that rollout strategy here.
There are also dedicated services that can help you parse and understanding these summary reports, especially if you start receiving a large volume of them, but typically you can just send them to a dedicated email address and review them periodically.
Note
Email services use SPF, DKIM and DMARC, but don’t have to honor the rules you put in place – ultimately, they determine how to serve the best interest of their customers, and what heuristics they use in addition to SPF and DKIM, to determine an email’s legitimacy, what to do with those flagged messages and how to report that (if at all).
In Summary
It can seem very technical, but SPF, DKIM and DMARC records are actually pretty simple ways to help authenticate messages from your organization’s domain. If you need any help setting these records for your domain or auditing your current configuration, don’t hesitate to drop us a line.
