alt.hn

7/28/2026 at 10:20:50 AM

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

 https://ciphercue.com/blog/dmarc-enforcement-gap-rua-fragmentation-2026

by adulion

7/28/2026 at 2:09:29 PM

Sadly the article doesn't really touch on whether or not DMARC accomplishes anything truly useful. When I enabled DMARC for ingress email on one of my own mail servers, it ultimately ended up regularly blocking a handful emails from customers, yet virtually all the spam coming in had valid SPF / DKIM / DMARC, as do most of the phishing attacks.

The core problem is that the real need of email end users need is a way of determining whether or not to trust a given sender. Signatures are purely a technical measure which provides no information on the trustworthiness of the sender. The end result is that email scoring still has to be content based, and the signature check technologies are pure noise with no useful signal for the purpose of determining if an email should actually show up in my inbox.

The tech industry has a bad habit of providing solutions to problems adjacent to problems the user actually needs solved while leaving the user's actual problem unresolved.

by bcrl

7/28/2026 at 2:27:00 PM

> The core problem is that the real need of email end users need is a way of determining whether or not to trust a given sender.

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.

by bawolff

7/29/2026 at 6:43:50 AM

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

Does it verify the sender or the domain/service which the sender is using?

by deknos

7/29/2026 at 11:20:41 AM

Yes. If an email comes from alice@gmail and validates to gmail, alice sent it.

It's possible that gmail screwed up and gave Bob access to Alice's account. In this situation, though, Alice still sent it.

by inigyou

7/29/2026 at 2:35:42 PM

Google is not the only email provider in the world, though. Not all email services are global corporations, and we must be careful never to interrupt the services of independent email providers.

by Freebytes

7/28/2026 at 3:35:56 PM

> virtually all the spam coming in had valid SPF / DKIM / DMARC, as do most of the phishing attacks.

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.

by brightball

7/28/2026 at 5:28:27 PM

Can we use DMARC to ask Gmail to close registrations? Google Calendar to allow far fewer people the ability to send invite notifications? Firebase to close registrations? Azure? Microsoft 365? AWS SES?

It feels like the biggest spammers have swung back to just abusing SaaS and getting SPF / DKIM / DMARC for free from one of the big email providers.

by WorldMaker

7/29/2026 at 11:21:40 AM

Google now requires you to send them an SMS to open a new account. Also, Google got banned from Usenet (yes, the whole thing, yes really) because it only ever sent spam.

by inigyou

7/28/2026 at 7:06:49 PM

Exactly this. Spammers have the technical competence to overcome any technical hurdle, so using evidence of technical competence achieves nothing.

If it were possible to charge $0.25/email for delivery, I'd be more than happy . However, I'm sure large tech firms will need to say that is "too hard to implement at scale".

by bcrl

7/29/2026 at 12:26:47 PM

> using evidence of technical competence achieves nothing

Evidence of technical competence wasn't what I was talking about. I meant that it creates a trail of evidence for police to actually pursue them, particularly in the case of phishing.

To setup DMARC, DKIM and SPF you need to control a domain. Somebody has to own that domain, unless you just hacked a DNS or somebody's already configured email server.

If you hacked it, there's a trail to contact the domain owner to notify them. If you bought it, there's a trail to find the domain owner.

You can obfuscate that with stolen cards and fake registration details, but now there's a central point where identity validation and security can concentrate itself.

A lot of positive side effects happen when the bar is raised from "any email server can send email claiming to be from anybody" to "email can only be sent claiming to be from a domain if the domain approves the sending email server."

At least when the spam concentrates from major senders like Google, etc those major senders have the means to analyze and take steps to prevent it.

by brightball

7/28/2026 at 8:01:23 PM

Stamp costs don't stop snail mail spam, either, unfortunately. I would be concerned if we added something like bitcoin fees to email delivery rather than curtail spam it would just further encourage grifters seeking ROI on their spam deliveries.

by WorldMaker

7/28/2026 at 9:05:13 PM

What if a single email cost $0.001 cent to send, and it was paid to the recipient? For $10, you could send 10,000 emails. For recipients, every 1,000 emails they get is a dollar in their wallet. You’d need something like a blockchain for this to work because the traditional payment processors still haven’t figured out micropayments.

by ebcode

7/28/2026 at 9:41:20 PM

If snail mail cost $0.001 per recipient people would be getting much, much more junkmail. Likewise, if e-mail cost as much as even bulk snail mail, there'd be much less spam.

Some sort of payment scheme is really the best, most durable option. The problem of mailing-lists and personal correspondence could be solved by an exclusion mechanism where the recipient effectively whitelists senders, explicitly or implicitly (e.g. whitelist a replying-sender automatically if a recipient initiates a conversation).

by wahern

7/28/2026 at 10:04:27 PM

The problem with a payment scheme is that spammers (who make money by spamming) will happily pay as a cost of doing business (or negotiate discounts/deals), but Joe User might just look at the cost and say, "you know what, maybe I'll send this as SMS instead of E-mail."

So the end result will be more spam and fewer legit E-mails.

by ryandrake

7/29/2026 at 5:39:23 AM

I've wondered if it cost $10 to get through my email box the first two times what they would mean.

Hormozi could charge $1,000 to get into his read box.

We could refund people, add them to a whitelist - and return a 405? payment required by default and things change in interesting ways when the amount is variable.

by stevenicr

7/29/2026 at 7:11:34 AM

