SMTP AUTH is not the signature on the message

Answer SMTP AUTH authenticates the client that submits the mail. RFC 4954 defines that extension. It is not the DKIM signature on the message. A solo ad can be logged in and still be the wrong mail, and it can be signed by a platform that signs whatever the logged-in account was willing to submit. Ask who holds the password.

The note that started this: RFC 4954, SMTP Service Extension for Authentication, RFC 4954.

Sellers like the word authenticated because it sounds like identity. There are two identities in this story, and they answer to different systems. The first is the account that is allowed to hand a message to the server. The second is the domain that signs the message so a receiver can check it. Safe solo ads sellers can name both. A pitch that names only one is half a sentence.

RFC 4954 is the authentication extension for SMTP. The client proves to the submission server that it is allowed to submit. The proof is a login, a password, or some other mechanism the server accepts. That conversation ends at the server that accepted the client. The message that leaves can then be signed, or not, by a different mechanism that receivers know how to check. Mixing the two is how a screenshot of a green checkmark gets treated as proof that the right human pressed send.

What does SMTP AUTH prove on a solo ad?

It proves that a client authenticated to the submission server, under RFC 4954. It does not prove that a DKIM signature on the message is valid, and it does not prove the reader wanted the mail.

Think of a front door and a letterhead. The front door asks for a key. The letterhead is what the reader sees on the page. A person with the key can put any letterhead the stationery drawer allows onto the page. The key does not read the letter. The letterhead does not check the key. On a solo ad, the platform is the door and the signing domain is the letterhead. You want both to belong to the seller you think you hired.

A failed login is easy to understand. The message does not go. A successful login is the dangerous case, because it feels like safety. Safety was only the door. The creative, the list segment, and the links inside the creative are still whatever the account was told to send. Authentication did not review the offer.

• The platform account is named in the order.
• The signing domain is a separate line in the order.
• A login is not described as a DKIM result.
• A DKIM pass is not described as proof of who typed the password.

Can a platform sign mail that a stolen login submitted?

Yes. If the platform signs whatever an authenticated account submits, a stolen or shared password can produce a message with a valid signature. The signature then identifies the domain, not the thief.

This is the failure mode that matters on a rented send. The buyer is often given a login, or the buyer's copy is pasted in by a freelancer, or the password lives in a spreadsheet called passwords-final. Any of those people can submit. The platform, doing its job, signs the message with the domain key. Receivers see a valid signature. The list sees an offer the owner did not approve. The complaint sticks to the domain, which is the asset, not to the spreadsheet.

Shared logins are the ordinary version of the same bug. You do not need a thief. You need two people who both believe they are allowed to hit send on the day your solo is scheduled. One of them will be early. The creative that leaves will be whichever draft was open.

What should you ask about the sending login?

Ask who holds the password, ask whether it is shared, and ask what the seller does when a person who should not have the login sends a drop.

You want a name, a yes or a no on sharing, and a habit. The habit can be a second person who approves the send, or a log that shows which account submitted your creative. A seller who says the password is with the team has told you the team is the account. Pay that seller only if you are willing to treat the team as the sender of record.

Keep the two proofs apart in the quote. Login is RFC 4954's question. Signature is a later question. Neither one is the reader's permission. On a solo ad, you still need all three, and you need them named as three.