X-Header

Q: Is the “X-” prefix still an official standard?

Not formally, no. The X- prefix comes from an old RFC convention (RFC 822 and its successors) that marked a header as experimental or non-standard, a signal to other systems that they were free to ignore it. That guidance was later deprecated by RFC 6648, which recommends against minting new X- headers for anything meant to become a permanent standard. In practice the convention never went away. Mail systems still use the X- prefix constantly, mostly out of habit and because it is instantly recognizable as “custom, safe to ignore” to any server or client reading the header dump.

Q: What’s the most useful X-header to check when troubleshooting deliverability?

X-Spam-Status and X-Spam-Score, if the receiving system adds them, are usually the fastest read. They tell you not just that a message was flagged, but roughly how close it came to the threshold, which is far more actionable than a bounce alone. Beyond spam scoring, the full header dump also shows routing hops and which filter or system handled the message. That said, headers only tell you what happened to a message that was accepted for delivery. They say nothing about whether the address it was sent to was even real, which is a separate check entirely.

Q: Do X-headers affect spam scoring?

The X-headers a spam filter adds after scoring, like X-Spam-Score, are a record of a decision already made, not an input to it. Adding your own custom X-header to outgoing mail does not itself move a spam score up or down. What does move the needle is the stuff X-headers can’t fix: SPF, DKIM, and DMARC alignment, sender reputation, and list hygiene. A clean set of X-headers on an otherwise unauthenticated, poorly targeted send won’t rescue it.

Q: What’s the difference between X-Spam-Score and X-Spam-Status?

X-Spam-Score is a raw numeric value: the higher it is, the more spam signals the filter matched. X-Spam-Status is the interpreted result, typically a line reading something like Yes or No alongside the score and the threshold the filter used to make that call. Reading both together tells you not just the verdict but how close the message came to the line, which matters when you’re trying to figure out whether a delivery problem is a hard block or a borderline case worth fixing quickly.

Q: What is X-Originating-IP and why does it matter?

X-Originating-IP is a header some webmail and mail relay systems add to record the IP address a message was actually sent from, distinct from the IP of the outbound mail server that ultimately delivered it. It is most often added when mail is sent through a web interface or shared relay. It matters for abuse investigations and tracing spoofed or compromised-account mail back to a source, but not every provider adds it, and some strip it deliberately for sender privacy, so treat its absence as normal rather than suspicious.

A custom header field a mail system adds for its own tracking.

Receiving servers ignore headers they don’t recognize, making it safe.

SMTP SMTP Response Codes MX Record DKIM Feedback Loop NDR

Definition

An X-header is a custom, non-standard header field, conventionally prefixed with X-, that a mail system adds to a message for internal tracking, routing, or diagnostics without touching standard headers like From or Subject. Receiving servers ignore headers they don’t recognize, so any system can add one safely.

We spend a lot of time reading full header dumps to figure out why a message landed where it did, and the X-headers in that dump are usually where the real story is. The standard headers — From, To, Subject — tell you almost nothing about how a message was actually handled in transit. The X-headers are where mail systems leave their own notes.

What an X-header is

An X-header is a custom header field that any mail system — sending, relaying, or filtering — can attach to a message without coordinating with anyone else. The name comes from an old RFC convention: prefixing a header with X- marked it as experimental or non-standard, a plain signal that it wasn’t part of the formal email spec and existed purely for that system’s own purposes.

That convention has since been formally deprecated (RFC 6648 recommends against minting new X- headers for anything meant to last), but it never actually went away in practice. It survives because it works: the prefix is instantly recognizable, both to humans reading a header dump and to software parsing one, as “custom, safe to ignore if you don’t know what to do with it.” An X-header sits alongside the standard headers in the same block at the top of a message, it just never touches the ones that define the message itself, like who it’s from or what it’s about.

Common X-headers you’ll actually see

A handful of X-headers show up often enough to be worth knowing by name:

X-Mailer. Identifies the software that generated the message — a mail client, a transactional email service, a script using a particular library. Useful for spotting whether a message came from a legitimate sending platform or something unusual.
X-Spam-Score. A raw numeric value a spam filter assigns: the higher the number, the more spam signals the filter matched. It is a diagnostic, not a cause: nothing about adding this header changes the score itself.
X-Spam-Status. The interpreted verdict that usually rides alongside the score, typically something like Yes or No plus the threshold the filter used to decide.
X-Originating-IP. Sometimes added by webmail or relay systems to record the actual IP address a message was sent from, distinct from the outbound server that ultimately delivered it. Handy for tracing abuse or a compromised account back to a source.

None of these are guaranteed to appear on any given message. Whether a system adds them, and what it names them, is entirely up to that system.

Why they’re safe to add and ignore

