Re: [dane] How a multiple tenant SMTP service provider implement the DANE

Viktor Dukhovni <> Fri, 21 February 2020 03:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FE6E120814 for <>; Thu, 20 Feb 2020 19:21:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yt3eCMjsUq7a for <>; Thu, 20 Feb 2020 19:21:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1523D120233 for <>; Thu, 20 Feb 2020 19:21:25 -0800 (PST)
Received: by (Postfix, from userid 1001) id 3437C198C7B; Thu, 20 Feb 2020 22:21:24 -0500 (EST)
Date: Thu, 20 Feb 2020 22:21:24 -0500
From: Viktor Dukhovni <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <>
Subject: Re: [dane] How a multiple tenant SMTP service provider implement the DANE
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Feb 2020 03:21:28 -0000

On Thu, Feb 20, 2020 at 11:27:38AM +0800, Harvy Chen wrote:

> Once studied the DANE RFCs, for the multiple tenant service providers,
> like this: Sender ----> Service -----> Rcpt.

With DANE for SMTP the client authenticates the MX host, not the
recipient domain.  All the recipient domain has to do is have
DNSSEC-signed MX records.

As the provider your first responsibility to *monitor* your service
that you are promptly notified and take action to remediate any
situation in which your TLSA records for some reason stop matching
your certificate chain (e.g. poorly-executed certificate rollover).

Your next responsibility is to have a robust certificate rollover
process that avoids the potential outages that the monitoring
would detect.

> How can it implement the DANE for inbound traffic? It requires the
> customer's (rcpt) certificate, in TLS connection setup stage, we even
> don't know who is the rcpt, and cannot decide to use which
> certificate.

You DO NOT need certificates for the recipient domain, you just need
certificates for the supported name(s) under which your MX hosts are


    ; Some domains with DNSSEC-signed MX records that are MX-hosted
    ; by (there are many more):
    ; IN MX 10 IN MX 10 IN MX 10 IN MX 10 IN MX 10 IN MX 10

    ; The A records of are also DNSSEC-signed

    ; Both MX hosts also have DNSSEC-signed TLSA records.
    ; IN TLSA 3 1 1 d2a84de1a2049598ddc02f9a30f01f45c83d9fdde099657155d8e88d9515afe7 IN TLSA 3 1 1 d2a84de1a2049598ddc02f9a30f01f45c83d9fdde099657155d8e88d9515afe7

    ; Their certificates matches these TLSA records. With RFC7672
    ; DANE SMTP, when using DANE-EE(3) (certificate usage 3) TLSA
    ; records, the names in the certificate are irrelevant.  They
    ; are implicit in the TLSA RR owner name (_25._tcp + "TLSA base
    ; domain").
    ;[]: pass: TLSA match: depth = 0, name = *[]: pass: TLSA match: depth = 0, name = *
      TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384,P256
      name =
      name = *
      depth = 0
        Issuer CommonName = Sectigo RSA Domain Validation Secure Server CA
        Issuer Organization = Sectigo Limited
        notBefore = 2019-03-04T00:00:00Z
        notAfter = 2021-03-03T23:59:59Z
        Subject CommonName =
        pkey sha256 [matched] <- 3 1 1 d2a84de1a2049598ddc02f9a30f01f45c83d9fdde099657155d8e88d9515afe7

If your MX hosts support SNI, you can if desired have separate
certificates for a few different names of each MX host.  If
your MX support both RSA and ECDSA (configured with separate
certificates for each algorithm), then you need multiple TLSA
records to match these: