Hacker News new | past | comments | ask | show | jobs | submit
"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?
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 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.
This service is not accurate, it cannot handle multiple dkim keys.
Not enough. O365 still discard/lose e-mails.
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?
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 in 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.
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.

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.
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.
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 what the big providers can't stand and why they 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.

Also why they do non-standard stuff like accepting mail but then simply not delivering it, rather than bouncing it.

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.

loading story #50421257
Microsoft has provided free email addresses to the public for decades.
There is no such thing as a free and open channel on the internet that will not suffer the tragedy of the commons.
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.
loading story #50418843
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.
Strengthen your contracts / terms of service. Make it their responsibility to configure their email systems properly so they receive emails sent from your domains.
So what have you switched to instead?
Postal mail still works.
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.
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.