Forwarding adds another sending server to an email's journey. A message that authenticated on arrival at the forwarder can get a different result at the destination. Diagnose that final hop before changing DNS or your mail client.
Three addresses with different jobs
| Address | Job | Example |
|---|---|---|
| SMTP envelope sender | Receives delivery failures; normally appears as Return-Path after delivery | bounce@author.example |
| Message From | Identifies the visible author | Alice <alice@author.example> |
| Reply-To | Directs an ordinary reply when present; otherwise the client normally uses From | help@author.example |
SRS changes the envelope sender. It does not configure the address you select when composing a reply in Apple Mail or another client.
Why forwarding can fail SPF
Suppose alice@author.example sends to an address that forwards to your inbox.
If the forwarding server keeps the original envelope sender, the destination
checks that server's IP against the original sender's SPF policy. The forwarding
server may not be authorized there.
An SPF failure is not automatically a DMARC failure. DMARC can pass through a valid DKIM signature aligned with the visible From domain. Conversely, an SPF pass for a different forwarding domain does not establish alignment with the original author. See the current DMARC specification, RFC 9989.
What SRS changes
A forwarder can replace bounce@author.example with a signed, time-limited
address on a domain it controls, such as:
SRS0=HASH=TIME=author.example=bounce@forwarder.example
SPF can then authenticate the forwarding infrastructure against that domain's policy. If delivery fails, the notification returns to the rewritten envelope address; the forwarder validates and reverses it to route the bounce onward. This is bounce routing, not ordinary human reply routing. The PostSRSd documentation explains the Postfix implementation and configuration requirements.
Read the results at the final inbox
This example shows a forwarded message whose original DKIM signature
survived. author.example and forwarder.example stand in for unrelated domains.
From: Alice <alice@author.example>
Return-Path: <SRS0=HASH=TIME=author.example=bounce@forwarder.example>
Authentication-Results: receiver.example;
spf=pass smtp.mailfrom=forwarder.example;
dkim=pass header.d=author.example;
dmarc=pass header.from=author.example
The aligned original DKIM signature explains the DMARC pass. Now consider a forwarder that changes signed content and adds its own signature:
Authentication-Results: receiver.example;
spf=pass smtp.mailfrom=forwarder.example;
dkim=fail header.d=author.example;
dkim=pass header.d=forwarder.example;
dmarc=fail header.from=author.example
A passing forwarder signature is not an aligned original-author signature.
Adding a footer, changing a signed header, or changing MIME content can affect
DKIM. Inspect which signature passed instead of treating every dkim=pass as
equivalent.
ARC can preserve authentication observations across intermediaries. A receiver decides whether to trust that chain and how to handle the message. Neither ARC nor SRS guarantees acceptance or inbox placement. ARC specification.
Postscale forwarding and Shield replies
Postscale's mail infrastructure uses PostSRSd for envelope rewriting. The inbound forwarding path also supports ARC sealing and DKIM signing where configured. Those mechanisms need correctly deployed keys, DNS and mail-server settings; inspect actual received headers to establish the result for your domain.
For Shield masked aliases, Postscale creates a reply address and sets Reply-To so the recipient can respond through the masked identity. That is a separate application feature, documented in the Shield API. If reply-address creation fails, forwarding may proceed without that replacement Reply-To: inspect it before relying on the alias for privacy.
For ordinary personal-domain forwarding, receiving a message does not set up an outgoing identity in your client. You need an authorized sending service and the correct From address. See SMTP settings.
A useful diagnostic checklist
If your question is which address appears when you press Reply, start with aliases and reply identities. That is separate from troubleshooting a delivery-failure notification.
- Save the final inbox's full headers and the exact SMTP rejection or bounce, if there is one. Remove addresses, tokens and message content before sharing.
- Compare envelope sender, visible From, Reply-To and each DKIM
d=domain. Use the receiving service's trusted Authentication-Results, not an arbitrary header earlier in the message. - Check the SPF policy for the final envelope domain and whether the original aligned DKIM signature survived forwarding.
- Test direct delivery and forwarding from the same controlled sender. Repeat with another destination to distinguish a routing fault from receiver policy.
- Use a controlled nonexistent recipient for a bounce test. Confirm the failure reaches the expected sender; record the observed timing rather than assuming an immediate bounce.
- Test a normal reply separately. Check both the recipient and the visible sending identity. A successful bounce test does not validate replies.
Quota failures and temporary deferrals are different from authentication failures. Check inbound usage and rate limits alongside the SPF, DKIM and DMARC setup guide.