There are platforms based on this idea: pay to reach a public person’s inbox, often with guaranteed responses (“guaranteed” as in “you get a response or you money back”). For example: https://mypublicinbox.com/en/

by grodriguez100

7/29/2026 at 5:48:54 AM

> What if a single email cost $0.001 cent to send, and it was paid to the recipient? For $10, you could send 10,000 emails. For recipients, every 1,000 emails they get is a dollar in their wallet.

I'm not sure you realize your proposal's only contribution is to worsen spam. You are unwittingly creating an incentive for email providers to lift anti-abuse filters and to maximize the volume of spam delivered to you.

by locknitpicker

7/29/2026 at 5:45:54 AM

> If it were possible to charge $0.25/email for delivery, I'd be more than happy .

I'm baffled by this blend of replies. What exactly do you believe charging for an email would do? I mean, other than fabricating a revenue stream. Do you seriously believe that spam would vanish as soon as anyone charged for it's delivery? Because advertisers already pay for reaching their target audiences, and do so well beyond email.

by locknitpicker

7/28/2026 at 4:26:51 PM

They're generally hosted on a google or microsoft 365 or something slightly less shady. Good luck with that.

by bigbuppo

7/28/2026 at 7:08:49 PM

What spammers are using the same domain for longer than couple of hours?

What do you expect to achieve by blocking an already abandoned domain?

by illliillll

7/29/2026 at 12:10:59 AM

@gmail.com and @outlook.com are like 90% of the spam I receive. What’s missing is effective accountability for those two companies hosting persistent spam groups who operate for months unimpeded.

by acdha

7/29/2026 at 11:22:20 AM

Sue the spammer, getting a subpoena from Google to find their identity.

by inigyou

7/29/2026 at 11:40:12 AM

That surely is a sustainable and cost-effective alternative to Google using their trillions of dollars in resources to behave responsibly.

by acdha

7/28/2026 at 3:43:00 PM

The primary purpose of DMARC is to prevent impersonation not to prevent spam. I own a domain, I implement DMARC to make sure others know when email from my domain is legitimately from my domain.

by thedougd

7/28/2026 at 6:50:48 PM

Then you don't deal with email in the real world. DMARC prevents legitimate emails from people in the real world from being delivered because people make mistakes with their email systems. Passing DMARC is not a signal that the email isn't legitimate; it's merely a sign that someone correctly set up their mail server to modern standards. The email might be an impersonation, or not. There's no way to know.

DMARC does absolutely nothing to prevent the kind of impersonation that occurs in the real world. It doesn't block homoglyphs or or typo-squatting or all the other forms impersonation that matter. It has failed at preventing impersonation.

Just a few days ago I had a phishing email from an elderly woman I had previously done some work for. The message passed DMARC and everything else, and the domain it was sent from was valid. But it was not legitimate; it was an impersonation of her which became obvious once the content was read.

DMARC is noise, not signal. It has to be ignored in the real world as it provides virtually no value beyond blocking emails pretty randomly because someone made a mistake when rotating their DKIM keys or one of a million other mistakes that do happen.

by bcrl

7/28/2026 at 7:08:24 PM

Okay but that doesn’t detract from the intended purpose of DMARC.

by thedougd

7/28/2026 at 10:06:04 PM

Perfect example of "The Purpose Of A System Is What It Does."[1]

1: https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...

by ryandrake

7/29/2026 at 12:09:42 AM

That saying is bullshit. The purpose of a system is, by definition, what it is intended to do, not what it does. You can judge efficacy by the results, but not the purpose.

by bigstrat2003

7/29/2026 at 11:23:07 AM

No, the entire purpose of the POSIWID principle is to refute what you just said. Do read the wikipedia page linked above. You called it out yourself when you said "by definition" - there is definition, and then there is reality, and they need not align.

by inigyou

7/28/2026 at 4:31:38 PM

Isn't that the purpose of DKIM and SPF already?

by HenriTEL

7/28/2026 at 4:43:31 PM

DKIM and SPF validate a message. DMARC sets a policy as to what to do with it (quarantine/reject.)

by wafflebot

7/29/2026 at 11:24:50 AM

So DMARC is just advertising whether you think your SPF and DKIM are set up correctly?

Seems useless to me. SPF already specifies what to do with messages that fail SPF. SPF is necessary. DKIM is questionable. DMARC is useless.

by inigyou

7/28/2026 at 4:41:51 PM

ELI5: https://www.reddit.com/r/sysadmin/comments/16gvtdj/comment/k...

by warkdarrior

7/28/2026 at 9:06:16 PM

Wish I didn't have to log in to reddit to read that post. RIP useful reddit links.

edit: looks like I had an extension that was redirecting to old.reddit.com, and it was old reddit that required login. Though when I turned that extension off, I got a "blocked by reddit security" error. ugggh.

by joemi

7/29/2026 at 10:29:14 AM

[–]iceph03nix

655 points 2 years ago

SPF: These are the servers I will send from. If it says it's from me, but comes from somewhere else, it's likely fake

DKIM: This is my signature, if it's not on the email, it probably didn't come from my server.

DMARC: If you get mail that doesn't match the above, here's what I want you to do with it.

by justsomehnguy

7/28/2026 at 4:46:44 PM

Yes and no. DKIM signs part of the envelope to help recipients detect alteration (by verifying authenticity), SPF locks down the permissible origins for the sender. SPF is in itself imperfect and can in some situations be exploited on open-access shared systems. If the two are used in concert they offer decent protection.

