* SPF: Tell the world which servers are allowed to send email for your domain
* DKIM: Weak version of digitally signed email, add a header that only mailservers that have the private key you supply can generate. Tampering invalidates the signature (for example when an email gets relayed for a second time). The private key used counts for your whole domain.
* DMARC: Tells other mailservers what to do when the SPF and/or DKIM check fails, and also allows you to set an address where to send reports to. These reports contain counts of messages that failed the SPF and/or DKIM checks.
The thing missing is that DMARC ensures alignment with the From header as well which SPF and DKIM don’t do.
SPF is about the domain in the envelope address.
DKIM signatures can reference any DKIM selector on any domain.
But DMARC also checks that the domains used match the domain of the From header. DMARC passes when at least one of the two is aligned. It’s possible to require strict alignment (exact domain) or allow subdomains as well.
> DMARC: Tells other mailservers what to do when the SPF and/or DKIM check fails
It's only "and" in this statement. You can't use DMARC to tell mailservers what to do when only one of them fails, as DMARC passes if at least one passes. The report will say which ones pass or not though.
...and everything you mention doesn't help shit for mitigation of spam because all spamming domains have SPF entries meanwhile, too. Which, by definition of its concept, can also be a lie that no receiving server cares about.
SPF, DKIM, DMARC are even more useless than the dbl protocol of spamhaus.
Also: this DMARC action is used for tracking whether or not an email was received, without the client of the receiving address needing to do any action.
>...and everything you mention doesn't help shit for mitigation of spam because all spamming domains have SPF entries meanwhile, too.
It does help stop false attribution of spam mail, though; spammer@example.net can't pretend to be sending mail from example.org.
It does lose its effectiveness when huge mail domains (e.g. GMail) can pump out so much spam, though, or when domains share email hosts (and therefore different tenants will be sending from the same IP addresses - another reason why IPv4 exhaustion is bad, isolation would work better with IPv6).
> Also: this DMARC action is used for tracking whether or not an email was received, without the client of the receiving address needing to do any action.
>
> So yep, it's also a privacy invasion.
Isn't it just the receiving mail SERVER acknowledging receiving the message? That says nothing about mailbox access or reading. I would not consider it a privacy invasion.
Most modern communication apps have a similar process of separating "sent", "received" and "displayed to user" which is super useful. Apart from the last part I would not consider them a privacy violation and you can usually turn that off. Similarly, if I download my mail to a local client, the server never knows if or when I read it and definitely not the sender.
But maybe I am missing your point, could you elaborate if that is the case?
Shortcuts for HN readers to avoid the pain of SPF, DKIM, and DMARC.
- Cloudflare Email Routing and DMARC Management. If all you need is inbound email inboxes at a custom domain that routes to your GMail or other addresses, this is the way to go.
- Fastmail. If you want an alternative to GWorkspace that is cheaper and more lightweight and that has its own non-Google mobile apps and a fast web app. Also if you need IMAP, POP, SMTP support.
- GWorkspace. Sometimes you just have to give in to the overlords. If you need inbound/outbound business mail that just works and integrates with all the Googley services, including GMail and GDrive, you just have to give in to this. Cloudflare makes the DNS setup easier if you go with this option. (They have a x-admin-panel integration.)
- Honorable mention for Opalstack.com. They'll give you open source powered email-server-in-a-box. On a shared Linux server, Procmail rule support, and with Roundcube access for mailboxes.
- The tool https://learndmarc.com is particularly helpful for debugging. It generates a unique email address you can send an email to and it'll tell you what's happening from an SPF, DKIM, and DMARC standpoint. All in the browser.
I disagree with the Cloudflare solution.
They have issues with their IP address reputation which makes their forwarding very unreliable. They basically get rate limited by Google and smaller email providers.
Your experience matches mine exactly. Client has a spoofing problem, we setup DMARC, reports are sent, not much is found. Client is billed. Client grumbles. Reports keep coming. Not much is found. Reports get ignored.
DMARC reports are not good for "keep an eye on who is spoofing my domain and then take action on it." But what they ARE good for is finding gaps in your DMARC policy. Like "oops, I forgot to add the helpdesk ticketing system to the policy" or "huh, it looks like the marketing department started using a new email provider, and they're not covered by the policy."
In other words, it's useful for spotting legitimate stuff that's accidentally failing, not for doing anything with the unauthorized stuff.
For a personal domain that only one or two people use, this is less likely to be worth bothering with.
I get reports showing attempts at least one a month per domain, a few in a week trying root and then subdomains. So I do like the fact that I know the policy I have implemented is useful. I do wish, however, that there was more useful information in the reports and that a variation of forensic reporting was more of a thing.
But you're spot on with finding gaps. It's basically the premise for every commercial DMARC product on the market. It's also crazy to see how companies blindly trust and never remediate senders from having access to corporate domains.
I'll, however, disagree with regard to personal domains. It's not hard. Do it. Everyone who helps clean up these things makes a small difference. If you own your own domain and are leveraging email this should be table stakes. I have recommended MailHardener [0] (no affiliation) in the past for their fantastic documentation around SPF, DKIM, DMARC, BIMI, etc - but also they have a free tier of one domain and they provide a grade with respect to your posture. It's really simple, and people I know have used it to learn how to implement these configurations on a broader scale.
I have definitely done it for my personal domains and I agree that it's not particularly hard. I just meant that for my personal domains I have not found the reports as useful as I do in business contexts, because I am the only person sending mail from those domains and it's (mostly) unlikely that I'd spin up a new source and forget to add it to the DMARC policy.
To clarify: The false positives/negatives are for the spam filter, not DMARC specifically.
My DMARC policy is lenient, so it only ever creates reports that I don't read, it never filters.
False positive: A legit email ends up in my spam folder.
False negative: A spam email ends up in my inbox.
I check my spam folder occasionally, so that's how I count false positives.
As far as I understand from this thread, maintaining a DMARC policy set makes more sense for bigger companies that have a lot of automated email traffic and a lot of consistently shaped traffic between larger groups. My Microsoft email at work is full of useless notifications because we don't have policies set up that whitelist our main customers or even our own automated tools. ("You don't often get emails from Jira!" -- if only.)
This was a great article and covered most of the things I've learned "the hard way" about SPF/DKIM/DMARC.
My only beef is with this:
> If you're running a large domain, you'll get a bunch of these reports. If you're running a small one, you might be able to handle it yourself.
Even with a "small" domain, you're looking at basically another part time job to analyze these reports. It's not fun, and you grow tired of it very quickly. Sure if you're running 1 website, and that's all you do it might make sense. But for a web firm like mine (serving small biz), there's no way I can set this up for clients without charging them an extra fee and most aren't willing to pay me to spend several hours each week analyzing DMARC reports.
In no way is it a part time job. You analyze the reports when you change where your mail is sent from (adding in Sendgrid or what have you), and once you confirm it’s working, you ignore the reports.
If your email stops going through, you’ll hear about it before you ever get a DMARC report about it.
I’ve been using Postmark’s DMARC report collector[0] for more years than I remember, and it’s great - you get a count of all the emails that passed SPF/DKIM, and a list of the ones that didn’t. Easy to spot any problems, and I don’t need to know anything about the reports themselves. Any time I setup a new domain that needs to send email, I make sure to get that up (and you’d be well advised to do it even if you don’t, just to block spammers trying to spoof it).
It does allow for your company's emails to stand out in the recipients' inbox. In Gmail they'll see a logo next to the email, in a sea of placeholders, and they'll see a blue checkmark when reading the email.
The money wasn't of consequence for my organization, but we had just sunset our final remaining Digicert certificate and are fully on automatic renewing AWS ACM and LetsEncrypt certificates. It felt like a step back to have to manage a new one manually.
If you're looking to check for issues with your SPF, DKIM and DMARC setup: https://aboutmy.email/ is a tool that calls out all the issue with a message that you send to their temporary address.
SPF and DKIM are in place, if not change your hosting company.
then you set up 2 emails dmarc_agg and dmarc_forensic on whatever.com
and then you add a custom DNS record. name: _dmarc type: TXT value:
Some email servers will outright reject emails if one or more of these is incorrectly parsable - for example using run=email@domain instead of having a mailto in there.
Too little too late. Running your own email server is a thing of the past.
I have properly and correctly implement SPF, DKIM and DMARC for years. Still, at any time Google, Microsoft or some Big Party might find - for reasons unclear - my server not trustworthy and decide to bin any mail it receives from me. Without informing the sender.
It's so random who this hits. I've had very little problems. YMMW. If you really want to run your own mail server and can stand to try, just try it. It may work with your IP. (Or whatever heuristic which the main providers go by.)
* SPF: Tell the world which servers are allowed to send email for your domain
* DKIM: Weak version of digitally signed email, add a header that only mailservers that have the private key you supply can generate. Tampering invalidates the signature (for example when an email gets relayed for a second time). The private key used counts for your whole domain.
* DMARC: Tells other mailservers what to do when the SPF and/or DKIM check fails, and also allows you to set an address where to send reports to. These reports contain counts of messages that failed the SPF and/or DKIM checks.