Email can feel like a constant battle. Let's forget about how much of it there is for a moment. The world is so focused on how to avoid spam and phishing attempts it is easy to forget there is an opposite side to the email coin. What if you are a business leader? How do you ensure that the emails you are legitimately sending on behalf of your organization don't simply get tossed in with the rest of the garbage and incorrectly labeled as spam or suspicious?

What follows is a summary of the three most important tools that will help ensure the deliverability of your legitimate email. This is not a "how to" guide. Although, much of that information is available in the linked headers for each section. Rather, this is an overview of the information that can be included in your domain record (your DNS record) to help provide for the maximum acceptance of your emails for your intended audience.

SPF - Sender Policy Framework

This is a list of resources in your DNS Record that are allowed to legitimately send email using the @yourdomain.com domain. It would include:

• Your email service provider (Google, Outlook, ProtonMail, etc).
• The IP of your website server so that your website can send emails for anything like based contact forms, password reset requests, or other site features.
• Third party vendors like e-newsletter companies, donation tools, or ticketing services that might send emails on your behalf using a "from" @yourdomain.com email address.

DKIM - DomainKeys Identified Mail

DKIM sends an encrypted key in the header of every email that is sent from an @yourdomain.com email address. When the recipient gets the email, the hidden key is compared with the record in your DNS to see if the public key in the email works with the private key on your email server. If the keys work together the email is "authentic" and the recipient knows with confidence that it came from your organization. Unlike SPF, this matching of keys survives for forwarded emails. So it is an extra layer of proof that the email coming from you is legitimate. Anyone trying to spoof an email from you will not have a matching key in the header of their email making it look more suspicious to the recipient's email provider.

Of course email end users don't know how to match keys and authenticate emails. All that is handled by their email providers. This is why emails sent with a good SPF record and DKIM authentication are very unlikely to get flagged as spam or rejected outright. The email provider is basically assessing on every email which ones look the most legit and then passing them along, informing the end user of anything suspicious, or simply filtering the emails that look super sketchy.

That leads us to...

DMARC - Domain-based Message Authentication, Reporting & Conformance

DMARC is not necessarily required [updated February 14, 2024] for good email deliverability. It does provide two things over and above SPF and DKIM that can completely maximize your control over how recipients handle emails sent from your domain. [New information as of February 14, 2024 - Everything below is still an accurate description of how DMARC works but major email vendors are now rejecting emails coming from domains without a good DMARC dns record. You can avoid all the reporting provided below by simply creating a TXT record for "_DMARC" with a value of "v=DMARC1; p=none; fo=1"]

DMARC tells your email recipients what to do if an email from your domain does not pass both SPF and DKIM. ("accept" the email anyway, "reject" the email, or "quarantine" it as spam or suspicious).

DMARC provides you with a daily emailed report of what messages are recommended for quarantine or rejection. All fully verified "authentic" emails are simply sent to the recipient. The report allows you to assess whether there are any problems with your SPF Record or DKIM. Let's say there is a legitimate third party service that you forgot to include in your SPF. Your DMARC report would likely show that people getting emails from that service are either having them quarantined or rejected. That would be an important signal to review your SPF Record to find out what is wrong. You would find that you forgot to include the service in the record and update it.

Initially we always set DMARC to "none" that means you are recommending that all emails coming from your domain be accepted as legit but you want a report of anything that fails either SPF or DKIM. This report of failures allows you to identify and correct any issues with SPF and DKIM.

Once you are confident that everything is working well and you are not getting reports of legit emails failing you increase DMARC settings from "none" to "quarantine". This is telling recipient email servers to label as "spam" or "suspicious" emails that don't pass all the rules in SPF and DKIM.

Finally, when you have several months of confidence that SPF and DKIM are working fully as expected you can more safely update your DMARC to tell recipients to "reject" all email that does not pass both systems. The only thing that should show up in the email reports at this point are emails that are not coming from sources that legitimately represent your organization.

From this point forward you have to be careful about making sure your SPF and DKIM records accurately reflect the legitimate sources of email for your organization. If you add a new service that is sending email from your domain it MUST be included in your records or the emails it sends for you will be rejected by the emails services of your intended audience.