Birbla

Discussion summary

DKIM2 and DMARCbis are new email authentication standards gaining attention, with discussions on their impact and implementation challenges. Major providers like Gmail, iCloud, and Microsoft are involved, raising concerns about access and security.

What the discussion says

  • Some see DKIM2 as a way to improve email security and reduce spam.
  • Others worry it could centralize email control with big providers.
  • There are concerns about setup complexity and potential new exploit vectors.
  • Participants are curious about migration experiences and technical details.
“DKIM2 layering seems to fix that for mailing lists.”
— braiamp
“I wonder if it closes enough holes to stop using SPF.”
— stefan_lec

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • I really don't understand what the original DKIM was not sufficient. Can someone ELI5? If you can verify that a message (including headers, which DKIK can sign) was signed by the outgoing server, then why isn't that the end of the story? Who cares how or why it got forwarded, or whatever else?
    by dataflow
  • > Who cares how or why it got forwarded, or whatever else?

    Because it broke enough niche usecases that lots of people didn't feel comfortable fully turning on dmarc in strict mode. Fixing that will hopefully spike adoption

    by bawolff
  • There are a few gaps with DKIM.

    1. You have to set it up on every sending server. It's easier today but it wasn't always

    2. You have to periodically rotate each of the keys that you setup because they can be cracked/stolen. Soon as somebody steals your key, they can impersonate anyone sending email from your domain.

    3. Receiving email servers have no way of knowing if a message they received without a DKIM signature is supposed to include a DKIM signature, so simply not including one creates a scenario where receiving mail servers have to guess if the message was really from you.

    by brightball
  • They want to allow forwarders (such as mailing lists) to modify signed messages all while keeping the original signed author email address. It is meant to replace ARC which is now deprecated.

    You can now verify who changed what and when but it is still based on will and trust to accept what has been altered and therefore a security theatre.

    It ‘solved’ a problem for a mailing list that insist on altering signed messages, even though they do not have to modify forwarded messages in my opinion and many lists do not.

    by winstonwinston
  • They spent a huge amount of complexity supporting mailing lists that claim mutated messages came FROM the original sender instead of FROM mailinglist@example.com. Is that use-case worth the additional effort?
    by drhagen
  • Yes. Mailing lists are incredibly useful and very hard to change.
    by bombcar
  • Yes! Forwarding is the reason mail flow authentication does not work very well today. Fix the forwarding use cases (and by extension: mailing lists & out of office arrangements) and we can finally just tell all senders: "Your domains do not match, please use DMARC so we can automatically detect whether that is OK. No excuses, no exemptions, your use case can be dealt with using DMARC!"
    by edelbitter
  • First time I'm reading about this, I'm glad there's progress in this area.

    The JSON DSL for rewriting emails feels like a spammer/exploit vector waiting to happen. Some product is going to spam filter before applying reconstruction rules, or get tricked into applying reconstruction rules when it shouldn't, and spammers and scammer are going to abuse it.

    Until either Google or Microsoft will adopt these standards, they'll remain effectively meaningless most likely. But even so, it's good to know people haven't given up on fixing email's spam problem entirely.

    by jeroenhd
  • well done

    you're among the first few who have done it:

    https://github.com/mjl-/mox/issues/404#issuecomment-43627498...

    by meysamazad
  • Maybe it's time to call it CMTP
    by edoceo
  • Complex Message Transfer Protocol
    by toomim
  • I wonder how this post was composed. It's full of LLM-isms, but is also pretty informative and not too fluffy - basically, higher-quality than I'm used to seeing from LLM blog posts, especially at this length. Perhaps it was composed based on a detailed human outline? Or perhaps, could this be the power of Fable?
    by comex
  • Can someone distill this down to how it will be used by the big three email providers to make it impossible to use email except through them?
    by bigbuppo
  • > by the big three

    Which big three?

    Gmail has something like 1.8 billion users. iCloud mail around 1 billion.

    Microsoft with 400 million users of its email is closer to Yahoo! Mail (225 million users) than to the big two.

    by TacticalCoder
  • If anything, this moves it towards anyone having more access to everything. For example, reject isn't going to be treated anymore as a bounce. Now, provider policies still can and would be BS, but the standard doesn't tell them to do it certain way.
    by braiamp
  • Questions:

    - How much infrastructure has to be fixed before this works, and in what order?

    - Can you send mail from something that doesn't have a DNS entry? How does this affect the first hop from a desktop or mobile SMTP client?

    - If an spam email came via SendGrid, Constant Spammer, or MailChump, are you going to be able to tell from the header signatures?

    - If your headers are correct, are you guaranteed mail bounces for un-deliverable emails?

    by Animats
  • > If an spam email came via SendGrid, Constant Spammer, or MailChump, are you going to be able to tell from the header signatures?

    Couldn't you always tell this from headers? At the very least the recieved headers are going to be a give away.

    by bawolff
  • > Can you send mail from something that doesn't have a DNS entry?

    I hope not. Just like SSL, I think requiring a registrar+DNS server to vouch for a durable identity is an important barrier to abuse (and an important intervention point for violation reports).

    by zbentley
  • > Can you send mail from something that doesn't have a DNS entry?

    You never really could. Participating in public email exchange requires that the sender can resolve then "fully qualified" domain in your return address. Except after prior agreement or authentication, messages simply that fail this are not generally accepted.

    > If your headers are correct, are you guaranteed mail bounces for un-deliverable emails?

    Even better: You are more likely to see an immediate refusal instead of a delayed bounce, if the recipient exchange can during transmission already determine that they do not want message claiming to be originally transmitted from X to Y yet breaking their ability to check the signature added by X.

    by edelbitter
  • Missed opportunity to get rid of SPF. What I want to my DMARC policy to say: if someone is sending you an email that claims to be from my domain and it's not signed by one of the keys I have published under my domain, you should reject it, regardless where it came from.

    And on the receiving side, the policy is similarly simple: if I receive any unsigned or unaligned email, I will reject it.

    Edit: to clarify, I want there to be an option where I specify my DMARC policy to explicitly tell well-configured receiving servers "ignore whatever I have configured as my SPF record, only look at the signatures". There will no doubt be a long tail of mail servers where I will still need an SPF record for them to accept my mail.

    Edit2: Another feature that I feel is lacking is ability to give dkim selectors a scope - e.g. this key is only valid for these particular From addresses.

    by peanut-walrus
  • I suspect SPF is used because it's cheaper than performing cryptographic checks for each email. A (cached) DNS lookup and IP check on a connection is comparatively cheaper.
    by AceJohnny2
  • >Missed opportunity to get rid of SPF.

    > you should reject it, regardless where it came from.

    Just don't use it yourself then?

    "v=spf1 ?all"

    by TZubiri
  • Isn’t that already what DMARC does though? For DMARC to pass you need DKIM _or_ SPF alignment, not both. It’s designed that way because there are scenarios where SPF _can’t_ pass (email forwarding, mailing lists). So a well-configured mail server should accept your email regardless of SPF if DKIM is properly configured.

    Re: specific keys for specific usernames: I can appreciate that you wish DKIM allowed for this, and I could imagine it being handy, but that was never the problem DKIM set out to solve — DKIM and SPF are all about be domain.

    I’m also not sure it’s a great idea — the sender identity should be under the control of the sender. If you control the domain @foo.com, you could use that ability to assert that an email came from Bob, even if Bob never sent it. Contrast that with Bob signing the email using his own private key.

    by justusthane
  • And I want mine to say: if it comes from my MX server it's legit, don't worry about the keys.

    Because that's easy and keys and signing are hard.

    by inigyou
  • Best way to go about this is just blackhole SPF so it never passes, then set your DMARC alignment to strict. This approach prevents SPF from satisfying DMARC on the vast majority of providers [1].

    [1] https://taejoong.github.io/files/publications/hamza-2026-dma...

    by ericpauley
  • Despite what everyone said, I'm excited specifically for DKIM2. As someone that had managed a mailing list, that one is probably the hardest thing to juggle around and DKIM2 layering seems to fix that issue neatly. I hope postfix has a guide proto.
    by braiamp
  • Aw hell. How many things do I have to set up just so that I can send e-mails from my own domain?

    The effect of all this seems to be less "making e-mail secure" and more "making it so that only Google, Apple, and Microsoft can send e-mail successfully"

    by qurren
  • Eh, I read the article, and at most you only have to wait for your MTA to update to add the required headers and update your DNS records and you are golden. It still uses the same key you generated as far I'm aware.
    by braiamp
  • > Aw hell. How many things do I have to set up just so that I can send e-mails from my own domain?

    ... said every spammer.

    I'm sorry for your pain, and I'm in the same boat.

    But it's important to understand that any sufficiently large, distributed-agent system (like federated email), will see the rise of parasites that will pump resources and diminish the value of the system.

    What we're seeing here is an "immune" response to those parasites. We all pay for it.

    I think this is an important lesson for anyone designing a distributed-agent system [1]. How do you design it so as to keep the bad actors out, or at least so their impact is negligeable?

    [1] imma make my own email system! With blackjack, and hookers! oh wait...

    by AceJohnny2
  • This sort of Regulatory Capture is quite old in the software field. People were already noticing it in the 90's.

    Making a spec that contains a venn diagram of most of the features each of the signatories to the specification have implemented themselves ends up pulling the ladder up behind them. Each non-academic committee member discovers they're already more than 75% of the way to having completed the spec and any junior members or amateurs have years of work to do in order to catch up to Now. If any upstarts threaten to get within striking distance of an implementation you can always convene the committee again and discuss version 2 of the spec.

    Mobile devices tamped this down just a little bit but mostly they lowered the slope of the line a hair and changed where the focus was a bit.

    by hinkley