by daneel_w

7/28/2026 at 5:04:22 PM

Using both has to be done very carefully, because a positive result from the weaker one (SPF) will override a negative result from the stronger one (DKIM). You should maximally use DKIM and minimally use SPF. Ideally, you should not use SPF at all, but there are some senders that still don't support DKIM.

by kbolino

7/28/2026 at 5:43:41 PM

Many email providers and third party security tools default settings automatically bounce or block SPF failures, no matter what DKIM says... so no, not using SPF completely is a bad idea.

Using it minimally is correct, thou. Route outbound mail through as few controlled relays as possible so your SPF record only needs to list infrastructure you actually *own*, rather than growing it every time a new tool needs to send mail.

I have seen way too many clients almost hit the char limit in a TXT record

by zahrc

7/28/2026 at 6:08:16 PM

SPF failures overriding DKIM successes is a direct violation of RFC 7489 section 4.2 [1]. I have never observed such behavior in the wild, though my experience may be more limited than yours. There are two possible explanations anyway, one is that the DMARC record was missing or misconfigured, the other is that the DKIM check did not actually succeed even though you had reason to believe it should have (e.g., misaligned sender domain, invalid/stale/rotated key, etc.).

I would certainly agree that DKIM is harder to get right. However, the TXT record data size limit is surmountable. You can either use EC algorithms, which have much shorter keys, or stick with e.g. RSA and its very long keys, but span them across multiple 255-byte record data chunks. That having been said, I still think DNS providers should do more to make configuring DKIM easier.

Ultimately, if you have SPF and DKIM set up such that both cover all senders, then you are just using SPF. It is the simpler and more forgiving mechanism, so its broad-scoped successes will always swallow DKIM in practice. The only reason I can think of to do this anyway is if you suspect your email provider will change IPs on you and they don't provide their own SPF record, but if that were the case, they are basically telling you not to use SPF in the first place.

EDIT: RFC 7489 was superseded by RFCs 9989-9901 rather recently. Nevertheless, the definition of success, now given in RFC 9989 section 5.3.5 [2], remains the same.

[1] = https://datatracker.ietf.org/doc/html/rfc7489#section-4.2

[2] = https://datatracker.ietf.org/doc/html/rfc9989#section-5.3.5

by kbolino

7/28/2026 at 7:27:42 PM

The "logical OR" of DMARC is absolutely a glaring caveat. I run my own MX and would personally under no circumstance omit SPF, because I consider neither SPF nor DKIM complicated enough to warrant consideration.

by daneel_w

7/28/2026 at 5:06:36 PM

This is true, and yet DMARC v1 does not require you to use them in concert. Either one (a valid DKIM-signed message with sender alignment or a message that passes SPF checks with sender alignment) is enough to pass DMARC.

by aaronmdjones

7/28/2026 at 4:06:55 PM

> The tech industry has a bad habit of providing solutions to problems adjacent to problems the user actually needs solved while leaving the user's actual problem unresolved.

Extremely well said.

by egorfine

7/28/2026 at 2:48:00 PM

My domain is very low traffic but, I just looked through my admin email account and opendmarc has rejected 18 attempts by spammers just this past week. More were rejected by my domain's DMARC policy.

by newsoftheday

7/28/2026 at 7:00:08 PM

It works at small scale when you self-select for technical competency. It does not work at larger scale when that self selection is no longer possible.

My scale is that I ran an ISP for ~500 users before the network was disassembled last month. At that scale, you will encounter people that make mistakes with their email setups. When the people who make mistakes are customers which DMARC prevents delivery of emails, it is an issue as those are exactly the people for which I want to see the emails from.

I get more spam with valid SPF and DKIM via Google's own mail servers than DMARC blocks.

It says something when even gmail doesn't use DMARC as a signal that an email is valid, as gmail regularly blocks legitimate mailing list emails with completely valid signatures and non-spam content from a reputationaly sound IP.

The problem DMARC was supposed to solve (impersonation to reduce spam) isn't solved by DMARC.

by bcrl

7/28/2026 at 3:24:09 PM

My work email is Outlook, which is horribly broken and terrible to use. I have a rule configured to "re-send" all my mail to a different account where I read it with a usable MUA. Unfortunately this seems to break DMARC for external mail as now an email from e.g. user@example.com appears to have been sent by outlook.com.

by SoftTalker

7/28/2026 at 3:50:09 PM

I'm not familiar with Outlook's resending, but the use case is supported if the sender uses DKIM. If the email is forwarded without changing any details, it can keep the DKIM signature. That allows the forwarded email to still pass DMARC.

Now if the sender used SPF + DMARC but not DKIM, this does not work, since the sender IP can't be verified with the forwarded email. In that case, the forwarder has to change the from address to prevent the email from failing DMARC and be rejected.

In practice, senders using SPF+DMARC but not DKIM should be quite rare, you see DKIM+DMARC much more often.

by matharmin

7/28/2026 at 4:38:22 PM

I have a long-standing email address that forwards to an email system that I run. The operator of the forwarder switched to using Microsoft's mail infrastructure some years ago and the quality of service of the forward has degraded dramatically ever since.

I've often seen messages resent by Microsoft's mail infrastructure with gratuitously broken DKIM signatures, generally due to changes to whitespace that are not anticipated by DKIM's message canonicalization.

