Elena' s AI Blog

Configuring DNS for Email

28 Sep 2026 (updated: 28 Sep 2026) / 9 minutes to read

Elena Daehnhardt

 Generated by Midjourney. Prompt: Computational peacock spreading a circuit-board tail fan.



If you click an affiliate link and subsequently make a purchase, I will earn a small commission at no additional cost (you pay nothing extra). This is important for promoting tools I like and supporting my blogging.

I thoroughly check the affiliated products' functionality and use them myself to ensure high-quality content for my readers. Thank you very much for motivating me to write.



TL;DR:
  • Email deliverability depends on correct DNS records (SPF, DKIM, DMARC) and continuous policy monitoring.

📚 This post is part of the "MLOps & Deployment" series

Series: MLOps & Deployment (Part 8 of 7)

Previous: Part 7 — Docker Compose CI/CD with GitHub Actions: A Reliable Flask Workflow

Next: Part 9 — DNS Made Easy

Introduction

Getting email to send is easy. Getting it to land in the inbox instead of spam - or not get silently dropped at all - is a DNS problem, and it is one I have got wrong more than once. This post is about the DNS side of email specifically: SPF, DKIM, and DMARC, the three records that prove a message claiming to be from your domain actually is. If you want the general A/CNAME/MX/TXT basics first, I cover those separately in DNS Made Easy; this post assumes you already have MX records pointed at a working mailbox and picks up from there.

Since February 2024, this is not optional homework anymore. Google and Yahoo now require SPF and DKIM, with DMARC alignment, for anyone sending meaningful volume to Gmail and Yahoo addresses - and “meaningful volume” for Google is roughly 5,000 messages a day to personal Gmail accounts, which a small business newsletter can hit without noticing. Get any of this wrong and your mail does not bounce with a helpful error; it just vanishes into spam folders or gets rejected outright.

MX Records: The Prerequisite

Before SPF, DKIM, or DMARC mean anything, you need MX (Mail Exchanger) records telling the internet which servers accept mail for your domain. Each MX record has a priority (lower number = tried first) and a target mail server hostname. If you are using a hosted mailbox provider - Google Workspace, Microsoft 365, Tuta, Zoho, or your registrar’s own email product - they will give you the exact MX records and any supporting CNAME records (often for POP, IMAP, or SMTP endpoints) to add at your DNS provider. Copy them exactly; a typo in an MX hostname is a silent, total mail outage, not an error message.

Where providers differ is in the specifics: GoDaddy Workspace Email, for instance, publishes its own MX and CNAME values in its help documentation, and Tuta’s custom-domain guide walks through pointing MX records at their infrastructure. Whichever provider you use, the pattern is the same: get their exact records, add them at your DNS host, and give DNS propagation time (see the validation section in DNS Made Easy) before you assume something is broken.

With mail actually arriving, the real subject of this post starts: proving it is not being spoofed.

Spam Filters and Email Authentication

Spam filters do not just look at content. They check whether the sending server was actually authorised to send as your domain, using three DNS-based mechanisms:

  • SPF (Sender Policy Framework) - lists which mail servers may send for your domain.
  • DKIM (DomainKeys Identified Mail) - cryptographically signs outgoing mail so receivers can verify it was not altered in transit and did originate from a server holding your private key.
  • DMARC (Domain-based Message Authentication, Reporting and Conformance) - tells receivers what to do when SPF or DKIM fail, and where to send reports about it.

All three publish as DNS TXT records. None of them work well alone; DMARC in particular depends on SPF and/or DKIM already being in place and aligned with your visible From address.

SPF

An SPF record is a single TXT record at your domain’s root listing authorised senders:

v=spf1 include:_spf.google.com include:mailgun.org ~all

Every service that sends mail on your behalf - your mailbox provider, your newsletter tool, your CRM - needs an include: entry here, or its mail will fail SPF. You can only have one SPF record per domain; if you use several senders, merge them into one v=spf1 ... string rather than publishing two records. End with ~all (soft fail - flag but do not reject) while you are testing, and consider -all (hard fail) only once you are confident every legitimate sender is listed.

