[dataflow]

Re: #3, shouldn't this be per-domain anyway, rather than per server? If a domain has one server signing and another one not signing then something feels wrong. It seems pretty fine to just look at what the domain did in the past as the basis, no?

[brightball]

Since multiple services can send on behalf of the domain, DKIM has to be configured for each of them. A service provider, like Google, will likely use the same private key across any of their servers that is sending your mail but Sendgrid won't have access to that private key so they have to setup their own. Same goes for any other services that send mail using your domain.

As a receiving mail server, they have no way of knowing how many different parties are legitimately sending email on behalf of your domain.

SPF is per domain. You setup a DNS record at the domain (or subdomain) level that lists all of the IPs (or a DNS reference to a list of those IPs) that are authorized to send email on your behalf...but, that breaks with mail forwarding and mailing lists.

SPF is much simpler, absolutely. DKIM requires a private key to sign outgoing messages from every mail server sending mail on your behalf.

[dataflow]

> A service provider, like Google, will likely use the same private key across any of their servers that is sending your mail but Sendgrid won't have access to that private key so they have to setup their own. Same goes for any other services that send mail using your domain.

I'm sorry, I'm so lost and confused. Why would a service like SendGrid be impersonating a random domain without being able to get a private key from the domain owner? Like you're saying SendGrid offers the ability to send emails from a domain like @gmail.com without its private key?

[brightball]

I'll try to explain.

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 [e-mail] 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 [e-mail] 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?