I've also seen messages sent by my bank directly to the email system I administer that had broken DKIM signatures apparently due to some sort of antivirus software they had downstream of the DKIM signer.

by Polizeiposaune

7/28/2026 at 6:12:24 PM

Outlook.com also seems to routinely ignore DMARC (it will bounce emails with a DMARC that's report only)

by ryanbrunner

7/28/2026 at 5:28:16 PM

I never understood the point of the anti-virus adding a message to _outgoing_ emails. Basically "I swear there is no virus in this email I'm sending you, trust me bro".

by matharmin

7/28/2026 at 7:15:18 PM

"We take security seriously."

by SoftTalker

7/29/2026 at 2:07:25 AM

Stopping spam isn't what DMARC was designed for.

by Geezus_42

7/28/2026 at 2:32:14 PM

^ this

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

by cookiengineer

7/29/2026 at 10:21:08 AM

Why would you care about TLS for spam? Are you proposing that any email sent without TLS should be label spam?

by Geezus_42

7/29/2026 at 2:58:23 PM

The cheaper the relay mechanism is, the more noise/spam you'll get.

Lots of servers online have a publicly exposed smtp port, where all kinds of script kiddies are just using a sendmail style email from another (not-owned) domain.

DKIM/DMARC tried to fix this (without success due to fakeable entries in the DNS records, spf=all is pretty much everywhere anyways nowadays). So my proposal for actual ownership of domain AND server infrastructure would be mutual TLS. Reverse IP lookups are broken almost always anyways, due to most hosting providers not offering real reverse DNS infrastructure that users can modify.

This way a compromised server can't send as another domain, and large-scale spamming relays that rotate ASNs would have indicators in the cert itself, which they run out of real quick due to limitations of how many IP/DNS subjects you can set in an SSL/TLS cert.

No faking and avoiding bad IP reputations by rotating ASNs anymore.

by cookiengineer

7/29/2026 at 6:05:40 PM

[flagged]

by bks

7/28/2026 at 1:52:47 PM

I mind email for a number of small orgs (<1000 recipients each). There are so many SPF and DKIM failures from senders who you'd think would know better (Fortune 100-type companies). I don't want complaints from users missing messages so I end up disregarding failures even when published policy says to do otherwise.

by EvanAnderson

7/28/2026 at 3:06:16 PM

I take the opposite approach, I refuse to whitelist domains. When someone internal complains I send a notice to their contact on the other end (CCing the internal recipient) saying their email is misconfigured and ask them to put me in touch with their IT department to help them fix it. I use a script to do some DNS lookups and write the email for me. I have about a 50% success rate getting them to fix it.

by velcrovan

7/28/2026 at 3:31:23 PM

My spirit was broken for that kind of work a long time ago.

More often than not I end up talking to someone in the sender's IT who fancies themself an expert and is completely incredulous that there could possibly be a problem on their side ("But we don't have problems sending email to anybody but you...")

I should want to fight the good fight, but it's so demoralizing.

Edit:

Dealing with other IT people on problems like this taught me a ton of humility. It wasn't until I was in my early 30s before I'd reached a level of maturity to approach trouble reports like this being reported to me with an open mind. Before that I fancied myself and expert and, likely, was insufferable in many contexts.

Now I'm insufferable in fewer contexts.

by EvanAnderson

7/28/2026 at 3:33:27 PM

What happens in the other 50%? Your users work around you somehow?

by account42

7/29/2026 at 10:36:27 AM

Falls outside scope.

Only half joking. If you can't figure out SPF/DKIM then you should find a new job.

by Geezus_42

7/28/2026 at 4:18:06 PM

I have also done this, but instead by finding someone from IT or security on LinkedIn and messaging them there.

by drdexebtjl

7/29/2026 at 10:58:47 AM

Good on you!

by Geezus_42

7/29/2026 at 10:32:59 AM

I don't get it. Neither one is hard to setup. How do people have such a hard time with such simple configuration. Then again the majority of "mail admins" I have interacted with have absolutely no understanding of SMTP and can barely wrap their heads around DNS.

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

by Geezus_42

7/29/2026 at 11:26:44 AM

DKIM is hard to set up. SPF is easy.

by inigyou

7/29/2026 at 2:39:57 PM

The real reason p=none persists is because people would rather err on the side of email being delivered that is actually junk than having a miss of legitimate mail. (This also the reason for so many soft failure entries in SPF records.)

by Freebytes

7/29/2026 at 2:58:39 PM

This is true. Here’s a cautionary tale to that end. My org’s IT recently introduced, without input, an ai filtering tool to automatically filter junk email. It apparently worked too well. In an ironic twist of fate, it filtered a raft of emails (across multiple domains, including tickets and account reps!) to IT from an important vendor about contract renewal into junk that ultimately resulted in leaving the vendor no choice but to suspend service until the bill was paid (they waited until the very large bill was over two months past due to do this, to their credit).

When I learned about this during the post-mortem I was incensed, to say the least. Email mgmt is part of a professional’s job, for better or worse. Accountability for that doesn’t suddenly evaporate because of a scenario like this. I don’t practice zero inbox for fun. I do it for my sanity and effectiveness. Technology can’t magically solve every problem.

by CSSer

7/29/2026 at 3:07:53 PM

I don't mind p=none. I'm more bent out of shape about policies that tell me to reject that, if followed, would result in the loss of legit email.

by EvanAnderson

7/28/2026 at 1:51:13 PM

If you have any domains that does not use email, it may be a good idea to set up some DNS records to prevent it being used.

DNS SPF record: mydomain.io. TXT "v=spf1 -all"

DNS DMARC: _dmarc.mydomain.io. TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"

That ought to stop anyone trying to use your domains as source.

by TheChaplain

7/28/2026 at 3:37:41 PM

Yes! IMHO every registrar should be turning this on by default. Every DNS should do this by default until the owner explicitly turns on email sending.

It would solve a lot of issues globally.

by brightball

7/28/2026 at 3:11:53 PM

Also consider (using your example domain):

  *.mydomain.io. TXT "v=spf1 -all"
to restrict SPF on all subdomains.

by teddyh

7/29/2026 at 10:55:01 AM

Specifying sp=reject in a DMARC policy would have a similar effect right?

by auscompgeek

7/29/2026 at 11:30:02 AM

The wildcard DNS SPF record is useful for mail receivers who won’t check DMARC, but will check SPF records. Also, the DMARC sp= setting defaults to the same as the p= setting (unless the DMARC record is itselt on a subdomain, in which case the sp= setting is ignored). So if you already have a strict p=reject setting, the sp= setting is useless.

by teddyh

7/28/2026 at 2:54:45 PM

I use postfix and the recipient_access file to control email to my domains which use little email, so the domains are able to process standard email:

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

by newsoftheday

7/29/2026 at 11:27:37 AM

Isn't it default for domains without MX records, usually?

by inigyou

7/28/2026 at 12:59:43 PM

The article speaks about DMARC monitoring, but not about "writing" it. So many orgs are too small to have someone paying attention of these things. Where I work, the CTO used to manage the DNS, but with very little understanding of what it all means. It was just copy and paste. And yes, it also says p=none. Probably because it was in the example. It's like setting up a website for your company, and picking some wordpress instance: how are you supposed to know the risks? It's just too much.

by tgv

7/28/2026 at 2:31:16 PM

LLMs are very good at helping you manage DMARC/DNS related configuration, even as a non-expert. I used it to develop custom DMARC report processing app that: 1. sucks in reports sent to our dmarc inbox into a sqlite db, 2. displays the results in a web page. The reports queue up in the mailbox and I open and start the app once a month to check the status. The agent also also reviewed the state of email-related DNS records, describe what needs to change, including how and why, and verify changes after the fact to ensure they are correct.

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.

by infogulch

7/28/2026 at 4:13:00 PM

Sounds nice, but it adds to the load. Small businesses consider their direct customers much more important, and have little time for this kind of thing. Managing a domain is more work than godaddy makes you believe...

by tgv

7/29/2026 at 10:41:45 AM

SPF, DKIM, and DMARC are not hard. It's literally just publishing data you should already have, a list of your sending IPs, a pubkey, and how to reach you.

by Geezus_42

7/28/2026 at 1:19:11 PM

I really think we should be solving a much bigger problem of the major email providers not providing an automated way of handling abuse and not caring about abuse reports at all. Most of my spam comes from the three major email providers and at this point I gave up even trying to send abuse reports because they just get ignored.

The big companies do not have to care because nobody will block Google, Microsoft or Amazon. They are too big to fail.

Spoofing a From field is an insignificant problem in comparison.

by jwr

7/28/2026 at 1:31:53 PM

It's ironic that I set everything up correctly on my self hosted domain and still end up in spam because of my low volume.

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.
Each screen only shows: "No data was found for this domain."

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/...

by cube00

7/28/2026 at 2:09:15 PM

In the same boat here. At least still have a good standing at Microft. Lost goodwill at big G by what I vaguely narrowed down to self hosted images in e-mail signature.

by butterknife

7/28/2026 at 3:03:00 PM

Don't self-hosted images in the email signature allow you to track whether the email was opened or not and potentially where it was opened? I can only imagine they want you to pay for that privilege as a service.

by draygonia

7/28/2026 at 3:54:02 PM

Gmail already proxies embedded images so you'd only be able to track when an email was opened the first time. Anyway, I have been sending (very low volume) of mails with self-hosted images embedded in the body for years without problems with Gmail but Microsoft doesn't like my VPS IP because sometimes there are temporarly bad actors on the same block. So I guess it's mostly random luck.

by account42

7/28/2026 at 2:28:38 PM

Email providers do have an automated way of handling abuse. Send the message to abuse@provider and they automatically ignore it. =)

