In this rather propeller beanie episode of Chit Chat Across the Pond, Bart Busschots explains how to configure your DNS records on your server to ensure you can send email from your domain. Like I said, it’s nerdy, but we know a fair number of NosillaCastaways host their own servers and will enjoy learning how all of this works. Or maybe it’s just that I really wanted to understand more about MX Records and such, so it was fun for me!

This episode also has a full written explanation written by Bart, so you’ll have it as a reference when you’re done listening.

Read an unedited, auto-generated transcript with chapter marks: CCATP_2025_12_30

Setting the Scene

One of the things I’ve advised many times on the NosillaCast over the years is owning your own domain as a means of ensuring you have a permanent email address. When you own your own domain, you can bring that with you from provider to provider as your needs and the offerings change over the years.

For the most part, this is quite a simple proposition:

You pay a domain registrar and an annual fee to retain ownership of your domain
You host your DNS records somewhere online, usually with your domain registrar
You procure an email service from a provider.

When it comes to registering your domain, there are more providers than you can shake a proverbial stick at. For example, Allison’s podfeet.com domain is registered with GoDaddy, and my bartbusschots.ie domain is registered with Hosting Ireland.

What does it really mean to own a domain? At a practical level, it means you get the ability to specify DNS servers that will publish the authoritative DNS records for the domain. What you’re doing under the hood is specifying the DNS Name Server, or NS, records for your domain.

In theory, you could run your own DNS servers, but in practice, you’re going to make use of a provider’s DNS servers. Every registrar I have ever used provides the option to use their DNS servers via a web control panel at no extra charge (beyond the annual fee for the domain registration). Sometimes that works out great. For example, Hosting Ireland has a really nice control panel, but sometimes you get what you pay for!

If you host your own website (not a requirement for hosting a domain), you have more options. Many hosting companies and cloud providers also include the option to use their DNS servers and control panel for free with your website or virtual server. For example, Digital Ocean, the cloud provider both myself and Allison use for our servers, offer a great DNS service with a very human-friendly control panel, and CloudFlare offer the best DNS service I’ve ever used to all their users, even those on the free tier!

Both bartbusschots.ie & podfeet.com use CloudFlare as their authoritative DNS servers.

Once you own your domain and have it configured to point to a DNS server of your choice, you can attach an email service to your domain by running your own mail server (a bad idea for almost everyone), or by buying one from a cloud provider of your choice. Whatever email service you procure, your provider will give you instructions for configuring a DNS Mail Exchanger, or MX, record. This record directs email sending servers to the correct incoming mail server for mail addressed to your domain.

I’m currently using the enterprise version of Office365 from Microsoft for emails to any @bartbusschots.ie address, and Allison is currently using iCloud+ from Apple for emails to@podfeet.com.

Once your MX record is configured, you can start receiving emails on your domain. At a technological level, you can start sending emails from your domain the moment you create your account with your provider, even before you’ve configured any DNS records. But only theoretically. If you want your emails to arrive in people’s inboxes rather than their spam folders, you have a little more work to do!

Bonus Extra — Domain Registration, DNS & MX Commands

BART: I think we should have the output of these if we’re going to say “you’ll notice…”

Mac and Linux users can quickly and easily determine the registrar for any domain name with terminal commands of the form:

whois bartbusschots.ie | grep Registrar

returns:

Registrar WHOIS Server: whois.weare.ie
Registrar URL: http://www.hostingireland.ie
Registrar: Hosting Ireland/ Team Blue Internet Services IE Ltd
Registrar IANA ID: not applicable
Registrar Abuse Contact Email: [email protected]
Registrar Abuse Contact Phone: +353.19020020

You can also determine the DNS servers authorised to publish DNS records for any domain with commands of the form:

dig +short bartbusschots.ie NS

which returns:

aaron.ns.cloudflare.com.
savanna.ns.cloudflare.com.

And finally, you can determine the email server or servers receiving email for any domain with commands of the form:

dig +short bartbusschots.ie MX

which returns:

0 bartbusschots-ie.mail.protection.outlook.com.

You’ll notice the mail server or servers returned by this command are pre-fixed with a number. This is the server’s priority; if there are multiple MX records, a sending email server tries the listed servers in the order determined by their priority, lowest first. If there are multiple servers listed with the same priority, the sending mail server gets to choose the order.

