Yeah, and people who don't switch to Dvorak are lazy, too!

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

https://news.ycombinator.com/item?id=49081783

I have MCP servers for the creation of domains, DNS records with DNSSEC, and email accounts with SPF, DKIM and DMARC. I'm sure if someone wants to be a professional spammer today, DMARC is not a differentiator.

It's an interesting argument. The fact this article exists is somewhat proof that it is a differentiator. The flipside, however, is that spammers very specifically require their emails to get to add many mailboxes as possible, so their motivation is greater to make their emails service compatible.

Company sys admins have likely got all sorts of other issues to worry about, and the occasional report of an email not getting through is likely low on their to-investigate list.

Having said that, I self host a mail server, and have all those things setup correctly, and my workplace uses Outlook, and I've not had issues with delivery, so it's not a particularly difficult bar to jump.

What? How does it prove it's a differentiator for someone who wants to be a spammer, which is what the comment you replied to made a claim about? As far as I can tell, it's evidence (not proof) that Microsoft thinks that they will reduce spam by requiring it, which in turn is circumstantial evidence (definitely not proof) that spammers might have to spend some amount of effort to start using DMARC. I don't understand how you can conclude that it would be onerous for them to do so indefinitely; it seems equally plausible that they might have just not bothered to do it before now but will be able to start doing it without much cost.

"Lazy people"? I only heard about this because a customer complained. Am I supposed to go around the Internet, checking what each mail server will allow or deny?

As a company we realised about 12 months ago that email can no longer be considered a reliable method of communication. I understand the reasoning but the result is the result. Many new clients we deal with have whitelists on and we have to pester our clients to add us to their lists. Not a great experience for anyone. I think we should consider email pretty much moribund at this point.

So what have you switched to instead?

Spoiler alert: no method of communication is reliable anymore. All of them are controlled by companies that will route your messages to spam.

If reliable means the message gets through no matter what, then it's good that no channel is reliable. Such a channel will inevitably be used for spam and attention grabbing.

Postal mail still works.

Most of the world has switched to sending SMS to user's phone numbers.

Strengthen your contracts / terms of service. Make it their responsibility to configure their email systems properly so they receive emails sent from your domains.

It is literally one of the last free and open channels on the Internet – I suggest you work on supporting its use and keeping it that way rather than moving to something controlled for profit or data harvesting.

It being free and open is exactly why the big providers are coming up with ever more "standards" that are complex to configure as well as "reputation" scores that are hard for small senders to clear.

DMARC is not hard.

"Reputation scores" and blacklists / greylists started in late 1990s / early 2000s as multiple grassroots efforts when spam started to overwhelm systems. Gmail did not exist, outlook.com did not exist, it was easy and expected to run your own SMTP (which I did). And it was very unpleasant.

DMARC appeared 10 if not 15 years ago. There's no reason for a sane MTA configuration not to have it.

Outlook.com is a rebranding of Hotmail.com which absolutely did exist in the 90’s.

Indeed, Hotmail was sold to MS in 1997, which I incorrectly remembered to have happened past 2000.

Microsoft has provided free email addresses to the public for decades.

Calling it a "free and open channel" when 80% of consumers are on Microsoft/Google addresses that control who can deliver e-mail is laughable. It's dead, Jim.

Fair point - I meant free in the sense that the protocol is open. I didn’t mean that it’s not under threat.

You seem to miss the point WHY customers go there. I, for one, switched when I realized Google filters spam effectively.

That WHY seems to only address a very small slice of the market. Some other WHYs I've encountered

- it was a way to outsource the mail server administration and already free in our corporate package

Which is pretty much all I have from the corporate side. On the personal or small business side its most often

- I don't really care that much about running my own stuff

- I needed a personal email address

All these are valid reasons/motivations but none explicitly argue that email messaging should become proprietary.

There is no such thing as a free and open channel on the internet that will not suffer the tragedy of the commons.

It can be reliable, but requires an explicit agreement between the two parties. When my server connects to your server and sends a message, that part is reliable enough. If your server decides to delete the message after receiving it, that's entirely on you. You could configure it to never delete messages from me and then it's fine. The problem is that in reality nobody does this, so your vendors and customers get treated identically to random spammers.

To be fair, DMARC has been required for a very long time. IIRC Google warned about 2 years ago circa that non-compliant emails would land to spam or be null-routed. And the DMARC noise started even before that.

