As you're may be aware, I actively promote adoption of DANE SMTP, many thanks to everyone who's moved forward with DANE SMTP deployment!
That said, I also always stress that, when deploying DANE SMTP, *monitoring* must come first, and publishing of DANE TLSA records second. If your DANE TLSA deployment is unmonitored, it will some day fail, with you being the last to know that something is wrong when some email fails to arrive on time or at all. Unmonitored security is a ticking time-bomb.
Please implement monitoring of your DANE TLSA records vs. the live certificate chain through regular probing of your MX hosts (I'd suggest hourly if not more often for more critical servers). Of course you also need to have good automation of the certificate rollover process so that normally TLSA records aren't out sync with the certificates even during a rollover.
If you don't yet have monitoring in place, the below could be a useful building block for your monitoring scripts.
The "danesmtp" shell (bash) function can take an optional explicit IP address to connect to, so you can test each of the IP addresses of a host in turn:
danesmtp () { local OPTIND=1 opt local -a rrs sslopts local rr i=0 host addr while getopts a: opt; do case $opt in a) addr=$OPTARG case $addr in *:*) addr="[$addr]";; esac;; *) printf 'usage: danesmtp [-a addr] host [ssloption ...]\n' return 1;; esac done shift $((OPTIND - 1)) host=$1 shift if [[ -z "$addr" ]]; then addr="$host" fi sslopts=(-starttls smtp -connect "$addr:25" -verify 9 -verify_return_error -dane_ee_no_namechecks -dane_tlsa_domain "$host") rrs=( $(dig +short +nosplit -t tlsa "_25._tcp.$host" | grep -Ei '^[23] [01] [012] [0-9a-f]+$') ) while (( i < ${#rrs[@]} - 3 )); do rr=${rrs[@]:$i:4} i=$((i+4)) sslopts=("${sslopts[@]}" "-dane_tlsa_rrdata" "$rr") done ( sleep 1; printf "QUIT\r\n" ) | openssl s_client -brief "${sslopts[@]}" "$@" }