YHK - yet another hacker news clone

Yes. In the first place, this should not even be a thing. Two corporations should not be in control of who can send e-mail. If they want to mark not having DMARC as spam, mark it as spam, or better yet flag it with a specific warning about the domain, but these games with refusing to deliver are just bullshit and essentially force a monopoly where other e-mail providers cannot compete because their e-mails aren't delivered.

That said checking for these things is a good idea, the only problem I see is dropping the mail on the floor, rather than rejecting it at SMTP time - at least that lets the self-hosting users who haven't got things configured know their email is being rejected, and to pick up the phone instead.

There's nothing worse than sending an email, it being accepted, and then later discarded with no clue to either sender or recipient.

En contraire, I think not delivering mail is the fastest way to adoption. People will use an old system for as long as it works. It now does not anymore.

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

Not true, at least in my experiences.

I have a bunch of email accounts which have SPF and DKIM, but are missing the DMARC line - I've had no deliverability problems at all, until this weekend, and now only with Outlook. Emails to Gmail accounts go through just fine.

The combination of: √ Valid SPF √ Valid DKIM signature X Missing DMARC policy

Is clearly ambiguous. Since a DMARC of "p=none" (in the context of valid SPF and DKIM) really adds no information, so interpreting "missing DMARC" as "p=none" seems reasonable. Sounds like Microsoft was taking that approach until this weekend.

I wonder if there's an actual written standard?

When I ran that server, outlook.com was also the only one that would blackhole my email for no known reason. Support was unhelpful and also could not point to any reason. I've since given up, but for a short time it was glorious, email to family would not leave the lan and we could send attachments of arbitrary size.

[0] https://news.ycombinator.com/item?id=7708882

Is there a risk some people on this thread are mixing up DKIM and DMARC?

DKIM = proving that an email was sent from a specific domain using cryptography. Good for spam fighting and deliverability.

DMARC = telling receivers how to handle mail that fails authentication.

DMARC is primarily useful for large, complex organizations where email admins may not be aware of everyone inside the org who is sending mail that advertises the domain in the From header, or organizations that might be targeted by impersonation attacks (e.g. phishing). Being able to tell recipients "yes we absolutely have our act together so feel free to reject or spamfolder unauthenticated email" is great for killing phishing campaigns, and being able to request reports is great for finding that one sales org that signed up for a guerrilla marketing SaaS that's impersonating them.

But for small personal domains the value isn't that high.

maybe someone was too lazy to set up "inbound block list" and just did a total blackout instead?

Sounds like kind of a hack:

"ARC was devised to solve this problem by giving intermediate servers a way to sign the original message's validation results. Even if the SPF and DKIM validation fail, the receiving service can choose to validate the ARC chain. If it indicates that the original message passed the SPF and DKIM checks, and the only modifications were made by intermediaries trusted by the receiving service, the receiving service may choose to accept the email."