DMARC has been public since 2012 but most company domains still don't enforce it

Which is only the core problem because dmarc fixed the other core problem of figuring out who the given sender is.

DMARC does not solve everything, but it does make other solutions more effective.

This should create a means to go after the domain owners via registrar and trail of ownership, even so far as blocking email from the domain.

Forcing the spammers to pass DMARC creates a burden and an evidence trail that didn't exist before.

Extremely well said.

Additionally, I would probably guess correctly that almost all spam comes from rotating ASNs these days. Aka from companies that do "growth marketing" or other bullshit that isn't a valid business but just... spamming people.

A lot of the domains that fall through the cracks for single-spam-campaigns have been taken over by botnet campaigns, so the actual owners of said domains probably don't know that their website is spamming everyone else.

But the major providers are the culprit, too, here. Gmail, hotmail, microsoft o365, mailgun ... they all don't even enforce SSL from server to server, and let through "sendmail" like spam because the spammers are paying customers to them.

Source: I am maintaining antispam [1] which I am using to combat spam, phishing, and malware campaigns targeting my customer networks.

[1] https://github.com/cookiengineer/antispam

I've had more than one argue with me that having more than 10 lookups in the SPF isn't the issue even though I am showing them the SPF failure and the RFC stating that you are not allowed more than 10. Like, good for you that Gmail doesn't care, we do, fix your shit.

It would solve a lot of issues globally.

  *.mydomain.io. TXT "v=spf1 -all"

  @ IN MX 0 .

admin@example.com OK postmaster@example.com OK abuse@example.com OK webmaster@example.com OK hostmaster@example.com OK info@example.com OK example.com REJECT example.com

Some changes I made at the direction of an agent: fix domainkeys CNAMEs for M365, rotate M365 dkim keys that haven't been rotated for over a decade, fix broken spf record formatting.

My biggest issue is that squarespace refuses to enable dkim signing for transactional emails that they send for us (order/shipping confirmation etc). The email sending service they use (socketlabs) supports it but they are not interested in enabling the feature, so I can't lock down our dmarc. I guess that means squarespace is not a good fit for our needs; it's just disappointing that we have to move to a different platform again for technical reasons that are solvable with a dashboard switch.

I even go to the trouble of registering in their Postmaster Tools and clogging up my DNS with their verification tokens all for the tools to tell me I don't send enough mail while they happily pass what little mail I send straight to spam.

  Not enough outgoing email
  You haven't sent enough email to personal Gmail (@gmail.com) accounts to determine deliverability status for your domain and messages.

Guess it doesn't help that as I look today the Postmaster Tools dashboard shows "Last updated Sun, Apr 26, at 9:30 AM."

Then on the other hand Google can flood me with spam filled Google Calendar Invites and Google Drive Share notifications, all fully DKIM signed because they are coming out of those services, all day long.

Microsoft have also recently changed their Smart Network Data Service (SNDS) so now only my cloud provider can access the console as they only allow verification to the owner of the whole ASN block you're under. I can't access detail about my domain anymore, and still my mail goes to junk. Unless you own a chunk of IPv4 ASN range you're out of luck. IPv6? Nope, not at Microsoft. "Please note that IPv6 is not currently supported." [1]

[1]: https://substrate.office.com/ip-domain-management-snds/SNDS/...

Depending on how hard you want to make it, you can slap all the parts together yourself or use something like Zimbra, Mailcow, iRedMail, mail-in-a-box.

The advantage over a fork, whatever specifically that means, is any service that needs E-mail as an identity verification, still works.

It's time for a new protocol with end to end encryption and sender verification built-in. That shouldn't be as hard as it sounds, because at the time when email was invented the internet was very different. Connections were intermittent, for example I would retrieve my email once a day with UUCP (and some other people would use batched-SMTP). Which means you could not rely on the sending and receiving server being able to communicate directly. In this day and age this is possible and that direct communication opens up a lot of better crypto like key generation algorithms which require both parties to be online at the same time.

The problem is, is you don't allow corpos you will break 95% of mainstream people's usecases. So I think this is a non-starter, unfortunately, though it is a lofty goal.

There is so much crossover between personal email and corporate email.

When its unimportant or important to the receiver only, you push responsibility to them: "I sent it. Must be your email that's glithced. Tried Gmail or Proton?"

When its important to you, you use your backup Gmail or Proton account.

But if you send all emails for your domain from one email server, you could just disable rua reporting. The reports are mainly useful to see whether you have some misconfigired email server somewhere that causes (or will cause) dropped emails. That can easily happen if you send some email from your own server, some via sendgrid, some via some marketing tool, and start to lose track of them. But for a personal email server, that's not common.

The message you obviously refer to as just an educated guess by a forum user who seems to be experienced in email topics. It could be that the guess is correct. It could be hat the consumtants are too overloaded to configure things differently. Another user has that guess. We don't know as long as the provider does not answer.

Some mail providers will junk your mail if you don't have a reject/quarantine DMARC policy because you're seen as enabling the spammers so everything out of your domain must be punished.