I had a task this week at work to see what could be contributing to our email series being sent to spam within Microsoft email products. This would be my first exposure to SPF, DKIM, and DMARC. At first, it was, as most tech-related heavy-acronym things are, confusing. I started with an article a colleague shared from Microsoft, Strengthening Email Ecosystem: Outlook’s New Requirements for High‐Volume Senders. Next, I logged into our Cloudflare account and started to dig into our DNS.
I don’t know about you, but DNS records are, at first, second, and seventeenth glance, a large party of letters scattered about. I mean, not really, but that is what it feels like. So persistence and yes, a good conversation with ChatGPT can help one cut through what on earth we, as web developers, must foray into if we would like to get a handle on such topics.
I started with our SPF record, which is typically one TXT entry starting with “v=spf1” in your DNS. Pretty quickly, I found an old reference to a previous hosting domain within the TXT file. That felt like a win—I may not understand this completely at this point, but look, here is something I do understand and can delete. As I progressed in my conversation with ChatGPT, it became obvious that the SPF records are a permission list of what services can send email on your domain’s behalf. Another win because I became familiar with who we send emails from, like our Google Workspace and Mailchimp, among others. So slowly, I understood the SPF records.
Next up were the DKIM records, which are also typically TXT records in your DNS starting with “v=DKIM1;” but I did find a CNAME record too. These serve as public-private key pairs between the services listed in your SPF records and your DNS. The public keys are saved in each TXT record. The private keys will be in your service provider’s account. When you are setting up your DKIM records, if you don’t have access to your Google Workspace or another email sender’s settings, contact your organization’s admin so you can either get access or have the admin set these up for you.
Together, SPF and DKIM help to harden your domain’s email sending reputation. You will want to validate that all of your sending services are represented and that no one is spoofing your domain to send email.
The last configuration, DMARC, helps you to validate and enforce your setup. DMARC is represented in your DNS by, yup, you guessed it, another TXT file starting with “v=DMARC1;”. This entry should tie to a service like dmarcian.com or Cloudflare, where you can see reporting about email volume and sources sending email on your behalf. It also sets a policy to let email services know how to handle email that does not adhere to your SPF and DKIM records.
You will want to start out with your DMARC policy set to none (p=none) as this denotes that reports are being compiled. Once you have the reporting phase complete and you have validated that all of your emails being sent are properly represented in your SPF and DKIM records, you can increase your policy to the next level, “quarantine,” and after more time assessing your reports you can level up the policy to “reject”. The policy will tell email services receiving your email how to handle unverified senders.
It is key to understand what entities are sending email on your domains behalf, attribute those services properly via SPF and DKIM records on your domain and lastly have insights into what is happening out there on the internet when it comes to who is sending email as you and what to do about it if someone or something is not, indeed, you so your excellent email marketing and education efforts land properly in recipients inboxes.
Happy coding and configuration!
Other helpful resources:
- Tackling Email Spoofing and Phishing
- Cloudflare Docs – Cloudflare DMARC Management