The Problem to be Solved

Even though it was first released in 1982, the Simple Mail Transfer Protocol, or SMTP, is still the protocol used to send emails today. 1982 was a much more innocent time, so by today’s standards, SMTP is hopelessly naive! The SMTP protocol was designed with the implicit assumption that all mail servers would be well-intentioned and play by the rules. How quaint!

The fundamental problem is that SMTP doesn’t provide any kind of mechanism for validating the address an email appears to be from! You can use the SMTP protocol to send emails appearing to be from any address you like. When I taught CS230, I always took great joy in demonstrating this fact, sending the students emails from [email protected] 🙂

As far as SMTP is concerned, the sender addresses on emails are no different to the reply addresses on postcards. If everyone sending postcards is honest, they’re meaningful; otherwise, they’re meaningless!

SMTP worked fine for a few years, until some entrepreneurial geek somewhere realised you could abuse SMTP to flood people with unwanted email, birthing the scourge of spam!

Initially, mail providers tried to fight spam with simple techniques like rate limiting sending IPs, or block-listing IPs known to send a lot of spam, but as the cat-and-mouse game escalated, it soon became clear we needed a real fix. We needed to layer some kind of email sender validation on top of SMTP so we could meaningfully differentiate between emails really from bartbusschots.ie and emails just pretending to be!

Today, emails arriving at the major providers without valid sender validation are almost certain to get delivered to users’ spam folders, or worse, get quarantined or even outright rejected!

If you want to be able to reliably send emails from your own domain in 2025, you absolutely need to configure email sender validation on your domain.

Why Have One Standard When You Can Have Three‽

Since SMTP doesn’t provide a mechanism for authenticating email senders, some other mechanism needed to be layered on top of it. For various reasons, we didn’t end up with one mechanism for authenticating emails, but two — the Sender Policy Framework, or SPF, and DomainKeys Identified Mail, or DKIM.

Often, when two technologies emerge to solve the same problem, one eventually gains dominance, and the other fades away into irrelevance, but that didn’t happen with SPF and DKIM. Why? Because while they do both solve the same problem, email authentication, they solve it in completely different ways. This means that neither is universally better, but for some people, SPF is the obvious best choice, while for others, DKIM is.

Both because neither SPF nor DKIM won out, and because neither actually proved to provide adequate functionality for really big senders, a third protocol was layered across the top to tie it all together and to fill the gaps neither SPF nor DKIM can. That’s how we got the clumsily named Domain-based Message Authentication, Reporting & Conformance protocol, or DMARC.

In practice, what this all means is that those of us who own our own domains need to be sure our domains have at least valid DMARC and SPF records, and perhaps, some DKIM records too.

Let’s dive a little deeper into all three, starting with the oldest and the simplest, SPF, and ending with the newest and the one most often overlooked, DMARC. We will explore DKIM a little, but since it’s the least relevant of the three for home users, we won’t get too far into the weeds on that one.

Understanding the Sender Policy Framework (SPF)

One reason SPF hasn’t fallen out of favour is its elegant simplicity. By definition, domain owners control the DNS records on their domain, so the simplest way to advertise to the world which servers are legitimately authorised to send emails from your domain is with a DNS record that lists them!

That really is all SPF is — an allow-list of authorised mail senders. Because the list has to be machine-readable, there needs to be a defined structure to the records, but they’re really quite human-readable, especially when you’ve taken a few minutes to learn the basics.

Firstly, SPF records are DNS text, or TXT, records, and they apply only to the domain name they are set on. If your organisation is big enough to send email from multiple sub-domains, you’ll need an SPF record on each.

The structure of the record is quite simple — the string v=spf1 followed by a space-delimited list of so-called mechanisms, each optionally prefixed by a so-called qualifier. The mechanisms are different ways of specifying valid mail sending servers, and the qualifiers tell receiving servers how to treat emails originating from that source.

We’ll look at the mechanisms in a moment, but let’s start with the qualifiers.

The default qualifier is +, which means the source is authorised to send emails from the domain. This means that when you list a mechanism without a qualifier, you’re authorising it. The opposite qualifier is -, which marks emails arriving from that sender as unauthorised. You usually only see this qualifier applied to the all mechanism, which acts as a catch-all for all other mechanisms and should always appear as the last mechanism in a record.

