It's amazing that having someone in your address book isn't enough in many cases. Like, why?

One of my clients is a construction firm specializing with churches. It is not infrequent for them to be communicating about a project with a church - often to a role account (e.g. [email protected]), which is step 1 towards being filed as spam - where the role account is shared with a dozen or more people. The building manager will check the email on Mon, Wed and Fri and every other day there will be a number of well-intentioned volunteers at least one of which will click on the spam button dooming my client's email into the abyss. Weeks later we find the church has gone with a different contractor, as they "could never get a response" from my client.

We will go so far as to donate a new IT/Cloud system to the church (small $$ compared with the project) just to ensure reliable communication. But then they think we are just trying to buy them.

Now my client has a blacklisted domain/mail server IP, and bids they send out are rejected as spam by the providers to other churches.

Makes no difference if we are hosting the mail server or if it is a 3rd party mail service. As soon as a customer is sold, we try and move them off email into a web-application framework for ongoing legitimate communication. Again a lot of resistance.

Also I'd expect all the firms competitors to be using Workspace or 365, so if using them gives no apparent protection, presumably they should be suffering from this as well?

The current situation is that we have technical solutions for authenticating smtp sending domains. But there will always be someone who flags an email too quickly or just wants to spite you. And so we’re back at square one.

There's almost no cost to send an email except time so even when n is large, this does not prove nearly as intractable as one wants it to be.

If they pass their log through a scanner, come up with a few dozen small servers that look fishy (e.g your IP is contiguous to some other spammer’s IP), and yours is rope in as false positive, you’re banned.

And from there you’ll have to convince Google that you’ve done nothing wrong.

Imagine the conversation with their support when you ask why [email protected]'s email was put in spam folder of [email protected]'s email, as both are hosted by Gsuite and presumably entirely within the Google network.

The answer, after two levels of support, was, "We don't understand why, but we can open a ticket with the developers." In the business world, you don't have time to wait for that, especially when non-technical business users are making mistakes or losing business because they can't function properly.

You would really think that Google would whitelist emails within the same custom domain which is paying for Gsuite service. Maybe that has changed, but it was definitely a problem 5 years ago.

And we're not talking about an email which had some copy/paste of spam, we're talking about a one or two line sentence giving an instruction or asking a question to a colleague.

> Bypass spam filters for internal senders

Is this what you are looking for?

The issue here is that developers and IT folk seem to think that email is easy because the know IT. Email is a complex, and old protocol that has many nuances and, believe it or not, phishers are smart; end users are naive, and often reckless. Spammers, be they benign or otherwise, can be incredibly lazy too, but don't think for one second that you, as a postmaster, are cleverer than they are. Spam and phishing are getting harder to beat. Businesses like Proofpoint, Cisco and Mimecast, along with the likes of Google and Microsoft, are investing heavily in trying to beat these guys, but the reality is that they are always at least two steps ahead.

Drives me nuts having to leave a UI to google (ironically) the issue to find a doc to enable a check box.

They still didn't care at all!

Just let ChatGPT send emails to itself, using mail server and client software that it wrote itself, and the rest of us don't have any need to handle email ever again.

Ingress - out of the box rspamd is pretty decent and it is rather configurable.

Egress - DNS (A,AAAA, PTR), (E)HELO, SPF, DKIM, DMARC. "IP Reputation".

There are absolutely no shortcuts and yet most of the problems I diagnose regarding email delivery will find a missing PTR record or a miss-configured (or non configured) HELO. You cannot be lazy when it comes to email. SPF + A + AAAA + PTR and (E)HELO is a minimum.

There is one thing that you cannot generally, personally mitigate and that is being on a deny list due to your IP address. This one is a bit more tricky to deal with. You might have to use a relay. Another mitigation might involve IPv6.

Any insight into why this is a giant ball of complexity? I’ve had to setup spf, dkim, dmarc a couple times now and man… design by committee?

The standards are fine in terms of achieving their goal, the hard part is getting the ecosystem to follow and make everyone's life easier.

Am I missing something not knowing what HELO is ??

AFAIK plenty ofservers will outright reject all mail if you only have an IP address and not a domain name there.

Extremely filtered emails is practically the same as a social network determining what I can see at this point.

Web standards have advanced to a level that walled gardens are replacing email. Email itself is still stuck on IE6 level standards. And SPF, DMARC and DKIM are a confusing mess to deal with.

Sounds like a salesmen who doesn't understand DMARC himself was trying to sell it by labeling it too complex.

From a purely technological point of view DMARC isn't that complicated. It just specifies how to treat DKIM and SPF results (with a bit of rather simple configuration). SPF is basically a list of ip's you own published on your domain (if the email was sent by that ip, you vouch that it was sent by you) and DKIM signs the email with a private key and you publish your public key on your domain so everyone can verify that this email was signed by the domain owner. SPF might fail if your mail gets proxied (as now its a different sender ip that you didn't vouch for) and DKIM might fail if the mail got modified including headers (because the signature can only be verified for exactly the original headers+content). So if you're sending email for someone else it gets a bit tricky, but for your own emails it's certainly not "just too complex" and boils down to a few line long configuration file, a list of ip's and a private/public key pair for signing emails.