The entire value of the X- convention is that it lets any system add metadata to a message without asking permission and without breaking anything else that reads that message. A receiving server, mail client, or intermediate relay that doesn’t recognize a given header simply skips over it. The message still parses correctly, and the standard headers it actually needs are untouched.

That is also why you can add your own. Tagging outgoing mail with an internal ticket ID, a campaign identifier, or a build name for debugging costs nothing and can’t break delivery, since any system that doesn’t care about your custom header will simply pass over it. The only caveat is that some intermediate servers strip unrecognized headers before forwarding a message, so an X-header surviving to the final recipient isn’t guaranteed on every hop.

Why they matter for deliverability troubleshooting

When a message lands somewhere unexpected, the junk folder instead of the inbox, or nowhere at all, the full header dump is usually the fastest way to see what actually happened. The standard headers won’t tell you that. The X-headers a spam filter or relay added along the way often will, directly recording the score, the verdict, and sometimes which rule triggered it.

That said, header inspection is one layer of diagnosis, not the whole picture. Reading X-Spam-Score and X-Spam-Status tells you how a message that was accepted got scored. It tells you nothing about whether the address it was sent to exists at all. A bad address never gets far enough to generate an interesting header dump in the first place, it just bounces. Confirming the underlying address with real verification is a separate, earlier check, and pairing the two — verify the address, then read the headers if something still goes wrong — covers far more of a deliverability problem than either does alone. You can run that check for free with the free email checker.

Explore more from Verifox

The X-header sits inside a wider set of deliverability concepts. These are the terms most worth understanding next.

Common questions

X-headers, answered

X-headers are the metadata riding along with every email, mostly invisible unless you go looking. Here’s what’s actually in them, and why they matter.

Is the “X-” prefix still an official standard?

Not formally, no. The X- prefix comes from an old RFC convention (RFC 822 and its successors) that marked a header as experimental or non-standard, a signal to other systems that they were free to ignore it. That guidance was later deprecated by RFC 6648, which recommends against minting new X- headers for anything meant to become a permanent standard.

In practice the convention never went away. Mail systems still use the X- prefix constantly, mostly out of habit and because it is instantly recognizable as “custom, safe to ignore” to any server or client reading the header dump.

What’s the most useful X-header to check when troubleshooting deliverability?

X-Spam-Status and X-Spam-Score, if the receiving system adds them, are usually the fastest read. They tell you not just that a message was flagged, but roughly how close it came to the threshold, which is far more actionable than a bounce alone.

Beyond spam scoring, the full header dump also shows routing hops and which filter or system handled the message. That said, headers only tell you what happened to a message that was accepted for delivery. They say nothing about whether the address it was sent to was even real, which is a separate check entirely.

Can I add my own custom X-headers?

Yes. Any mail system, script, or application sending mail can attach an X- header of its own — there is no registration or permission needed — which is the entire point of the convention. Common uses are tagging a message with an internal ticket ID, a campaign identifier, or a build or environment name for debugging.

Just pick a name unlikely to collide with one a receiving system already uses for something else, and don’t rely on it surviving every hop: some intermediate servers or filters strip unrecognized headers before forwarding a message.

Do X-headers affect spam scoring?

The X-headers a spam filter adds after scoring, like X-Spam-Score, are a record of a decision already made, not an input to it. Adding your own custom X-header to outgoing mail does not itself move a spam score up or down.

What does move the needle is the stuff X-headers can’t fix: SPF, DKIM, and DMARC alignment, sender reputation, and list hygiene. A clean set of X-headers on an otherwise unauthenticated, poorly targeted send won’t rescue it.

What’s the difference between X-Spam-Score and X-Spam-Status?

X-Spam-Score is a raw numeric value: the higher it is, the more spam signals the filter matched. X-Spam-Status is the interpreted result, typically a line reading something like Yes or No alongside the score and the threshold the filter used to make that call.

Reading both together tells you not just the verdict but how close the message came to the line, which matters when you’re trying to figure out whether a delivery problem is a hard block or a borderline case worth fixing quickly.

Are X-headers visible to email recipients?

Not by default. Most email clients show only a handful of headers, From, To, Subject, Date, and hide the rest. X-headers are still physically part of the message and travel with it, but a recipient has to deliberately open the full source or raw header view to see them.

That is exactly why they are useful for internal metadata: they ride along with the message for systems and diagnostics to read, without cluttering what an actual recipient sees.

What is X-Originating-IP and why does it matter?

X-Originating-IP is a header some webmail and mail relay systems add to record the IP address a message was actually sent from, distinct from the IP of the outbound mail server that ultimately delivered it. It is most often added when mail is sent through a web interface or shared relay.

It matters for abuse investigations and tracing spoofed or compromised-account mail back to a source, but not every provider adds it, and some strip it deliberately for sender privacy, so treat its absence as normal rather than suspicious.