Throughout my previous posts on SPF, DKIM, and DMARC, I gave pieces of advice on what to do and not do. I figured I should write up one final post that lists all of these in a single place. Background bullet points. Email has two “from” addresses. One address is practically invisible; this is the envelope address. The “From” address in the message headers is what people actually see. The envelope and “From” addresses do not need to match. Bounces go to the envelope address. SPF bullet points. Never touch any existing SPF records. SPF only cares about the envelope address. You can probably just use your own domain in the envelope address. Alternative: have client create a subdomain with your platform’s SPF and MX records. Don’t try to “verify” the SPF record, it may not work. Clients can only add so many platforms to an SPF record. If you never touch the existing record this isn’t a problem. DKIM bullet points. Every account on your platform should have dedicated DKIM keys. Hosting the public keys in your DNS and having the client publish CNAME entries allows you to perform key rotation easily. Clients can publish virtually unlimited DKIM public keys. DMARC bullet points. DMARC passes if either SPF or DKIM pass, and that passing result is aligned with the “From” address. You only need 1 passing mechanism - SPF or DKIM. DMARC never requires both. Creating subdomains (outlined above) for the envelope address allows you to pass SPF relaxed alignment. Assume DKIM is in strict alignment and you’ll pass DMARC, as well as most local policies. Misc bullet points. SPF and DKIM should be tackled separately. DKIM signing should not depend on verifying SPF. Thanks again! Please reach out and let me know your thoughts. I’m hoping to maintain these posts as a sort-of living document. ...

So in my article on SPF, I briefly touched on how SPF only looks at a message’s envelope address, and not at the “From” address you see in the message headers, and that it’s not required for these addresses to match. In my article on DKIM, I mentioned that DKIM alone only handles determining if a signature is valid, but isn’t concerned with the “From” address of the message. How to handle signatures, and whether or not they should match the “From” address is left up to local policy. ...

This will likely be a shorter part of the series, most platforms can get DKIM implemented, unlike SPF, which they get wrong all the time. Still, there’s a few misconceptions I see around DKIM that I’d like to try to clear up, and give a few tips to have a nicer client experience. Background - what is DKIM? DomainKeys Identified Mail, or DKIM, is a method of cryptographically signing email messages using public-key cryptography. ...

In my experience: SPF is the most misunderstood part of all email authentication. To put it simply: if you tell customers to include your own SPF record in theirs, you’ve immediately signaled you (probably) don’t understand SPF. The “too long; didn’t read” summary: Man I sure did write a lot more than I intended to! So if you want to send emails using a client’s domain, here’s what to do: Do not touch the client’s existing SPF record. Do not force the message’s “from” address to match the envelope address. Do create a subdomain for bounce-tracking. Do sign messages with DKIM. Read on for a better understanding of why. ...

I’m an email administrator. Something that’s been frustrating for me is how often third-party platforms get email authentication wrong. By “platform” I generally mean something that’s probably going to send email, but isn’t an email provider outright. Things like: mailing list software marketing platforms sales platforms ticket and issue tracking systems customer relationship management systems At some point, all of these platforms will want to send an email using the customer’s domain name. In order to not wind up in spam boxes, they’ll ask the customer to take steps to authenticate their platform for emailing, and odds are they’ll get some part of how authentication works wrong. ...