STARTTLS on one hop is not a policy
Answer STARTTLS is a way for one SMTP connection to upgrade to TLS when both sides agree. RFC 3207 defines that extension. A hop that upgraded is not a policy that every hop must upgrade, and it is not a promise that the solo ad will reach the inbox. Ask the seller what they can actually say about the path.
The note that started this: RFC 3207, SMTP Service Extension for Secure SMTP over TLS, RFC 3207.
Yesterday's note retired cleartext on submission. Today is the word people use once they have heard that note. They say the mail is TLS and they stop. TLS on a slide is usually one hop, the one they control, offered rather than required. The reader is several hops away. Buy solo ads from a seller who can tell an offer from a requirement.
RFC 3207 is the service extension. A client and a server negotiate. If both want TLS, the session can upgrade. If they do not, the old behavior remains available unless something else forbids it. That sentence is the whole desk lesson. An extension that depends on agreement is not the same object as a rule that refuses mail when agreement fails. Sellers collapse them because both contain the letters TLS.
What is STARTTLS on a mail path?
It is the SMTP extension in RFC 3207 that lets a connection upgrade to TLS when both sides agree. It describes a hop. It does not, by itself, require every later hop to upgrade.
Mail is a chain. Your platform talks to a server. That server talks to another. The mailbox provider talks to its own delivery machinery. Each link can have its own decision about encryption. A badge that says the first link upgraded does not interview the rest of the chain. A buyer who stops at the badge has audited the slide.
This is also why a test message to yourself proves less than it feels like. Your own provider accepted a message on a path that happened to work at noon. The addresses on the seller's list use other providers. Some of those hops may upgrade. Some may not. You will not see the difference in a screenshot of your own inbox.
- The seller can say whether submission itself is encrypted.
- The seller does not claim that one hop covers the whole route.
- A test to your own mailbox is labeled as a test.
- Inbox placement is not listed as a benefit of the upgrade.
Is STARTTLS the same as a TLS policy?
No. STARTTLS is an offer to upgrade a connection. A policy that tells senders they must use TLS, and what to do when they cannot, is a different mechanism. One successful upgrade is not that policy.
A policy has consequences. It says what a sender should do when the upgrade is missing, stripped, or pointed at the wrong name. An offer has a handshake. The handshake can succeed on Tuesday and fail on Wednesday without the offer itself changing. If you want the stricter object, ask for it by its own name and read that document on its own day. Do not let a seller point at RFC 3207 and call it a policy.
The practical question on a solo ad is smaller. Does the platform require encryption for the session that submits your creative, and can anyone on the seller's side turn that requirement off for a single drop? A requirement that can be disabled for your order is a preference. Write down who is allowed to disable it.
Does a TLS upgrade put a solo ad in the inbox?
No. An encrypted hop protects that hop. Inbox placement still depends on the list, the domain, and how recipients treat the mail.
Encryption stops a listener on that connection from reading the message in transit. It does not introduce the sender to the recipient. It does not reduce a complaint rate. It does not repair a domain that signs as someone else. A buyer who pays extra because the mail is secure has paid for a property the message should have had anyway, and has not paid for the thing that makes a click.
Use the word precisely when you talk to a seller. Ask if the hop upgraded. Ask if a policy required it. Then ask about the list. STARTTLS is a real extension. It is not a halo.