DKIM2 and DMARCbis Have Landed

The point i was trying to make though, is that we are past the era of brute forcing email addresses to send spam. Most spam is at least a little targeted.

If you are an attacker and need to send 100,000 emails a week, that means your budget you can spend on each PoW is six seconds.

This is easily parallizable and you can get budget vps's for about $5/month (i dont know if its more ecconomically efficient to get more powerful VPS or lots of cheap ones, but your mail server is probably in the range of a budget vps so i think its a fair comparison).

So some back of the napkin math, if the marketer wants to send 100,000 emails a week it costs them very very roughly $1.25 per 6 seconds of PoW.

If they have a marketing budget of $500 (which seems very small by most advertising budgets). Then you need a proof of work that takes 40 minutes per email to deter them. I dont think most email providers would find that acceptable, and i also made a bunch of simplifying assumptions here that i think lean in the direction of making PoW sound better than it is.

Say I decide to open a pirate themed gym called Slimmer Ye Timbers and buy the domain slimmeryetimbers.com.

If I want to setup a website, I will go to a hosting company, set something up, go into the DNS and point a couple of records for the top level domain and the www subdomain to the hosting company.

If I want to receive email sent to argh@slimmeryetimbers.com I need to setup a mail server (Google, Outlook, web host may offer one, could setup an open source one, etc) and once it's setup I go to the DNS to point an MX record at the mail server.

So far, if people try to lookup my website or send an email TO me everything is pretty straightforward.

Now, if I want to send email that says it's FROM argh@slimmeryetimers.com is where things get weird. Because I don't have to do anything.

Any server, anywhere can just do it and every mail server that receives a message saying it's from that domain has to try to figure out if it really is or isn't. This is where antispam rules come in. Without DMARC, SPF & DKIM in place receiving mail servers will build up trust in different IP addresses, typically from vendors who go out of their way to prevent email abuse specifically to protect the reputation of those IP addresses. The receiving mail server my do a reverse DNS lookup to see if the hostname matched. They might see if the MX server used by domain is the same server sending the message along with a ton of other algorithmic hoops to make a good judgement. Even with DMARC, SPF and DKIM in place they may still use those rules.

DMARC, when strictly enforced with p=reject, let's you signal the receiving mail server that all mail claiming to be from your domain can be validated and if it can't be validated that message isn't from you and can be discarded. All that DMARC does is say that if you receive a message from this domain, it should pass either SPF OR DKIM for this domain as well.

So let's say, for example that I'm using both Google Workspace and Sendgrid for email for slimmeryetimbers.com. I'll setup Gmail for my main professional email for myself and my staff and I'll setup Sendgrid to send email from the website (responses to contact forms, etc).

For SPF it can be pretty simple, a single TXT record:

"v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Both Google and Sendgrid publish DNS records with the IP address of their servers and keep them up to date, so adding that include is all that we have to do.

DKIM is more complicated. Google will provide you with a DKIM record to put under a subdomain that includes the public DKIM key. Once they have verified it's setup, they will sign every email sent from your account with the private key that only they know. When a receiving server gets the message they will see that the message has been signed by DKIM and it will point to the subdomain where the public key was stored. By following the instructions from the signature in the email and using the public key, they can verify that the message was actually signed by the private key and hasn't been tampered with.

If we then setup Sendgrid they will give you their own DNS records for DKIM that work for their own private key. In both of these situations, we never get our hands on the private key because we are using a 3rd party service that doesn't disclose it. Sendgrid issues 2 CNAME records that point to DKIM public key records on their DNS so that they can control them. They'll send out messages signed with one private key and then later switch to a different private key while the original key and it's public record is changed, transparently without you having to deal with it.

If we were to setup our own mail servers, we would have access to it though. It's also entirely possible for somebody with access at an email company to go steal the private keys of their customers and sell them, or just use them. It's possible for those services or our mail servers to be hacked/compromised and the keys be stolen. Built in rotation process helps with this. It's the same reason that Let's Encrypt issues secure certificates that expire after 90 days (sometimes less). Just key rotation.

That was long but I hope it helps?