Define what the remailer is responsible for
An authenticated remailing service receives a message and sends another SMTP transaction onward. That description covers different services: an address forwarder, a discussion list, a security gateway or an application that redistributes mail. “Authenticated” is incomplete unless it names the identity, mechanism and receiving hop. A service can authenticate its own outbound connection without preserving authentication of the original author. The responsibility boundary should therefore follow the message through the route, rather than follow a product label.
Start with a written service contract for the mail flow. Identify who accepts the original message, changes the envelope, modifies signed content, handles delivery failures and supplies evidence to the final receiver. The proposed responsibility map below is a planning aid, not an observation of a deployed service. Each operator should be able to explain its own changes without claiming control over another operator’s filtering decision.
Separate the three identity questions
The connecting IP and SMTP envelope sender matter to SPF. The signing domain and protected message material matter to DKIM. DMARC asks whether a qualifying authenticated identifier aligns with the Author Domain from the message’s From field. A remailer’s successful SPF result for its own envelope domain is not automatically an aligned result for an unrelated original author. These are separate questions even when a user interface displays one reassuring “authenticated” label. RFC 7208, section 2.4 and RFC 9989, section 4.4 define the relevant boundaries.
Envelope rewriting can make the forwarder responsible for a new return path and allow SPF to describe its outbound infrastructure. It does not by itself repair original-author alignment. Likewise, a fresh DKIM signature from the remailer proves something about that signing domain, not necessarily the original author. Record both old and new identities so a later analyst can see which relationship was preserved, replaced or lost.
Own modifications that can break a signature
A service that appends a footer, changes a signed Subject field or re-encodes protected content needs to understand the relevant DKIM signature and canonicalization. Some transformations survive the selected canonicalization; others do not. Do not assume every header change breaks DKIM, or that “relaxed” canonicalization permits arbitrary edits. Preserve an original copy and compare the actual signed headers and body when diagnosing a failure. RFC 6376, sections 3.4 and 5.4 supply the mechanism, not a promise about a particular remailer.
Google’s forwarding guidance recommends protecting DKIM-covered content and states that Gmail evaluates forwarded messages itself. That is Gmail-specific operational advice, not a universal acceptance agreement. A remailer remains responsible for the changes it makes, including an intentional From rewrite used by some list designs. Such a rewrite changes the identity presented to recipients and needs an explicit product decision about replies and attribution. Google forwarding guidance.
Treat ARC as evidence with a trust boundary
ARC can carry an intermediary’s authentication assessment and a verifiable chain of handling. Its validation does not certify benign content or establish that every sealing domain is trustworthy. The final receiver must decide how, if at all, to use that information. Preserve the chain, the sealing domains, the receiver’s evaluation and the local disposition separately. An ARC pass is not a substitute entry for an aligned DKIM pass. RFC 8617, sections 7 and 9.
The standards status also needs a date. On 8 November 2026, RFC 8617 remains Experimental. The active draft-ietf-dmarc-arc-to-historic-01 proposes ending the experiment and moving the RFC to Historic; it is a work in progress, not an enacted reclassification. A service assessment should disclose that proposal without presenting either universal ARC deployment or completed retirement as fact. Current draft status.
Follow a fictional message through the boundary
Consider a fictional message from notices@sender.example, routed through an alumni forwarder to a final mailbox. Assume the original stream has an aligned DKIM signature. The forwarder changes the envelope sender to its own domain but leaves the protected message unchanged. The expected question at the final receiver is whether that original signature still validates and aligns. The new envelope’s SPF result answers a different identity question. This example is a reasoning exercise; no message, DNS response or receiver result was collected.
Now suppose the same service adds a body disclaimer. The analyst must compare the signature-covered content before and after that step. A service’s own signature or ARC seal may provide additional evidence, but neither should be silently described as restoration of the original signature. The corrective work belongs first with the actor that introduced the relevant transformation, while the original sender still owns its signing configuration and the receiver owns its acceptance policy.
Accept responsibility without promising delivery
SMTP responsibility transfers when the receiving server gives a positive completion response after message data. That server then owns delivery or the appropriate subsequent failure handling. This transport responsibility differs from a promise of inbox placement or continued authentication at every later hop. A remailer should retain queue identifiers, timestamps and bounded diagnostic records sufficient to explain that transfer. RFC 5321, section 4.2.5.
RFC 9989 explicitly discusses indirect-flow interoperability and warns against treating domain policy as the receiver’s only disposition input. Review list participation and legitimate forwarding when planning sender policy, rather than demanding that a remailer guarantee every receiver’s behavior. RFC 9989, section 7.4.
Evidence still required
Direct and indirect delivery samples with route, envelope, signatures and trusted results compared. This requirement remains open. Collect authorized matched samples, mark trusted receiver-added results, and compare the hop identities and modifications. Documentary standards research and the fictional route do not establish the behavior of an actual remailing service.