3 ms·

Thanks! Your reply and its siblings have convinced me why DKIM is better overall; my opinion was changed, but there's one part that doesn't make much sense to m

by lucb1e 3y ago

Thanks! Your reply and its siblings have convinced me why DKIM is better overall; my opinion was changed, but there's one part that doesn't make much sense to me: > 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.

LeonM 3y ago
> 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 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.

by lucb1e 3y ago

LeonM 3y ago

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