Understanding SPF, DKIM, and DMARC: A Simple Guide

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...

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.

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.

>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.

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.

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.