There are two other, less-used qualifiers. ? indicates a neutral policy, or that you explicitly have no policy for that source. Have I have never seen the ? qualifier used in the real world. Finally, there’s ~ to indicate a so-called soft fail. I think of it as meaning probably not authorised, and ~all can be used while large organisations are in the process of rolling out SPF and they’re not quite sure they’ve authorised absolutely all their servers that send emails. It’s shocking how much shadow IT exists in many organisations!

Before we look at some of the other available mechanisms, I want to make it clear that these days you really should always end your SPF record with -all!

I won’t list all the supported mechanisms, but the most common ones are:

Mechanism	Examples	Description
`mx` or `mx:<domain>`	`mx`, `mx:some.domain.com`	Authorise email to be sent from the server(s) listed in the domain’s `MX` DNS record(s), or in another domain’s `MX`record(s).
`a`		Authorise email to be sent from the server(s) listed in the domain’s primary DNS record (the `A` and/or `AAAA` records).
`dns:<domain>`	`dns:smtp.mydomain.com`	Authorise email to be sent from the server(s) listed in the DNS record for the specified domain.
`ip4:<ip>`	`ip4:123.321.45`.6	Authorise a specific IPv4 address to send emails. (There is also `ip6:<ip>` for IPv6 addresses)
`include:<domain>`	`include:icloud.com`	Delegate to another domain’s SPF record — if the sender would pass the specified domain’s SPF record, then it passes.

There are a few things to note here.

Firstly, unless you run your own email server, you need to add an include mechanism to your SPF record to delegate authorization for your domain to your provider’s SPF record.

Secondly, records designed to be included in other records generally do end in ~all, and there’s a good reason for that — modifier precedence. If your domain’s SPF record ends with ~all because you’re still rolling out SPF, and you include a domain whose SPF record ends with -all, it’s that stricter -all that wins, making it impossible for you to test SPF on your domain. But, when the included domain ends with ~all, and your record also ends with ~all, you do actually get the soft fail you specified, and when you update your domain’s record to -all because you’re ready to really enforce SPF, your -all will win. This means that when you include a record that ends with ~all, you remain in ultimate control.

Thirdly, if you run your own mail server, you probably send and receive email through the same server; that’s why a lot of personal domains include the mx mechanism in their SPF records.

Finally, if you run your own web server, you do not proxy it through a content delivery network (CDN) or a web application firewall (WAF), and you want to authorise it to send email, you should include the a mechanism in your SPF record. If you do use a CDN and/or a WAF (like Cloudflare), you’ll need to add one or more ip4 and/or ip6 mechanisms to your SPF record to authorise your actual server’s IP(s) because your DNS A and AAAA records point at your CDN/WAF rather than your actual server!

SPF Examples

What better real-world examples than our own domains 🙂

The SPF record on bartbusschots.ie is the simplest, so let’s start there:

v=spf1 include:spf.protection.outlook.com -all

I only want email to be allowed to come from my Office365 subscription, so I simply delegate to Microsoft’s SPF record and enforce a hard-fail on all other email sources with my own trailing -all.

The SPF record on podfeet.com is a little more interesting:

v=spf1 mx ip4:143.244.187.43 include:icloud.com -all

Allison allows the mail server specified in her MX record to send email, as well as the web server that actually hosts podfeet.com, then she delegates to Apple before also enforcing a hard fail on all other sources.

Note that because podfeet.com is proxied through Cloudflare, Allison couldn’t authorise the mail server with a simple a, she has to specify the server’s actual IP address with ip:143.244.187.43.

Bonus Extra — SPF Commands

You can use terminal commands of the following form to view any domain’s SPF record:

dig +short podfeet.com TXT | grep v=spf

Shallow-Diving into DomainKey Identified Mail (DKIM)

DKIM is more modern than SPF, so it shouldn’t be surprising that it’s also more powerful and more complicated. In fact, it’s so complicated that it’s generally only used in enterprise environments, or by Software-as-a-Service (SaaS) providers that need to send emails as part of the service they offer. Given that reality, we’re just going to describe what DKIM does in a broad sense, without diving into too many details.