Gmail only requires DMARC for senders that send >5000 emails per day. Below that it's not required. That rule only appeared in 2024 so I wouldn't say it's been required for a very long time. Perhaps you're thinking of DKIM, which is different.

Google required me to add a DMARC record for a domain that doesn't even send 5000 emails per year. I suspect it was because of another mail server that shared the same subnet but was not under my direct control.

No. You're supposed to understand how mail works on the Internet, and configure it correctly so that everyone else accepts it.

Go to https://mail-tester.com. Send a test email. If you don't get 10/10, fix your shit.

This seems overly dismissive especially for individuals who send emails from custom domains at low volumes. DMARC has previously been seen to only be really needed for high-volume senders. The mail testing service linked still gives 10/10 for emails received without DMARC (but with SPF and DKIK). My email is setup via Fastmail and I followed all the recommendations they provided (which didn’t include DMARC)

Imagine that I deploy a site in HTTP-only, without TLS, and then complain "hey, why are browsers claiming that my site is insecure and showing some red padlock shenanigan, scaring my users away? Am I supposed to go around the Internet, checking what each browser considers 'secure' or not?"

I've had DMARC implemented on my low volume server since I learned about it 10 years ago, it's not that hard.

I just tried this out now with an email from my personal domain that I have configured to send via my gmail account. I got a 10/10, but DMARC does not seem to be required for this. It shows a yellow checkbox for me on this, the same as it shows for me not having an unsubscribe button, which hardly gives the impression of it being necessary, given that I would not expect an unsubscribe button to make sense for most people manually sending emails to their customers from corporate email accounts.

Not enough. O365 still discard/lose e-mails.

This service is not accurate, it cannot handle multiple dkim keys.

The funny thing is, my domain with Fastmail gets 10/10 and I didn't have a DMARC policy configured. So you're being dismissive when you don't even know what you're talking about.

How about you read other testimonials in this thread and dial down your patronizing mouth?

Delivery to Microsoft's products has been patchy for several years. I am not remotely an email deliverability expert but I have made different SMTP service choices based on how companies approach shared-IP sending plans.

Some can affordably deliver to Microsoft because they aggressively police what they are actually sending on their customers' behalf; others don't get involved and you end up having to spend a fortune on a dedicated IP.

The DMARC thing is just another part of this; one of my clients discovered this silent failure themselves a few weeks back and addressed this.

If running a mail server is central to your business, you should keep up with best practices. If not, 2 days of non-delivery aren't important, just resend.

You don't have to, this is the key reason to have a DMARC monitoring service. It will tell you when there's a deliverability issue with some particular receiver.

DMARC applies not on your mail server, inbound or outbound, but on the server that is receiving your mail (which may in fact be your mail server).

That server will look at how the mail authenticates and decide if it should allow the mail to proceed, it (for the most part) will then tell you whether or not it allowed the mail. This is how you will know you might have a deliverability problem before your customers do.

If you're wanting to know about deliverability (particularly for this Microsoft case), my company (Alesian Security) has a free check at https://alesiansecurity.com/try?tab=deliverability

> You don't have to, this is the key reason to have a DMARC monitoring service. It will tell you when there's a deliverability issue with some particular receiver.

It's been a while, but monitoring DMARC seemed pointless once you got things started. If my outbound mail fails to validate, I've asked the receivers to bounce it, and I should be able to see that on my own system.

Otherwise, I'm just getting reports about spoofed spam or people who need to adjust their mail forwarding, but I can't do anything about either.

right, if you're at a reject status DMARC monitoring is (and should be) boring.

But it provides a safe guard against accidentally broken mail flows as your email stack evolves over time which is where it pays dividends.

I would love to say that it would have alerted you ahead of time to this particular event, but given that it's the fix here you would never have seen it.

DMARC is a DNS record that says "send emails about spoofed messages here", or optionally "I don't need you to tell me that scammers exist on the internet".

It doesn't prevent spoofing, it doesn't say which IPs are authorized to send on behalf of a domain, it doesn't sign messages. Spoofed messages are still sendable.

