Skip to main content
Forwarding relays a message from the mailbox it was addressed to into a second mailbox, through an alias, an auto-forward rule, or a mailing list. A message that passed SPF, DKIM, and DMARC at the first mailbox can fail authentication or go to spam at the second, with nothing changed on the sender’s side. This guide explains what forwarding does to each protocol, what SRS and ARC are for, and what a sender can do about it. This page builds on Understanding SPF, DKIM, and DMARC. Read that first if the terms below are new.

​
Why Forwarding Breaks SPF

SPF checks the connecting IP address against the list of servers published for the domain in the envelope sender (the Return-Path). Forwarding changes the connecting IP and, usually, nothing else. SPF passes at the first hop because the connecting IP is a Lettr sending IP, which your SPF data lists. After forwarding, the connecting IP belongs to the forwarder while the Return-Path is still your original one, so the final receiver finds no match in your SPF data and SPF fails. Neither the forwarder nor your SPF record is misconfigured. SPF has no way to express “this server is relaying mail that someone else authorized”. The SPF specification discusses this under mediators (RFC 7208, section 10.3).
This is why DMARC accepts either an aligned SPF pass or an aligned DKIM pass. Forwarding is the main reason the “or” matters.

​
SRS: Fixing SPF at the Forwarder

The Sender Rewriting Scheme (SRS) is a fix that the forwarding server applies. It rewrites the envelope sender to an address on the forwarder’s own domain before relaying the message, for example:
The receiving server now evaluates SPF against forwarder.example, whose SPF record does authorize the forwarder’s IP, so SPF passes. The rewritten address also encodes the original sender, so bounces can still be routed back through the forwarder to the real sender. What SRS does and does not do:
  • SPF passes, but only for the forwarder’s domain. That domain is not your From domain, so SPF alignment still fails and SPF cannot help DMARC.
  • SRS has to be implemented by the forwarder. A sender cannot enable it.
  • Many large providers rewrite for their own forwarding features, but behavior varies by service, and small or self-hosted forwarders often do not.
SRS is not an IETF standard. The SPF specification only says that mediators can rewrite the envelope sender into their own domain, and that schemes for doing so vary (RFC 7208, appendix D.2).

​
DKIM: Survives Forwarding, With Conditions

A DKIM signature travels inside the message headers and covers the body plus a chosen set of headers. A pure forwarder does not touch either, so the signature still validates at the final destination, and it still names your domain in the d= tag. DKIM breaks only when something modifies signed content. Common causes: Two details from the DKIM specification (RFC 6376) are worth knowing:
  • Canonicalization (c=relaxed/relaxed in the signature) tolerates harmless whitespace and header-folding changes made in transit. It does not tolerate content changes.
  • The optional l= tag limits the signature to the first N bytes of the body, so a footer could be appended without breaking it. The RFC warns that this opens the door to abuse, and many receivers treat such signatures with suspicion. Do not rely on it.
Mailing lists are the classic case: they edit the Subject and body, so the original DKIM signature fails, and many lists also send from their own IP, so SPF fails too. That combination is what ARC was designed to handle.

​
ARC: Preserving Authentication Results Across Hops

The Authenticated Received Chain (RFC 8617) lets each intermediary record what authentication looked like when the message arrived at it, and sign that record. The final receiver can then see that the message passed SPF, DKIM, and DMARC at the first hop, even though those checks now fail. Each ARC-aware hop adds a set of three headers, all with the same instance number (i=1, i=2, and so on, up to 50): A trimmed example from a mailing list hop:

​
How Receivers Use ARC

ARC does not override DMARC by itself. The RFC leaves the decision to the final receiver, and that is deliberate:
  1. The receiver validates the chain: every seal and message signature must verify, and the instance numbers must be continuous.
  2. If the chain is valid, the receiver looks at who sealed it. A receiver only trusts the recorded results from intermediaries it already considers reputable.
  3. If the receiver trusts the sealer, it may deliver a message that failed DMARC after the hop, using the recorded passing results as evidence.
Because trust is local, ARC helps with legitimate forwarding and mailing lists but gives no guarantee. A forwarder with no reputation, or a broken chain (cv=fail), earns nothing. Microsoft documents this model in Configure trusted ARC sealers, where an admin lists the intermediaries whose ARC results Microsoft 365 should honor.
ARC is implemented by the intermediaries. Signing your mail with ARC is not part of sending through Lettr, and there is no ARC record to publish in your DNS. The best a sender can do is make its own authentication strong enough not to need ARC.

​
What This Means for Mail You Send With Lettr

Lettr signs every message with DKIM on your domain. The signing domain is the sending domain you verified, and the public key lives at selector._domainkey.yourdomain.com as the TXT record shown in the domain’s TXT Record (DKIM) card. Its value has the form v=DKIM1;k=rsa;h=sha256;p=.... See Sending Domains and DKIM for the setup. That is exactly the combination that survives forwarding:
  • The d= value is your sending domain, so the signature aligns with the From domain under DMARC.
  • A simple forwarder leaves the signed content alone, so the signature still verifies at the final inbox.
  • DMARC needs only one aligned pass, so the broken SPF from forwarding does not cause a DMARC failure.

​
Subdomain and Root Domain Setups

When the From address is on the same domain verified in Lettr, alignment is exact and works under both strict and relaxed DMARC alignment. When a subdomain is verified but mail is sent From the parent domain (or the reverse), the signature aligns only under relaxed alignment, which is the DMARC default. The tag adkim=s in a DMARC record turns on strict alignment and would break that case. See Subdomain vs Root Domain for how this affects your choice. The default Return-Path on Lettr mail is a shared bounce domain, so SPF would not align with your From domain even before forwarding. A custom bounce domain moves SPF alignment to your own domain. Either way, forwarding breaks SPF alignment for everyone, so DKIM is the protection that matters here.

​
Recommendations

  1. Verify your DKIM record and keep it in a valid state. Mail signed with a broken key has no fallback after forwarding.
  2. Keep message content stable. Do not have a downstream gateway or tool rewrite links or bodies after Lettr signs the message. Lettr signs at send time, so changes made later by your own systems are not covered.
  3. Move DMARC to enforcement gradually. With p=quarantine or p=reject, forwarded mail whose DKIM is also broken (for example, through a mailing list) can be quarantined or rejected. Watch your aggregate reports at each phase, as described in the DMARC progression.
  4. Do not use l= or loosen your signing to work around lists. It weakens your own security and receivers may discount it.

​
Diagnosing a Forwarding Failure

Ask the recipient for the full headers of the forwarded copy and look at the Authentication-Results header (see Email Headers). When DKIM fails on a mailing list copy, the usual fix is on the list side (ARC, or rewriting the From address to the list’s own domain). Mailing list software commonly does the latter for domains with strict DMARC policies. If you run the list, consult its documentation. A subscriber can do little except accept that the list copy may be filtered.

Understanding SPF, DKIM, and DMARC

How the three protocols work together and what alignment means.

Custom Return-Path

Align SPF with your own domain using a custom bounce domain.

Sending Domains

Add and verify a sending domain in Lettr.

Email Headers

Read Authentication-Results and ARC headers on a received message.