Common Mistakes

Publishing DNSSEC DS records, and DANE TLSA records as a fashion statement
Keeping these correct requires operational discipline. Administrators who expect "fire and forget" should not publish DNSSEC signed zones or DANE TLSA records. Or they can pay others to host their zones and DANE TLS services.
Operating poorly maintained DNSSEC zones or TLSA records creates problems not only for the domain in question, but also for all the domains trying to communicate with such a domain. Everyone is better off if DNSSEC and DANE are taken seriously.
Failure to automate DNS zone signing
Multiple domains have been observed to become non-operational because the RRSIG records have expired. MAKE SURE you've automated zone signing reliably.
Failure to update TLSA records before updating the matching server certificate chain (deploying a new server key pair, or using a new issuing CA)
Multiple domains have left stale TLSA records in effect while updating the server certificate chain. Make sure that TLSA records matching the planned certificate chain are published in addition to the records matching the current chain, and left in place for a few TTLs, before deploying the planned certificate chain.
Once the planned certificate chain is deployed, TLSA records matching the previous chain can be removed. See Key rollover with fixed TLSA Parameters and TLSA Publisher Requirements Summary for details.
Initial, key1 is deployed on the server: 
_25._tcp.mail.example.com. IN TLSA 3 1 1 <key1-digest>
2 or more TTLs before switching to key2: 
_25._tcp.mail.example.com. IN TLSA 3 1 1 <key1-digest>
_25._tcp.mail.example.com. IN TLSA 3 1 1 <key2-digest>
After key2 deployed and key1 is no longer in use: 
_25._tcp.mail.example.com. IN TLSA 3 1 1 <key2-digest>
(Similar process with "3 0 1" and certificate digests, ...)
Remember to check that all secondary nameservers are getting timely updates of changes. The TTL clock starts only after the last secondary nameserver is serving the updated TLSA records.
When your DANE TLSA records are CNAMEs to a location where your organization's issuing authority maintains suitable TLSA records for you, you can deploy new certificates from that authority without updating the server's TLSA records. The burden of key rollover falls on that authority, before they issue any certificates via a new certificate or key.
Avoid the temptation to use the same certificate and keys on all the MX hosts. Otherwise, a careless key rotation that makes the TLSA records no longer match the keys, breaks all the servers that share the common records and keys.
Especially with the DANE-EE(3) certificate usage, use per-server self-signed keys. Ignore sites that tell you self-signed keys are bad, they don't know what they're talking about, such keys are just fine for SMTP, and with DANE as secure as TLS can be with SMTP. Rotate these keys now and then, but not on all the servers at the same time.
With DANE-TA(2) certificate usage, failure to include the Issuing CA (trust-anchor) certificate in the server's certificate chain.
With DANE-TA(2), the issuing CA certificate MUST be configured in the server's certificate chain file. DANE SMTP clients typically do not look for these in any local list of trusted roots, even if they have such a list (no such list is required or expected with DANE for SMTP).
Unsupported certificate usage
For SMTP the TLSA record certificate usage MUST be either DANE-TA(2) or DANE-EE(3). The usages PKIX-TA(0) and PKIX-EE(1) are NOT supported.
Incorrect TLSA selector
Some domains publish TLSA records with a selector of SPKI(1), which indicates a digest of a public key, but the digest in the TLSA record is that of the containing certificate. Make sure the digest is computed over the correct object. Use a command-line tool or website that automatically extracts the correct data from the certificate.
Incorrect TLSA digest
Some domains compute the digest of something other than the binary ASN.1 DER form of the certificate or public key (SPKI format). Make sure you compute the digest of the correct encoding. Use a command-line tool or website that automatically converts the data into the correct form.
Selective availability of STARTTLS
Some SMTP servers only enable STARTTLS for clients that have a history of sending non-spam email to the receiving domain. If TLSA records are published by a domain with such servers, new senders are in a catch-22. They can't send email with STARTTLS disabled (the domain's DANE TLSA records require use of TLS). And STARTTLS won't be enabled until they've sent email.
Selective availability of STARTTLS is not compatible with DANE. Make sure that either STARTTLS is always on, or DANE TLSA records are NOT published for your domain.
Keep in mind that STARTTLS may be disabled by a proxy such as "spamd" or similar, that sits between remote clients and your SMTP server.
Firewalls that filter out TLSA queries
If your domain is DNSSEC validated, Make sure that your firewalls allow TLSA queries to reach your nameservers, over every address type. (Some firewalls block TLSA lookups only for IPv4).
Broken nameservers
Some nameservers (various djbdns versions patched for DNSSEC, older PowerDNS versions, ...) don't handle "denial of existence" correctly. The negative reply for "IN TLSA _25._tcp." lookups appear "bogus" to validating resolvers when the records in fact don't exist.
Make sure to check each of your nameserver's for valid denial of existence responses. This applies to all DNSSEC domains, not just those implementing DANE, and especially if they are NOT publishing TLSA records.
Partial implementation
DANE only protects your domain if the domain is DNSSEC validated, ALL its MX hosts are also in DNSSEC validated zones (their A/AAAA records are "secure"), and all of the MX hosts have "_25._tcp" TLSA records.
When only some of the MX hosts are protected, an active attacker can block access to the protected ones, allowing connections to just the unprotected hosts, where SMTP transport is subject to STARTTLS downgrade or other attacks.
Publishing DANE TLSA records for your SMTP servers only makes sense if you are planning to eventually publish TLSA records for all your MX hosts.

Brought to you by Viktor Dukhovni, dotplex and sys4