Can you explain the benefit of only accepting email if Microsoft knows that you may or may not accept emails about scammers unsuccessfully spoofing your email domain? (Note, there's nothing you can do if they do tell you.)

Don't confuse DMARC with DKIM or SPF; DMARC doesn't actually do anything for email security.

[delayed]

And what should a provider do if the dmarc policy says that none of the dkim or dmarc records should matter? What was the point of spf saying what servers could send, or dkim specifying signing keys?

"Oh, please, don't ignore the other two ways I told you to ignore unauthorized messages" shouldn't need a knob.

You are a mail server.

You get an email without a DKIM signature from me.

Is that because I do not use DKIM and do not sign my emails or because the message is forged and not from me at all?

You cannot tell. There is a single SPF record that you can look up to see if SPF is configured. It's just a TXT record on the domain. But there is no standard DKIM record. A DKIM signed email tells you what key identifier it used and you have to use that to look up the DKIM key at <key identifier>._domainkey.<sender domain>. When the email has no DKIM signature you cannot tell if that's because the sender domain does not use DKIM or if it does have a DKIM key record but it was not used, potentially because the email is forged.

Right. And if you mandate dkim, as seems to be the case with servers that demand dmarc, what's the issue?

Or do you think it's critical to support mail that doesn't have dkim?

You'll have a bad time if you just drop all emails without DKIM. There are many large senders that do not care about well established email standards and you will drop important emails.

These are the same senders that are correctly configuring dmarc?

You said DMARC does not prevent email forgery. I simply corrected you on that and explained what DMARC does.

Setting a DMARC policy that allows unsigned emails is easier than configuring DMARC signing including key management. It's just adding a DNS record. Although large senders should of course do DKIM and it's not that hard either

But I'm not arguing with you about whatever Outlook did.

DMARC gives you 20 reminders that you have sent an email, just incase you had forgotten.

Are you just not familiar with the p= part of DMARC?

> Don't confuse DMARC with DKIM or SPF; DMARC doesn't actually do anything for email security.

DMARC doesn't introduce a new security mechanism by itself, but it fixed a few bad security flaws in SPF and DKIM. Without DMARC, SPF and DKIM do not add meaningful security.

DMARC updated and formalized how receivers should handle authorization and authentication of inbound email by adding the alignment requirement. Alignment ties the SPF and/or DKIM domain to the rfc5322.From domain. This also allows receivers to use domain reputation rather than IP-reputation.

SPF by itself has a bad design flaw that completely breaks any security that SPF was supposed to provide. By adding DMARC this security hole is fixed. (Although SPF is still horribly unreliable, it should be considered legacy at this point, don't rely on SPF).

DKIM benefits from DMARC alignment requirement too. DMARC ties the rfc5322.From domain to the DKIM signing domain, which makes DKIM practical for sender authorization, not just authentication.

lol, what a bunch of bs.

gmail runs with p=none

so tell me what benefits that has over having no dmarc record at all ?

> so tell me what benefits that has over having no dmarc record at all ?

The the existence of a DMARC assertion record in the DNS changes how the MTA (the receiving system) assesses the authentication of the message and authorization of the sender with SPF and/or DKIM, as per rfc7489 (and now also rfc9989).

No DMARC results in the MTA falling back to the original assessment method as defined in the original SPF and DKIM RFCs. These RFCs have design flaws and don't define the assessment flow all that well, they leave a lot up to the MTA's digression/interpretation.

So, the existence of a DMARC record with p=none is fundamentally different over not publishing a DMARC assertion record at all. It's just that with p=none you don't enforce the MTA to reject the email if it fails authentication/authorization, you're leaving it up to the MTAs digression.

that's not new for Hotmail/Outlook. They were _already_ requiring SPF or DKIM.

So how does them enforcing requiring a p=none record change that ?

I kind of have to agree. DMARC is not new. It's useful and helps make email safer. It's not even hard to set up. There's just no reason for any legitimate mail provider not to use it. Same for people who are technical enough to run their own mail servers.

Hey now, it's not just lazy people, some people set up a mail server twenty to thirty years ago and don't care about all that newfangled tech like DMARC or DANE or IMAPv4.

Too many companies run on incredibly frail email configurations (while at the same time asserting that an hour of downtime on their email is a catastrophic business risk).

Configuring your SPF wrong but everything still sort of working because DMARC doesn't explicityly say anything can be a feature. I guess the time may have finally come for those companies to pay decades of technical debt.