by thesuitonym

7/29/2026 at 2:45:40 PM

Not to mention that the larger companies are incentivized not to deliver your email due to low volume. If your service does not work, companies will be encouraged to use Google or Microsoft instead.

by Freebytes

7/29/2026 at 11:28:47 AM

As a rule of thumb, big companies only listen to lawsuits.

by inigyou

7/28/2026 at 3:49:06 PM

Agreed, most spam has valid DMARC - whether that's bigmail.com or just nobodcarestoprotectsubdomains.randompwnedcompany.com

by account42

7/29/2026 at 10:51:03 AM

The purpose of DMARC has nothing to do with stopping spam.

by Geezus_42

7/28/2026 at 1:31:39 PM

Email has been turned into a by-the-corporation, for-the-corporation service. Corporations need DMARC so they can control email and the ability to spam. The spam I cannot block is spam from Google.

If you decide to think about this, you will quickly realize that email is f*ked and needs to be forked. Perhaps we need a Community Email Initiative that blocks corporations and only allows Community members.

Trust is the one thing you can't buy on the Corporate Internet.

I am sure many people will be offended and down vote this comment because they cannot conceptualize an internet without Corporations.

by talkingtab

7/28/2026 at 1:41:53 PM

You can do this right now, and you don't even need to fork anything. E-mail is an internet scale protocol that's not owned or ownable, except by convention. Since you specifically want to cut out Google, and their attempts to capture E-mail are what makes rolling your own E-mail hard anyway, just go for it.

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.

