A private header is not a standard
Answer A private header is not a standard. RFC 4021 describes how mail and MIME header field names are registered, so the internet has one place to look up what a shared header means. A name in that registry carries a definition. A name a vendor invented for their own platform carries whatever they say it carries, on their platform. The second kind of name can be useful inside their walls. It is not a standard, and it is not a promise that Gmail or anyone else will honor it.
The note that started this: RFC 4021, Registration of Mail and MIME Header Fields, RFC 4021.
You will see private headers in raw mail all the time. List software adds them. Security tools add them. ESPs add them so their own support staff can trace a message. None of that is a scandal. The scandal starts when a sales page points at a private name and calls it the reason your solo ad will be delivered. If you buy solo ads, ask for the registered facts, the ones a stranger can look up, and treat the private names as internal ink.
Registration does not make a header powerful. It makes a header legible. People can argue about a shared definition because the definition is written down. A private name has no such argument. There is only the vendor's current story, which can change without a document you can cite. When the story changes, your last quote still says the old story. Keep quotes tied to names you can re-check.
What does it mean for a mail header to be registered?
RFC 4021 describes the registry of mail and MIME header field names. A registered name is a shared definition other people can look up. Registration is how a header becomes a standard name, not a private scratch pad.
Look up is the test a buyer can actually do. A registered header has a specification or a registration record that says what the field is for. You do not have to memorize the registry. You have to notice when a seller's magic header has no record at all. Ask them for the document. If the document is a help article on their own site, you are reading their scratch pad. If the document is a published specification, you are reading a standard, and you can then ask whether they implement it or only mention it.
Mentioning is the usual gap. A page can name a famous header, SPF adjacent language, a signature word, a complaint word, and implement none of it on the message you receive. The registry tells you what the name means if it is real. The received message tells you whether the name was used. You want both.
- A header used in a delivery claim has a public definition, or it is labeled private.
- The received test message contains the header the quote named.
- Internal trace headers stay in the support notes.
- The seller does not call a private name a mailbox rule.
Is an unregistered header illegal?
No. Private headers are common, and this note is not a law. An unregistered name is simply not a standard. Do not let a seller treat a private name as a rule other mailbox providers agreed to.
Mail would be worse if every experimental field had to be a federal case. Operators try things. Some of those things later get registered because they proved useful. Some stay private forever because they only matter inside one company. Both outcomes are allowed. What is not allowed, on a serious buying desk, is confusion about which outcome you are looking at. Ask the short question. Is this name yours, or is it everyone's?
A name that starts as an internal experiment can still affect you. If their software copies a private header onto every message, and a signature covers it, and a later tool strips it, you can get a verification failure from a field you never asked for. That is a reason to ask what they add, not a reason to ban private fields in the abstract. Inventory is enough.
How should a buyer read a vendor's custom header?
Read it as that vendor's note. Ask what it means in their system, and ask whether any receiver outside that system is supposed to act on it. If the answer is only we use it internally, keep it out of the delivery claim.
Internal notes can be good operations. A message id their support can find is a kindness when something breaks. Kindness is not delivery. When the quote says our header improves inbox placement, ask which receiver documented that behavior. A receiver's published rule is a thing you can read. A receiver's silence is not an endorsement of a vendor's private field. Silence is silence.
RFC 4021 is the door to the shared list of names. Use the door when a name is supposed to be shared. When the name is private, call it private. Standards are agreements. A note in the margin is not an agreement with the rest of the world.