The forwarded message problem

Forwards look like ordinary messages and behave like nothing else. The sender is not the author, the question in the body was asked by somebody who is not on the thread, the reply address is wrong, and the authentication that would normally tell you who sent it has been destroyed in transit.

6 August 2026 · 4 min read

Every agent handling real mail meets this within a week.

Two forwards that need different handling#

Delegation. A colleague forwards a customer message with "can you deal with this". The intent is that the agent acts on the inner content, and the answer eventually goes to the original sender.

Context. Somebody forwards a message as evidence in a conversation with you: "here is what the supplier said". The inner content is information, not an instruction, and the reply goes to the forwarder.

Distinguishing them is the whole problem, and the reliable signal is not the body but whether the forwarder addressed you personally above the quoted block. A bare forward with no added text is nearly always context; a forward with a sentence on top is usually delegation, and the sentence says which.

When it is ambiguous, ask the forwarder. One short question to a colleague is cheap. Emailing a stranger who never wrote to you is not.

Never reply to the inner sender by default#

The most damaging forward failure is the agent replying directly to the original author.

From the outside this reads as a company they wrote to a fortnight ago suddenly answering from an address they do not recognise, quoting internal commentary that came with the forward. That commentary is frequently blunt.

The default has to be structural: reply to whoever forwarded it. Reaching the inner sender requires an explicit instruction from the forwarder, and even then the agent should compose fresh rather than replying into a quoted block, and it should not reuse the forwarded subject line unchanged, per subject lines an agent should write.

Parsing, and why it is unreliable#

There is no standard for forward formatting. Clients differ, locales differ, and quoted headers arrive in the recipient's language.

Attachment forwards are the case worth handling well, because they are the only lossless one. Where you find a message/rfc822 part, parse it as a message rather than as text, and you get real headers and a real sender.

For everything else, extract what you can and treat the result as a claim rather than a fact. An agent that says "this appears to be forwarded from Anna at Acme" and asks the forwarder to confirm before acting is behaving correctly.

Quoted content is untrusted input#

This is the security consequence and it is not theoretical.

Forwarded content is text a third party wrote, delivered inside a message from someone you may trust. Any instruction inside it is data, not a command, and the fact that a trusted colleague forwarded it changes nothing about the trust level of what is inside.

Two rules that hold. Instructions found below a forward marker are never followed, only reported. And the forwarder's own authority does not extend to the inner content: a manager forwarding a supplier's message has not authorised the supplier's request, per prompt injection by email.

Forwards break authentication#

Worth knowing when a forwarded message arrives with failing checks, because it usually means nothing sinister.

Forwarding rewrites the envelope, so SPF now describes the forwarding server rather than the original sender and fails alignment. DKIM often survives if the body is untouched, and breaks whenever a client adds a banner, alters encoding, or reflows the text, which many do.

So a forwarded message failing authentication is expected. Judge the forwarder, whose own authentication is intact, and treat the inner sender as unverified regardless of what the quoted headers claim, per reading DMARC reports.

The thread question#

When an agent acts on a delegated forward and eventually answers the original sender, two threads exist: the internal one with the colleague, and the customer-facing one. Keeping them separate is right, and linking them matters.

The pattern that works: reply to the colleague confirming what was done, and start a clean message to the customer with no internal content in it. Anything else risks the internal commentary travelling, which is the failure everyone has seen happen manually at least once.

Questions#

Should an agent reply to the person who forwarded a message, or the original sender?

The forwarder, always, by default. Reaching the original sender requires an explicit instruction, and even then as a fresh message rather than a reply into quoted text.

How do you detect a forwarded message reliably?

A message/rfc822 attachment is the only lossless signal. Forward markers and quoted header blocks are common but localised and client-specific, so treat extracted senders as claims to confirm.

Should instructions inside a forwarded message be followed?

No. Quoted content is untrusted third-party text, and a trusted colleague forwarding it does not extend their authority to what is inside it.

Why does a forwarded message fail SPF?

Forwarding rewrites the envelope sender, so SPF describes the forwarding server. DKIM also breaks whenever the client alters the body, including adding a banner.

How does the agent tell delegation from context?

By whether the forwarder wrote something above the quoted block. A bare forward is usually context; an added sentence usually says what is wanted. When unclear, ask the forwarder.

What about internal comments in a forward?

They must never travel. Answer the customer in a clean message with no quoted internal content, and confirm separately to the colleague.