When Mail Changes Hands

This chapter diagnoses what happens when an email leaves the originating sender and passes through a forwarder, role-based address, mailing list, or other intermediary. The focus is the gap between an authorized message at origin and the message a final receiver can evaluate after the path, envelope, headers, or body have changed. By the end, you should be able to distinguish the failure caused by a handoff from the receiver's own policy choice, compare ARC with From rewriting, and understand how rejection timing changes what anyone can learn.

The simplest identity model assumes a direct path: the original sender connects to the final receiver, and the domains and message content remain stable. Real email often does not work that way. A university address can forward to a personal mailbox. A role address can relay mail to whoever currently manages finance or support. A mailing list can distribute one message to many subscribers and add its own material. Each handoff can preserve some evidence and invalidate other evidence.

That is why a report showing a later DMARC failure does not automatically contradict a sender's claim that the message was authorized. The sender may be right about the origin, while the final receiver is right about the message it received. The diagnostic task is to find what crossed the boundary and what state was lost.

Why a Clean Origin Can Become a Difficult Handoff

SPF is especially sensitive to forwarding. It authorizes sending systems for a domain in the SMTP envelope. When a forwarder connects to the next receiver, the connecting IP belongs to the forwarder, not to the original sender's authorized network. Unless the envelope identity is rewritten or another arrangement applies, the final receiver can see an SPF failure even though the first receiver or original path was authorized.

DKIM often behaves differently. Its signature travels with the message and can remain valid when the signed headers and body are not changed. That gives an indirect path a chance to preserve an aligned DKIM identity after the connecting IP has changed. But “often” is important. If an intermediary modifies signed material, the signature may no longer validate. A valid signature from an unrelated intermediary domain also does not satisfy DMARC alignment with the visible From domain. What survives the handoff must still be connected to the Author Domain.

Consider a message from example.com sent through an alumni forwarding service. At origin, the sender uses an aligned DKIM signature and an SPF identity for the organization's domain. The forwarder accepts the message and opens a new SMTP connection to the recipient's mailbox provider. The new connection is not an IP authorized by the original SPF record. SPF can fail at the final hop, while the original aligned DKIM signature remains valid. DMARC may still pass through DKIM. If the sender relied only on SPF, however, the same legitimate message is more exposed to the handoff.

Now consider a mailing list. A list server may add a footer, a subject marker, or other content to the message. If the original DKIM signature covers the changed material, the final verification can fail. The list may also preserve the original From header, causing the message to be evaluated under the original domain's DMARC policy. When that domain publishes p=reject, a receiver that treats the failure as decisive can reject the list copy even though the subscriber's original message was legitimate.

Mailing-list operators have adopted different workarounds. Some rewrite the From header so that the visible address is aligned with the list's domain; others use a per-address form intended to remain reversible or permit replies to return to the original author.