[HN Gopher] Understanding SPF, DKIM, and DMARC: A Simple Guide
___________________________________________________________________
Understanding SPF, DKIM, and DMARC: A Simple Guide
Author : miles
Score : 140 points
Date : 2024-06-17 17:35 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jprjr wrote:
| 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.
| jabroni_salad wrote:
| 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.
| velcrovan wrote:
| I manage IT at a mid-size business. At least once a month, I get
| asked to release some incoming email from quarantine that got
| sent there because the sender's SPF record is wrong or outdated
| and doesn't include all the email services they actually use.
| (What this really tells me is how many small businesses are out
| there running with no in-house IT expertise or support of any
| kind.)
|
| I don't do whitelisting. Instead, I always reach out and offer to
| help the other party correct their SPF record.
|
| It happens often enough that I wrote a script in Racket that will
| generate the email for me and paste it into the clipboard [1].
| The email tells them exactly what they need to change, and links
| to docs from their current email provider (so they don't have to
| trust me about edits to their DNS).
|
| [1]:
| https://gist.github.com/otherjoel/6b8bf02f6db6e0c47ba6bca72e...
| luckman212 wrote:
| Neat! I must try this.
| ziddoap wrote:
| What would you say the normal reception you receive from this
| email template is?
|
| I like the idea, but I would think sending a technical email
| (with industry-specific acronyms that you don't spell out!) to
| a business that has no in-house IT would just be ignored in
| most cases.
| velcrovan wrote:
| Well if you read the template, you'll see I start out with a
| non-technical explanation, advise that they forward the email
| to an IT type person, and offer to help in any way I can.
| Then I put in a "More info" heading further down with all the
| details and instructions.
|
| Overall I'm pleased with how well this approach works. When
| people realize that their email is getting stuck in spam
| filters because of a problem on their end, they're usually
| motivated to get it fixed. Sometimes it gets sent to an owner
| who had barely enough tech mojo to stand up a gmail account
| at a custom domain, and even then the instructions are
| usually simple enough for them to follow.
| ziddoap wrote:
| > _Well if you read the template_
|
| I read the template, that's how I spotted the acronyms that
| weren't spelled out. Like DNS on the second line, before
| you recommend forwarding.
|
| > _Overall I 'm pleased with how well this approach works._
|
| Interesting, I definitely would have thought it'd be
| ignored more often than not, but I might have to look into
| rolling out something similar. Thanks for the idea.
| ralferoo wrote:
| I think you're being a bit unfair here.
|
| > If you do not have access to your company's DNS
| records, please forward this email to someone in an IT
| role.
|
| If you don't even know what DNS records are, I'd imagine
| you'd assume you don't have access to them and so forward
| them to the IT person as suggested. But sure, maybe he
| could also add ", or don't know what they are" to this
| line.
| ziddoap wrote:
| I'm not trying to be unfair or critical or anything. My
| first question was genuine. I intended my note about
| acronyms to be just that: a side note. The response I got
| was "If you read the template [...]", which it should
| have been pretty obvious I did. Then I got an explanation
| of the template as if I hadn't read it, which was a bit
| patronizing.
|
| I think it's a good idea (and said so twice!). I was
| curious what the reception was like.
|
| Sorry if my comment about acronyms was too much. It is a
| pet peeve of mine to see acronyms not spelled out,
| especially technical ones in a document intended for non-
| technical people. I didn't intend it to derail the
| conversation. Obviously it was taken in a way more
| critical way than I had intended -- my fault.
| victorbjorklund wrote:
| That is really awesome. It can be easy to miss setting up SPF
| on every new tool.
| NoboruWataya wrote:
| > If you are invovled in developing, supporting, or maintaining
| an application that sends emails, this guide is a must read.
|
| I would also say a guide like this is helpful whenever you are
| using a custom domain with an email service, and therefore need
| to set these records yourself. Okay, you might not need to have
| an in-depth knowledge of these concepts, but it's certainly
| helpful to understand _why_ your email provider is telling you to
| set all these weird DNS records.
| lovasoa wrote:
| Just today, someone sent me the link to a great tool to debug
| dmark issues: https://www.learndmarc.com/
| UberFly wrote:
| Just tried it - you're right that is really good. Thanks.
| detourdog wrote:
| When I first implemented the above the next step was going to be
| ARC.
|
| Does anyone have thoughts on ARC?
|
| https://www.validity.com/blog/how-to-explain-authenticated-r...
| jabroni_salad wrote:
| It's only really needed if you need to robo-forward stuff
| between domains. For example if you set up a domain but want to
| receive emails to your usual gmail.
|
| I noticed that cloudflare's email forwarder uses an ARC record
| and it works a treat.
| lxgr wrote:
| I recently noticed this when debugging email delivery issues
| for a family member who have their own TLD, but forward
| everything to Gmail.
|
| Unfortunately, the mail server of the forwarding domain
| doesn't seem to support ARC, so Gmail frequently throws away
| everything that doesn't have a DMARC header, since without
| DMARC the only other option is SPF, which doesn't work for
| forwarding.
| jabroni_salad wrote:
| A lot of small businesses in my area have been bit by that
| this year. I have to give hostgator/bluehost/godaddy etc
| kudos for having an email forwarder work reliably for so
| long but I wish they were more proactive about getting
| their customers compliant with this.
|
| Also it's kinda messed up how much of the small business
| sector is relying on AOL webmail to operate.
| njt wrote:
| On a slightly related note, Michael W. Lucas[1] is working on an
| upcoming book entitled "Run Your Own Mail Server", that will be
| published shortly (there's a Kickstarter campaign as well[2]).
|
| I attended his tutorial and talk at BSDCan[3] this year and both
| were excellent. I highly recommend buying the book when it comes
| out (or supporting the Kickstarter), it will go through all the
| gory details of setting up and running a mail server, and best
| practices, including a ton of material on SPF/DKIM/DMARC.
|
| (P.S. I have no affiliation with the author or the book in any
| way.)
|
| [1] - https://mwl.io/
|
| [2] - https://www.kickstarter.com/projects/mwlucas/run-your-own-
| ma...
|
| [3] - https://www.bsdcan.org/2024/
| whartung wrote:
| Looking forward to this. First thing I ever ponied up on KS
| for.
|
| I don't even run a mailserver, I'm just hoping it will take a
| bunch of the guides that have been floating about on the web,
| consolidate the sharp edges, and make sure its up to date.
|
| I also hope it has some discussion on troubleshooting. Like
| dealing with blacklists and what not, folks always talk about
| that, but I've never see it documented what is actually done to
| resolve these problems (Like who do you send an email to, how
| do you even find out who to send an email to, etc.)
| disport wrote:
| Disclaimer: I founded a startup made for automatically onboarding
| user domains to applications, anything DNS-related such as
| SPF/DKIM/DMARC. It's a "Stripe-for-DNS" called cloudvalid.com.
|
| I like the quality of this SPF/DKIM/DMARC guide, and I would even
| say that the author has done a better job than I ever did. My
| career started in this email space, and I've written the
| SPF/DKIM/DMARC guides myself for SendGrid, Amazon SES, and a few
| other email products.
|
| That being said, I see guides like this pop up with some
| regularity, but users continue to have the same level of
| comprehension as before. The nature of the problem is one that a
| user does maybe once, which means that they're not getting the
| repetitions in to warrant long-term comprehension.
|
| I'm naturally biased here, but if you're onboarding user domains
| to your application, it's good if you can just offer them
| automation.
| heavyset_go wrote:
| Tangential, but what is the contemporary go-to for standing up a
| mail server these days? The last time I had to do so was a decade
| ago.
|
| I remember Mail-in-a-Box being popular at one point, wondering if
| that's still the case.
| jamespwilliams wrote:
| > If an email passes the SPF and DKIM checks, the receiver then
| looks at the DMARC rule book
|
| DMARC rules are applied regardless of whether the SPF or the DKIM
| component pass.
|
| I think it's worth mentioning that DMARC passes if the SPF _or_
| DKIM component passes (both passing is not required).
|
| It's also a bit surprising that there is no mention of alignment
| - I guess it'd make the guide more complicated, but it is
| important to understand.
|
| > It's generally recommended to use ~all while testing or setting
| up your SPF record, and switch to -all once you are confident
| that your SPF record is correct.
|
| It's much more nuanced than this in the context of DMARC, and
| many large senders use ~all for deliverability reasons. See
| https://redsift.com/guides/email-protocol-configuration-guid...
|
| > If you set up DMARC without SPF, it's like the security guard
| is missing one of its tools. It can still use DKIM to check
| emails, but it won't be as effective.
|
| Not sure I really agree here. Following on from the security
| guard analogy, I see it more like DMARC being a security guard,
| and SPF and DKIM are two ID badges that people can show to the
| guard to get into a building. If you don't hand out SPF "badges",
| the system is no less effective, in fact it's arguably actually
| more secure.
___________________________________________________________________
(page generated 2024-06-17 23:00 UTC)