I am self-hosting my (secondary) email and have only implemented SPF and DKIM. This works fine on a practical level for me. What would be the benefit of setting up DMARC on top?
Some large companies have started blocking domains that do not have DMARC. It is a simple DNS entry. (Easier than SPF.) You should add it to all of your domains even though it accomplishes very little other than meeting the requirements of some larger companies.
The article speaks about DMARC monitoring, but not about "writing" it. So many orgs are too small to have someone paying attention of these things. Where I work, the CTO used to manage the DNS, but with very little understanding of what it all means. It was just copy and paste. And yes, it also says p=none. Probably because it was in the example. It's like setting up a website for your company, and picking some wordpress instance: how are you supposed to know the risks? It's just too much.
I really think we should be solving a much bigger problem of the major email providers not providing an automated way of handling abuse and not caring about abuse reports at all. Most of my spam comes from the three major email providers and at this point I gave up even trying to send abuse reports because they just get ignored.
The big companies do not have to care because nobody will block Google, Microsoft or Amazon. They are too big to fail.
Spoofing a From field is an insignificant problem in comparison.
Not to mention that the larger companies are incentivized not to deliver your email due to low volume. If your service does not work, companies will be encouraged to use Google or Microsoft instead.
Email has been turned into a by-the-corporation, for-the-corporation service. Corporations need DMARC so they can control email and the ability to spam. The spam I cannot block is spam from Google.
If you decide to think about this, you will quickly realize that email is f*ked and needs to be forked. Perhaps we need a Community Email Initiative that blocks corporations and only allows Community members.
Trust is the one thing you can't buy on the Corporate Internet.
I am sure many people will be offended and down vote this comment because they cannot conceptualize an internet without Corporations.
You can't solve a social or political problem with a technical solution. Whatever you invent, Microsoft and Google will still collude to block you and not each other.
Article is missing a note on the existence of MX records for the domains. Sure, you can easily have a send-only domain without an MX record, but the common case is likely to setup both send and receive capability. It would be interesting to have that number included as domains without MX and DMARC might just not be configured for email at all. Worst case the 45% of domains without DMARC are simply not relevant for email and thus not configured at all. I would find "x% of domains with configured email don't enforce DMARC" more interesting.
I mind email for a number of small orgs (<1000 recipients each). There are so many SPF and DKIM failures from senders who you'd think would know better (Fortune 100-type companies). I don't want complaints from users missing messages so I end up disregarding failures even when published policy says to do otherwise.
I don't get it. Neither one is hard to setup. How do people have such a hard time with such simple configuration. Then again the majority of "mail admins" I have interacted with have absolutely no understanding of SMTP and can barely wrap their heads around DNS.
I've had more than one argue with me that having more than 10 lookups in the SPF isn't the issue even though I am showing them the SPF failure and the RFC stating that you are not allowed more than 10. Like, good for you that Gmail doesn't care, we do, fix your shit.
The real reason p=none persists is because people would rather err on the side of email being delivered that is actually junk than having a miss of legitimate mail. (This also the reason for so many soft failure entries in SPF records.)
Sadly the article doesn't really touch on whether or not DMARC accomplishes anything truly useful. When I enabled DMARC for ingress email on one of my own mail servers, it ultimately ended up regularly blocking a handful emails from customers, yet virtually all the spam coming in had valid SPF / DKIM / DMARC, as do most of the phishing attacks.
The core problem is that the real need of email end users need is a way of determining whether or not to trust a given sender. Signatures are purely a technical measure which provides no information on the trustworthiness of the sender. The end result is that email scoring still has to be content based, and the signature check technologies are pure noise with no useful signal for the purpose of determining if an email should actually show up in my inbox.
The tech industry has a bad habit of providing solutions to problems adjacent to problems the user actually needs solved while leaving the user's actual problem unresolved.
DMARC, just like SPF before it, solves nothing. The spammers adapt. And unlike SPF, DMARC has an enormous technology surface area. Its failure modes are legion, and each one is tedious to run down to resolution. Which just returns you to something which never pays the rent anyway.
SPF did solve an issue. Domain impersonation is no longer as much of an issue if you are strict against SPF failures. DMARC, on the other hand, solved absolutely nothing.
DMARC is simple in theory but quite tricky in practice (with subdomains, for example).
You follow the guide for a service (say Mailgun, for example) and everything looks fine, but CloudFlare shows up issues. You fix those issues and you're conflicting the mail service guide.
Anyways, the new CF AI tool is relatively decent for this purpose, explains the fact that most warnings in CF are harmless, but the lack of standardized guidelines is annoying to say the least.
I am running email server for my private domain using https://github.com/docker-mailserver/docker-mailserver . One day in 2023 i decided that beside of dkim i maybe should also enable dmarc. Because ... well, why not. What happened was that i started reciving regular reports over email from ms and google containing compressed xml containing no info other that empty report was generated. What should I do with that? At that time i could not find any tool that would be able to extract valuable info from that, so I disabled dmarc. Havent looked back since.
I’d be interested these stats broken down between domains associated with operating companies and personal or hobby domains.
The latter are likely to adopt much more slowly simply because of less perceived risk, lower payoff (no vendor reviews), and less dedicated technical expertise.
Just like personal sites were slow to adopt HTTPS. Mass HTTPS adoption happened once browser warnings and SEO incentives rendered sites mostly useless without it.
Mass HTTPS adoption happened when it stopped costing $100 every year and requiring three forms of KYC, which is after Snowden showed us why we really should be using it all the time.
I have set up DMARC, SPF, DKIM and whatnot. Sadly no one seems to take this as a signal for a competent mail setup, so Microsoft's mail servers regularly block my mails because of the surrounding IP range reputation - not because any spam would originate from my IPs or domains.
When its unimportant or important to the receiver only, you push responsibility to them: "I sent it. Must be your email that's glithced. Tried Gmail or Proton?"
When its important to you, you use your backup Gmail or Proton account.
I didn't see it explicitly mentioned in the post, I wonder if they filtered exclusively for domains with mx records. Because I would assume that lots of domains just don't have email configured and therefore aren't aware that you should still setup DMARC to prevent impersination of your domain.
46 comments
[ 0.28 ms ] story [ 41.6 ms ] threadThe big companies do not have to care because nobody will block Google, Microsoft or Amazon. They are too big to fail.
Spoofing a From field is an insignificant problem in comparison.
If you decide to think about this, you will quickly realize that email is f*ked and needs to be forked. Perhaps we need a Community Email Initiative that blocks corporations and only allows Community members.
Trust is the one thing you can't buy on the Corporate Internet.
I am sure many people will be offended and down vote this comment because they cannot conceptualize an internet without Corporations.
DNS SPF record: mydomain.io. TXT "v=spf1 -all"
DNS DMARC: _dmarc.mydomain.io. TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
That ought to stop anyone trying to use your domains as source.
I've had more than one argue with me that having more than 10 lookups in the SPF isn't the issue even though I am showing them the SPF failure and the RFC stating that you are not allowed more than 10. Like, good for you that Gmail doesn't care, we do, fix your shit.
https://utcc.utoronto.ca/~cks/space/blog/spam/DMARCPractical...
The core problem is that the real need of email end users need is a way of determining whether or not to trust a given sender. Signatures are purely a technical measure which provides no information on the trustworthiness of the sender. The end result is that email scoring still has to be content based, and the signature check technologies are pure noise with no useful signal for the purpose of determining if an email should actually show up in my inbox.
The tech industry has a bad habit of providing solutions to problems adjacent to problems the user actually needs solved while leaving the user's actual problem unresolved.
Anyways, the new CF AI tool is relatively decent for this purpose, explains the fact that most warnings in CF are harmless, but the lack of standardized guidelines is annoying to say the least.
The latter are likely to adopt much more slowly simply because of less perceived risk, lower payoff (no vendor reviews), and less dedicated technical expertise.
Just like personal sites were slow to adopt HTTPS. Mass HTTPS adoption happened once browser warnings and SEO incentives rendered sites mostly useless without it.
When its unimportant or important to the receiver only, you push responsibility to them: "I sent it. Must be your email that's glithced. Tried Gmail or Proton?"
When its important to you, you use your backup Gmail or Proton account.