A header screenshot is not the solo ad you paid for
Answer Do not accept a screenshot of a from-name as proof the solo ad went out as quoted. RFC 9787, published August 28, 2026, exists because headers on unprotected mail can be changed by a party in the middle. Ordinary marketing mail is usually not covered by that standard. Trust authentication results and your own link, not the picture.
The note that started this: RFC 9787: Header Protection for Cryptographically Protected Email, IETF, August 28, 2026.
Buyers get shown a cropped image. The from-name looks right. The subject looks like the swipe. The time in the corner is fuzzy. That image is a claim about what one mailbox displayed. It is not the log of what the seller's system handed to the network, and it is not a count of who clicked.
The IETF published RFC 9787 on August 28, 2026. The title is Header Protection for Cryptographically Protected Email. It is for mail that is already signed or otherwise cryptographically protected, so the headers a reader sees can be checked against the headers the sender protected. The standard would be unnecessary if headers were frozen the moment a message left. They are not. A gateway, a mailing list, a security appliance, or a meddler can rewrite what an unprotected message displays. A solo ad is almost never cryptographically protected mail in the sense that RFC cares about. The practical lesson is narrower, and it is enough.
Why is a screenshot of the from-name weak proof of a solo ad?
Headers can be rewritten after the mail leaves, so the from-name in a screenshot may not be the from-name the sending system logged.
You can lose the argument in either direction. A honest send can look wrong in one client because a downstream system folded a header. A dishonest send can look perfect in a screenshot taken from a test account the seller controls. The picture cannot answer the question. The records can.
When you buy solo ads, write the from-name and the subject into the quote before you pay. After the send, compare that sentence to the authentication result, not to a crop. If the domain that signed the mail is not the domain you were shown, the send is not the send you bought, even if a screenshot looks friendly.
What is RFC 9787?
RFC 9787, published August 28, 2026, is the standard for protecting headers on cryptographically protected email so a party in the middle cannot change them undetected.
It is not a new bulk-sender rule, and it does not give a solo ad a badge. It is the engineers saying, in the formal way, that the headers people read are a sensitive part of the message and that unprotected headers are exposed. You do not need to implement header protection to buy a solo ad. You need to stop treating the readable header as the whole truth.
Sellers who want to be believed can show the boring trio. SPF says which servers may send for the domain. DKIM says the message was signed by a key the domain published. DMARC says whether those results align with the from-domain. A pass is not a promise of the inbox. A fail is a reason to stop the conversation. The safe solo ads sellers check starts there because the rest of the pitch is theater until the name is real.
What proof should you ask for after a solo ad goes out?
Ask for the sending domain, the SPF, DKIM, and DMARC results, the time the broadcast left, and the click count on a link you control.
Four facts. None of them is a mood. The link you control is the one number the seller cannot draw for you. If their platform says 400 clicks and your link says 30, you have a tracking argument you can have while the refund line is still in reach. If they will only send the screenshot, you have already learned how the next order will be documented.
Keep the quote, the results, and the click log in the same folder as the payment. The header-protection standard is about mail that can prove its headers. Your order should be able to prove itself the same way, with documents, even though the email itself is ordinary mail.