Is it possible to use MTA-STS in Postfix without overriding DANE?

The SMTP MTA Strict Transport Security RFC 8461, 2 clearly states that:

However, MTA-STS is designed not to interfere with DANE deployments when the two overlap; in particular, senders who implement MTA-STS validation MUST NOT allow MTA-STS Policy validation to override a failing DANE validation.

Currently it seems that with the following Postfix configuration the MTA-STA overrides DANE (RFC 6698) validation when the recipient has implemented both, as discussed in the mta-sts-daemon's issue #67, and DANE is only used if the domain is explicitly listed in the first matching smtp_tls_policy_maps (/etc/postfix/tls_policy) as dane-only.

# Opportunistic DANE TLS
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec

# MTA-STS
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_policy_maps =
    hash:/etc/postfix/tls_policy,
    socketmap:inet:127.0.0.1:8461:postfix

Has anyone found a way to configure Postfix in a RFC 8461 compliant way, i.e., that MTA-STS policy validation through mta-sts-daemon cannot change the policy maps for domains that have both technologies enabled? Would this require an additional external "dane-daemon" providing dane-only smtp_tls_policy_maps for domains that have DANE enabled?

The comments already landed on the right primitive (having the resolver return dane-only instead of dane), so here is how to turn that into an actual RFC 8461-compliant config, plus a newer option that sidesteps the whole problem.

Why it happens, briefly: DANE in Postfix is internal, driven by smtp_tls_security_level = dane and the TLSA lookup. But a hit in smtp_tls_policy_maps overrides that security level for the matched domain. postfix-mta-sts-resolver cannot see TLSA records, so for any domain that publishes an MTA-STS policy it simply answers secure, and that answer supersedes DANE. If DANE would have failed for that domain, MTA-STS has now overridden a failing DANE validation, which is exactly what RFC 8461 section 2 forbids.

So yes, the fix is to put a "DANE decides first" lookup ahead of the MTA-STS socketmap, because Postfix uses the first matching entry in smtp_tls_policy_maps. You do not necessarily need a whole second daemon. The resolver's own README documents two ways to do it:

1. Put a DANE policy resolver that returns dane-only (Mandatory DANE) before postfix-mta-sts-resolver in the smtp_tls_policy_maps list. dane-only is the important part: unlike dane, it does not fall back to may/encrypt when the TLSA records are missing or unusable, it defers instead. So a failing DANE validation stays failed and MTA-STS never gets the chance to override it

2. For a small, known set of domains that run both, you can skip the extra daemon entirely and use a static table in front:

    smtp_tls_policy_maps =
        hash:/etc/postfix/tls_policy,
        socketmap:inet:127.0.0.1:8461:postfix
   

   with the DANE domains pinned in /etc/postfix/tls_policy:

    example.com   dane-only
   

   The hash table is consulted first, so those domains get Mandatory DANE and the socketmap is never asked about them; everything else falls through to MTA-STS exactly as before.

The catch with both approaches is that you are now maintaining, by hand or with a helper, the list of which domains have usable TLSA records. That bookkeeping is effectively the "additional dane-daemon" you asked about, and it is the price of bolting a DANE-blind MTA-STS resolver onto Postfix.

If you would rather not chain two resolvers, the cleaner modern answer is postfix-tlspol. It is a single TLS policy server for Postfix that evaluates both DANE/TLSA and MTA-STS for each destination and prioritizes DANE, so it returns dane-only on its own when TLSA records exist and only applies MTA-STS otherwise. That makes it RFC 8461-compliant by construction, and it replaces the socketmap line rather than sitting in front of it. For a fresh setup today, that is what I would reach for