Does DKIM alone not solve the spam issue? Why do I need SPF?

Question

FINAL EDIT : I was completely wrong about DKIM it seems, the signing domain does not have to be the same as the sender domain, thus the whole premise for my question is flawed. A lot of thanks to Paul for pointing out my mistake!

Original Question below:

I have tried reading up on both SPF and DKIM, but I do not understand the point of using both at the same time, at least in the context of fighting spam (forged sender addresses, which can result in my email server/domain becoming blacklisted). As far as I can understand DKIM alone should do the job the SPF is supposed to do.

My understanding so far is the following:

1. When sending an email the sender can claim anything they want (e.g. fake sender address)
2. DKIM allows to detect a fake sender email address, because you can verify the DKIM signature against the public key in the DNS TXT record.
3. SPF allows you to verify that the email was sent from a mail server that is authorized to send emails for a given sender address.

The thing that I do not understand is this: Unless the DKIM private key has become compromised in some way, the DKIM verification alone should be sufficient to verify that the email was sent from an authorized email server, because otherwise the email server would not have the private key to sign the email.

I have seen the answer to a very similar question here: https://serverfault.com/a/780248/154775, in it the author claims that DKIM cannot prevent replay attacks. I will concede that point, but I find that to be very much a corner case, the by far biggest issue in my opinion is spam with fake sender addresses - DKIM should prevent that easily on its own.

Is there a scenario beyond replay attacks where SPF provides additional protection compared to only DKIM?

EDIT : I have marked the core of my question in bold to clarify what exactly I want an answer to.

Answer 1

With DKIM only, there is no way for a receiving server to know where to find the DKIM key for your domain because the signature of the email is what includes the selector DNS record location, which is assigned by each mail server admin. So mail servers receiving emails from other servers will not be able to use this for evaluating a message.

If you have example.com and have configured DKIM and nothing else, and I send an email from my server, which is example.net, but my server otherwise "spoofs" the email to be from example.com, and I have configured a DKIM record for example.net, the email will pass DKIM tests and receiving servers would have a harder time determining the message is not from a server approved by the owners of example.com. This is because the DKIM test is performed using the sending server records to verify email integrity, nothing else.

The verification is performed using information in the email signature. In other words, the beginning of the DKIM test is the email, itself, which includes the location of the DKIM public key for the sending server. The DKIM standard is only for validating the email integrity sent by a server, so the domain of the server does not need to have anything to do with other header information, such as smtp.mailfrom. That is why I can "spoof" example.com and pass a DKIM test using the key for example.net

This is why everyone here is stating that DKIM serves the purpose only of message integrity, not approved sender validation. DKIM may only be used as a "proof of work" in regards to spam prevention unless used alongside DMARC with SPF configured because nobody knows where the key is located for your domain.

Answer 2

SPF and DKIM are protecting different things altogether: SPF protects the envelope sender whereas DKIM protects the integrity and authenticity of email headers and body. Furthermore, DKIM can only validate an existing signature, but does not have a method to tell whether a message without a signature should be accepted or not. Therefore, also DMARC is required in addition to both SPF and DKIM.

Also, none of these methods are for fighting the spam issue, but against email forgeries. Keep in mind that spammers can and do set them up as well. But without DMARC, DKIM and SPF they are free to use your domain for their purposes.

Answer 3

I think one of the reasons this is hard to satisfactorily answer, is because your core argument seems to be based on a theoretical ideal situation, not on the real world.

In principle, is DKIM not enough? Yes, sure, if your DKIM always works and no mail server ever rewrites your mail in a way that breaks your DKIM signature, if you don't care about anyone resending your emails, and if every one of your potential recipients also implement DKIM verification, then DKIM would, in principle, be enough for you. (You'd probably still need to add a DMARC policy to make the recipient reject mails that don't have a DKIM signature at all, though.)

But then, do people still need to care about SPF? Yes, for practical reasons, they do. SPF and DKIM are largely independent standards, but SPF was always easier to implement than DKIM, and many administrators seem to be happy with just using that. So there's still not quite universal coverage for DKIM. Thus, if your mailserver doesn't have SPF records, then chances are higher that someone can spam recipients that only have SPF by spoofing your domain. And thus, chances will also be higher that your own legitimate mails could get flagged as spam by these same recipients.

Answer 4

While the answer from Esa Jokinen is right, I find the language confusing.

Put simply:

• SPF checks the mail arrived at your server directly from particular agreed authorised mail server(s) or mail relays.
• DKIM checks that the mail was initially sent from a server with the correct key at some point and nobody played with the message body, whether it is a resend or not and where the message was received by your server from is anyone’s guess.

DKIM is cryptographic pass/fail and if a signature is added to the content by a mail server can break it (and it could be as innocent as a server or relay adding additional carriage returns), there’s various toggles for simple vs relaxed (to cover common modifications), where some modifications are permissible but at the expense of weakening the protection. Overall I find DKIM too complex and too easy for mail to accidentally get lost.

SPF I think is fairly easy to setup in comparison and requires less debugging so long as you don’t change your mail servers’ addresses often. You can also specify to treat not listed servers with more caution in SPF (a “soft fail”) which will give further credibility to those matching the list without penalising those that don’t too harshly.

DKIM is easy to get wrong. I have received quite a few legitimate e-mails that have made it into my spam folder as the DKIM hasn’t verified correctly (as shown in the headers and log by my mail server). It does however lend further credibility to your messages.

On balance DKIM could be useful where you have no idea what your mail server relay addresses are and/or they change frequently and you just want to give the signing key to an application on a host somewhere to send mail from your domain address on your behalf.

Spam checking servers which assign points and thresholds to work out spam/not spam will typically award additional points to a message that passes both SPF and DKIM. Literally you get bonus points for doing both.

See also: SPF vs. DKIM - The exact use cases and differences

Answer 5

There is absolutely no way to prevent spam using domain or sender authentication. None of these techniques are designed to fight spam, but they can help.

DKIM, DMARC and SPF protect recipients from email forgery or sender spoofing (point 1). This is particularly important to fight phishing more than spam, with regards to the meaning and utilization of the words. Namely, spam is often inoffensive and just harassing.

Phishing and spearphishing are instead intrinsically malicious and, without DKIM, can leverage on the trust relationship to the sender address. This is especially true when cyber criminals want to send a forged invoice to a customer of a company by changing the IBAN/SWIFT code to a rogue.

For bulky commercial emails, these technologies provide absolutely no help. I can buy, even in bulk, a large number of fresh burner domain names and use a little bit of DevOps automation to set up SPF, DKIM, DMARC and start sending massive spam campaigns from a sender address that is inevitably unknown. I find this every day on my spam inbox (if someone asks for evidence I can paste some headers on this answer).

As another counter-example related to phishing. If a phisher wants to attack customers of ACME bank (acme.com) they can't send emails that really look like being from [email protected], but they can buy (because they did!!) acme-confirm-credentials.com and send emails.

An educated recipient will notice that the email does not come from the official acme.com and become suspicious, despite that one should become suspicious on the very request for "credential confirmation".