by baron3dl

7/28/2026 at 8:16:14 PM

What I am proposing is that community email servers can talk to each other. I have email servers setup - all the hoops - for my community. I want others to set up community servers and be able to interoperate. My server can send and receive from other communities. No corporations, no tracking. If your sever spams it gets dropped from the federation. Yes it is more complex, and there will be problems and issues. But hey, if we can have crypto currency why can't we get emails?

by talkingtab

7/29/2026 at 2:49:07 PM

You are thinking of approved domains only, and perhaps people can vote them out. But, what you are describing is an RBL (in this case a real time whitelist instead). I like the ability for existing members to be able to vote out other members, but you run into the issue of spammers creating a million domains and then being able to vote out all legitimate members.

by Freebytes

7/29/2026 at 11:31:37 AM

We have this, it's called email. Until someone involved is using Google or Microsoft.

myserver.com can talk to yourserver.com just fine and since neither of us have insane spam filters set up, it just works and no megacorpo is involved.

The protocol is okay, it just needs more smaller operators including smaller spam blocklists.

by inigyou

7/28/2026 at 11:56:16 PM

let's say this federation has three communities, a, b, and c. you run a, I run b, and my spammy friend runs c. C is my friend, and I'm going to keep allowing him to send me email, but you drop him, because he spammed you.

that's literally how email works today, unless the federation can supersede my authority as an operator to choose who may send/receive with me, at which point it'd stop being a federation anyway.

by baron3dl

7/28/2026 at 3:26:37 PM

Yes, email is just completely broken. It's not private, sender identification is mediocre at best (and nonexistent without things like DMARC and SPF), and all the kludges thrown up make self-hosting harder. Spam has zero cost basically also. Nobody trusts email anymore for anything confidential, it's become a clumsy notification service "come check our portal for your real email".

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.

by wolvoleo

7/28/2026 at 11:48:12 PM

[dead]

by baron3dl

7/28/2026 at 2:27:59 PM

You can already do this without changing anything. Just set your corporate mailserver to not accept mail from common community email providers. There's a reason nobody does this, and it's because it's a bad idea.

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

by thesuitonym

7/28/2026 at 3:54:22 PM

My previous employer did this, and no one seemed to miss it. If you had a use case to add an exception (the most common was to send yourself a mail from your personal Gmail, to print something on the corporate printers) that was supported and straightforward too.

by dmurray

7/29/2026 at 3:02:39 PM

One solution would be whitelist only. You must specifically whitelist a domain or email address, and everything else is blocked. If someone wants to send you an email, you must get their email address.

However, if you are using it to sign up for a service online, the domain often does not match the sender. You might sign up at the example.com website, but you get an email from noreply@auth-example.com as the email address.

by Freebytes

7/28/2026 at 3:38:50 PM

No, email is the only digital communication left where I can talk to normie relatives AND businesses without having an account on normie tech service. DMARC does not impede that at all and it not a valid cause to throw away this lucky artifact of computing history.

by account42

7/29/2026 at 11:30:30 AM

You can't solve a social or political problem with a technical solution. Whatever you invent, Microsoft and Google will still collude to block you and not each other.

by inigyou

7/28/2026 at 2:00:40 PM

What do you mean “fork”? Just buy a domain and install an email server.

by 1over137

7/28/2026 at 5:00:27 PM

Buy a domain? If you're going to fork email, may as well go the whole hog and fork DNS too!

Have your own gmail.com

by onraglanroad

7/28/2026 at 3:25:32 PM

I have set up DMARC, SPF, DKIM and whatnot. Sadly no one seems to take this as a signal for a competent mail setup, so Microsoft's mail servers regularly block my mails because of the surrounding IP range reputation - not because any spam would originate from my IPs or domains.

by TonyTrapp

7/29/2026 at 11:34:20 AM

Are you sending important or unimportant things?

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.

by inigyou

7/28/2026 at 2:26:37 PM

I am running email server for my private domain using https://github.com/docker-mailserver/docker-mailserver . One day in 2023 i decided that beside of dkim i maybe should also enable dmarc. Because ... well, why not. What happened was that i started reciving regular reports over email from ms and google containing compressed xml containing no info other that empty report was generated. What should I do with that? At that time i could not find any tool that would be able to extract valuable info from that, so I disabled dmarc. Havent looked back since.

by raluk

7/28/2026 at 2:38:33 PM

There are lots of free tools that automatically analyze the reports for you (you send it to them, instead of yourself).

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.

by matharmin

7/28/2026 at 3:17:09 PM

The reports are kind of useful when first enabling, if you want to get warnings about non-compliant mail, but after you're established, they're not really useful, so you should turn reports off, but you can do that without turning off the whole thing.

by toast0

7/28/2026 at 7:38:14 PM

The domains that do enforce DMARC are apparently configured so badly that the German secure email provider mailbox.org decided not to honor DMARC.

See this thread in German: https://userforum.mailbox.org/topic/10676-mailbox-org-akzept...

