A clever encoded subject is still the subject you sent
Answer Do not encode a solo ad subject line to hide a claim. RFC 2047, from November 1996, is how a client displays non-ASCII text in a header. A capable inbox decodes it. A less capable one shows the raw token. Either way you own the line, and a disguise is still a disguise after it is decoded.
The note that started this: RFC 2047: MIME Part Three, Message Header Extensions for Non-ASCII Text, IETF, November 1996.
Every few years someone rediscovers the machinery. The subject looks clean in their own mail app and looks like a pile of question marks, equal signs, and charset tags everywhere else. Or they stuff the line with look-alike letters and invisible characters and call it a deliverability tactic. It is not a tactic. It is a broken label, and filters have spent years learning to read through it.
RFC 2047 is old on purpose. The note that started this is not a September announcement. It is the rule for how a header may carry text outside plain ASCII. An encoded-word names a charset, names an encoding, and then carries the text. Quoted-printable and base64 are the two encodings the standard describes. A mail client that implements the standard turns that token back into the characters the sender meant. A client that does not implement it shows the token. The reader sees the costume's zipper.
What is an encoded-word subject line?
RFC 2047 defines a way to put non-ASCII text in a header, using a charset and either quoted-printable or base64, so a capable client can decode it for display.
That is a courtesy for languages and symbols that ASCII cannot hold. A subject in another language, written by a person who means that language, is a normal use. A subject that is English in the seller's screenshot and a puzzle in the buyer's test account is a broken use. You do not get extra inbox placement by making the line illegible to a third of the file.
The same standard is why a copied swipe sometimes arrives already ruined. Someone exported a header, pasted the encoded form into a broadcast tool that encoded it again, and produced a line no one can read. If your test send shows the raw token, you are not looking at a clever hack. You are looking at a subject that failed its only job, which is to be read.
Should you encode a subject to slip past a filter?
No. Encoding is for characters the reader should see. A line that is a trick in clear text is still a trick when a client decodes it, and a client that does not decode it shows the raw token.
Filters are not stuck in 1996. Hiding a word inside an encoding, or swapping in characters that look like letters, is a known costume. The September 30 note on this desk already pointed at work aimed at look-alike and invisible characters. You do not need that citation repeated as a number. You need the refusal. Say the thing in characters a person can read in the mail app they actually use.
If you sell the send, reject a buyer swipe that arrives as a token or as a line full of odd substitutions. Ask for the plain sentence. If you are the buyer, send the plain sentence. Safe solo ads sellers will mail a line they can read aloud. They will not mail a puzzle and call it optimization.
How do you check a solo ad subject before you pay?
Read it in more than one mailbox, next to the body, and reject any version that depends on hidden characters or a client-specific decode.
One test account is a coin flip. Look at the same message somewhere else, at least in a second client, before you approve the creative. If the two displays differ, the line is not ready. If either display fails to match the first screen of the page, the line is not honest. Encoding will not repair either problem.
Then buy solo ads with the plain line written into the quote. The 1996 standard did its job when it let a true sentence travel. It was never a mask. Do not ask it to become one on a list you are paying to reach.