DKIM

DKIM works differently: instead of one record, each sending service gives you a selector-specific public key to publish, typically as:

selector1._domainkey.yourdomain.com   TXT   "v=DKIM1; k=rsa; p=<public key>"

The selector1 part is provider-defined (Google, Microsoft, and your newsletter tool will each use their own selector and give you the exact record to publish). The corresponding private key stays with the sending service and signs every outgoing message; receivers fetch your public key from DNS to verify the signature. You enable DKIM signing in your mail provider’s admin console first - they generate the keypair - then publish the record they give you.

DMARC

DMARC ties SPF and DKIM together with a policy. A starting record looks like:

_dmarc.yourdomain.com   TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

p=none means “just tell me what’s happening, do not act on it yet” - this is the correct starting point for everyone, not a shortcut. Watch the aggregate reports that arrive at the rua address for a couple of weeks, confirm every legitimate sender passes SPF or DKIM in alignment with your visible domain, then tighten the policy:

p=quarantine   # send failures to spam
p=reject       # refuse failures outright

Jumping straight to p=reject before you have watched the reports is how you silently lose your own legitimate mail. I would not do that on a first pass, and I would not recommend it to you either.

The Google and Yahoo Bulk Sender Rules

Since February 2024, Google and Yahoo enforce this properly rather than treating it as best practice. If you send close to 5,000 messages or more in 24 hours to personal Gmail addresses (Yahoo has no published threshold but applies similar scrutiny), you are classified as a bulk sender and must have:

  • SPF and DKIM both configured (not either/or, as was previously tolerated).
  • A DMARC record at p=none or stronger for your sending domain.
  • SPF or DKIM passing in alignment with your visible From domain.
  • A one-click unsubscribe header (List-Unsubscribe) on marketing mail.
  • A spam complaint rate kept under 0.3%, ideally under 0.1%.

Even if you are not sending bulk volume, Google and Yahoo now expect all senders to have at least SPF or DKIM configured - the days of “small sender, nobody checks” are over. If your DMARC policy has sat at p=none since 2024 with nobody reading the reports, that is worth revisiting: the enforcement bar keeps rising, and “started monitoring, never finished” is functionally the same as never having done it.

Conclusion

SPF, DKIM, and DMARC are not three unrelated acronyms to tick off - they are one system, and each one only works properly once the others are in place. Get MX right first, add SPF for every legitimate sender, turn on DKIM signing with your provider, then bring DMARC in gently at p=none and read the reports before you tighten anything. Rushed DMARC enforcement is the single fastest way to make your own email vanish, which is a strange kind of self-inflicted problem to have.

Did you like this post? Please let me know if you have any comments or suggestions.

AI-generated art and music/sound posts that might be interesting for you




References

  1. RFC 7208 - Sender Policy Framework (SPF)
  2. dmarc.org - DMARC Overview
  3. Google: Email sender guidelines
  4. Tuta: setting up a custom email domain
  5. GoDaddy: set up forwarding / workspace email

Related tools you may want to try next.

B12.io Recently, I have found an AI-powered platform that enables you to create professional websites, pages, posts, and emails with ease. I will also give it a try and soon write a new post about B12.io (I am working on my coding post at the moment :).

Make provides a visual automation platform to connect apps, APIs, and AI services without writing code.

Deliverability Verification Steps

  1. Publish SPF with minimal include scope.
  2. Enable DKIM signing and test alignment.
  3. Start DMARC with p=none, then tighten policy.
  4. Monitor aggregate reports for anomalies.
  5. Re-test after provider or domain changes.
desktop bg dark

About Elena

Elena, a PhD in Computer Science, simplifies AI concepts and helps you use machine learning.

Citation
Elena Daehnhardt. (2026) 'Configuring DNS for Email', daehnhardt.com, 28 September 2026. Available at: https://daehnhardt.com/blog/2026/09/28/email-dns/
All Posts
Copyright © Elena Daehnhardt
Privacy and Terms