by asimops

7/29/2026 at 1:11:43 AM

Interesting thread. However, for over a year, the "secure email provider" did not reply more than that the consultants are too overloaded to reply...

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.

by usr1106

7/28/2026 at 4:18:16 PM

I didn't see it explicitly mentioned in the post, I wonder if they filtered exclusively for domains with mx records. Because I would assume that lots of domains just don't have email configured and therefore aren't aware that you should still setup DMARC to prevent impersination of your domain.

by agotterer

7/28/2026 at 1:35:51 PM

Article is missing a note on the existence of MX records for the domains. Sure, you can easily have a send-only domain without an MX record, but the common case is likely to setup both send and receive capability. It would be interesting to have that number included as domains without MX and DMARC might just not be configured for email at all. Worst case the 45% of domains without DMARC are simply not relevant for email and thus not configured at all. I would find "x% of domains with configured email don't enforce DMARC" more interesting.

by rft

7/28/2026 at 3:58:06 PM

Technically you can receive mail without MX records if your mail server is on the same host as the web server.

by account42

7/29/2026 at 11:36:01 AM

And if you send, a lot of mail servers will assume it's not meant to have any email service and will treat it as an SPF fail.

by inigyou

7/28/2026 at 1:28:43 PM

I'll set up DMARC after I get DKIM working... migrating my homelab has been taking forever...

by nubinetwork

7/28/2026 at 9:35:04 PM

At our small 12-person company, I help manage DNS. Email service is through Microsoft. I had previously configured SPF and DKIM etc. but never DMARC. We are too small to have time for everything. But, I recently asked Claude to review the entire config and recommend changes. It suggested DMARC. I said, "implement it". And it did. It does have access to our Cloudflare/DNS account and make changes using terraform/opentofu in a way that allows me to review the changes before they are made.

LLMs are great for this sort of thing that used to be a massive pain in the rear.

by cheema33

7/28/2026 at 2:13:31 PM

DMARC, just like SPF before it, solves nothing. The spammers adapt. And unlike SPF, DMARC has an enormous technology surface area. Its failure modes are legion, and each one is tedious to run down to resolution. Which just returns you to something which never pays the rent anyway.

by vandyswa

7/28/2026 at 8:33:13 PM

One awesome thing that SPF/DKIM/DMARC did... Now that spammers have "adapted", it means they can't say their email is from @mybank.com, or @microsoft.com, or @facebook.com, etc!

by BenjiWiebe

7/29/2026 at 11:35:16 AM

Exactly. This is a very important step. The fact that it did not stop spam is irrelevant.

by inigyou

7/29/2026 at 3:05:40 PM

SPF did solve an issue. Domain impersonation is no longer as much of an issue if you are strict against SPF failures. DMARC, on the other hand, solved absolutely nothing.

by Freebytes

7/28/2026 at 12:55:38 PM

I am self-hosting my (secondary) email and have only implemented SPF and DKIM. This works fine on a practical level for me. What would be the benefit of setting up DMARC on top?

by smartmic

7/28/2026 at 2:30:53 PM

DMARC is essentially an opt-in to strict mode. Primarily it prevents other people from forging email to look like it is coming from you. The goal of dmarc is to prevent other people from impersonating you.

by bawolff

7/28/2026 at 1:30:45 PM

The biggest benefit I saw in a small domain was greatly reduced backscatter spam. Before someone’d randomly make up a billion emails on my domain and send “from” them, and I’d get various out of office replies, etc (catch all) - that basically never happens anymore.

by bombcar

7/29/2026 at 11:37:33 AM

That affects your reputation BTW as they have no way to know they aren't really from your domain.

by inigyou

7/28/2026 at 2:01:38 PM

> What would be the benefit of setting up DMARC on top?

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.

by cube00

7/29/2026 at 3:07:43 PM

Some large companies have started blocking domains that do not have DMARC. It is a simple DNS entry. (Easier than SPF.) You should add it to all of your domains even though it accomplishes very little other than meeting the requirements of some larger companies.

by Freebytes

7/28/2026 at 12:59:02 PM

Because if someone spoofs an email coming from your domain DMARC tells the receiver what to do with the spoofed email.

by asimpletune

7/28/2026 at 1:08:27 PM

Google, Microsoft, Amazon and others send me summary reports of people spoofing my domains. I have dmarc set for them to accept the email, mark it spam (presumably) and send me a report. I really should and can tell them to reject the spam completely - another setting in dmarc but haven't yet out of laziness basically.

by comrade1234

7/28/2026 at 1:07:45 PM

And what is the sane way to handle a spoofed email?

by kamma4434

7/28/2026 at 2:20:39 PM

`p=reject`, ESPECIALLY for your personal email. `p=quarantine` is really only useful if you suspect your marketing department has set up some email blaster somewhere.

by thesuitonym

7/28/2026 at 2:11:47 PM

Realistically spoofed address (unauthenticated email) will be treated as spam and it’ll be implicitly quarantined or rejected as such by many well-known mail receivers. You can make this an explicit “reject” by publishing DMARC policy for your domain.

For example, gmail.com treats unauthenticated email as spam implicitly, regardless of DMARC policy.

by winstonwinston

7/28/2026 at 1:11:54 PM

That's what the policy setting tells the recipient. You can tell them to trest it as normal, send it to spam or delete it.

The report that they send you is useful for you to make sure your emails that you expect to go through are going through.

