Digging Deep Into Email DNS Records

Every day millions of emails are sent. I’m convinced that 90% of them are spam, but I won’t get ahead of myself. hahaha… I have had a basic understanding of MX, SPF, and DKIM records, but I recently decided to dig deep into how these records affect email transportation. It’s important to me to understand how the technology we use every day works. I want to know that the email I receive is coming from the source claimed in the email headers. Let’s start by how a source email server identifies the destination.

MX records form the backbone and foundation of Email transportation. They provide the directions for a particular domain’s email server(s). When you send an email, your email provider will identify the proper MX records for the recipient and use those directions to deliver the email. MX records are set using DNS. MX records clearly identify the destination server, however they do nothing to help identify authorized email sources.

So now we can send email from one server to another. However, how does the recipient know that they are actually receiving email from you? For example: Let’s say you receive an email from Google saying that you should click on a link to change your password. (disregard phishing email procedures). How can you know that the email you received is actually from Google? Enter SPF, DKIM, and DMARC records.

SPF records are DNS records that specify what IPv4 and IPv6 addresses can send email on your behalf. This is a great first step! As the owner of a domain, you can specify the specific services that can send email on your behalf. These services may be Google Workspace, MailChimp, or plenty of other 3rd party services that might manage or send email on your behalf. However, what if the malicious actor uses the same email services as you? How can we prove that we are the original senders of the email.

DKIM records introduce public and private key cryptography to DNS records and email headers. On the source email server, a private and public key is generated. The public key can be published as a DNS record, and the private key and some extra sauce is combined together to create email headers that can be verified using the public key. Using DKIM records, the recipient server can verify using math that an authorized email server sent this email.

Wrapping it all up is the DMARC record. DMARC records provide instructions to receiving email servers for how you would like received emails to be authenticated. You can specify that SPF and DKIM record checks must pass and what happens if they do not pass. One of the things that stood out to me the most is that you can provide an email where the SPF, DKIM, and DMARC results should be sent. This allows you as the domain owner to know the source of emails that are supposedly being sent and what email servers are receiving your emails and if these emails are passing the checks. These really help with Auditing and better understanding how your email is being received.

Overall, my deep dive into better understanding email DNS records really helped me to better understand email transport and verification and I hope this introduction helps you on your journey as well!