HN Debrief

DKIM2 and DMARCbis Have Landed

  • Infrastructure
  • Security
  • Standards
  • Open Source

The post announced that DKIM2 and DMARCbis have now landed, with the pitch that they modernize email authentication without throwing away the current stack. The practical change is that email systems get better ways to preserve authentication when messages are forwarded, rewritten by mailing lists, or otherwise touched in transit. That is the part the existing DKIM and DMARC world has handled badly for years. Several people pointed out that this is not really about making email harder for small operators. It is mostly a cleanup of brittle behavior that already punishes normal workflows and keeps domains from enforcing stricter anti-spoofing policies.

If you run email for your company, plan for these updates as compatibility work rather than a strategic reset. They should reduce pain around forwarding and list traffic, but they will not solve the bigger operational problem that Microsoft, Google, and other large receivers still gate delivery with opaque reputation systems.

Discussion mood

Cautiously positive on the standards themselves, frustrated about real-world email operations. People liked that DKIM2 and DMARCbis appear to fix forwarding and mailing-list edge cases that have blocked stricter adoption, but they were blunt that deliverability is still dominated by opaque reputation systems, especially at Microsoft and other large providers.

Key insights

  1. 01

    Forwarding is the blocker, not spoofing theory

    Forwarding and mailing-list rewriting are the operational reason strict DMARC still gets watered down. Fixing those paths means domains can finally publish stronger policies without breaking legitimate mail, which is more important than any abstract improvement to the crypto itself.

    If you have held back on stricter DMARC because of list traffic, aliases, or forwarding, this is the part to watch. Test those workflows first when your MTA adds support, because they are where adoption can actually move.

      Attribution:
    • braiamp #1
    • bombcar #1
    • edelbitter #1
    • bawolff #1
  2. 02

    Standards compliance still will not buy deliverability

    Even perfect authentication does not override receiver policy. Large providers still refuse mail based on sender IP reputation, shared VPS ranges, or provider-level abuse history, so a cleaner DKIM and DMARC stack fixes protocol breakage without fixing the thing operators usually experience as email being broken.

    Treat authentication and deliverability as separate tracks in your mail plan. Passing DMARC is table stakes, but you still need to think about outbound IP quality, relay choice, and whether self-hosting is worth the operational drag.

      Attribution:
    • doubled112 #1 #2
    • braiamp #1
  3. 03

    SPF survives because the ecosystem still depends on it

    People want a world where only DKIM signatures matter, but receivers and spam filters still use SPF heavily enough that you cannot safely ignore it. DMARC already allows either DKIM or SPF alignment, which means operators cannot express a clean "DKIM required, SPF ignored" policy without risking compatibility problems on older or nonstandard systems.

    Do not plan on removing SPF yet, even if your security model would be cleaner with DKIM alone. Keep SPF configured conservatively and assume you will be running both for years.

      Attribution:
    • peanut-walrus #1 #2
    • ericpauley #1
    • toast0 #1
    • reader9274 #1
    • AceJohnny2 #1
  4. 04

    DKIM is per sender service, not just per domain

    A domain often sends mail through several independent systems like Google Workspace, SendGrid, or marketing platforms. Each one needs its own DKIM setup because those providers cannot all share one private key, which is why receivers cannot infer a domain's intended signing behavior from history alone.

    Audit every system that can send as your domain, not just your primary mailbox provider. Marketing tools, transactional mail services, and support platforms all need explicit DKIM and DMARC alignment or they become your weakest link.

      Attribution:
    • brightball #1 #2 #3
  5. 05

    Missing DMARC became a spam signal by shortcut

    Some operators turned "no DMARC record" into a negative trust signal even though DMARC was meant to say what to do when authentication is evaluated, not to punish domains that have not published a policy yet. That shortcut trained people to experience DMARC as a deliverability hurdle instead of an anti-impersonation control.

    If you run inbound filtering, check that your rules distinguish absent DMARC from failed DMARC. If you send mail, assume many receivers do not make that distinction and publish at least a basic record.

      Attribution:
    • bombcar #1
    • qurren #1
    • drdexebtjl #1
  6. 06

    SMTP refusal and bounce are not the same thing

    A 5xx SMTP response during delivery is a refusal to accept the message, not a bounce generated by the remote provider. The bounce-like notice users see usually comes later from their own MTA after it fails delivery, which matters because these standards aim to enable more immediate, deterministic refusals before mail is accepted and queued.

    When debugging mail failures, separate remote SMTP rejects from post-acceptance non-delivery reports. They point to different failure modes and different places to instrument in your mail pipeline.

      Attribution:
    • toast0 #1
    • edelbitter #1
    • turpentine #1

Against the grain

  1. 01

    Standards churn still favors incumbents

    The skeptical view is that every new revision rewards the vendors already closest to the spec and pushes hobbyists and small operators further behind. Even if DKIM2 and DMARCbis are technically cleaner, they still add moving parts to a system where the people with the most engineering staff already control the outcome.

    If you are choosing whether to self-host mail, count future standards maintenance as a real ongoing cost. This stack does not stand still, and the upgrade burden falls hardest on the smallest operators.

      Attribution:
    • hinkley #1
  2. 02

    Mailing list compatibility may be the wrong goal

    One objection was that too much complexity is being spent preserving old behavior where lists mutate a message but keep the original author's identity in the From field. From that perspective, DKIM2 solves a social and product design choice by adding more protocol machinery, when lists could instead present themselves as the sender and avoid the problem.

    If you operate list software, do not assume the protocol should absorb every legacy behavior. Sometimes changing product semantics is cheaper and safer than preserving them cryptographically.

      Attribution:
    • winstonwinston #1
  3. 03

    Proof of work will not rescue self-hosted email

    The idea of using Hashcash or another proof-of-work system to price out spam sounds attractive to small senders, but the economics do not work cleanly. A cost low enough for legitimate mail barely slows targeted spam, and a cost high enough to hurt attackers becomes unacceptable friction for normal communication.

    Do not expect computational postage to become the missing piece that makes personal mail servers viable. The bottleneck is receiver trust and abuse handling, not just the marginal cost of sending one more message.

      Attribution:
    • SXX #1
    • bawolff #1 #2

In plain english

DKIM ↩
DomainKeys Identified Mail, a system that lets a sending domain attach a cryptographic signature to an email so receivers can verify it was authorized by that domain and not altered in transit.
DKIM2 ↩
A newer revision of DKIM intended to handle message forwarding and modification more cleanly while preserving authentication.
DMARC ↩
Domain-based Message Authentication, Reporting, and Conformance, a policy system that tells receivers how to evaluate and act on email that claims to come from a domain using DKIM and SPF.
DMARCbis ↩
A revised version of the DMARC standard that updates how domains publish and receivers interpret DMARC policies.
Hashcash ↩
An early proof-of-work scheme proposed for email, where the sender computes a token that is cheap to verify but costly enough to generate at scale.
IP ↩
Internet Protocol address, the numeric network address used to identify a device or server on the Internet.
MTA ↩
Mail Transfer Agent, the server software that sends, receives, and relays email between systems.
SMTP ↩
Simple Mail Transfer Protocol, the core protocol used to send email between clients and mail servers.
SPF ↩
Sender Policy Framework, a DNS-based record that lists which mail servers are allowed to send email for a domain.
VPS ↩
Virtual Private Server, a rented virtual machine often used to run self-hosted services like websites or mail servers.

Reference links

Implementation and rollout references

Papers and technical references

Deployment and adoption data