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.

  • 491
  • 1
  • 4
  • 8
  • 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 '21 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 01 '21 at 04: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 01 '21 at 19:41
  • Short answer: DKIM alone cannot solve spamming. On my server, for instance, over 20% of incoming spam mails pass DKIM. The sender simply has access to a real domain and has set up the DNS appropriately. There is no such thing as an "authorized email server". – EML Feb 04 '22 at 10:58
  • @EML [RFC 7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1](https://datatracker.ietf.org/doc/html/rfc7208): "This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization." – Paul Feb 05 '22 at 03:04

5 Answers5


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.

Matija Nalis
  • 2,478
  • 24
  • 37
Esa Jokinen
  • 46,944
  • 3
  • 83
  • 129
  • 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 01 '21 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. – Esa Jokinen Mar 01 '21 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 – usr-local-ΕΨΗΕΛΩΝ Mar 02 '21 at 12:10
  • Thanks, that is certainly an important point to consider, and I must admit I have not really kept up with the "advances in spam technology". My question is posed purely from the perspective as a mail server owner who does not want his server/domain to become blacklisted due to forged sender information. – cornergraf Mar 03 '21 at 10:11
  • 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 03 '21 at 18:02
  • 1
    I think the premises for this question are partly based on the same [bias the email delivery industry has](https://serverfault.com/a/1045645/274176) about SPF, DKIM and DMARC. – Esa Jokinen Mar 03 '21 at 18:15
  • Ditto the chorus: DMARC prevents **spoofing**, but not spamming _per se_. It merely prevents spammers from _impersonating_ known-non-malicious domains. – JamesTheAwesomeDude Apr 19 '21 at 19:16

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

  • 105
  • 3
  • 317
  • 2
  • 4
  • 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 01 '21 at 19:29

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.

  • 181
  • 2
  • 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 03 '21 at 10:15
  • Pauls answer shows that this one is completely wrong, unfortunately. I ask that everyone upvote the correct answer instead! – cornergraf Mar 07 '21 at 10:22
  • 1
    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 '21 at 12:25

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.

  • 3,037
  • 6
  • 27
  • 40
  • 2
    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 05 '21 at 23:14
  • 3
    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 06 '21 at 00:08
  • 2
    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 07 '21 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 07 '21 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? – JamesTheAwesomeDude Apr 19 '21 at 19:21
  • @JamesTheAwesomeDude This is something I haven't investigated because it mostly applies to list management. My understanding is that there are some specific headers included in the email that inform the client when and what to display in "sent via" or "on behalf of". However, few admins will configure their servers to forever assume email from any given server is never spam, so the other rules will still be applied and enforced per the server's configuration and anit-spam tools. – Paul Apr 19 '21 at 19:34
  • @cornergraf: This is wrong, and shouldn't be the accepted answer. Yes, you can sign your mail with the key from *another* domain, and I do this, and it's common (in virtual hosting environments, for instance). But you can only do this if you know the *private* key for that *second* domain (because you sign with it), and only the *public* key is stored in the DNS record. So DKIM is a guarantee of an unmodified message which is provided by the *second* domain. It's broken only if that domain has been compromised. – EML Feb 04 '22 at 10:53
  • @EML When a receiving server receives a message that is not DKIM signed, how does it know whether the sender is authorized? – Paul Feb 04 '22 at 12:07
  • Sorry, don't understand your question. Presumably it's rhetorical? But note that there's no such thing as 'authorized'. What DKIM tells you is that the sender knows the private key of the pointed-to domain. One would assume that the real sender is 'authorized' to know the key. – EML Feb 04 '22 at 12:38
  • @EML You need to read the question, read my answer, then read through the comments, because you don't understand the conversation here, especially what OP was asking in the question. – Paul Feb 04 '22 at 13:02
  • You have misunderstood DKIM. If you have example.net, and you want one of your emails to appear to be from example.com, you have exactly two options: (1) steal the signing *private* key from example.com, or (2) change the DNS records for example.com (*not* example.net) so that it includes *your* (example.net's) public key. And, If you can change the DNS records for example.com, then you already *own* example.com, for all practical purposes, so you don't need to 'spoof' anyway. The question asks about DKIM *solving* the spamming issue. Your response is wrong *and* has nothing to do with spam. – EML Feb 04 '22 at 15:24
  • @EML An email will appear to be from `example.com` with the header `From: username@example.com` and has nothing to do with the DKIM header. The DKIM header can include `d=example.net`, and `example.net` will be the domain the receiving server authenticates with, because that is what RFC 6376 specifies. There is no requirement for DKIM headers to be added, so even easier is no DKIM header. This is at least partly why SPF and DMARC exist, which is the answer to the question of why can't only DKIM be used to protect from being spoofed (the spamming issue the OP is asking about). – Paul Feb 04 '22 at 20:09

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".

  • 2,359
  • 7
  • 34
  • 52