Since source IP spoofing is rather tricky¹ with TCP, I've always wondered what advantage DKIM has over SPF. I've always just configured SPF to allow $myIP only: good luck sending spam in the name of my domain, you'd have to compromise my ISP or registrar first, at which point you can also get TLS certs for my domain for example.

Even for larger organisations which need to allowlist multiple sending systems, how would one spoof being one of the legitimate SPF sender in a situation where it is not also possible to spoof the DKIM records?

That is, besides allowlisting a range of IPs that anyone can publicly use (as in the submitted talk), which is just dumb.

¹ although not impossible, spoofing an entire mail exchange requires terabytes of traffic for one email of a few bytes, iff starttls is not enforced in which case it becomes impossible

- SPF breaks with forwarding. This is by far the biggest problem.

You typically end up with very large IP blocks being included in your policy (for example: MS365 includes a total of half a million IPv4 addresses, and billions of IPv6 addresses). All of which are now allowed to send on behalf of your domain. You'll have to trust (or hope) that the third party properly prevents other tenants from sending email on behalf of your domain. This is the problem with MailChannels as explained in the PDF.

- SPF can be very tricky to get right, one simple mistake and you either allow way to many IPs, or break your entire email domain. Even most seasoned IT administrators don't fully understand the entire RFC with all its errata and amendments. Now imagine some less technical user trying to set up SPF.

- You can only have one SPF record. If you want to add some external service, you'll need to merge your existing SPF record with the example given by your vendor. This can be highly confusing to many.

- The SPF DNS record is placed at the domain root (apex), which as shown in other comment here can be problematic for large orgs. This also prevents using a CNAME for SPF.

- SPF limits to 10 DNS lookups, which has proven far to low for modern use. The rules on how to calculate the number of required lookups is also ambiguous, so some receivers may accept your email, some may reject based on lookup limits.

- SPF contains many rarely used features (such as macros) that may or may not be implemented by the receiver, so you can't really rely on it.

- IP spoofing is an issue, but as you noted, this is not always a practical attack.

DKIM is in any regard more robust, more secure, and more important: easier to set up for the domain administrator. Just copy/paste the DKIM record provided by the third party email service. The third party vendor can (and most do) easily verify that the DKIM record is set up correctly. This is about as easy as it gets for DNS.

> Even for larger organisations which need to allowlist multiple sending systems, how would one spoof being one of the legitimate SPF sender in a situation where it is not also possible to spoof the DKIM records?

That is the problem with the (current) DMARC specification, you need SPF or DKIM to pass DMARC. Emphasis on or. So no matter how well you manage your DKIM keys, if someone can spoof (or has access to) one IP in your SPF policy, then the email is delivered. This is also explained in the talk.

Also, with DKIM you don't 'spoof' the record, you'd have to MITM the receiver when they fetch the DKIM DNS record, this is very hard to pull of in practice.

> and more important: easier to set up for the domain administrator. Just copy/paste the DKIM record provided by the third party email service

Pasting the same known value (my IP address) into a TXT record of the domains I want to send email from is an order of magnitude easier than

1. configuring the mail delivery software to ask opendkim for a signature, which in turn needs multiple config files and lookup tables for every domain

2. deploying a cryptographic key that doesn't even fit into one record, with various guides telling you different things on how you should be inputting the data

3. still failing the DKIM check because it turns out that 4k or even 3k rsa keys (let alone ecc! But I wasn't trying to be adventurous...) are not commonly enough supported and so you get to start over, wait another 24 hours for caches to flush, and ask another favor from that friend using that failing provider if they can send me the headers of a new test email to see if it passes now.

Even in your scenario where you hand your emails off to a third party, they can give you the SPF record to plug in literally, same as with DKIM, and then SPF is still easier because the input format doesn't depend on the registrar.

For your own domain this may be true, but or the majority of domain the SPF record will be far more complex. Adding a new third party sender to an existing SPF record is error prone. Unless you work with these sorts of things on a regular basis, it can be very confusing.

> 1. configuring the mail delivery software to ask opendkim for a signature, which in turn needs multiple config files and lookup tables for every domain

99.9% of domains do not self-host their email (and rightfully so!). Generally you don't set up DKIM on the sending side yourself. All you typically need to do is copy/paste the provided DKIM DNS record (the public key) into your DNS zone. Most major email services will also verify for you of you did that correctly.

> 3. still failing the DKIM check because it turns out that 4k or even 3k rsa keys (let alone ecc! But I wasn't trying to be adventurous...)

The recommended key length for DKIM is 2048 bit for this very reason. Don't try to use >2048 bit keys since there are plenty of legacy email systems that can't handle keys larger than that. ECC keys are much shorter, but can't be relied on for the coming decades (or ever) since you'll have to deal with legacy systems.

> Even in your scenario where you hand your emails off to a third party, they can give you the SPF record to plug in literally, same as with DKIM, and then SPF is still easier because the input format doesn't depend on the registrar.

It's true (and very unfortunate) that DNS is treated as a second class citizen by most registrars. The UI is often horrible. However, I do want to point out that SPF records can also easily exceed the maximum UDP length, so you'll need to start splitting your SPF with includes, which can be confusing to many

Again, my job is to assist domain administrators with email infrastructure related stuff. So I'm telling from experience that most of the configuration errors come from SPF, not DKIM.