Solo ads sellers / Blog / DANE for SMTP

Solo ads blog

A DNS certificate check is a different question from a solo ad

Answer DANE for SMTP is a way for a sender to check a mail server's certificate against a TLSA record in DNS. RFC 7672 describes that check. It does not score a solo ad list, and a missing record is not a verdict on the seller. Do not buy or refuse a drop because of a census this note does not have.

Cream stationery and a teal accent on a dark navy desk
A certificate in DNS answers a path question.

The note that started this: RFC 7672, SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS), RFC 7672.

The month has already covered a TLS policy the receiver can publish for its MX hosts. DANE is a different mechanism with a similar motive: know which server you are talking to, and know the certificate is the one that domain's DNS expects. People collapse every encryption acronym into one badge. The badge does not tell you if the list opted in.

RFC 7672 is SMTP security via opportunistic DANE TLS. A TLSA record is published in DNS, ideally under DNSSEC so the record itself can be authenticated. A sender that implements the specification looks up that record and uses it when it negotiates TLS with the MX. If the certificate does not match, a careful sender does not shrug and send the message to whoever answered. That is a path control. It sits far below the question of whether the person wanted a guest offer in today's letter.

What does DANE add to mail delivery?

RFC 7672 lets a sender authenticate an SMTP server's certificate using a TLSA record in DNS. The check is about the server you are handing the message to. It is not a test of whether the recipient opted in.

The useful picture is a locked door on the building, not a guest list at the party. The door can be real and the party can still be the wrong party. A solo ad can travel over a well-authenticated hop and still be unwanted mail. It can also travel a hop that has never heard of TLSA and still be a fair letter to people who asked. Path quality and list quality are different purchases. Pay for the one the quote actually describes.

If you buy solo ads, you will meet a seller who stacks acronyms under the price. SPF, DKIM, DMARC, TLS, and now DANE, offered as a single yes. Ask them to point at the record they mean. If they cannot show a TLSA record they rely on, the word was decoration. Decoration is cheaper than a false sense that the list was vetted by a certificate.

Does a missing TLSA record mean the solo ad is unsafe?

No. Many receivers never publish one. Absence is not a finding about the seller's list, and this note will not pretend a count of who publishes TLSA. The list question is still whether people asked for the mail.

This desk has seen writeups that count how many big consumer domains publish a TLSA record. Those counts belong to those writeups and those dates. They will not be repeated here as if they were part of RFC 7672. The specification does not require every mailbox on earth to participate. Treating non-participation as a scandal will push you to reject ordinary mail and to trust a seller who merely pronounces the acronym.

The safety question for a buyer remains the one on safe solo ads sellers. Who collected the names. What they were promised. Which domain signs. How complaints are suppressed. Where the exit sits. A certificate record does not replace any line on that list.

What should a buyer ask instead?

Ask who operates the hop, whether TLS is required when the receiver demands it, and where bounces are read. Leave certificate-in-DNS trivia off the invoice unless the seller actually uses it and can show it.

Those three questions are answerable in a sentence each. The operator is a platform or a host. The TLS behavior is a yes they can point to in a bounce, or a guess. The bounce mailbox is an address with a person. DANE, if it is real for them, is a fourth sentence with a record attached. If the fourth sentence is missing, the order can still be honest.

Pay for the list and the path they can describe. Solo ad pricing does not go up because a proposal contains more protocol names. A TLSA record is a lock. The lock is not the letter.