As we’ve seen, SPF is built on the assumption that a domain will only have a few authorised mail servers and that they won’t change very often. This is usually a valid assumption for a person, a small organisation, and even the primary email infrastructure for large enterprises, but it’s not true for Softare-as-a-Services offering. By definition, SaaS services are delivered from the cloud, so constantly changing server IPs is the norm rather than the exception. This makes SPF a really bad fit for SaaS offerings.

This is why DKIM exists, and why it has endured. SPF thinks at the server level, but DKIM works at the level of individual emails. Rather than allow-listing servers, DKIM digitaly signs every email using a private key published via DNS records on the authorising domain.

This means the SaaS provider generates a public-private key pair, keeps the private key, and requires the domain owner to publish the public key. Every DKIM-authorised email contains mail headers specifying the email’s digital signature, and the domain and key identifier. Because any domain can authorise any number of SaaD providers, you can add arbitrarily many DKIM DNS records to a domain.

This means the DKIM doesn’t specify a single record as the SPF spec does, but a naming convention:

<key_name>._domainkey.<domain>

For example, if Bartificer Creations were to start writing commercial software, I might deploy the corporate version of MailChimp to send out emails on my behalf with a sender address on bartificer.ie, and I might also deploy the corporate version of SurveyMonkey to request customer feedback, again configured to send emails from bartificer.ie. Both of those providers would then give me the details for their server’s DKIM configuration, and I would publish those details in a pair of DNS records named something like mailchimp._domainkey.bartificer.ie and surveymonkey._domainkey.bartificer.ie.

For the people operating a mail server, DKIM is complex to deploy, but as a customer of some kind of SaaS offering, it’s usually as simple as adding one ._domainkey DNS record to your domain, and your provider will give you the exact details that are needed. In fact, they’ll usually ask you to delegate to their DNS server using a DNS CNAME record so they can isolate you from the ongoing technical minutia like periodic key rotations.

One Protocol to Bind Them All (DMARC)

The newest and most capable protocol of them all is the cryptically named Domain-based Message Authentication, Reporting & Conformance, which everyone just calls DMARC 🙂

DMARC lets domain owners define policies for how receiving mail servers should treat incoming emails purporting to be from their domain when those emails don’t pass SPF or DKIM. That’s DMARC’s primary function, but it also lets domain owners request aggregated reports from receiving mail servers with statistics about the emails they’ve received claiming to be from the domain. This reporting feature is invaluable for large organisations where there could be hundreds of legitimate email sources, some of which will inevitably be misconfigured some of the time. If you’re a big multinational company, you’d rather find out your Peruvian branch office has their DKIM misconfigured via an automated report from Gmail than from cranky customers complaining important emails are not arriving or getting junked!

Enabling reporting unleashes a torrent of data, so don’t do it unless you’re subscribed to some kind of DMARC monitoring service configured to receive and process those reports on your behalf! You can have the reports go to any email address, but trust me, you don’t want to!

Like DKIM, DMARC is very powerful, so there are lots and lots of little nuances. We’re going to ignore all that and say that if you own your own domain, you should publish the following boiler-plate DMARC record:

v=DMARC1; p=reject; adkim=s; aspf=s;

This tells receiving mail servers to reject all email from your domain that does not pass SPF or DKIM.

Bonus Extra — DMARC Commands

You can use terminal commands of the following form to view any domain’s DMARC record:

dig +short _dmarc.podfeet.com TXT

Bonus Extra — Free SPF & DMARC Tools

If you want to quickly check your domain’s email validation health, I’ve not found anything better than MXToolbox’s free checker — mxtoolbox.com/….

If you’re looking for a helping hand building your SPF record, their free SPF builder tool works well too — mxtoolbox.com/….

Finally, if you really need a more complicated DMARC record than the boilerplate above, they even have a nice free DMARC builder — mxtoolbox.com/….

Final Thoughts

If you have your own domain for email, make absolutely sure you have your SPF record properly configured, and that you have the boilerplate DMARC record in place. Unless one of your providers spoon-feeds you a DKIM record, don’t worry about DKIM; you don’t need it.

CCATP #827 — Bart Busschots on Understanding Email Sender Validation