←back to thread

Understanding SPF, DKIM, and DMARC: A Simple Guide

(github.com)
443 points miles | 3 comments | 17 Jun 24 17:35 UTC | HN request time: 0.001s | source
Show context
jprjr ◴[17 Jun 24 20:47 UTC] No.40710866[source]▶
What I really want to see is a guide for SPF/DKIM/DMARC oriented towards people writing apps that send email using other people's domains. I have dealt with so many ticketing systems and marketing platforms that do not understand the roles of SPF/DKIM/DMARC at all.

Things like, insisting we need to include their SPF record in ours, even going so far as to scan the SPF record for the include, only to find out they use their own domain in the envelope address (which is what I wanted them to do in the first place).

Or not distinguishing at all between envelope and header addresses and using our domain in both. Which of course means they're not tracking delayed bounces.

It really becomes an issue with larger orgs where everybody wants to use the main domain for brand purposes and subdomains are just totally frowned upon for whatever reason. If you just leave my SPF alone and rely on DKIM, it means you can still pass DMARC and track bounces properly. Hell I'd be fine with making subdomains for the envelope address that lists your infrastructure in the MX records but again, eyes really start to glaze over when you say "envelope address."

Basically what I really want is a guide that boils down to: if you're not their primary email provider, then don't touch your client's SPF record.

replies(1): >>40711350 #
jabroni_salad ◴[17 Jun 24 21:37 UTC] No.40711350[source]▶
I recently set up a mailchimp tenant for someone and was surprised that their email authentication wizard pretty much began and ended with DKIM. I'm way too used to b2b solutions that want the equivalent of a chmod+999 before it can run a hello world.
replies(1): >>40714037 #
TheNewsIsHere ◴[18 Jun 24 04:19 UTC] No.40714037[source]▶
In my experience this approach is becoming more common, but slowly.

I still configure my default apex DMARC records (in most scenarios) to enforce strict alignment on both SPF and DKIM, but I’ve been relaxing that on a case by case basis or overriding the apex DMARC policy at a subdomain level and only using DKIM where supported.

replies(1): >>40716888 #
1. joveian ◴[18 Jun 24 12:15 UTC] No.40716888[source]▶
There seems to be incorrect information out there about strict alignment requesting more strict checking. Strict vs relaxed alignment is just about the domain being able to send mail from subdomains without extra DNS records on the subdomains (relaxed) or not (strict). The envelope from (for SPF) and d= domain (for DKIM) must match the DNS records used. If you don't use SPF for DMARC you don't use SPF for DMARC and it doesn't matter if the DMARC SPF alignment is strict or relaxed (there is no way in DMARC to require both DKIM and SPF to pass). It is still a good idea to always pass plain (non-aligned) SPF (just based on envelope from) since sometimes this is checked independently from DMARC.
replies(1): >>40717613 #
2. TheNewsIsHere ◴[18 Jun 24 13:28 UTC] No.40717613[source]▶
I am slightly confused, and perhaps misunderstanding your framing.

I do use DMARC and SPF in the fashion you described. In my environments I typically need to take every measure to ensure only authorized services/servers/senders are sending, via authorized hosts and IPs, and this often changes based on subdomain, so that’s why I use strict alignment. Personally I strive to keep various services strictly separated by (sub)domain.

replies(1): >>40726219 #
3. joveian ◴[19 Jun 24 08:47 UTC] No.40726219[source]▶
I thought it might just be ambiguous language. It wasn't clear to me what you were trying to say and it could be read as implying what I have seen (incorrectly) stated in some DMARC descriptions elsewhere. Just trying to prevent any misunderstandings from anyone reading the thread and improve my own understading by checking that I got it right before posting. Thanks for clarifying what you ment :).