For me, as someone with their own mail server, these technologies mostly serve to inform me that Russian IP addresses are still trying to send email in the name of my domain for some stupid reason.
It makes sense that people whose business is sending email know how to set up email correctly. I'm mostly surprised at how many legitimate sysadmins struggle with getting the basics correct. Surely those dozens of DMARC emails you get that your sendgrid email has been refused because of a bad SPF signature should set in motion some kind of plan to ask if maybe marketing is using them legitimately?
Automated signatures are of limited value but I rarely see rejections based on SPF and DKIM that are a mistake. Things are probably worse for big organizations but as a small email server, technical rejections are usually the right call. The only exception is mailing lists, but the dozens of people who still use those can usually figure out how to add an exception for them.
The problems I noticed were, it doesn't matter what the SPF and DKIM look like. If Google or Microsoft refuse to relay your email based on secret internal factors then you're out of business.
The issue here generally boils down to the defining difference between a generalist Admin and a Messaging Admin. The generalist can follow instructions, and nearly all the instructions out there stop at the point where SPF/DKIM/DMARC are successfully implemented. A generalist worth their salt will then fill in the gaps if they can', and knows this isn't where you stop when you want mail deliverability. There's a higher bar.
If you follow instructions written by non-professionals blindly you don't ever reach the point where you get to quality work.
Google, Microsoft, and the other large ESPs don't refuse to relay your email based on secret internal factors. This is what the non-professional people say to falsely justify why they can't do something.
Google and Microsoft publish the internal factors they use in the form of whitepapers at the industry working group. Its not ready made, and there are a lot of them, and they may not release their specific implementation details, but the metrics are there and often are based in weighted form (reputation-based systems).
If you follow them correctly, and set up the appropriate reporting accounts, and maintain those accounts, you won't have these problems. You generally only have problems once you've violated guidelines continuously, which happens when you rely on, or are unable to discern between qualified and unqualified help.
But there are big problems with mapping from IPs to countries. My IPv6 is detected as Russian, though it is London-located tunnel exit point and I'm in the Netherlands.
Ive got a server hosting a number of things, amd monitoring setup for a lot of stats. Got tired of seeing blips because various countries were beating on my server, not a DoS, but enough requests to notice, and sometimes generate an alert. I blocked 7 countries, in full, and the impact was fantastic. No more 2gb of logs generated every day by countries that have no business accessing my server.
Unless you own a global business, i see no reason to even allow other countries access. The potential for attacks is too great, especially from some very specific countries.
Ok but you can’t block someone else using their own IPs to send email.
If you set DMARC to report, you’ll get notices from remote email systems when they receive noncompliant emails with your domain in the Envelope From field. Those reports are where you’ll see Russian IP addresses show up when they are trying to spoof your emails.
But there is no way to block them because neither the senders nor receivers are on your infrastructure. The best you can do is set a reject DMARC policy and hope everyone follows it.
As a non-email guy, I can tell you that if a system that boils down to having an (optionally certified?) key requires much more than just putting it into a folder with a domain name and running a service, it’s badly designed and has unnecessary complexity. Which will result into abusers having more expertise than legitimate users. The fact that you can “get” DMARC SPF DKIM wrong, while it’s basically a hard requirement for operation, is just screaming something important to the email software.
As a generalist admin, would you say the same about DBA operations or would you say that's just not my specialty?
The reasoning you provide doesn't differentiate, and speaks more of frustration which naturally comes with any area you aren't steeped in, or knowledgeable about.
In most organizations there is no point in a sysadmin to spend the effort in understanding how to set it up correctly as Marketing has got more authority on email. Marketing will simply demand changes to the config that they do not understand and there is nothing you can do to stop it as they will have the CEO on their side.
> Marketing will simply demand changes to the config that they do not understand and there is nothing you can do to stop it as they will have the CEO on their side.
Marketing should get their own (sub)domain for sending their missives, that way the primary corporate domain's reputation is not harmed.
Unless you want to run the risk of outgoing e-mails from Finance / Accounts Receivable to be sent to other companies' Junk folder.
Orgs like that will hire consultants like me when they can't figure out why their stuff isn't landing in the inbox. Then 3 months later their webdev will somehow delete the entire zone when adding their A record.
You mean like the time I had a salesperson demanding that we turn off Cloudflare across our entire domain because he'd read some random article somewhere saying we should?
Which is another reason to strictly enforce SPF and DKIM, in my book. Let marketing break those policies, that way I don't need to bother with reading your company's spam!
even worse when you have even less control than that, if you run some type of hosting and are trying to convince non-technical clients (or even worse, non technical clients who think they are technical) to “please just add this record exactly as it says here to your domain” and they’re somehow unable to for months and months
to be fair here: for a lot of companies, if the mass mailing stops, the money-flow stops then that's no good for anyone... so the CEO will probably err on the side of money, presumably.
As someone who set these up, I can tell you, the answer is rather simple:
- spammers have 1 system to set up in order to spam. They get it right.
- company admins have dozens of projects, of which this is a tiny one, with zero ROI to the bottom line (if people don't consider how critical security is). So they delay.
- companies often have dozens of systems integrated, when I set up DMARC/DKIM the first time for my company, a bunch of email tools broke, we had to do a bunch of leg work, took us a month end-to-end. The value was recognized when we almost lost 20k to a "ceo emails you" scam. But until then it wasn't a priority.
- we didn't even have a full IT, i just stepped in because I cared enough.
- my current company has a dedicated security team. These holes are plugged VERY quickly.
I used to have my policy set to reject, but then I found out some part of an Enterprise Outlook mail filtering chain was rewriting the mail I sent before checking the DKIM signature. I can't fix stupid, especially for other parties, so I changed the policy to quarantine instead.
I doubt Russian spammers will care about the difference to be honest. If they accept that their email will be delivered to spam folders, why would they care that the email gets silently dropped? In neither case anyone is going to fall for them.
I am just having this problem. Actually getting SPF, DKIM and DMARC right and having a domain with a 0 spam score will still land you in the spam directory. It turns out, you need to have a "reputation"? before your email gets accepted into gmail. My head was spinning as to how that reputation will be built if your email just goes straight to spam.
But sure, Linkedin emails are definitively not spam and their dark-patterns at adding you at n+1 emailing list doesn't get them banned from the big (or any?) provider.
It's easy, you just have to have a regular, decently sized volume of non-spam emails, and suddenly your email stops being marked as spam!
The logic isn't even that bad. SPF and DKIM serve to prove to the email who the sender is. That doesn't mean much if the sender is a spammer. Verifying identity claims is only the first part in checking email for spam, the harder part is checking if that identity is someone you trust.
When you email Outlook or Google, you're better sending more than a few every single day, and the recipient better manually drag those emails from their spam folders to their inbox, or they're all being learned as spam.
> you just have to have a regular, decently sized volume of non-spam emails
But if you have a regular decent size of emails coming from your domain, that is more likely to be spam than if you have a small number of intermittent emails coming from a domain.
I worked on this for a while, at a time and in a market where most of our recipients had @hotmail addresses. I discovered that mass email sending was akin to a "pay-to-win" game.
We had/opted to acquire the services of a company "expert in email deliverability" (Return Path), who somehow provided detailed metrics of how our IPs were scored by MSFT. I always wondered why MSFT didn't provide those scores by themselves, and how a 3rd. party could have access to them.
Re. your comment... slow ramp-up is the only way, with constant monitoring of deliverability and consequent adjusting of recipients (i.e. removing those who do not open or hard-bounce). I did also wonder if paying that company perhaps gave us a headstart when adding new IPs...
It's almost like all those bad actors (linkedin) are owned and controlled by the big players (microsoft) that benefit from email being only commodity they can provide.
I think the domain rep is worth less than IP rep. I had occasional issues sending issues when I self hosted on a VPS. When I moved my domain to Fastmail I haven’t ever had my emails go to spam.
As a tip, go to a VPS that's had a history of being very selective of allowing SMTP traffic but still allows after some kind of review. Cheap providers that never did any blocking probably have bad reputations for their entire address range.
I've been successfully using VPSes to send emails for 20 years.
I am sending from SES. Interestingly, I didn't have a problem getting the email delivered to inbox in fastmail despite having an aggressive "protection level".
This isn't a problem for personal emails, as after a request or two friends will unspam you. Google blackholes emails, breaking all mail logic (no bounce), so I assure you the SPAM folder is a good gmail sign.
I would imagine that on the corporate side, your employees could do the same. Beyond that, if you're sending spammy stuff, have unsubscribe headers and links in emails.
If it's a new domain, then your problem isn't reputation exactly, it's having a newly-registered domain. Buying a new domain, setting up the SPF, DKIM, and MARC, and then immediately spamming from it until it's banned everywhere a week later is standard spammer MO.
I've been self-hosting mail for me and my family for about 20 years and don't send nearly enough mail to have a "reputation" with anybody. Still, I don't have any problems with deliverability of mail.
> Actually getting SPF, DKIM and DMARC right and having a domain with a 0 spam score will still land you in the spam directory.
This little bit of wisdom gets passed around all the time, but it's actually not true. You can send email from a brand new domain to Google and Microsoft and whoever just fine. What you can't do is send email from a brand new domain, and a brand new email server--or an email server on a VPS, or an email server on a residential IP. Residential IP blocks are almost completely blocked, because of unsecured devices being used to send spam, and VPS blocks have the same problem. You can get around this by using a mail relay, or building your domains reputation on a server that already has a good reputation.
SPF/DKIM is really about mail server reputation. So it mostly benefits larger servers like the ones run by Google, Microsoft and Yahoo. Unfortunately, that means that attempts by those larger providers to combat spam using such reputation will naturally hurt smaller providers. So the actual effects of SPF/DKIM are on the whole negative.
The root problem is that we don't actually need to keep track of email server reputation. No one says to themselves "Huh, this is from a Gmail address, it must be legit". We really want to keep track of sender reputation. We need to be able to treat anonymous email differently than email from people we actually know. That implies that we have some work to do on the problem of identity. As it is, there is not even a way for a known email sender to securely introduce an unknown email sender. You know, the way that regular human people normally are able to transfer identities from one to the other.
>SPF/DKIM is really about mail server reputation. So it mostly benefits larger servers like the ones run by Google, Microsoft and Yahoo. Unfortunately, that means that attempts by those larger providers to combat span using such reputation will naturally hurt smaller providers. So the actual effects of SPF/DKIM are on the whole negative.
That paragraph is incorrect. SPF/DKIM is not about reputation. The main purpose is preventing domain impersonation from unauthorized senders. E.g. mail servers will reject fake emails from "upofadown@microsoft.com" because you don't control any email servers that's whitelisted in microsoft.com DNS TXT records.
E.g. I was able to register a brand new .com address and then successfully send to gmail and MS Outlook accounts within minutes because I had proper SPF/DKIM in the DNS records for that new domain. That new domain had zero reputation and yet Gmail accepted it because SPF/DKIM was configured correctly -- and -- the underlying ip address of the server it came from had a good reputation.
If SPF/DKIM was truly about "reputation", it would mean I'd have to wait days or months for reputation history to build up before Gmail accepted it.
And it will mysteriously _stop_ being able to send mail to Google despite you doing everything right, because of whatever nonsense they use to determine reputation.
I don't think this is correct? SPF and DKIM are about ensuring that the server actually is who it says it is, not about its reputation. In other words, when you receive an email that claims to be from Gmail, SPF and DKIM help you ensure that's where the letter actually came from, not from a server just pretending to be one of Gmail's servers.
> That implies that we have some work to do on the problem of identity. As it is, there is not even a way for a known email sender to securely introduce an unknown email sender.
There is: gpg/pgp signature, but many people find it complicated, primarily because they are reluctant to read the documentation. And it’s popular to criticize it, especially here on HN, in favor of various half-baked alternatives.
I think everyone can agree that any technology that "isn't complicated if you read the documentation" is by definition complicated. I don't need to read the documentation for Gmail to use Gmail successfully.
Could I, as a trained programmer, use PGP and GPG? I'm sure I could if I spent some time reading about it. Could my 90 year old grandmother, who is otherwise quite comfortable with email and whatsapp? No, not to any meaningful extent.
That's what kills a lot of these "perfect" implementations.
HN members tend to be nerds, and we don't really have an issue with setting stuff up (many HN IDs, for instance, have Keybase auths).
Most non-HN types have no patience for that stuff. Security needs to be made accessible and easy-to-use, before the vast majority of folks will implement it. That's the single biggest conundrum, IMNSHO.
We really need a "Trust on First Use"(TOFU) system for messaging, that can be verifified, or pre-trusted offline, face to face. It'd be awfully nice for your bank to give you some thing that you can later verify that any communication from them (web site, online banking, text message, email, etc) are legit and verified.
Or if we can't trust users to handle TOFU, then some token/unique address/whatever that we can exchange face to face to enable trusted communication.
> We need to be able to treat anonymous email differently than email from people we actually know.
The simplest solution to that would be an "only show me emails from people in my address book" filter. That would mostly echo how we treat user trust on all other platforms. Genuinely surprised this doesn't exist in most email clients (or does it and I have just overlooked it so far?)
Of course that's only a partial solution and wouldn't work for accounts where you expect unsolicited mails from people you don't know. I'd see it more as a "low-hanging fruit" solution. You could also expand the heuristic, e.g. also consider previous conversations, mailing lists, etc.
(Interestingly, the "introduce a friend" functionality would come for free: You can already send contact details as a VCard in an attachment. When receiving such a mail, some email clients will show a button to quickly add the contact to the address book.)
> only a partial solution and wouldn't work for accounts where you expect unsolicited mails from people you don't know.
I actually think this would work fine. Imagine a quarantine inbox for new emailers that the user must scan and approve/block. This is exactly what hey has implemented.
> The root problem is that we don't actually need to keep track of email server reputation.
We actually do. Is the server allowing anyone to sign up so that it's sending 99% spam, or does it have a lot of anti-spam measures so sign-ups can't be automated and it blocks accounts as soon as it detects them sending spam?
> As it is, there is not even a way for a known email sender to securely introduce an unknown email sender. You know, the way that regular human people normally are able to transfer identities from one to the other.
That's exactly what PGP's web of trust model is for. Someone you know, and trust, can sign and send you a public key of someone that they trust.
This new key will be automatically trusted in your trust store because it's signed by someone you already trust, although in a lesser trust level to account for the degree of separation. If you later verify that key out of band you can upgrade it to a higher trust level.
SPF/DKIM, as well as TLS etc., is just stupid shit we do because we're too lazy and/or incompetent to make web of trust work for us. It's not a technology problem, it's a human problem.
Well, yeah, we should use preexisting standards and OpenPGP would be perfectly fine here and is probably the best choice. That is a wheel we do not need to reinvent. But the actual system used to do the signatures and keep track of the reputation is the last thing we should be thinking about at this point. We should instead concentrate on how to create a system that the majority of people can use and understand. We should be concentrating on standardizing concepts...
It's weird so see such a factually incorrect comment so high up on HN.
SPF/DKIM is literally how you establish sender identity instead of relying on the IP address of the email server so it is ironic to claim that they have anything to do with server reputation while lamenting a lack of sender reputation mechanisms.
Currently, SPF/DKIM are mostly used to prevent fraud, but they also provide the best tool we have to build sender based reputation systems.
> Unfortunately, that means that attempts by those larger providers to combat spam using such reputation will naturally hurt smaller providers.
Indeed. I am on a few mailing lists and many people on them host their own email. I use Gmail so that means visiting my spam inbox once a day to click "not spam" upward of a few dozen times. Day in and day out, same people end up in Googles spam folder. It's bullying and sabotage.
> No one says to themselves "Huh, this is from a Gmail address, it must be legit".
Indeed. I get a shit load of spam from google addresses so reputation is not there.
> We really want to keep track of sender reputation.
This is the hard part but I do think it's something to think about. I should be able to get an email from a known sender every time without $emailprovider making that decision for me. Some sort of attached signature or key that is proof of sender identity so I can route that right into my inbox.
To be fair, SPF saves mail.ru and outlook.com users from five, maybe six spam emails per month coming from my domain, based on DMARC reports. If those numbers scale to include every domain on the internet, that's a huge amount of spam being filtered out very easily and very early.
You'd think spammers would've learned to avoid SPF domains at the very least but they haven't, so despite SPF/DMARC/DKIM failing to get anyone out the spam folder, the technology is still catching spam bots.
While it may or may not reduce spam, it has definitely (based on my personal experience) reduced the amount of spoofed phishing emails and backscatter spam emails to nearly nothing.
In the early-to-mid '10s, before SPF/DKIM/DMARC became the law of the email land, one had to be much, much more careful with phishing emails, checking the wording, the logos, etc, because 9 out of 10 of them appeared to come from the actual domain the email purported to be from. In the past several years (I honestly don't know exactly when the change happened; I don't get a huge amount of phishing emails), it's shifted so that the first thing to check is the sender address. Usually that turns out to be some nonsense string @gmail.com or some long garbled domain.
All of these technologies are basically DOA because of how fickle they are and for lack of support across the board. Most policies are set to not to deny.
DMARC is nice though. It won't stop spam. It won't stop spoofing. But you will know that someone somewhere is spamming people using your domain name. How awesome. :)
I never found the DMARC reports actionable, so I quickly turned them off. What do you do with the information?
Of course, even with hard fail spf and dmarc, I still see some bounces from spam where some server accepted the mail to deliver it elsewhere and the next server denies it, so the first server sends me a bounce.
Trouble is, this is simply not true. My SPF and DKIM are fine. This makes me wonder whether the email ingestion system is simply broken for everyone.
—⁂—
2. I got involved in setting up a Google Workspace for someone a few months back, and the entire tool that their own documentation instructs you to use to check things, https://toolbox.googleapps.com/apps/checkmx/, has been laughably broken for years, sometimes not working at all, but mostly producing misleading nonsense results (e.g. claiming domains have no mail server set up when they do).
I observe the same thing. However, that does mean that SPF and DKIM are useless (although DMARC probably is).
It is correct that SPF/DKIM does not really avoid spam, because spammers are not stupid and can read these standards like anyone else. However, before SPF/DKIM, I remember that I got a ton of phishing mails with FROM containing "support@paypal.com" or similar. Then came Bayes spam filtering, and that would move legitimate mail from Paypal to spam, because obviously, the phishing mails are quite similar.
This problem has pretty much vanished, because Paypal clearly denotes which IP addresses are allowed to send mails from that domain via SPF and the client can verify the mail via DKIM. For instance, Spamassassin makes sure that mails with correct DKIM and from paypal.com get a massively reduced spam score so that your Bayes filter will not move it to spam. This is hardcoded for a lot of domains (see *welcomelist_dkim.cf).
I run my own email server. Most spam crap cannot pass spf/dkim. Although this post has caused me to sit up and notice that the trendline is moving in the unfortunate direction, where I'd say 3 years ago the ones that pass were about 1/4, today it feels like 40-60% pass. The amount of mail I get that I expect, passes spf/dkim at around 90-95%
I suspect the delta between their any my results are the very restrictive sender rules I have prior to accept. In addition any_address@domain goes to my default mailbox, so I'm also probably selecting for laziness a bit more than most.
I also publish an email address without obfuscation on my site, which is getting very little spam, (near zero) which makes me wonder if most spam has given up on scraping the Internet for emails these days.
It’s far easier to buy the email addresses of known good people by buying dumps of websites that got breached.
Web scraping gets you a lot of fake emails, company sinkholes, and other low reward stuff. Paying $20 for 100k confirmed real emails with names? That’s gold.
I think the problem isn't necessarily that adding DNS entries is hard (especially compared to the rest of the process of hosting your own email), but that getting a clear overview of what email tools an organization uses is difficult.
You need IT to list all of the reporting tools, customer service to tell you about their support system, marketing to tell you about their mailing list tool of the week, the sales guys to warn you they're using this new AI email enhancer, and somehow get that shady email forwarding service the CEO uses to give up their mail server IP addresses. Then you need to figure out how to get coverage for all of those tools and keep on top of them whenever something changes.
A lot of companies promise to do great things for you if you just enter the email address you'd like to send email from, and a lot of people gloss over the important details because those sound hard and when they tested the tool on their personal email it worked fine so that's probably unnecessary anyway! Managing email for a corporate domain can be like herding cats.
I think pretty much all email providers (and other systems that want to send on your behalf) have this. More or less the same process where they tell you what to add and then a "check my stuff" button to verify. Which is great.
Sounds good. As I said it was my first time, and I'd just glossed over the specs and did not look forward to it (I usually don't enjoy sysadmin work). So, was just pleasantly surprised.
Naively I thought that one value proposition of SPF, DKIM and DMARC is that reputation shifts from based on IP to be based on domain, once you set these up correctly. So as long as you can maintain a good reputation for your domain and have SPF, DKIM and DMARC correctly set up, then you can host your SMTP server at any IP and your emails will get delivered.
IMHO, their main advantage is that third parties can’t send email which appears to originate from my domain.
I configure my domain to use SPF, so now spammers can’t sign it properly.
However, the fact that an email passes SPF verification only ensures that it was authorised by the domain owner. It doesn’t say anything about whether the domain owner is a spammer.
It does work like that except nobody actually knows Google or Microsoft's algorithms to allow or deny mail delivery. It's the whole SEO thing all over again.
It does work that way, but IP reputation is a thing as well so you need to keep that in mind. IPs need to be "seasoned" and "trusted" as well as domains.
This is how email-as-infra works, you're sending from a shared pool of their ips and they sign your emails with DKIM and you'll have SPF set up as well on your own.
I've been running my own spam filter for many years now based on this super-simple heuristic: My filter looks at my outgoing mail, and any mail received from an address I've sent mail to, or with a subject that has appeared in my outgoing mail (possibly with a "re:" prefix) is marked as non-spam. Everything else goes in spam, and any spam message from an address I've never received mail from before is marked as unread. I get hundreds of spams per day, but only about a dozen from new addresses. It takes me about ten seconds to scan them for non-spam cold calls, which are extremely rare. The other source of false positives is things like subscription confirmations, but because I know to expect those, they are always at the top of the spam folder.
I put this initial system in place expecting to have to augment it later with a more traditional content-based filter, but this simple heuristic works so well I've never felt the need to implement that additional step.
Someone posted on X advice that really helped me clean up my inbox
Add a filter looking for the word "Unsubscribe" and automatically put them in "Promotional" category or something similar. Also apply the filter to existing emails, and let it run for a minute.
Try it now! And comment if it reduced your inbox to like 2% of what it was :)
I've commented here before that it is obvious to me that gmail makes no effort to combat spam anymore given that unsubscribe links are legally required and generally present for spam in the US and are an obvious heuristic that aren't used. I would expect basically any trained filter to pick up on it, so my assumption is that they actually intentionally have rules to allow spam.
I get emails that literally say "This is an email advertisement". These are presumably being blasted out to tons of mailboxes. How does a model not notice this?
I tried that a long time ago and the problem with it was that it produced a lot of false positives for me because I subscribe to a lot of Google Groups.
The problem with greylisting is that it delays subscription confirmation emails when you sign up for a new service. I found that to be more trouble than it was worth. YMMV.
Providers should really stop using spam folder and refuse email at the session lvl, that alone would fix the false positive issue. I had a rant [1] about it a while ago.
My biggest problem with SPF, DKIM, DMARC is when you go to test this crap there's really only commercial apps. So people who are setting up things for a non-profit or a personal project are either forced to pay after doing 3 or 4 test emails or you wait like 24 hours or some crap.
And all that just for the privilege of being able to send email to some gmail accounts. Trying to get email to properly encrypt is pulling teeth and yet I still get hundreds of thousands of spam a month on my gmail account.
Any time I have to set up an email server on a new system I just kind of die a little.
I built a free DMARC/DKIM/SPF checker: https://dmarcchecker.app/. No usage limits, no ads—just a small footer link to one of my other projects. Made it for the exact reason you mentioned.
That’s good to know. I’ve not seen it mentioned anywhere. The tools I’ve used in the past give me 3 or 4 test emails before they require me to sign up.
You can always first send it to yourself and read the Authentication-Results header. Though even Gmail displays SPF/DKIM/DMARC status when you view the raw source of an email.
DKIM is not meant to block spam, it's meant to authenticate that the sender had access to the private key for the public key exposed on the domain that it was sent from, implying that the sender has sufficient permissions to send from the domain.
It should not be used to imply anything else, none of these have anything to do with spam, that's reputation (and yes, having DKIM set-up boosts your reputation but it is not sufficient) and should be "built" up by the domains sending the emails.
You may be surprised to learn that spammers, being criminals, have no issue with stealing money from others to spend on email delivery fees.
Edit: Proof-of-work "email postage" schemes are similarly doomed - The botnet that zero-day'd your mail servers does not care how much electricity they use.
IP reputation, proof-of-work, and various fee-for-receipt schemes are trying to solve spam in the same way: by charging low-volume users a trifle to send messages at a "normal" rate, which adds up to become more expensive when you start bulk mailing. The problem is that these schemes have to assume that there is a single market-clearing price[0] for sending messages that is both low enough to not inconvenience legitimate users and high enough to make bulk messaging uneconomic.
Such a concept goes against how communications networks actually function. The amount of communications resources the average person uses is so low that it's not worth billing for them. Sending any sort of data isn't free, but it's "cheap as free[1]". Any communications technology that bets against this will fail in the marketplace. People are not going to go back to, say, buying (virtual) stamps at 73 cents[2] a piece to send mail with. Hell, the $10/GB I pay with Google Fi is already enough to make me cringe every time I actively use my data plan.
On the other side, charging a fee for misbehavior legitimizes that misbehavior; if the fee is less than the value of the misbehavior then you are just imposing a cost of business. Spammers need to send lots of mail because the rate at which people fall for your scam is comically low. But when you do hook a sucker in, they yield a huge return.
So what we have here is that legitimate users would balk at per-message rates that wouldn't even be close to what would make spammers flinch. Which is, again, the same problem that SPF/DKIM/DMARC have. People whose job it is to send garbage e-mail for a living have a far higher tolerance for Internet bureaucracy bullshit[3] than people who use e-mail to get their real work done or to talk to friends and family.
[0] Getting your IP banned for spamming or having to burn energy brute-forcing a hash can be considered a price.
Do you know of any data on this? It seems like the kind of thing that could be studied and measured. I'm inclined to believe the opposite about the viability of e-stamps, but I will readily admit I have no data to back that opinion up.
I know very little about these protocols, except for having to deal with them a bit on those few sad occasions I need to get a server to send email. From those experiences I had a strong sense that Google pushes out all these complicated and difficult procedures on everyone just as a means of discouraging people from using email servers in the first place...."just use google, we control the whole thing anyway".
Things have gone in the direction of being favorable for spammers.
* WHOIS is effectively destroyed.
* Companies like Cloudflare actively protect known spammers & scammers, and have made abuse reporting time consuming and error prone.
* Consolidation of most email to several large players means filtering them causes problems.
* Large delivery companies such as Sendgrid, Salesforce and Google basically do nothing about reported abuse.
Yes, most spammers these days that set up their own domains have tools to make sure DKIM, SPF and DMARC are all good, but consider that we can't know anything about these spammers: TLS certificates no longer contain contact information, large providers don't provide useful WHOIS, don't forward abuse complaints, have no clue what an SOA record is, and so on.
The way things should work is that we get a spam, we see the network from which the spam came through WHOIS, we forward the spam to their abuse address or the address they list in WHOIS, and we're done.
The way things work is that they don't have working information in WHOIS, they ignore the abuse complaints, they act like they don't know what to do with it, or they reply with a form email saying to go and use a web page where it takes time and work to paste in each part of a spam.
I blame the large companies who do this. Make reporting abuse difficult and you'll get much less reported abuse.
I used to run my own e-mail server for my personal address. In an attempt to reduce spam I configured Postfix to reject all inbound messages that weren't DKIM signed. The only time I ever had an issue was when somebody from the multinational publicly-traded company that I worked for tried to send a message to my personal inbox. They ran Exchange in the datacenter at the time (this would have been ~2017) and hadn't enabled DKIM signing. I had a friendly conversation with the sysadmin responsible for it and they had it enabled by the end of the week.
I suppose the moral of the story is that it's possible to do billions of dollars in business a year without having textbook-perfect mail infrastructure. Hell, I ran a mail server with bad MX records, a missing PTR record, and a mismatched HELO header and the world kept spinning (when I was a literal child with nobody to tell me better - I've since learned the error of my ways).
I have a much bigger issue with "legitimate" spam these days. Every service makes you give an email address, and they all force you to check a box allowing them to email you whatever they want. Then if they even have an "opt out" link, it takes you to a list of 500 different types of notifications and forces you to opt out of each one individually.
Usually I will just disable the iCloud hide-my-email I used for a site, but sometimes there are legitimate emails mixed in with the stream of crap. I opted out of marketing emails from my credit card company, and now they instead send me emails asking me to re-evaluate my email preferences...
It would be nice to see more done to fix this, but I guess it doesn't make anyone money. I guess I'll just have to use AI to filter signal from noise.
Of course they are.
It's how they make their money.
The big email providers generally don't make their money from selling email services,
it's a thing they offer as an in to sell the services that do generate profits.
On the other hand, successfully sending an email that bypasses both technical and human barriers is spammer's business.
To be clear, I'm not necessarily a fan of DMARC, particularly how it was introduced. But it is very obvious that spammers will eventually do everything to not be flagged as spammers.
What DMARC gives you is that it makes it less likely that your phishing mail will come from contact@yourbank.com. It will rather come from contact@y0urbank.com or some other domain.
How much of an improvement that is and how many people will notice is certainly debatable. But that's what DMARC can give you. Nothing more, nothing less.
Is there actually an "domain reputation as a service" provider, which controls a couple thousand gmail addresses, sends itself the emails and manually unmarks them as spam? Asking for a friend..........
Yeah, SPF, DKIM and DMARC are incomprehensible. The only people with the time, motivation and expertise to understand and apply them, are professional spammers. Most of the legitimate email I get, fail one or more of these tests.
If I recall, SPF limits the number of domains you can enumerate in your DNS records.
I have now sent messages to 3 companies that I am a customer of where their SPF, DKIM, and/or DMARC were failing - for things like initial signup emails.
we by far don't enforce them strict enough, because if we where people would make sure to get it right
it's all a question about effort/turnout
if you make it so that most times you mails still somehow end up with the user even if you mess them up there is much less insensitive for companies to fix their mail or force their provider to fix it
so IMHO if all of SPF,DKIM and DMARC are not correct setup mails should just be directly discarded and not even delivered to spam
while being more flexible was reasonable when this tech was new, that was 10 years ago. If being flexible mean that you also will sometime deliver outright cyber attacks like spear phishing and similar to your user and everyone had 10 years to fix their systems then there is really no reason to still be flexible.
Also "scammers get it right so it's useless" is such a huge red hearing argument, yes they do get it right _for their domains_. It sill makes it harder (and if strictly enforced impossible, except if you give them permissions to do that*) for them to impersonate your domains.
And yes that doesn't fix scammers from using their own domains, but it also was never intended to do so. Doing so is a very different problem one which probably needs some form of reputation system which isn't something you can just solve technically as it touches on a lot of subtle social political issues. Also given that all of the huge mail vendors have insensitive to use their "intern proprietary obscure" reputation system I don't expect there to be a technical solution provided/adopted tbh.
(and yes SPF/DKIM/DMARC are all tech wise quite "meh", but we are kinda stuck with them, through that never was the issue IMHO, the issue is missing insensitive to bring the adoption up and missing insensitive for large mail providers to enforce it strictly)
EDIT: PS: In one point they are fully right so, that is, with how things are you can't give SPF/DKIM/DMARC a large weight for calculating reputation. Also they where always only meant to tell you if someone can't be trusted, but never if someone can be trusted.
A better analogy would be a passport. It doesn’t stop all terrorists from boarding a plane at lest it stops already know to authorities ones (unless they have a passport on someone else’s name which is not easy).
Or perhaps, why do you lock the door to your house? A few solid kicks will open most doors, the locks can be picked, someone can smash windows and enter, and many modern homes can be entered by ripping the wall open with a crowbar and axe.
I forgot the name of this fallacy, I read about it in Nassim Taleb’s Antifragile a long time ago, but basically being wrong at spam won’t cause a lot of damage while being wrong once about a terrorist may cause thousands of deaths
For me, as someone with their own mail server, these technologies mostly serve to inform me that Russian IP addresses are still trying to send email in the name of my domain for some stupid reason.
It makes sense that people whose business is sending email know how to set up email correctly. I'm mostly surprised at how many legitimate sysadmins struggle with getting the basics correct. Surely those dozens of DMARC emails you get that your sendgrid email has been refused because of a bad SPF signature should set in motion some kind of plan to ask if maybe marketing is using them legitimately?
Automated signatures are of limited value but I rarely see rejections based on SPF and DKIM that are a mistake. Things are probably worse for big organizations but as a small email server, technical rejections are usually the right call. The only exception is mailing lists, but the dozens of people who still use those can usually figure out how to add an exception for them.
The problems I noticed were, it doesn't matter what the SPF and DKIM look like. If Google or Microsoft refuse to relay your email based on secret internal factors then you're out of business.
Best, and often practically only, way to avoid this problem is to buy your email services from Google Microsoft duopoly.
2 replies →
Microsoft seems to be the most common culprit.
2 replies →
Yes, and they do that routinely.
1 reply →
This attitude is just FUD.
The issue here generally boils down to the defining difference between a generalist Admin and a Messaging Admin. The generalist can follow instructions, and nearly all the instructions out there stop at the point where SPF/DKIM/DMARC are successfully implemented. A generalist worth their salt will then fill in the gaps if they can', and knows this isn't where you stop when you want mail deliverability. There's a higher bar.
If you follow instructions written by non-professionals blindly you don't ever reach the point where you get to quality work.
Google, Microsoft, and the other large ESPs don't refuse to relay your email based on secret internal factors. This is what the non-professional people say to falsely justify why they can't do something.
Google and Microsoft publish the internal factors they use in the form of whitepapers at the industry working group. Its not ready made, and there are a lot of them, and they may not release their specific implementation details, but the metrics are there and often are based in weighted form (reputation-based systems).
If you follow them correctly, and set up the appropriate reporting accounts, and maintain those accounts, you won't have these problems. You generally only have problems once you've violated guidelines continuously, which happens when you rely on, or are unable to discern between qualified and unqualified help.
The factors are published at https://www.m3aawg.org/
Every professional that specializes in email or messaging that I know of is well aware of this.
People don't have the same vitriol when it comes to comparing Generalist Admins to DBAs, and this is the same with any specialized niche.
If you need email and messaging to work in a complex environment, you hire a person that specializes in it.
12 replies →
> Russian IP addresses are still trying to send email in the name of my domain for some stupid reason
For what it's worth, I've started seeing cybersecurity insurers requiring riders and extra payments if you don't block Russian IPs.
But there are big problems with mapping from IPs to countries. My IPv6 is detected as Russian, though it is London-located tunnel exit point and I'm in the Netherlands.
9 replies →
Ive got a server hosting a number of things, amd monitoring setup for a lot of stats. Got tired of seeing blips because various countries were beating on my server, not a DoS, but enough requests to notice, and sometimes generate an alert. I blocked 7 countries, in full, and the impact was fantastic. No more 2gb of logs generated every day by countries that have no business accessing my server.
Unless you own a global business, i see no reason to even allow other countries access. The potential for attacks is too great, especially from some very specific countries.
21 replies →
Ok but you can’t block someone else using their own IPs to send email.
If you set DMARC to report, you’ll get notices from remote email systems when they receive noncompliant emails with your domain in the Envelope From field. Those reports are where you’ll see Russian IP addresses show up when they are trying to spoof your emails.
But there is no way to block them because neither the senders nor receivers are on your infrastructure. The best you can do is set a reject DMARC policy and hope everyone follows it.
As a non-email guy, I can tell you that if a system that boils down to having an (optionally certified?) key requires much more than just putting it into a folder with a domain name and running a service, it’s badly designed and has unnecessary complexity. Which will result into abusers having more expertise than legitimate users. The fact that you can “get” DMARC SPF DKIM wrong, while it’s basically a hard requirement for operation, is just screaming something important to the email software.
As a generalist admin, would you say the same about DBA operations or would you say that's just not my specialty?
The reasoning you provide doesn't differentiate, and speaks more of frustration which naturally comes with any area you aren't steeped in, or knowledgeable about.
8 replies →
In most organizations there is no point in a sysadmin to spend the effort in understanding how to set it up correctly as Marketing has got more authority on email. Marketing will simply demand changes to the config that they do not understand and there is nothing you can do to stop it as they will have the CEO on their side.
> Marketing will simply demand changes to the config that they do not understand and there is nothing you can do to stop it as they will have the CEO on their side.
Marketing should get their own (sub)domain for sending their missives, that way the primary corporate domain's reputation is not harmed.
Unless you want to run the risk of outgoing e-mails from Finance / Accounts Receivable to be sent to other companies' Junk folder.
3 replies →
Orgs like that will hire consultants like me when they can't figure out why their stuff isn't landing in the inbox. Then 3 months later their webdev will somehow delete the entire zone when adding their A record.
You mean like the time I had a salesperson demanding that we turn off Cloudflare across our entire domain because he'd read some random article somewhere saying we should?
4 replies →
Which is another reason to strictly enforce SPF and DKIM, in my book. Let marketing break those policies, that way I don't need to bother with reading your company's spam!
Marketing decides on DKIM and SPF ?
6 replies →
even worse when you have even less control than that, if you run some type of hosting and are trying to convince non-technical clients (or even worse, non technical clients who think they are technical) to “please just add this record exactly as it says here to your domain” and they’re somehow unable to for months and months
2 replies →
to be fair here: for a lot of companies, if the mass mailing stops, the money-flow stops then that's no good for anyone... so the CEO will probably err on the side of money, presumably.
1 reply →
As someone who set these up, I can tell you, the answer is rather simple:
- spammers have 1 system to set up in order to spam. They get it right.
- company admins have dozens of projects, of which this is a tiny one, with zero ROI to the bottom line (if people don't consider how critical security is). So they delay.
- companies often have dozens of systems integrated, when I set up DMARC/DKIM the first time for my company, a bunch of email tools broke, we had to do a bunch of leg work, took us a month end-to-end. The value was recognized when we almost lost 20k to a "ceo emails you" scam. But until then it wasn't a priority.
- we didn't even have a full IT, i just stepped in because I cared enough.
- my current company has a dedicated security team. These holes are plugged VERY quickly.
> that Russian IP addresses are still trying to send email in the name of my domain for some stupid reason
You can set your policy to reject, that will deter the Russians from using your domain.
I used to have my policy set to reject, but then I found out some part of an Enterprise Outlook mail filtering chain was rewriting the mail I sent before checking the DKIM signature. I can't fix stupid, especially for other parties, so I changed the policy to quarantine instead.
I doubt Russian spammers will care about the difference to be honest. If they accept that their email will be delivered to spam folders, why would they care that the email gets silently dropped? In neither case anyone is going to fall for them.
1 reply →
I am just having this problem. Actually getting SPF, DKIM and DMARC right and having a domain with a 0 spam score will still land you in the spam directory. It turns out, you need to have a "reputation"? before your email gets accepted into gmail. My head was spinning as to how that reputation will be built if your email just goes straight to spam.
But sure, Linkedin emails are definitively not spam and their dark-patterns at adding you at n+1 emailing list doesn't get them banned from the big (or any?) provider.
It's easy, you just have to have a regular, decently sized volume of non-spam emails, and suddenly your email stops being marked as spam!
The logic isn't even that bad. SPF and DKIM serve to prove to the email who the sender is. That doesn't mean much if the sender is a spammer. Verifying identity claims is only the first part in checking email for spam, the harder part is checking if that identity is someone you trust.
When you email Outlook or Google, you're better sending more than a few every single day, and the recipient better manually drag those emails from their spam folders to their inbox, or they're all being learned as spam.
And you have to build up the volume gradually. In the industry this is called "warming up IP addresses". See for example https://help.elasticemail.com/en/articles/2788598-how-to-war... or https://docs.aws.amazon.com/ses/latest/dg/dedicated-ip-warmi...
1 reply →
> you just have to have a regular, decently sized volume of non-spam emails
But if you have a regular decent size of emails coming from your domain, that is more likely to be spam than if you have a small number of intermittent emails coming from a domain.
so my personal domain just needs to send newsletters to millions of people, or ... how exactly? what's decent size? how frequently?
> It's easy, you just have to have a regular, decently sized volume of non-spam emails, and suddenly your email stops being marked as spam!
The domain is new and didn't send a single email until I tested it.
Edit: The domain is actually a bit old but was parked/inactive for a while, though the email was used only for receiving.
7 replies →
I worked on this for a while, at a time and in a market where most of our recipients had @hotmail addresses. I discovered that mass email sending was akin to a "pay-to-win" game.
We had/opted to acquire the services of a company "expert in email deliverability" (Return Path), who somehow provided detailed metrics of how our IPs were scored by MSFT. I always wondered why MSFT didn't provide those scores by themselves, and how a 3rd. party could have access to them.
Re. your comment... slow ramp-up is the only way, with constant monitoring of deliverability and consequent adjusting of recipients (i.e. removing those who do not open or hard-bounce). I did also wonder if paying that company perhaps gave us a headstart when adding new IPs...
Turn on dmarc reporting. There are loads of tools to read the resulting xml.
It's almost like all those bad actors (linkedin) are owned and controlled by the big players (microsoft) that benefit from email being only commodity they can provide.
I think the domain rep is worth less than IP rep. I had occasional issues sending issues when I self hosted on a VPS. When I moved my domain to Fastmail I haven’t ever had my emails go to spam.
Most home and VPS IP ranges have negative rep.
As a tip, go to a VPS that's had a history of being very selective of allowing SMTP traffic but still allows after some kind of review. Cheap providers that never did any blocking probably have bad reputations for their entire address range.
I've been successfully using VPSes to send emails for 20 years.
I am sending from SES. Interestingly, I didn't have a problem getting the email delivered to inbox in fastmail despite having an aggressive "protection level".
This isn't a problem for personal emails, as after a request or two friends will unspam you. Google blackholes emails, breaking all mail logic (no bounce), so I assure you the SPAM folder is a good gmail sign.
I would imagine that on the corporate side, your employees could do the same. Beyond that, if you're sending spammy stuff, have unsubscribe headers and links in emails.
If it's a new domain, then your problem isn't reputation exactly, it's having a newly-registered domain. Buying a new domain, setting up the SPF, DKIM, and MARC, and then immediately spamming from it until it's banned everywhere a week later is standard spammer MO.
I've been self-hosting mail for me and my family for about 20 years and don't send nearly enough mail to have a "reputation" with anybody. Still, I don't have any problems with deliverability of mail.
> Actually getting SPF, DKIM and DMARC right and having a domain with a 0 spam score will still land you in the spam directory.
This little bit of wisdom gets passed around all the time, but it's actually not true. You can send email from a brand new domain to Google and Microsoft and whoever just fine. What you can't do is send email from a brand new domain, and a brand new email server--or an email server on a VPS, or an email server on a residential IP. Residential IP blocks are almost completely blocked, because of unsecured devices being used to send spam, and VPS blocks have the same problem. You can get around this by using a mail relay, or building your domains reputation on a server that already has a good reputation.
> or an email server on a VPS, or an email server on a residential IP
So what options are left for a self-hoster. Colo?
2 replies →
SPF/DKIM is really about mail server reputation. So it mostly benefits larger servers like the ones run by Google, Microsoft and Yahoo. Unfortunately, that means that attempts by those larger providers to combat spam using such reputation will naturally hurt smaller providers. So the actual effects of SPF/DKIM are on the whole negative.
The root problem is that we don't actually need to keep track of email server reputation. No one says to themselves "Huh, this is from a Gmail address, it must be legit". We really want to keep track of sender reputation. We need to be able to treat anonymous email differently than email from people we actually know. That implies that we have some work to do on the problem of identity. As it is, there is not even a way for a known email sender to securely introduce an unknown email sender. You know, the way that regular human people normally are able to transfer identities from one to the other.
>SPF/DKIM is really about mail server reputation. So it mostly benefits larger servers like the ones run by Google, Microsoft and Yahoo. Unfortunately, that means that attempts by those larger providers to combat span using such reputation will naturally hurt smaller providers. So the actual effects of SPF/DKIM are on the whole negative.
That paragraph is incorrect. SPF/DKIM is not about reputation. The main purpose is preventing domain impersonation from unauthorized senders. E.g. mail servers will reject fake emails from "upofadown@microsoft.com" because you don't control any email servers that's whitelisted in microsoft.com DNS TXT records.
E.g. I was able to register a brand new .com address and then successfully send to gmail and MS Outlook accounts within minutes because I had proper SPF/DKIM in the DNS records for that new domain. That new domain had zero reputation and yet Gmail accepted it because SPF/DKIM was configured correctly -- and -- the underlying ip address of the server it came from had a good reputation.
If SPF/DKIM was truly about "reputation", it would mean I'd have to wait days or months for reputation history to build up before Gmail accepted it.
preventing impersonation is an important part on correctly attributing reputation to source domains.
1 reply →
Exactly. The people bashing SPF & DKIM don't seem to understand their intended purpose.
And it will mysteriously _stop_ being able to send mail to Google despite you doing everything right, because of whatever nonsense they use to determine reputation.
1 reply →
I don't think this is correct? SPF and DKIM are about ensuring that the server actually is who it says it is, not about its reputation. In other words, when you receive an email that claims to be from Gmail, SPF and DKIM help you ensure that's where the letter actually came from, not from a server just pretending to be one of Gmail's servers.
SPF more like whether the email came from a server that's authorized to send emails on behalf of a particular domain.
The foundation of reputation is reliable identity.
> Unfortunately, that means that attempts by those larger providers to combat spam using such reputation will naturally hurt smaller providers
Tin-foil hat time, but I've always thought there was nothing unintentional or "unfortunate" (from Google's perspective) about this.
While there's some truth to that, neither SPF nor DKIM nor DMARC have anything at all to do with reputation.
They serve to authenticate that the sender is somewhat connected to the person who controls that sending domain.
> That implies that we have some work to do on the problem of identity. As it is, there is not even a way for a known email sender to securely introduce an unknown email sender.
There is: gpg/pgp signature, but many people find it complicated, primarily because they are reluctant to read the documentation. And it’s popular to criticize it, especially here on HN, in favor of various half-baked alternatives.
I think everyone can agree that any technology that "isn't complicated if you read the documentation" is by definition complicated. I don't need to read the documentation for Gmail to use Gmail successfully.
Could I, as a trained programmer, use PGP and GPG? I'm sure I could if I spent some time reading about it. Could my 90 year old grandmother, who is otherwise quite comfortable with email and whatsapp? No, not to any meaningful extent.
7 replies →
> many people find it complicated
That's what kills a lot of these "perfect" implementations.
HN members tend to be nerds, and we don't really have an issue with setting stuff up (many HN IDs, for instance, have Keybase auths).
Most non-HN types have no patience for that stuff. Security needs to be made accessible and easy-to-use, before the vast majority of folks will implement it. That's the single biggest conundrum, IMNSHO.
We really need a "Trust on First Use"(TOFU) system for messaging, that can be verifified, or pre-trusted offline, face to face. It'd be awfully nice for your bank to give you some thing that you can later verify that any communication from them (web site, online banking, text message, email, etc) are legit and verified.
Or if we can't trust users to handle TOFU, then some token/unique address/whatever that we can exchange face to face to enable trusted communication.
> We need to be able to treat anonymous email differently than email from people we actually know.
The simplest solution to that would be an "only show me emails from people in my address book" filter. That would mostly echo how we treat user trust on all other platforms. Genuinely surprised this doesn't exist in most email clients (or does it and I have just overlooked it so far?)
Of course that's only a partial solution and wouldn't work for accounts where you expect unsolicited mails from people you don't know. I'd see it more as a "low-hanging fruit" solution. You could also expand the heuristic, e.g. also consider previous conversations, mailing lists, etc.
(Interestingly, the "introduce a friend" functionality would come for free: You can already send contact details as a VCard in an attachment. When receiving such a mail, some email clients will show a button to quickly add the contact to the address book.)
> only a partial solution and wouldn't work for accounts where you expect unsolicited mails from people you don't know.
I actually think this would work fine. Imagine a quarantine inbox for new emailers that the user must scan and approve/block. This is exactly what hey has implemented.
> The root problem is that we don't actually need to keep track of email server reputation.
We actually do. Is the server allowing anyone to sign up so that it's sending 99% spam, or does it have a lot of anti-spam measures so sign-ups can't be automated and it blocks accounts as soon as it detects them sending spam?
> As it is, there is not even a way for a known email sender to securely introduce an unknown email sender. You know, the way that regular human people normally are able to transfer identities from one to the other.
That's exactly what PGP's web of trust model is for. Someone you know, and trust, can sign and send you a public key of someone that they trust.
This new key will be automatically trusted in your trust store because it's signed by someone you already trust, although in a lesser trust level to account for the degree of separation. If you later verify that key out of band you can upgrade it to a higher trust level.
SPF/DKIM, as well as TLS etc., is just stupid shit we do because we're too lazy and/or incompetent to make web of trust work for us. It's not a technology problem, it's a human problem.
> SPF/DKIM, as well as TLS etc., is just stupid shit we do because we're too lazy and/or incompetent to make web of trust work for us.
Having key signing parties for the entire world wide web does not seem scalable to me.
* https://en.wikipedia.org/wiki/Key_signing_party
1 reply →
Well, yeah, we should use preexisting standards and OpenPGP would be perfectly fine here and is probably the best choice. That is a wheel we do not need to reinvent. But the actual system used to do the signatures and keep track of the reputation is the last thing we should be thinking about at this point. We should instead concentrate on how to create a system that the majority of people can use and understand. We should be concentrating on standardizing concepts...
1 reply →
It's weird so see such a factually incorrect comment so high up on HN.
SPF/DKIM is literally how you establish sender identity instead of relying on the IP address of the email server so it is ironic to claim that they have anything to do with server reputation while lamenting a lack of sender reputation mechanisms.
Currently, SPF/DKIM are mostly used to prevent fraud, but they also provide the best tool we have to build sender based reputation systems.
> Unfortunately, that means that attempts by those larger providers to combat spam using such reputation will naturally hurt smaller providers.
Indeed. I am on a few mailing lists and many people on them host their own email. I use Gmail so that means visiting my spam inbox once a day to click "not spam" upward of a few dozen times. Day in and day out, same people end up in Googles spam folder. It's bullying and sabotage.
> No one says to themselves "Huh, this is from a Gmail address, it must be legit".
Indeed. I get a shit load of spam from google addresses so reputation is not there.
> We really want to keep track of sender reputation.
This is the hard part but I do think it's something to think about. I should be able to get an email from a known sender every time without $emailprovider making that decision for me. Some sort of attached signature or key that is proof of sender identity so I can route that right into my inbox.
The point of SPF/DKIM/DMARC is to bind emails to domains, so no more spoofing. It is naive to expect authentication alone can reduce spams.
To be fair, SPF saves mail.ru and outlook.com users from five, maybe six spam emails per month coming from my domain, based on DMARC reports. If those numbers scale to include every domain on the internet, that's a huge amount of spam being filtered out very easily and very early.
You'd think spammers would've learned to avoid SPF domains at the very least but they haven't, so despite SPF/DMARC/DKIM failing to get anyone out the spam folder, the technology is still catching spam bots.
While it may or may not reduce spam, it has definitely (based on my personal experience) reduced the amount of spoofed phishing emails and backscatter spam emails to nearly nothing.
In the early-to-mid '10s, before SPF/DKIM/DMARC became the law of the email land, one had to be much, much more careful with phishing emails, checking the wording, the logos, etc, because 9 out of 10 of them appeared to come from the actual domain the email purported to be from. In the past several years (I honestly don't know exactly when the change happened; I don't get a huge amount of phishing emails), it's shifted so that the first thing to check is the sender address. Usually that turns out to be some nonsense string @gmail.com or some long garbled domain.
All of these technologies are basically DOA because of how fickle they are and for lack of support across the board. Most policies are set to not to deny.
DMARC is nice though. It won't stop spam. It won't stop spoofing. But you will know that someone somewhere is spamming people using your domain name. How awesome. :)
I never found the DMARC reports actionable, so I quickly turned them off. What do you do with the information?
Of course, even with hard fail spf and dmarc, I still see some bounces from spam where some server accepted the mail to deliver it elsewhere and the next server denies it, so the first server sends me a bounce.
2 replies →
Finally, a comment that understands the concepts instead of insolently ranting about how useless it is.
It feels similar to people conflating green https check marks in browsers and trustworthiness.
1 reply →
Google are bad at SPF and DKIM.
—⁂—
1. I tried responding to a Chromium bug tracker message by email a couple of months ago, and it failed me:
> Unfortunately, your email to create/update an issue was not processed.
> Reason: SPF/DKIM check failed. Please ensure your domain supports SPF (https://support.google.com/a/answer/178723) and DKIM (https://support.google.com/a/answer/174124). If your domain does not support them, please use the Google Issue Tracker UI (https://issuetracker.google.com).
Trouble is, this is simply not true. My SPF and DKIM are fine. This makes me wonder whether the email ingestion system is simply broken for everyone.
—⁂—
2. I got involved in setting up a Google Workspace for someone a few months back, and the entire tool that their own documentation instructs you to use to check things, https://toolbox.googleapps.com/apps/checkmx/, has been laughably broken for years, sometimes not working at all, but mostly producing misleading nonsense results (e.g. claiming domains have no mail server set up when they do).
Then, to make it even more absurd, the feedback link they give you, https://toolbox.googleapps.com/apps/main/feedback?toolname=c..., iframes https://docs.google.com/a/google.com/forms/d/e/1FAIpQLSdnlp8..., but you haven’t been allowed to iframe such documents for I don’t know how long so it doesn’t load, and even if it did, it’s a private form that only Googlers, I suppose, can fill in. And there have been plenty of reports about all of this for years, and it’s still broken.
I observe the same thing. However, that does mean that SPF and DKIM are useless (although DMARC probably is).
It is correct that SPF/DKIM does not really avoid spam, because spammers are not stupid and can read these standards like anyone else. However, before SPF/DKIM, I remember that I got a ton of phishing mails with FROM containing "support@paypal.com" or similar. Then came Bayes spam filtering, and that would move legitimate mail from Paypal to spam, because obviously, the phishing mails are quite similar.
This problem has pretty much vanished, because Paypal clearly denotes which IP addresses are allowed to send mails from that domain via SPF and the client can verify the mail via DKIM. For instance, Spamassassin makes sure that mails with correct DKIM and from paypal.com get a massively reduced spam score so that your Bayes filter will not move it to spam. This is hardcoded for a lot of domains (see *welcomelist_dkim.cf).
No they're not.
I run my own email server. Most spam crap cannot pass spf/dkim. Although this post has caused me to sit up and notice that the trendline is moving in the unfortunate direction, where I'd say 3 years ago the ones that pass were about 1/4, today it feels like 40-60% pass. The amount of mail I get that I expect, passes spf/dkim at around 90-95%
I suspect the delta between their any my results are the very restrictive sender rules I have prior to accept. In addition any_address@domain goes to my default mailbox, so I'm also probably selecting for laziness a bit more than most.
I also publish an email address without obfuscation on my site, which is getting very little spam, (near zero) which makes me wonder if most spam has given up on scraping the Internet for emails these days.
It’s far easier to buy the email addresses of known good people by buying dumps of websites that got breached.
Web scraping gets you a lot of fake emails, company sinkholes, and other low reward stuff. Paying $20 for 100k confirmed real emails with names? That’s gold.
Moved my mail over to Proton and they had a very nice process that made it easy to add the required DNS entries and verify that they were correct.
I was dreading this step as I hadn't done it before but turned out to be a breeze thanks to that.
I think the problem isn't necessarily that adding DNS entries is hard (especially compared to the rest of the process of hosting your own email), but that getting a clear overview of what email tools an organization uses is difficult.
You need IT to list all of the reporting tools, customer service to tell you about their support system, marketing to tell you about their mailing list tool of the week, the sales guys to warn you they're using this new AI email enhancer, and somehow get that shady email forwarding service the CEO uses to give up their mail server IP addresses. Then you need to figure out how to get coverage for all of those tools and keep on top of them whenever something changes.
A lot of companies promise to do great things for you if you just enter the email address you'd like to send email from, and a lot of people gloss over the important details because those sound hard and when they tested the tool on their personal email it worked fine so that's probably unnecessary anyway! Managing email for a corporate domain can be like herding cats.
I think pretty much all email providers (and other systems that want to send on your behalf) have this. More or less the same process where they tell you what to add and then a "check my stuff" button to verify. Which is great.
Sounds good. As I said it was my first time, and I'd just glossed over the specs and did not look forward to it (I usually don't enjoy sysadmin work). So, was just pleasantly surprised.
I moved to Fastmail, and they have a nice guide to set up what's needed on DNS:
https://www.fastmail.help/hc/en-us/articles/360060591153-Man...
Naively I thought that one value proposition of SPF, DKIM and DMARC is that reputation shifts from based on IP to be based on domain, once you set these up correctly. So as long as you can maintain a good reputation for your domain and have SPF, DKIM and DMARC correctly set up, then you can host your SMTP server at any IP and your emails will get delivered.
I wonder why it doesn't work this way.
IMHO, their main advantage is that third parties can’t send email which appears to originate from my domain.
I configure my domain to use SPF, so now spammers can’t sign it properly.
However, the fact that an email passes SPF verification only ensures that it was authorised by the domain owner. It doesn’t say anything about whether the domain owner is a spammer.
domains are cheap and easy to get new ones. IPv4 addresses are limited so you can't burn them as freely.
Do you imply that sending e-mail via IPv6 doesn't work?
It does work like that except nobody actually knows Google or Microsoft's algorithms to allow or deny mail delivery. It's the whole SEO thing all over again.
It does work that way, but IP reputation is a thing as well so you need to keep that in mind. IPs need to be "seasoned" and "trusted" as well as domains.
This is how email-as-infra works, you're sending from a shared pool of their ips and they sign your emails with DKIM and you'll have SPF set up as well on your own.
Cause IP is a finite resource (even IPv6 where the granularity is more like /48) while domains are infinite.
See https://en.wikipedia.org/wiki/Sybil_attack
I've been running my own spam filter for many years now based on this super-simple heuristic: My filter looks at my outgoing mail, and any mail received from an address I've sent mail to, or with a subject that has appeared in my outgoing mail (possibly with a "re:" prefix) is marked as non-spam. Everything else goes in spam, and any spam message from an address I've never received mail from before is marked as unread. I get hundreds of spams per day, but only about a dozen from new addresses. It takes me about ten seconds to scan them for non-spam cold calls, which are extremely rare. The other source of false positives is things like subscription confirmations, but because I know to expect those, they are always at the top of the spam folder.
I put this initial system in place expecting to have to augment it later with a more traditional content-based filter, but this simple heuristic works so well I've never felt the need to implement that additional step.
Someone posted on X advice that really helped me clean up my inbox
Add a filter looking for the word "Unsubscribe" and automatically put them in "Promotional" category or something similar. Also apply the filter to existing emails, and let it run for a minute.
Try it now! And comment if it reduced your inbox to like 2% of what it was :)
I've commented here before that it is obvious to me that gmail makes no effort to combat spam anymore given that unsubscribe links are legally required and generally present for spam in the US and are an obvious heuristic that aren't used. I would expect basically any trained filter to pick up on it, so my assumption is that they actually intentionally have rules to allow spam.
I get emails that literally say "This is an email advertisement". These are presumably being blasted out to tons of mailboxes. How does a model not notice this?
4 replies →
I tried that a long time ago and the problem with it was that it produced a lot of false positives for me because I subscribe to a lot of Google Groups.
2 replies →
I'm using something very similar, except incoming messages from never-seen-before senders are greylisted instead:
https://en.wikipedia.org/wiki/Greylisting_(email)
95% of spammers never retry.
The problem with greylisting is that it delays subscription confirmation emails when you sign up for a new service. I found that to be more trouble than it was worth. YMMV.
2 replies →
Providers should really stop using spam folder and refuse email at the session lvl, that alone would fix the false positive issue. I had a rant [1] about it a while ago.
[1]: https://www.kuon.ch/post/2024-09-16-email-rant/
> Surely everyone (and by everyone I mean Google) is rejecting their mail? How do they not realize this?
Not sending email to google helps.
My biggest problem with SPF, DKIM, DMARC is when you go to test this crap there's really only commercial apps. So people who are setting up things for a non-profit or a personal project are either forced to pay after doing 3 or 4 test emails or you wait like 24 hours or some crap.
And all that just for the privilege of being able to send email to some gmail accounts. Trying to get email to properly encrypt is pulling teeth and yet I still get hundreds of thousands of spam a month on my gmail account.
Any time I have to set up an email server on a new system I just kind of die a little.
I built a free DMARC/DKIM/SPF checker: https://dmarcchecker.app/. No usage limits, no ads—just a small footer link to one of my other projects. Made it for the exact reason you mentioned.
This is awesome. Thanks! Sensible, easy to use, easy to understand the results.
I've been trying the google one, for example, and it doesn't even work. "request timed out." Fishy, because yours works great.
much appreciated!
I use https://www.mail-tester.com/
[dead]
Yopmail does verify and show these results for free when receiving a mail, this not even being their core feature
That’s good to know. I’ve not seen it mentioned anywhere. The tools I’ve used in the past give me 3 or 4 test emails before they require me to sign up.
You can always first send it to yourself and read the Authentication-Results header. Though even Gmail displays SPF/DKIM/DMARC status when you view the raw source of an email.
Which works great unless you're trying to debug gmail refusing your emails because of some issue or another.
DKIM is not meant to block spam, it's meant to authenticate that the sender had access to the private key for the public key exposed on the domain that it was sent from, implying that the sender has sufficient permissions to send from the domain.
It should not be used to imply anything else, none of these have anything to do with spam, that's reputation (and yes, having DKIM set-up boosts your reputation but it is not sufficient) and should be "built" up by the domains sending the emails.
Spammers are worse at something no one tried to use AFAIK: require a fee to deliver email.
You may be surprised to learn that spammers, being criminals, have no issue with stealing money from others to spend on email delivery fees.
Edit: Proof-of-work "email postage" schemes are similarly doomed - The botnet that zero-day'd your mail servers does not care how much electricity they use.
Criminals yes, criminal spammers no. If they could make money with other crime there would be no point in wasting their time with sending spam.
4 replies →
No, they will happily pay money to spam you.
IP reputation, proof-of-work, and various fee-for-receipt schemes are trying to solve spam in the same way: by charging low-volume users a trifle to send messages at a "normal" rate, which adds up to become more expensive when you start bulk mailing. The problem is that these schemes have to assume that there is a single market-clearing price[0] for sending messages that is both low enough to not inconvenience legitimate users and high enough to make bulk messaging uneconomic.
Such a concept goes against how communications networks actually function. The amount of communications resources the average person uses is so low that it's not worth billing for them. Sending any sort of data isn't free, but it's "cheap as free[1]". Any communications technology that bets against this will fail in the marketplace. People are not going to go back to, say, buying (virtual) stamps at 73 cents[2] a piece to send mail with. Hell, the $10/GB I pay with Google Fi is already enough to make me cringe every time I actively use my data plan.
On the other side, charging a fee for misbehavior legitimizes that misbehavior; if the fee is less than the value of the misbehavior then you are just imposing a cost of business. Spammers need to send lots of mail because the rate at which people fall for your scam is comically low. But when you do hook a sucker in, they yield a huge return.
So what we have here is that legitimate users would balk at per-message rates that wouldn't even be close to what would make spammers flinch. Which is, again, the same problem that SPF/DKIM/DMARC have. People whose job it is to send garbage e-mail for a living have a far higher tolerance for Internet bureaucracy bullshit[3] than people who use e-mail to get their real work done or to talk to friends and family.
[0] Getting your IP banned for spamming or having to burn energy brute-forcing a hash can be considered a price.
[1] Buy all our playsets and toys!
[2] Current price of USPS letter postage
[3] In the Graeberian sense
Do you know of any data on this? It seems like the kind of thing that could be studied and measured. I'm inclined to believe the opposite about the viability of e-stamps, but I will readily admit I have no data to back that opinion up.
Sorry, I didn't clarify something.
Require a fee to deliver email. If the email is deemed legitimate by the recipient then refund the fee.
> No, they will happily pay money to spam you
It's a question of price. They can't spam at scale at high enough price.
You may have success checking for common tracking and advertising elements in a mail. Good chance it's spam if there's not 100 trackers. Frustrating.
I know very little about these protocols, except for having to deal with them a bit on those few sad occasions I need to get a server to send email. From those experiences I had a strong sense that Google pushes out all these complicated and difficult procedures on everyone just as a means of discouraging people from using email servers in the first place...."just use google, we control the whole thing anyway".
Things have gone in the direction of being favorable for spammers.
* WHOIS is effectively destroyed.
* Companies like Cloudflare actively protect known spammers & scammers, and have made abuse reporting time consuming and error prone.
* Consolidation of most email to several large players means filtering them causes problems.
* Large delivery companies such as Sendgrid, Salesforce and Google basically do nothing about reported abuse.
Yes, most spammers these days that set up their own domains have tools to make sure DKIM, SPF and DMARC are all good, but consider that we can't know anything about these spammers: TLS certificates no longer contain contact information, large providers don't provide useful WHOIS, don't forward abuse complaints, have no clue what an SOA record is, and so on.
The way things should work is that we get a spam, we see the network from which the spam came through WHOIS, we forward the spam to their abuse address or the address they list in WHOIS, and we're done.
The way things work is that they don't have working information in WHOIS, they ignore the abuse complaints, they act like they don't know what to do with it, or they reply with a form email saying to go and use a web page where it takes time and work to paste in each part of a spam.
I blame the large companies who do this. Make reporting abuse difficult and you'll get much less reported abuse.
It is incredible how the vast majority of the problems with the internet have their root cause in the activities of marketers.
I used to run my own e-mail server for my personal address. In an attempt to reduce spam I configured Postfix to reject all inbound messages that weren't DKIM signed. The only time I ever had an issue was when somebody from the multinational publicly-traded company that I worked for tried to send a message to my personal inbox. They ran Exchange in the datacenter at the time (this would have been ~2017) and hadn't enabled DKIM signing. I had a friendly conversation with the sysadmin responsible for it and they had it enabled by the end of the week.
I suppose the moral of the story is that it's possible to do billions of dollars in business a year without having textbook-perfect mail infrastructure. Hell, I ran a mail server with bad MX records, a missing PTR record, and a mismatched HELO header and the world kept spinning (when I was a literal child with nobody to tell me better - I've since learned the error of my ways).
I have a much bigger issue with "legitimate" spam these days. Every service makes you give an email address, and they all force you to check a box allowing them to email you whatever they want. Then if they even have an "opt out" link, it takes you to a list of 500 different types of notifications and forces you to opt out of each one individually.
Usually I will just disable the iCloud hide-my-email I used for a site, but sometimes there are legitimate emails mixed in with the stream of crap. I opted out of marketing emails from my credit card company, and now they instead send me emails asking me to re-evaluate my email preferences...
It would be nice to see more done to fix this, but I guess it doesn't make anyone money. I guess I'll just have to use AI to filter signal from noise.
Related: there are known problems with DKIM, and there's a DKIM2 effort:
* https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motiva...
* https://datatracker.ietf.org/wg/dkim/about/
* https://blog.redsift.com/email/dkim/first-look-at-dkim2-the-...
The recently-held IETF 122 had a session on it:
* https://www.youtube.com/watch?v=o-0OKfyLlBs
I'd also like to see an update to DMARC so you can require both SPF and DKIM in your policy, instead of just one out of the two.
Terrible idea, SPF is very hostile to (legitimate) forwarding. In general SPF should actually die.
9 replies →
Of course they are. It's how they make their money. The big email providers generally don't make their money from selling email services, it's a thing they offer as an in to sell the services that do generate profits. On the other hand, successfully sending an email that bypasses both technical and human barriers is spammer's business.
Rights of passage in sw-dev and IT is to propose a solution or re-implement something like many before you. Mine on email SPAM: https://paulhammant.com/blog/did-you-send-this
This is missing the point.
To be clear, I'm not necessarily a fan of DMARC, particularly how it was introduced. But it is very obvious that spammers will eventually do everything to not be flagged as spammers.
What DMARC gives you is that it makes it less likely that your phishing mail will come from contact@yourbank.com. It will rather come from contact@y0urbank.com or some other domain.
How much of an improvement that is and how many people will notice is certainly debatable. But that's what DMARC can give you. Nothing more, nothing less.
Is there actually an "domain reputation as a service" provider, which controls a couple thousand gmail addresses, sends itself the emails and manually unmarks them as spam? Asking for a friend..........
I use NameCheap for domain registration, web hosting, and email.
Unless I pay extra for Premium DNS, my DKIM is set wrong because their Web Hosting DNS does not oet me set it correctly.
> Rejecting mail based solely on authentication failures of those deeply flawed authentication methods does more harm than good.
How is DKIM "deeply flawed"?
Mission accomplished.
Nobody wants to solve the problem of spam, this is just theater to put another tax on the smaller players in the Internet industry business.
Just like spammers, scammers and other forms of predation will be better at crypto than everyone else, better at AI than everyone else, etc.
Yeah, SPF, DKIM and DMARC are incomprehensible. The only people with the time, motivation and expertise to understand and apply them, are professional spammers. Most of the legitimate email I get, fail one or more of these tests.
If I recall, SPF limits the number of domains you can enumerate in your DNS records.
I have now sent messages to 3 companies that I am a customer of where their SPF, DKIM, and/or DMARC were failing - for things like initial signup emails.
3/3 responded. 2/3 told me to f'off.
Tell them to fix their shit, from their own address.
honestly my take away is the opposite
we by far don't enforce them strict enough, because if we where people would make sure to get it right
it's all a question about effort/turnout
if you make it so that most times you mails still somehow end up with the user even if you mess them up there is much less insensitive for companies to fix their mail or force their provider to fix it
so IMHO if all of SPF,DKIM and DMARC are not correct setup mails should just be directly discarded and not even delivered to spam
while being more flexible was reasonable when this tech was new, that was 10 years ago. If being flexible mean that you also will sometime deliver outright cyber attacks like spear phishing and similar to your user and everyone had 10 years to fix their systems then there is really no reason to still be flexible.
Also "scammers get it right so it's useless" is such a huge red hearing argument, yes they do get it right _for their domains_. It sill makes it harder (and if strictly enforced impossible, except if you give them permissions to do that*) for them to impersonate your domains.
And yes that doesn't fix scammers from using their own domains, but it also was never intended to do so. Doing so is a very different problem one which probably needs some form of reputation system which isn't something you can just solve technically as it touches on a lot of subtle social political issues. Also given that all of the huge mail vendors have insensitive to use their "intern proprietary obscure" reputation system I don't expect there to be a technical solution provided/adopted tbh.
(and yes SPF/DKIM/DMARC are all tech wise quite "meh", but we are kinda stuck with them, through that never was the issue IMHO, the issue is missing insensitive to bring the adoption up and missing insensitive for large mail providers to enforce it strictly)
EDIT: PS: In one point they are fully right so, that is, with how things are you can't give SPF/DKIM/DMARC a large weight for calculating reputation. Also they where always only meant to tell you if someone can't be trusted, but never if someone can be trusted.
[dead]
[dead]
[dead]
SPF, DKIM, DMARC, IP reputation, whitelists, blacklists, graylists, spam filters, ...
https://xkcd.com/927/
ugh
I'm sure regular airline passengers trip the metal detectors more often than terrorists, doesn't mean we should get rid of the metal detectors.
A better analogy would be a passport. It doesn’t stop all terrorists from boarding a plane at lest it stops already know to authorities ones (unless they have a passport on someone else’s name which is not easy).
Or perhaps, why do you lock the door to your house? A few solid kicks will open most doors, the locks can be picked, someone can smash windows and enter, and many modern homes can be entered by ripping the wall open with a crowbar and axe.
It's to stop midrange threats.
3 replies →
I forgot the name of this fallacy, I read about it in Nassim Taleb’s Antifragile a long time ago, but basically being wrong at spam won’t cause a lot of damage while being wrong once about a terrorist may cause thousands of deaths