21

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.

3
  • 4
    I believe there are currently more servers checking SPF records than there are checking DKIM signatures, so you'll get better coverage adding SPF even if you implement DKIM. And even less checking DMARC records. And SPF is so trivial to set up...
    – jcaron
    Feb 28 at 23:44
  • 7
    The problem is some servers will reject your email without DKIM (they don't care about SPF) and some servers will reject your email without SPF (they don't care about DKIM). I'm only thankful nobody's taken any other solutions seriously or I'd need to also implement that thing
    – slebetman
    Mar 1 at 4:18
  • 1
    I appreciate the above comments, and they are important to consider when setting up an email server. Nevertheless, the core of my question is simply whether a valid DKIM signature does not virtually guarantee that the email was sent from an authorized server, because otherwise it could not have added the proper DKIM signature (replay attacks notwithstanding).
    – cornergraf
    Mar 1 at 19:41
3

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.

6
  • Huh? This goes completely contrary to my understanding. My DKIM public key is added as a special TXT record in my DNS server, and that entry should only be valid for my domain. When doing a DKIM validation, doesn't the email recpient verify that the domain name matches the DKIM key?
    – cornergraf
    Mar 5 at 23:14
  • 2
    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.
    – Paul
    Mar 6 at 0:08
  • 1
    It seems that I have completely misunderstood DKIM, the distinction you pointed out is crucial in understanding DKIM. Reading the RFC makes it clear that the intent of DKIM is not that the signing domain has to be the same as the sender domain, therefore a valid DKIM signature does not ensure the sender address has not been forged unless the signing domain is the same as the sender domain. Thank you so much for not just reiterating what everyone else has said, but actually pointing out my mistake.
    – cornergraf
    Mar 7 at 10:16
  • 2
    could you include the information form your comment above in your actual answer? That would make it easier for readers to see why your answer is correct.
    – cornergraf
    Mar 7 at 10:31
  • Don't most mail clients these days mark emails that are DKIM-signed by an otherwise-reputable domain whose keys were not pointed to by the From/sender domain's DMARC with a conspicuous "sent via" or "on behalf of" notice? Apr 19 at 19:21
31

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.

7
  • I appreciate especially your second point, and in the case of business transactions I am certain that there are more issues to consider than spam. However, my question remains basically unanswered. For personal emails, wouldn't a valid DKIM signature virtually guarantee that this is an email sent by my server on my behalf, and not a spam message with fake sender? Keep in mind that I am claiming that no one has any interest or gain from replaying my (personal) emails - outside that scenario I will stipulate that SPF may be useful, though I will still say the value is relatively small.
    – cornergraf
    Mar 1 at 19:34
  • 1
    It would be a proof of the signed message being valid, but it would not tell that a message without a signature should be treated as invalid. Without a DMARC policy both would pass equally. Mar 1 at 21:14
  • 2
    Keep in mind that spammers can and do set them [domains] up as well. ==> I'd like to highlight that today spammers buy a large number of burner domains and configure DMARC for them. None of these affect the reputability of a domain name. I can simply check my spam folder to find that almost every email is DMARC-authenticated Mar 2 at 12:10
  • 1
    They do help in fighting spam, in the sense that while having these features set correctly doesn't signal a message is valid, failing to have proper SPF/DKIM/DMARC setups is a strong signal a message is likely to be spam.
    – Joel Coel
    Mar 3 at 18:02
  • 1
    I think the premises for this question are partly based on the same bias the email delivery industry has about SPF, DKIM and DMARC. Mar 3 at 18:15
8

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.

3
  • Thanks, this is the sort of answer I was looking for. Since I do not know if your answer is the (entire) truth I will wait a few days and let others weigh in, and if no better answer appears I will mark this as the answer. Thank you!
    – cornergraf
    Mar 3 at 10:15
  • Pauls answer shows that this one is completely wrong, unfortunately. I ask that everyone upvote the correct answer instead!
    – cornergraf
    Mar 7 at 10:22
  • This answer is not completely wrong. It is (probably) correct if DMARC is included in both cases, so read it as comparing DKIM+DMARC with SPF+DMARC.
    – JanKanis
    Aug 18 at 12:25
8

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

1
  • I appreciate the effort put into this answer - thank you - but it honestly doesn't tell me anything I don't already know, and I have already read the linked article.
    – cornergraf
    Mar 1 at 19:29
4

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 service@acme.com, 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".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.