Learn about email authentication and how you can improve your email deliverability with any ESP.
Since the birth of email, Email Service Providers (ESPs) have tried to weed out the bad emails from the good to protect their users from spam and fraudulent scams. (Also maybe to convince companies to buy advertising instead of emailing their users for free).
Whatever the motivation, it’s in your best interest as marketers for your email to be categorized as “good.” In this blog post, we’ll share some important background context and a few tips on how to effectively navigate ESPs to ensure your emails are delivered.
Email Authentication
Email authentication is an automated process ESPs use to prove an email is sent by a legitimate sender instead of a scammer. This actually benefits your organization as much as your contacts. Knock on wood, imagine a scenario where scammers try to trick your contacts into opening a phishing email by sending it from your email address. This would be a blow to your brand reputation as well as a security risk for all your contacts. Email authentication was developed to combat this type of situation.
Fortunately, email authentication is also completely in your control and can be configured within your organization. You just need to know what to do. Which means, if you don’t have these settings configured properly, you could encounter deliverability issues that are completely avoidable.
Email authentication relies on three very important records which are connected to the DNS settings of your web domain address: SPF, DKIM and DMARC.
SPF: The Sender Policy Framework (SPF) is a record in your hosting DNS that specifies the IPs and domains that are allowed to send email on behalf of an organization. If an email isn’t sent from that domain, then ESPs will block it as a security risk.
DKIM: Domainkeys Identified Mail (DKIM) is a public key associated with your DNS record that can be attached to your emails to prove that an email was sent from the right organization.
DMARC: Domain-based Message Authentication Reporting & Conformance (DMARC) is a security protocol that uses SPF and DKIM to authenticate emails and also report on the status of your emails. DMARC reports can help you track your domain health and identify security and deliverability risks. It also ensures that the sending domain, bounceback domain (return-path), and DKIM signing domain match. So someone can’t impersonate your organization.
ESPs authenticate your emails by checking that these records align and you can opt to receive regular DMARC reports to evaluate the emails that didn’t pass authentication. You could encounter real examples of impersonation and scams. You could also encounter examples of genuine emails that should be delivered but aren’t properly configured. The more complete your configuration, the more likely suspicious emails will actually be security threats (true positives) instead of simply mis-configured communication that should actually be delivered (false positives).
As you become more confident in your configuration, which you can confirm by analyzing your regular DMARC reports, you can establish a DMARC policy that tells ESPs what they should do with suspicious emails. There are three DMARC policies to choose from:
None: you don’t want the ESP to do anything with suspicious emails. This is a good default setting to use when you’re first configuring your email authentication, giving you the time and space to analyze DMARC reports.
Quarantine: You are mostly configured and, based on your analysis of the DMARC reports, you are fairly confident that these suspicious emails should be quarantined or go to spam.
Reject: You are fully configured and the likelihood is very low that any genuine email from your organization would somehow get flagged as suspicious.
Infrastructure To Do List
Armed with this background context, you can take action to ensure your email infrastructure is properly configured to pass email authentication. These action items are the most basic foundation of your configuration
If you don’t have at least one static IP, you should get one. Shared IP ranges are bad because they mean shared reputation. If a bad actor is using the same IP address, ESPs will penalize you for something you can’t control. If you have custom routing for multiple IPs, consider what content you will be sending over each IP.
Remember if you opt to get a static IP, you should go through a proper IP warming process so you don’t get blocked by ESPs.
Separate your email marketing from your primary business email. Either via a subdomain or as a separate domain.
Align from addresses with bounceback addresses. This will ensure DMARC alignment policy is satisfied. If this isn’t possible, DMARC will still pass if you have a properly configured SPF record.
Curate/clean up your SPF records to make sure there’s no associations with systems you are no longer using. Otherwise, if you have more than 10 SPF associations, your configuration will be more complex.
Set up DKIM (if you have a static IP and are on Eloqua, other MAPs may allow DKIM on a shared range).
Set up DMARC (plan on rolling out over several weeks and plan ahead). The final DMARC policy state needs to be set to at least quarantine. A reject policy is the gold standard for DMARC. Many organizations that have DMARC configured have not moved beyond a policy of none.
Want to see the full range of Motiva’s capabilities? Schedule your demo below!