by azeemba

7/28/2026 at 3:20:44 PM

Reject it in the SMTP transaction.

by toast0

7/28/2026 at 1:09:55 PM

And SPF doesn't?

by AshamedCaptain

7/28/2026 at 1:24:39 PM

Technically, no.

SPF allows to say “these IPs are authorised to send emails as example.com”, where DMARC allows to say “I as domain owner recommend to quarantine emails that fail SPF and DKIM”, it also allows finer alignment (ie, matching between different “from” parameters) configuration and reporting by the receivers.

Of course, with absence of DNARC policies, receivers default to some internal defaults, or may ignore the policies altogether. But at least, the big ones send DMARC reports.

by ivlad

7/28/2026 at 5:20:33 PM

No, it doesn't.

In the following SMTP conversation:

  MAIL FROM: foo@example.net
  RCPT TO: victim@example.com
  DATA
  From: service@paypal.co.uk
  To: victim@example.com
  Subject: We are updating our Terms of Service
  [...]
SPF checks whether the sending host is allowed to send e-mail from example.net (the envelope sender).

The recipient sees service@paypal.co.uk (the From address on the inner message), because most ESPs do them the great disservice of not indicating that the sender identities are not aligned.

Adding a DMARC record to a domain requires that e-mail whose inner messages claim to be from that domain must have sender alignment to the envelope sender.

The above message would pass SPF (if the spammer owns example.net and has created SPF records for themselves) but would fail DMARC (paypal.co.uk's DMARC record exists, so alignment is required, and yet example.net != paypal.co.uk, so they are not aligned). In this case their DMARC policy says to reject the message, so (if the recipient is checking DMARC) it would either be rejected outright or it would land in Spam/Quarantine rather than Inbox.

by aaronmdjones

7/28/2026 at 1:29:51 PM

Not always. An email has a valid SPF when its return path email’s domain permits the sending server’s IP. But that email may have a forged From: header (which causes an SPF mis-alignment), and the receiving server checks the DMARC of *the From header* domain to determine how to handle that mis-alignment.

by wolttam

7/28/2026 at 3:16:42 PM

I’d be interested these stats broken down between domains associated with operating companies and personal or hobby domains.

The latter are likely to adopt much more slowly simply because of less perceived risk, lower payoff (no vendor reviews), and less dedicated technical expertise.

Just like personal sites were slow to adopt HTTPS. Mass HTTPS adoption happened once browser warnings and SEO incentives rendered sites mostly useless without it.

by at1as

7/29/2026 at 11:36:40 AM

Mass HTTPS adoption happened when it stopped costing $100 every year and requiring three forms of KYC, which is after Snowden showed us why we really should be using it all the time.

by inigyou

7/28/2026 at 3:46:35 PM

I'd expect the opposite really. Personal domains sending email are more likely to be run by MTA enthusiasts who don't have any money riding on others being able to receive their mails compared to corporate IT where mail is just one more thing they have to wrangle and really don't need the company leadership being angry at them because the spam-as-a-service company that marketing has been using without telling anyone gets blocked due to their DNS settings.

by account42

7/28/2026 at 1:41:36 PM

68.4% is actually a lot. Considering how badly abused email has always been, I'm actually surprised its nearly 70% and growing. Cup half full I guess

by datakan

7/28/2026 at 2:59:21 PM

68.4% still don't enforce it, i.e. adoption is just over 30%, not nearly 70%.

by OJFord

7/28/2026 at 3:41:48 PM

Thank you

by datakan

7/28/2026 at 3:09:08 PM

You misunderstood, it's 31.6% actually.

by bornfreddy

7/28/2026 at 3:41:54 PM

Thank you

by datakan

7/28/2026 at 2:36:50 PM

Domains with stricter DMARC that isn't on 'none' are in my experience more likely to be spammers than desirable email.

by thyristan

7/28/2026 at 8:26:30 PM

Given how much spam has valid DMARC/DKIM it is just useless.

Turns out making absolutely sure email isn't faked means jack shit if user isn't even looking at it, or the spoofed domains looks "close enough".

Currently the big pile of mail "security" extensions is basically useless pile of waste that just gives mail server admins some extra work.

by PunchyHamster

7/28/2026 at 2:16:01 PM

DMARC is simple in theory but quite tricky in practice (with subdomains, for example). You follow the guide for a service (say Mailgun, for example) and everything looks fine, but CloudFlare shows up issues. You fix those issues and you're conflicting the mail service guide.

Anyways, the new CF AI tool is relatively decent for this purpose, explains the fact that most warnings in CF are harmless, but the lack of standardized guidelines is annoying to say the least.

by sebow

7/28/2026 at 3:57:10 PM

[flagged]

by thomas_krosos

7/28/2026 at 9:58:33 PM

[flagged]

by fdcampbell

7/28/2026 at 7:26:59 PM

[flagged]

by landver

7/28/2026 at 1:26:44 PM

[flagged]

by nextblock

7/28/2026 at 2:02:59 PM

[flagged]

by sharpnick

7/28/2026 at 4:50:03 PM

[flagged]

by ovo101

7/28/2026 at 9:31:58 PM

[dead]

by Lookbefore-org

7/28/2026 at 3:44:22 PM

[dead]

by luciana1u

7/28/2026 at 5:08:39 PM

[dead]

by tailscaler2026

7/28/2026 at 2:02:34 PM

[dead]

by damonblue