Email is inherently flawed.
Email is built on trust. Yes, trust, and many hacked-together solutions, such as SPF and DKIM, are slapped on top of it. That doesn’t mean those systems are bad, though; just that they are “added on” and not a core part of email.
In the early days of email, you connected to the mail server where you wanted to deliver a message, told the server who you were and to whom to deliver the message, and then the contents of your message. That was it – you delivered an email. The astute among you may have already realized the problem and have probably experienced it yourself: spoofing.
Spoofing is when an email’s “from” header is forged to look like it came from someone it did not. We’ve all received emails addressed from us to us that we didn’t send – and that’s an example of spoofing.
Email is built on trust – trust that the sender is who they claim to be. How do you really know, though? How can you be sure that the email from your bank is really from your bank and not someone pretending to be your bank to steal your information?
SPF [Sender Policy Framework]
SPF was introduced in 2000 to combat email spoofing, a common tactic in phishing attacks. It allows the domain owner to specify which mail servers are authorized to send emails on behalf of that domain.
When the receiving mail server receives the message, it can verify that it was sent from an approved server by checking the sending mail server IP against the domain’s public SPF record.
An important note about SPF records is that the domain owner can choose to strictly allow only the servers they list to send messages or they can choose to be more relaxed and allow anyone to send messages but log the failures. This is “-all” vs “~all” at the end of the SPF records respectively.
It is essential for the domain owner to ensure that their SPF record includes all servers they send email from, especially if they use the strict “-all.”
Most phishing and spam emails are spoofed, which means they are sent from servers that the domain owner does not authorize.
DKIM [DomainKeys Identified Mail]
DKIM was introduced in 2004 to address issues that SPF couldn’t handle. SPF only validates the sending server but doesn’t verify the integrity of the email content or guarantee that the email wasn’t altered during transmission. DKIM uses cryptographic signatures to ensure the email’s content and headers remain unchanged from when it was sent. It also helps verify the sender’s domain, enhancing trust in email communications.
Why block the failures?
The simple truth is that if you don’t block the failures, both systems are entirely useless for their original purposes. Having SPF and DKIM set up can help with email deliverability to the inbox, but that is only a side effect of these systems building trust.
Blocking messages that fail SPF checks ensures that the messages you receive are from authorized sources and are not spoofed.
Blocking messages that fail DKIM protects you against messages that have been modified but also verifies that the sender had permission from the domain owner to transmit the message.
What if the sender is legitimate but sends from the wrong server?
This situation can happen for many reasons, but most often, it’s due to a misconfiguration on the sending side of things. For example, having two servers that send emails for a domain but only listing one of them in the SPF record would cause issues. The receiving side can do nothing about this beyond ignoring the failures.
If SPF and DKIM are so great, why block them now and not much earlier?
The plain truth is that we’re a small provider, and it is impossible for us to affect meaningful change in the email system at large. If we were to implement such policies before they were common and expected, our customers and those who wish to email them would see us as the problem.
Google is huge, and it can and has affected email for the masses. Google led the way by requiring valid SPF or DKIM to deliver messages to their users. This policy has forced most legitimate email senders to configure proper SPF and DKIM. Google’s user base is just too large for them to ignore, and blaming Google won’t solve the problem. *Have you ever tried calling Google?)
TL;DR
Email senders configure SPF and DKIM to control who can send messages on their domain. When SPF and DKIM failures are blocked, only messages the domain owner allows can be delivered. This blocks SPAM, phishing, and spoofed messages, helping you be sure the messages in your inbox are authentic.