Nobody told me that email is this complicated

19 Oct 2025

Of late I’ve been doing some voluntary work as an administrator for a charity. It’s been a good way of keeping my hand in, and I’ve welcomed the chance to get my hands dirty and address some real world problems. Makes a change from writing essays about theology, at least.

One thing that was mentioned to me quite early on, more or less in passing, was that they’d been having an issue sending email to Gmail accounts. My ears pricked up at this; here was a technical problem that I might be able to get to grips with. I thought it might be a good idea to summarise some of my findings in case its helpful to anybody else - although none of this is exactly rocket science I did find myself having to read across several different sources before I felt like I’d fully understood it.

SPF : Sender Policy Framework.

Back in the old days of the internet, when much greater minds than my own were architecting the various communication protocols that the nascent internet would depend upon, only an extremely cautious person would have highlighted that it was relatively straightforward to spoof email message headers such that it appeared to come from somebody other than the actual sender. At a time when the only people on the internet were likely to be research scientists and suchlike, there was much less reason to doubt other people’s good intentions. Or so the thinking presumably went.

I must admit at this stage that it seems quite amazing to me that we got by without this rather elementary form of authentication of senders for so long. While the technology has been around for a couple of decades now, Gmail only started requiring it to be set up in order to handle incoming email at all.

SPF is the simplest of the three email security technologies that I’m going to discuss here. In a nutshell, when a mail server receives an email, it will check whether it originated from a source designated in public DNS records before deeming it to be authentic. For example, for a domain that uses Microsoft’s email infrastructure, the SPF TXT record would look something like this

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

Usually this information will be provided for you. If you are running your own email server (a) why? (and good luck) and (b) your knowledge is probably - hopefully- so advanced that you have no need of reading this post.

DKIM: DomainKeys Identified Mail

While SPF is better than nothing, it doesn’t offer complete protection against spoofing.¹ DKIM uses public-key cryptography to implement a further layer of authentication. In this case, the public key is again stored in a DNS record.

NAME: default._domainkey.mail.example.org VALUE: "v=DKIM1; k=rsa; p=hsfaiab2931u9din29f9nh29dn924n929n92d9n29d9dkandad092090f2f2;"

(Not a real public key. I just typed a load of gibberish at random.)

In this case, an authentic email message will contain a signature that could only have been generated by a server with access to the private key. The recipient may verify that the signature is valid by retrieving the public key from the DNS records. (I’m not going to get into the weeds of public key cryptography here. Hopefully this is a concept you’re already familiar with.)

DMARC: Domain-based Message Authentication, Reporting and Conformance

Google requires organisations who send out over five thousand emails a day to also have DMARC set up correctly. According to Cloudflare’s documentation:

“A DMARC policy determines what happens to an email after it is checked against SPF and DKIM records. An email either passes or fails SPF and DKIM. The DMARC policy determines if failure results in the email being marked as spam, getting blocked, or being delivered to its intended recipient. (Email servers may still mark emails as spam if there is no DMARC record, but DMARC provides clearer instructions on when to do so.)”

To re-iterate: it defines what a mail server should do with emails that do not pass SPF and DKIM checks. When determining DMARC policies it is wise to adopt a gradual approach - first, start with p=none - email that fails validation checks will still be transmitted to the recipient, allowing monitoring of the situation. Gradually you move towards stricter settings - only when you are entirely confident that every aspect of your email configuration is sound should you really consider adopting a p=reject policy.