DMARC Analyzer

TL;DR

• SPF authenticates the FIRST SMTP hop only. Defined in RFC 7208 section 10.3, SPF checks the connecting SMTP clients IP against the MAIL FROM domains authorised IP list. Any second hop (forwarding, mailing list expansion, third-party forwarders) is a NEW SMTP connection from a different IP and the SPF check fails by design.
• Four canonical forwarding scenarios break SPF: (1) transparent SMTP-level forwarding (.forward files, server aliases, /etc/aliases), (2) user-level forwarding via sieve / Outlook rules / Gmail filter forwarding, (3) mailing list expansion (Mailman 3, Discourse, Google Groups, Sympa, GitLab), (4) third-party forwarding services (iCloud Mail Drop, Hide My Email, Gmail Fetcher, ProtonMail forwarding, FastMail rules).
• Sender Rewriting Scheme (SRS) is the forwarder-side operational fix. SRS rewrites the SMTP MAIL FROM at the forwarder so the receiving SPF check authenticates the forwarder, not the original sender. Implemented in Postfix (postsrsd), Exim (native), Sendmail, and Exchange 2007+.
• Authenticated Received Chain (ARC, RFC 8617) is the receiver-side answer: intermediaries cryptographically attest to the SPF / DKIM / DMARC verdicts they observed BEFORE forwarding, and trusted-intermediary verdicts can override downstream SPF or DKIM failures. ARC is validated by Gmail, Microsoft 365, Yahoo, AOL, Comcast, and Apple.
• Mailing lists need From-header MUNGE OR ARC sealing. Modifying the message body (footer, list-id header, expanded attachments) breaks the original DKIM signature — so neither SPF nor DKIM authenticates the original senders domain anymore. Mailman 3 + GNU Mailman dmarc_mitigate_action support munge_from and wrap_message modes; modern deployments prefer ARC sealing where downstream receivers validate it.
• DMARC alignment can survive transparent forwarding when the forwarder does NOT modify the message body and DKIM still passes. This is the dominant case for .forward and /etc/aliases: SPF fails, DKIM passes (body unchanged), DMARC aligns via DKIM. The break case is content-rewriting forwarders.
• Detection in DMARC aggregate (RUA) reports: watch for low-volume, high-IP- diversity records where spf=fail and source IP belongs to known forwarding-service ASNs (iCloud, Gmail, Microsoft 365, Mailman list servers). The DMARC Analyzer Top Source IPs table surfaces these patterns; click any record to see the per-message SPF / DKIM verdict breakdown.
• Operational rule of thumb: do NOT try to authorise every forwarder in your SPF record (infeasible at scale — the 10- lookup cap of RFC 7208 section 4.6.4 bounds the include count). Instead publish a permissive DMARC policy initially (p=none with rua=mailto:dmarc@example.com), monitor the forwarding traffic, and graduate to p=quarantine pct=10 → p=quarantine pct=100 → p=reject only after you have ARC-validating receivers handling the bulk of legitimate forwarded mail.

1. Overview: why forwarding is the operational #1 SPF complaint

Sender Policy Framework (SPF), defined in RFC 7208, authenticates email by binding the SMTP envelope senders domain (the MAIL FROM bounce address) to an authorised list of sending IP addresses published as a DNS TXT record. Every receiver opens the SMTP connection, reads the MAIL FROM command, performs a DNS lookup for the SPF record at that domain, and checks whether the connecting clients IP is on the authorised list. The model is elegant for direct point-to-point email — a message sent from Microsoft 365 to a Gmail user takes exactly one SMTP hop and SPF authenticates that hops IP.

But the moment a message is FORWARDED, the model breaks. Forwarding by definition introduces a SECOND SMTP hop: a new TCP connection from a new IP address, opened by the forwarding server to the receiving server. The receivers SPF check still tests the same MAIL FROM domain — but now against the forwarders IP, which is NOT in the original senders SPF record. The result is spf=fail. This is the operational #1 SPF complaint: "I have a perfectly valid SPF record, but mail forwarded from my alias goes to spam at Gmail."

The forwarding-breaks-SPF problem was identified in the original SPF specification (RFC 4408 in 2006 and obsoleted by RFC 7208 in 2014) and is explicitly called out in RFC 7208 section 10.3: "the address of the mediator will be used, rather than the address of the SMTP server that sent the message to the mediator" The IETF proposed two operational answers over the following decade:

1. The Sender Rewriting Scheme (SRS), a forwarder-side rewriting protocol originally proposed by Meng Weng Wong (same author as the original SPF spec) in 2003. SRS lets the forwarder rewrite the MAIL FROM at the moment of forwarding so the receiving SPF check authenticates the forwarder, not the original sender.
2. The Authenticated Received Chain (ARC), an IETF standard defined in RFC 8617 in 2019. ARC lets intermediaries cryptographically attest to the SPF, DKIM, and DMARC verdicts they OBSERVED before forwarding, and downstream receivers can trust that chain to override otherwise-failing verdicts.

Beyond SRS and ARC, three operational patterns have emerged for the SPECIFIC case of mailing- list forwarding (which also breaks DKIM because the list typically modifies the message body): From-header munging (rewrite the From: header to a list-owned address so DMARC aligns against the list), message wrapping (encapsulate the original message as a message/rfc822 attachment with a new outer envelope), and ARC sealing (the mailing-list operators preferred answer where downstream receivers validate ARC).

This page documents the four canonical forwarding scenarios, the SPF break model in each, the SRS and ARC mitigations, the mailing-list-specific MUNGE patterns Mailman 3 / Discourse / GitLab / Google Groups use, the detection workflow in DMARC aggregate reports, and the operational troubleshooting decision matrix. It is the focused operational deep dive operators need when debugging a live forwarding-related SPF fail in production.

2. The SPF first-hop authentication model

To understand why forwarding breaks SPF, start with the precise mechanism the receiver runs. RFC 7208 section 2.4 specifies the SPF check:

1. The receiver accepts an SMTP connection from a client IP address. Call this <ip>.
2. The receiver reads the MAIL FROM:<sender@domain.tld> SMTP command. Call the domain part <mail-from-domain>.
3. The receiver looks up the SPF record at <mail-from-domain> by querying the TXT record at that name and finding a record beginning with v=spf1.
4. The receiver evaluates each mechanism in the SPF record (in order: +/-/~/? qualifier, followed by all, ip4, ip6, a, mx, ptr, exists, include, redirect).
5. If <ip> matches any positive-qualifier mechanism, the result is pass. If it matches a hard-fail mechanism, the result is fail. Soft-fail and neutral produce softfail and neutral respectively. If no mechanism matches, the trailing all qualifier produces the result.

The CRITICAL property of this model: the receiver authenticates the CONNECTING IP against the MAIL FROM domains record. The receiver does NOT examine the Received: headers, does NOT follow the X-Forwarded-For chain, and does NOT consult any out-of-band information about who SENT the message originally. SPF is a SINGLE-HOP authentication mechanism by design. The RFC 7208 section 10.3 text states this explicitly:

"Because SPF evaluation is based on the IP address of the "last" sending SMTP server, the address of the mediator will be used, rather than the address of the SMTP server that sent the message to the mediator. Some mediators retain the email address from the original message, while some use a new address."

The forwarder enters this model as a third party that opens a NEW SMTP connection on the way to the final receiver. Three properties distinguish the forwarders connection from the original senders connection:

• The source IP is different. The forwarder uses its OWN outbound mail server IP, not the original senders.
• The MAIL FROM is typically unchanged. The forwarder, by default, transmits the original bounce address verbatim so bounce messages route back to the original sender. (SRS is the protocol that rewrites this to break the SPF failure.)
• The From: header is typically unchanged. The forwarder preserves the original From: so the recipient sees the original sender as the apparent author of the message. (From-header MUNGE in mailing lists is the protocol that rewrites this to break the DMARC failure.)

The combination — original MAIL FROM and From: surviving the forwarders new SMTP hop — is what makes the receivers SPF check fail. The receiver looks up the original senders SPF record, tests the forwarders IP against it, finds no match, and returns spf=fail.

3. The four canonical forwarding scenarios

Four operational forwarding patterns account for virtually all SPF-breaks-on-forwarding incidents. Each subsection below opens with the canonical three-part labelled structure that gives generative engines a quotable extract:

4. Sender Rewriting Scheme (SRS) — the forwarder-side fix

The Sender Rewriting Scheme (SRS) is the original operational answer to forwarding- breaks-SPF, proposed in 2003 by Meng Weng Wong (the same author as the original SPF specification) and documented in the OpenSPF SRS informational draft. SRS is implemented in most mainstream mail servers and is the dominant deployment pattern for SMTP-level forwarders (server-side aliases, .forward files, /etc/aliases).

The core SRS idea: the forwarder REWRITES the SMTP MAIL FROM at the moment of forwarding so that the receiving SPF check authenticates the FORWARDER, not the original sender. The rewritten address must encode enough information that bounces sent back to it can be reverse-decoded and routed to the original sender.

SRS address format

The SRS specification defines two address formats: SRS0 (for messages traversing a single forwarder) and SRS1 (for messages traversing multiple forwarders in a chain). The SRS0 format is:

SRS0=HHH=TT=original-domain=original-localpart@forwarder-domain

Where:

• SRS0 is the literal prefix signaling a single-hop SRS rewrite.
• HHH is a base32-encoded HMAC of the rest of the address, computed with a secret key the forwarder holds. The HMAC prevents attackers from forging SRS-encoded addresses to bypass bounce routing.
• TT is a base32-encoded timestamp limiting the rewrites validity (typically 21 days). Old SRS-encoded addresses expire so bounces cannot be relayed indefinitely.
• original-domain is the domain part of the original MAIL FROM.
• original-localpart is the local-part of the original MAIL FROM.
• forwarder-domain is the forwarders own domain.

Concrete example: an original MAIL FROM: alice@sender.org forwarded by example.com becomes SRS0=HHH=TT=sender.org=alice@example.com.

SRS1 format for multi-hop chains

The SRS1 format is for messages traversing multiple forwarders. The format is:

SRS1=HHH=intermediate-forwarder==SRS0-payload@final-forwarder

SRS1 lets each forwarder in a chain rewrite without losing the original-sender information. In practice multi-hop SRS is rare because most deployments terminate at a single forwarding tier and ARC has displaced SRS for multi-intermediary chains.

Bounce reverse-decoding

Bounces sent to the SRS-encoded address must be reverse-decoded. The forwarder:

1. Receives a bounce addressed to SRS0=HHH=TT=sender.org=alice@example.com.
2. Validates the HMAC HHH against the forwarders SRS secret to confirm the address was genuinely SRS-encoded by this forwarder.
3. Validates the timestamp TT has not expired (typically <21 days).
4. Reconstructs the original address alice@sender.org from the encoded fields.
5. Re-sends the bounce to alice@sender.org.

The HMAC validation is critical: without it an attacker could send arbitrary mail to SRS0=fake=fake=sender.org=alice@example.com addresses and the forwarder would dutifully relay them to alice@sender.org, making the forwarder an open relay.

Implementations

• Postfix: via the postsrsd daemon (separate package; runs as a TCP service on localhost; integrates via sender_canonical_maps and recipient_canonical_maps).
• Exim: native SRS support via the srs_ ACL conditions and the srs_secret configuration option.
• Sendmail: via the sendmail-srs milter or via custom mc configuration.
• Microsoft Exchange: since Exchange 2007, SRS is automatic for accepted-domain forwarding (the SRS prefix is the literal BPM rather than SRS0, but the mechanism is equivalent).
• qmail: via the qmail-srs patch (legacy).

SRS limitations

• SRS rewrites only the MAIL FROM; it does NOT touch the From: header. So while SPF passes, DMARC alignment is only achieved if DKIM also passes (the body is unchanged) — this is typically true for transparent forwarders.
• SRS does not help mailing lists, which modify the message body. Mailing lists need From-header MUNGE or ARC.
• SRS bounce reverse-decoding adds operational complexity. Bounces lost in the reverse-decoding chain confuse senders.
• SRS-rewritten addresses expire (typically 21 days), so very-delayed bounces cannot be reverse-decoded.
• SRS does not address the privacy concern that the forwarders domain leaks in the rewritten address.

For modern deployments handling many forwarding intermediaries (corporate mail gateways, SaaS forwarding aggregators, multi-region routing), ARC has largely displaced SRS as the operational answer because ARC handles multi-hop chains natively and does not require bounce reverse-decoding. SRS remains the dominant pattern for self-hosted single-hop forwarders (the .forward / /etc/aliases case).

5. Authenticated Received Chain (ARC) — the receiver-side answer

The Authenticated Received Chain (ARC), defined in RFC 8617 (July 2019), is the IETF standard answer to forwarding-breaks-SPF and forwarding-breaks-DKIM. ARC lets intermediaries (forwarders, mailing lists, mail-relay services) cryptographically attest to the SPF, DKIM, and DMARC verdicts they OBSERVED at the moment they received the message — and let downstream receivers trust that chain to override otherwise-failing verdicts when their own SPF and DKIM checks fail because of forwarding.

The three ARC headers

Each intermediary in an ARC-aware path adds three header fields, all carrying the same incremental instance number i=N (1 for the first hop, 2 for the second, etc.):

• ARC-Authentication-Results (arc-authentication-results): the SPF, DKIM, and DMARC verdicts the intermediary observed when it received the message. Mirrors the syntax of the Authentication-Results header (RFC 8601).
• ARC-Message-Signature (arc-message-signature): a DKIM-like signature over the message contents AT THE TIME the intermediary handled it. Lets downstream receivers verify the message has not been modified since this intermediarys checkpoint.
• ARC-Seal (arc-seal): a signature over the ARC headers themselves (the ARC-Authentication-Results and ARC-Message- Signature for this hop, plus all previous ARC-Seal headers in the chain). Prevents intermediaries from tampering with earlier hops attestations.

The chain accumulates as the message traverses intermediaries: hop 1 adds three headers with i=1; hop 2 adds three more with i=2 covering hop 1s chain in the ARC-Seal; hop 3 adds three more with i=3 covering hops 1 and 2; and so on. The final receiver validates the chain by verifying every ARC-Seal in sequence and every ARC-Message-Signature against the message state observed at that hop.

How downstream receivers use ARC

When a downstream receiver evaluates DMARC and finds that SPF and DKIM have both failed (the classic forwarding-broken case), it consults the ARC chain:

1. Validate every ARC-Seal in the chain. If any seal fails to verify, the chain is broken (cv=fail) and ARC cannot rescue the message.
2. Validate every ARC-Message-Signature against the message state at the corresponding hop. If any signature fails, the chain is broken.
3. Inspect the ARC-Authentication-Results from the FIRST hop (the originating intermediary). If this hop attests that SPF + DKIM + DMARC passed at the time it received the message, the receiver MAY treat the message as if the original authentication had passed.
4. Apply local trust policy. The receiver maintains an internal allow-list of trusted ARC sealers (typically major forwarders like icloud.com, mailman lists, googlegroups.com). If the originating intermediary is in the allow-list, the receiver overrides the otherwise-failing DMARC verdict and delivers the message.

Validators in production

The major mailbox providers validate ARC and use it to rescue forwarded mail:

• Gmail — ARC validation since 2017 (pre-RFC pilot deployment), full RFC 8617 conformance since 2019. Gmail treats trusted intermediaries (icloud.com, major mailing lists, FastMail, ProtonMail) as authority for SPF / DKIM rescue.
• Microsoft 365 / Outlook.com — ARC validation since 2020. Microsoft documents the ARC-aware path under the ARC trusted-sealer configuration in the Defender for Office 365 portal.
• Yahoo — ARC validation since 2019.
• AOL — ARC validation since 2019 (now operated by Yahoo / Verizon Media / Apollo, same validator stack).
• Apple iCloud — both seals and validates ARC since 2019.
• Comcast — validates ARC since 2021.
• ProtonMail, FastMail, Mailfence — validate ARC in their hosted mail services.

Sealers in production

Most major forwarders and mailing-list software seal forwarded messages with ARC:

• Apple iCloud Mail Drop — seals all forwarded messages.
• Apple Hide My Email — seals all forwarded messages.
• Gmail filter-based forwarding — seals when forwarding to external addresses.
• Microsoft 365 transport rules — seals when configured.
• Mailman 3 — seals when configured ([ARC] enabled: yes in mailman.cfg).
• Google Groups — seals all list traffic by default.
• Discourse — seals when the SiteSetting.email_in_arc_sealing flag is enabled.
• SimpleLogin, DuckDuckGo Email Protection, AnonAddy — seal all forwarded mail by default.
• Self-hosted Postfix and Sendmail — via the OpenARC milter.
• Self-hosted Exim — via native arc_sign at the time of forwarding.

ARC failure modes

ARC chains can fail in three ways:

• cv=fail — chain validation failed. A previous intermediary either signed incorrectly or modified a message already signed by an earlier hop without re-sealing. The receiver MUST NOT use ARC to rescue.
• cv=none — no ARC chain was found. The message did not traverse an ARC-sealing intermediary. The receiver falls back to plain SPF / DKIM / DMARC.
• cv=pass — the chain validates. The receiver MAY use the first-hop attestation to rescue otherwise-failing SPF / DKIM verdicts, gated by local trust policy.

The most common ARC failure mode in production is double-modification: hop 1 seals, hop 2 modifies the body without resealing (because it does not understand ARC), and hop 3 validates and finds the ARC-Message- Signature from hop 1 broken. The fix is for hop 2 to either reseal (preferred) or pass through without modification.

6. Mailing list mitigations: From-header MUNGE, message wrapping, ARC sealing

Mailing lists are a special case because the list software modifies the message body (footer, subject tag, List-Id header), so BOTH SPF AND DKIM fail at the downstream receiver. Three mitigations have emerged:

Mitigation A: From-header MUNGE (Mailman 3, Discourse legacy)

The list rewrites the RFC 5322 From: header so the From address is owned by the list rather than the original poster. Example:

From: "Alice Carpenter via Dev List" <dev@list.example.com>
Reply-To: alice@example.com
Sender: dev-bounces@list.example.com
List-Id: <dev.list.example.com>

Effects:

• SPF check passes — the list server is authorised by list.example.coms SPF record.
• DKIM signature from the list server validates the modified body.
• DMARC alignment passes against list.example.com (the new From: domain).

Mailman 3 implements this via the dmarc_mitigate_action per-list setting:

dmarc_mitigate_action: munge_from
dmarc_mitigate_unconditionally: False

Discourse implements this via SiteSetting.email_in_munge_from_address (legacy, deprecated in favor of ARC sealing in Discourse 3.0+).

Downsides: the From: no longer cleanly displays the original poster. Mail clients show "Alice Carpenter via Dev List" rather than "Alice Carpenter". Reply-all may route incorrectly. Address-book auto-add picks up the list address rather than the posters. Some MUAs collapse threads incorrectly because the From: identity changes per list.

Mitigation B: Message wrapping

The list encapsulates the original message as a message/rfc822 attachment inside a new outer envelope. The outer envelope is From: the list, addressed to the subscriber, with a multipart/mixed body that contains the original message as an attachment.

Effects:

• SPF and DKIM authenticate the OUTER envelope (list-owned, passes).
• DMARC aligns against the outer From: (list-owned, passes).
• The original message is preserved intact inside the attachment.

Downsides: severe UX degradation. Subscribers receive a confusing "message contains attachment" presentation. Many mail clients do not render embedded message/rfc822 attachments inline. Message-wrapping is rarely chosen in modern deployments; Mailman 3 supports it via dmarc_mitigate_action: wrap_message but the documentation marks it as legacy.

Mitigation C: ARC sealing (modern preferred)

The list seals the message with ARC headers attesting that the original message passed authentication at the list server. Downstream receivers that validate ARC trust the chain and override the failing SPF / DKIM / DMARC verdict.

Effects:

• From: header is preserved (good UX).
• Original author is visible in mail clients.
• Reply-all works correctly.
• Downstream receivers that validate ARC (Gmail, Microsoft 365, Yahoo, Apple, Comcast) accept the message; receivers that do NOT validate ARC apply the published DMARC policy.

Mailman 3 enables ARC sealing via [ARC] enabled: yes in mailman.cfg. Discourse 3.0+ enables ARC sealing via SiteSetting.email_in_arc_sealing. Google Groups seals all list traffic by default. The IETF mailing-list infrastructure (tools.ietf.org / mailman.ietf.org) seals all list traffic by default.

Choosing between MUNGE and ARC

The current operational guidance from Mailman 3 maintainers (2024 release notes):

• If subscribers primarily use Gmail, Microsoft 365, Yahoo, Apple iCloud, or Comcast — choose ARC sealing. These receivers validate ARC and rescue forwarded mail.
• If subscribers use older receivers that do not validate ARC — choose MUNGE. The display-quality downsides are preferable to spam-foldering.
• If unsure — enable both. Mailman 3 supports dmarc_mitigate_action: munge_from AND [ARC] enabled: yes simultaneously. ARC-validating receivers rescue based on the chain; non-ARC receivers fall back to MUNGE.

7. Detecting SPF forwarding failures in production

SPF forwarding failures show up in three diagnostic surfaces. Operators should monitor all three to triage the prevalence and impact of forwarding-related authentication failures in their environment.

Surface 1: DMARC aggregate (RUA) reports

DMARC aggregate reports, defined in RFC 7489 section 7, are daily XML reports that DMARC-honouring receivers send back to the rua= mailbox listed in your DMARC record. Each report contains per-source-IP aggregates of:

• Message count.
• SPF result code (pass / fail / softfail / neutral / temperror / permerror / none).
• SPF authenticated identifier (which domain SPF actually authenticated, when there is one).
• DKIM result code, signing domain, and selector.
• DMARC disposition (none / quarantine / reject).

The forwarding-failure pattern in aggregate reports:

• Low volume per source IP (often 1-5 messages per day per forwarding intermediary).
• High diversity of source IPs over time (different forwarding-service nodes, different mailing-list IPs).
• Source IP belongs to a known forwarding- service ASN (Apple AS714 for iCloud, Google AS15169 for Gmail, Microsoft AS8075 for Microsoft 365, list-server hosting providers).
• spf=fail combined with EITHER dkim=pass (transparent-forwarder case) OR dkim=fail (body-modifying-forwarder case).

The DMARC Analyzer dashboard surfaces this distinction in the Top Source IPs table. Click any "Failures" row to see the per- record breakdown and look for the body of the report under the Reporter Detail view to see whether SPF, DKIM, or both failed.

Surface 2: Authentication-Results header (RFC 8601)

For end-to-end diagnosis of a SPECIFIC failed message, inspect the Authentication-Results: header in the raw message source. The header is added by the FIRST receiving mail server in the path and surfaces the SPF, DKIM, DMARC, and ARC verdicts that server observed.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@sender.org header.s=selector1 header.b=...;
       spf=fail (google.com: domain of alice@sender.org
                 does not designate 198.51.100.42 as
                 permitted sender) smtp.mailfrom=alice@sender.org;
       dmarc=pass (p=quarantine sp=quarantine dis=none)
              header.from=sender.org;
       arc=pass (i=1 spf=pass dkim=pass dmarc=pass)
                 smtp.remote-ip=198.51.100.42

Key signals in this header:

• spf=fail with a parenthetical "does not designate <IP> as permitted sender" — the canonical forwarding break.
• dkim=pass alongside spf=fail — transparent forwarder (body unchanged); DMARC may align via DKIM.
• dkim=fail alongside spf=fail — body-modifying forwarder (mailing list or content-rewriting forwarder); DMARC cannot align and falls to the published policy.
• arc=pass at the bottom — the chain validates and the receiver used ARC to rescue the message.
• arc=fail — the chain broke; ARC could not rescue.
• arc=none — no ARC chain was present; the message traversed non-ARC intermediaries.

The DMARC Analyzer Email Header Analyzer parses pasted Authentication-Results headers and surfaces each verdict individually with cross-references to the RFCs and the canonical failure-cause explanations.

Surface 3: Received: header chain

The Received: header chain surfaces every SMTP hop the message traversed. When triaging a forwarding failure, the chain tells you:

1. How many hops the message traversed (count the Received: headers).
2. What IPs handled each hop (look at the from and by clauses).
3. When the message was relayed at each hop (look at the timestamps).

A typical forwarding chain:

Received: from mx.google.com by inbox.gmail.com
          ; Mon, 21 May 2026 08:32:11 -0700
Received: from forwarder.example.com (198.51.100.42)
          by mx.google.com via SMTP
          ; Mon, 21 May 2026 08:32:09 -0700
Received: from mx.sender.org (203.0.113.7)
          by forwarder.example.com via SMTP
          ; Mon, 21 May 2026 08:32:08 -0700
Received: from sender-mta.sender.org by mx.sender.org
          ; Mon, 21 May 2026 08:32:06 -0700

The forwarders IP (198.51.100.42) appears as the from clause of the SECOND-from-top Received: header. Gmails SPF check is performed against THIS IP — and fails because 198.51.100.42 is not in sender.orgs SPF record.

8. The four canonical operational fixes

The four operational answers to forwarding- breaks-SPF, ranked by deployment scope:

Fix 1: Implement SRS on the forwarder

Scope: SMTP-level forwarders under operator control (.forward, /etc/aliases, server-side alias rules, corporate mail gateways).

Postfix configuration via postsrsd:

# /etc/default/postsrsd
SRS_DOMAIN=example.com
SRS_EXCLUDE_DOMAINS=example.com,internal.example.com
SRS_SECRET=/etc/postsrsd.secret
SRS_FORWARD_PORT=10001
SRS_REVERSE_PORT=10002

# /etc/postfix/main.cf
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient,header_recipient

Exim configuration via native SRS:

# /etc/exim4/exim4.conf.template — under main configuration
srs_config = secret_text:LONG_RANDOM_SECRET_HERE
srs_maxlifetime = 21d

# under routers — forward router with SRS rewrite
forward_with_srs:
  driver = redirect
  domains = example.com
  data = ${lookup{$local_part}lsearch{/etc/aliases}}
  errors_to = ""
  pipe_transport = address_pipe
  file_transport = address_file
  reply_transport = address_reply
  qualify_preserve_domain
  srs = forward

Fix 2: Implement ARC sealing on the forwarder

Scope: any forwarder (SMTP-level, mailing list, third-party). ARC is the modern preferred answer where downstream receivers validate it.

Postfix with OpenARC milter:

# /etc/openarc.conf
Mode sv
Domain example.com
Selector arc1
KeyFile /etc/openarc/keys/arc1.private
Socket inet:8893@localhost
SignatureAlgorithm rsa-sha256
Canonicalization relaxed/simple
AuthservID example.com

# /etc/postfix/main.cf
smtpd_milters = inet:localhost:8893
non_smtpd_milters = inet:localhost:8893
milter_default_action = accept

DNS publication for the ARC selector:

arc1._domainkey.example.com.  IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." )

Fix 3: Configure mailing-list software for DMARC-aware operation

Scope: mailing lists you operate.

Mailman 3 (preferred: ARC sealing):

# /etc/mailman3/mailman.cfg
[ARC]
enabled: yes
authserv_id: list.example.com
privkey: /etc/mailman3/arc.privkey
selector: arc1
domain: list.example.com

# per-list setting (mailman-cli or HyperKitty admin)
dmarc_mitigate_action: munge_from  # fallback for non-ARC receivers
anonymous_list: no
subject_prefix: "[Dev] "

Discourse 3.0+ (preferred: ARC sealing):

# app.yml > env
DISCOURSE_EMAIL_IN_ARC_SEALING: true
DISCOURSE_EMAIL_IN_ARC_DOMAIN: discourse.example.com
DISCOURSE_EMAIL_IN_ARC_SELECTOR: arc1
DISCOURSE_EMAIL_IN_ARC_PRIVATE_KEY: /shared/arc/arc1.private

Fix 4: Publish a permissive DMARC policy and accept some forwarding loss

Scope: any organisation that cannot enforce SRS or ARC at every intermediary in the forwarding chain. The rule of thumb:

• Phase 1 (monitor): v=DMARC1; p=none; rua=mailto:dmarc@example.com; — gather two to four weeks of aggregate reports to baseline forwarding-traffic prevalence in your domain.
• Phase 2 (quarantine pct=10): v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com; — start spam-foldering 10% of failing mail; monitor user-reported false positives.
• Phase 3 (quarantine pct=100): v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; — full quarantine; receivers without ARC support spam-folder all failing mail.
• Phase 4 (reject): v=DMARC1; p=reject; rua=mailto:dmarc@example.com; — bounce all failing mail. Only graduate here after ARC-validating receivers handle the bulk of legitimate forwarded mail.

Critically: do NOT try to authorise every forwarder in your SPF record. The 10-lookup cap from RFC 7208 section 4.6.4 makes this infeasible at scale — every include:forwarder.example token consumes one of your ten lookups, and a typical organisation needs three to five lookups for legitimate ESP / transactional / Microsoft 365 includes already.

9. Symptom decision matrix

Use this matrix to identify the forwarding- related root cause from the symptoms you observe in production.

10. Real-world examples

Example 1: Corporate .forward to personal Gmail

A finance team member has jane.doe@bigcorp.com with a server-side .forward to jane.doe.personal@gmail.com. Vendors email jane.doe@bigcorp.com from their own infrastructure; bigcorp.coms Postfix server relays each message to jane.doe.personal@gmail.com. Gmail performs an SPF check against the vendors domain (the MAIL FROM is still the vendors), tests bigcorp.coms IP against the vendors SPF record, and gets spf=fail. Without SRS or ARC at bigcorp.com, all vendor mail goes to Janes Gmail spam folder.

Resolution: bigcorp.coms IT team enables postsrsd on the Postfix relay. After SRS, the MAIL FROM is rewritten to SRS0=HHH=TT=vendor.com=billing@bigcorp.com. Gmail tests bigcorp.coms IP against bigcorp.coms SPF record (which lists bigcorp.coms own IPs), gets spf=pass, and delivers normally.

Example 2: Mailman 3 mailing list with strict-DMARC posters

An open-source projects mailing list dev@list.example.com hosts Mailman 3. A subscriber from a strict-DMARC domain (p=reject at sender.example.org) posts a question. Mailman expands the recipient list, appends an unsubscribe footer, adds List-Id: <dev.list.example.com>, and re-sends to 500 subscribers. The body modification breaks the original DKIM signature; the list servers IP is not in sender.example.orgs SPF record; DMARC fails at every receiver. With p=reject at sender.example.org, 500 subscribers see the message bounced.

Resolution path A (legacy MUNGE): list operator enables dmarc_mitigate_action: munge_from. The From: is rewritten to "Original Poster via Dev List" <dev@list.example.com>. SPF passes; DKIM passes (Mailman re-signs the modified message with list.example.coms DKIM key); DMARC aligns. 500 subscribers receive the message but see a list-owned From: address.

Resolution path B (modern ARC, preferred): list operator enables [ARC] enabled: yes + publishes arc1._domainkey.list.example.com TXT. Mailman seals every outgoing message with ARC headers attesting that SPF + DKIM + DMARC passed at the list server BEFORE modification. Downstream Gmail / Microsoft 365 / Yahoo subscribers receive the message normally with the original From: preserved; downstream non-ARC subscribers may still see the message quarantined (the From: still says sender.example.org with broken DKIM / SPF — no rescue).

Example 3: iCloud Mail Drop with Outlook destination

A user has alice@icloud.com with Mail Drop forwarding to alice@outlook.com. A vendor sends billing@vendor.com to alice@icloud.com. iCloud receives the message, performs SPF + DKIM + DMARC verification (which all pass), seals the message with an ARC chain, and forwards to alice@outlook.com. Microsoft 365 performs SPF against vendor.coms record, gets spf=fail (iClouds IP is not authorised), but validates the ARC chain, sees iCloud (a trusted intermediary) attesting that authentication passed at receipt, and delivers the message normally to Alice.

No operator action required. ARC handles this case end-to-end transparently because both iCloud (sealer) and Microsoft 365 (validator) deployed ARC support in 2019-2020.

11. FAQ

Why does SPF fail when an email is forwarded?

SPF authenticates the SMTP envelope sender (the RFC 5321 MAIL FROM, also called the bounce address or return-path) against the IP address of the connecting SMTP client. When a message is forwarded at the SMTP layer — for example, alice@example.com has a .forward file that pipes mail to bob@othersite.net — the forwarding server (example.com) opens a NEW SMTP connection to othersite.net using its OWN IP address as the SMTP client. The receiving server at othersite.net then performs an SPF check against the original MAIL FROM domain (the original senders bounce address, NOT the forwarders domain), and finds that the forwarders IP is NOT authorised by the original senders SPF record. The result is spf=fail. This is by design: SPF was specified in RFC 7208 to authenticate the FIRST SMTP hop only, and forwarding by definition introduces an additional hop. The Sender Rewriting Scheme (SRS) is the operational workaround at the forwarder side; the Authenticated Received Chain (ARC, RFC 8617) is the receiver-side answer.

What is the Sender Rewriting Scheme (SRS)?

The Sender Rewriting Scheme (SRS) is a technique by which a forwarding mail server REWRITES the RFC 5321 MAIL FROM (envelope sender) at the moment of forwarding, replacing the original bounce address with a forwarder-owned address that encodes the original. Example: alice@example.com forwards to bob@othersite.net via forwarder.com. Before SRS: MAIL FROM is alice@example.com — receiving SPF check against example.com fails because forwarder.com is not in example.com SPF record. After SRS: MAIL FROM is SRS0=HHH=TT=example.com=alice@forwarder.com — receiving SPF check against forwarder.com succeeds because forwarder.com publishes its own SPF record authorising its own outbound IPs. SRS was originally proposed in 2003 by Meng Weng Wong (the same author as the original SPF spec); the canonical reference is the OpenSPF SRS informational draft. SRS is implemented in most mainstream mail servers including Postfix (via postsrsd), Exim (native), Sendmail, qmail (via qmail-srs), and Microsoft Exchange (since Exchange 2007). The trade-off is that bounces sent to the rewritten address must be reverse-decoded and forwarded back to the original sender, which adds operational complexity.

What is the Authenticated Received Chain (ARC)?

The Authenticated Received Chain (ARC) is an IETF standard defined in RFC 8617 that lets intermediaries (forwarders, mailing lists, mail-relay services) cryptographically attest to the SPF, DKIM, and DMARC verdicts they observed AT THE TIME THEY RECEIVED the message — and let downstream receivers trust that chain when their own SPF and DKIM checks fail because of forwarding. Each intermediary adds three header fields: ARC-Authentication-Results (the verdicts they saw), ARC-Message-Signature (a DKIM-like signature over the message at the time they handled it), and ARC-Seal (a signature over the chain itself). Downstream receivers including Gmail, Microsoft 365, Yahoo, AOL, Comcast, and Apple validate the ARC chain; if the chain is intact and the originating intermediary is trusted (the receiver maintains an internal allow-list), the receiver MAY override an otherwise-failing DMARC verdict and deliver the message. ARC is the modern operational answer to forwarding breakage at scale and is the dominant deployment pattern in 2024 for mailing-list operators (Mailman 3, Discourse, Google Groups, GitLab) and major forwarders (iCloud Mail Drop, Gmail Fetcher, Microsoft 365 transport rules).

How do mailing lists break SPF?

A mailing list is conceptually a forwarder that fans out one incoming message to many subscribers. The list software (Mailman, Discourse, Google Groups, Sympa, Majordomo, GitLab incident notifications) receives the original message from the poster, re-sends it from the list server to each subscriber, AND typically modifies the message body (adds a footer, list-id header, unsubscribe link). Three SPF-breaking effects result: (1) the list server is a new SMTP hop with a different IP than the posters authorised SPF range, so receiver-side SPF check against the posters domain fails by default; (2) any DKIM signature applied by the poster over the modified body breaks because the body hash no longer matches; (3) the message arrives at subscriber inboxes with the original From: header (so DMARC alignment is still required), but neither SPF nor DKIM authenticates the posters domain anymore. The result is spf=fail + dkim=fail (body mismatch) + DMARC=fail. For DMARC policies of quarantine or reject, the message is dropped or spam-foldered for every subscriber. The two modern solutions are (a) From-header MUNGE rewriting (the list rewrites From: to a list-owned address such as list@list.example.com so DMARC aligns against the list-owned address) and (b) ARC sealing (the list seals the message with ARC and lets downstream receivers trust the chain).

What is From-header munging and how does Mailman use it?

From-header munging (also called From-rewriting or Reply-To munging in the variant case) is a mailing-list-software technique that rewrites the RFC 5322 From: header of every list message so that the From: address is owned by the list server rather than the original poster. Example: a message originally from alice@example.com posted to dev@list.example.com is sent to subscribers with From: "Alice via Dev List" <dev@list.example.com> and Reply-To: alice@example.com. The effect is that the SPF check now passes (list.example.com is authorised by list.example.com SPF record), the DKIM signature from the list server validates the body the list has modified, and DMARC alignment passes against the list-owned From: address. The trade-off is that the From: header no longer cleanly displays the original posters address, which breaks some mail-client features (one-click sender filtering, address-book auto-add) and may surprise reply-all users. Mailman 3 implements From-header MUNGE via the dmarc_mitigate_action setting (dmarc_mitigate_action: munge_from); Discourse implements it via the SiteSetting.email_in_munge_from_address flag; GitLab implements it via gitlab.yml > smtp.from_email. The standard alternative — preferred where downstream receivers validate ARC — is to seal the message with ARC instead of munging the From: header.

Does iCloud Mail Drop break SPF?

Yes, but iCloud Mail Drop also seals messages with ARC so downstream receivers can recover the authentication chain. iCloud Mail Drop is the @icloud.com and @me.com email-forwarding service (and as of macOS Ventura, the @hideMyEmail unique-address-per-app feature) that lets users receive mail at an iCloud-managed address and have it forwarded to a private external address such as alice@gmail.com. At the SMTP layer this is exactly equivalent to .forward forwarding: the iCloud server receives the message, opens a new SMTP connection to gmail.com using an iCloud-owned IP, and re-injects the message. The original senders SPF record does NOT authorise iCloud IPs, so spf=fail. However, iCloud seals every forwarded message with an ARC chain attesting that the message passed authentication at iCloud, so downstream receivers (Gmail, Outlook.com, Yahoo) that validate ARC see the chain and may override the SPF fail. The same architecture applies to the broader Apple Hide My Email feature where users get a unique <random>@privaterelay.appleid.com address per app; ARC sealing is the default.

How does Gmail Fetcher break SPF?

Gmail Fetcher (the "Check mail from other accounts" feature in Gmail Settings > Accounts and Import) is a POP3 / IMAP polling service rather than an SMTP forwarder, so the SPF break model is subtly different. Gmail Fetcher logs into a remote IMAP or POP3 mailbox (such as your work IMAP server) and DOWNLOADS messages, re-inserting them into your Gmail inbox via an internal mechanism. Because the message is not re-injected via SMTP, there is no second-hop SPF authentication failure in the strict sense. But Gmail STILL evaluates SPF retroactively against the original message metadata (the Received: header chain reveals the original sending IP), and if the original SPF check failed because the message had already been forwarded once before reaching the source IMAP mailbox, the chain may surface a fail. Operationally Gmail Fetcher messages are flagged with a "via" indicator and treated with reduced trust for spam-filtering purposes. The fix is the same as for SMTP forwarding: either (a) the source mailbox forwards via SMTP with SRS, or (b) the source mailbox seals with ARC, or (c) reconfigure Gmail to use OAuth-based IMAP rather than Fetcher so trust is delegated at the protocol level instead of inferred from headers.

What is the relationship between SPF forwarding breakage and DMARC?

DMARC, defined in RFC 7489, requires either SPF or DKIM to pass AND be aligned with the From: header organisational domain. When a message is forwarded and SPF breaks because of the new SMTP hop, DMARC alignment can still succeed if DKIM passes — assuming the forwarder did NOT modify the message body or any signed headers in a way that breaks the DKIM signature. This is the classic operational pattern for transparent forwarders that do not rewrite the message: SPF fails on the forwarders IP, DKIM passes because the forwarder is a faithful transcriber, DMARC alignment passes via DKIM. The problem cases are mailing lists (modify the body, add footers, expand attachments) and content-rewriting forwarders (iCloud strips X-headers; some corporate email gateways insert disclaimer text). For these the body hash in the original DKIM signature no longer matches and BOTH SPF and DKIM fail, so DMARC fails too. The receiver applies the published policy: none means deliver-and-report, quarantine means spam folder, reject means bounce. The two structural answers are ARC (RFC 8617 lets receivers trust an intermediarys attestation of pre-forwarding verdicts) and From-header MUNGE (the list rewrites From: so DMARC aligns against the list-owned address).

How do I detect SPF forwarding failures in my DMARC aggregate reports?

SPF forwarding failures show up in DMARC aggregate (RUA) reports as records where spf result is fail (or sometimes softfail) AND the source IP does NOT match any of your own authorised sending IPs. The pattern to watch for: a recurring source IP that belongs to a known forwarding service (iCloud, gmail.com, outlook.com, Mailman list servers, custom alias-forwarding services) sending small volumes of mail purporting to be from your domain. The forwarded-mail signal is typically (a) low volume per source IP (often 1-5 messages per day per forwarding intermediary), (b) high diversity of source IPs over time (different iCloud server hits, different list-server IPs), (c) high incidence of dkim pass + spf fail (the transparent-forwarder pattern) OR dkim fail + spf fail (the body-modifying-forwarder pattern). The DMARC Analyzer dashboard surfaces this distinction in the Top Source IPs table — click any "Failures" row to see the per-record breakdown, and look for the body of the report under the Reporter Detail view to see whether SPF, DKIM, or both failed. Operationally the right response is usually to publish a permissive DMARC policy (p=quarantine pct=10 or p=quarantine with explicit From-header MUNGE recommendations) rather than try to authorise every forwarder under SPF, which is infeasible at scale.

12. Related guides

• SPF explained — the canonical SPF pillar. Covers mechanism types, qualifiers, the 10-DNS-lookup limit, and the seven result codes overview. Start here if SPF as a whole is new to you.
• SPF mechanisms explained — the SPF-MECHANISM-EVALUATION-AT- AUTHORING-TIME-VS-FORWARDING-INDUCED- EVALUATION-DEGRADATION-AT-SECOND-HOP companion to this SPF-forwarding-issues protocol-mechanic diagnostic. Where THIS page documents the SECOND-HOP-BREAK forwarding-failure-mechanic (the envelope-MAIL-FROM-IP-changes-at- forwarder pattern, the recipient-side auto-forwarding scenario, the mailing- list intermediary footprint, the vacation-forwarder / corporate-to- personal forwarding patterns, the DKIM-rescue mechanism + ARC-trust- anchoring path that survives the envelope-IP rewrite), the SPF-mechanisms spoke documents the SEVEN RFC 7208 §5 mechanism tokens whose AUTHORING-TIME choice determines the forwarding- scenario evaluation outcome: (i) a ip4: / ip6: IP-literal mechanism evaluates against the connecting client's IP at evaluation-time — when a forwarder rewrites the envelope to its own IP, the original ip4:/ip6: set does NOT match and the mechanism produces spf=fail; (ii) an include: mechanism delegates to a third-party sender's SPF record — forwarders that emit from infrastructure not enumerated in the included SPF set produce spf=fail identically to the IP-literal case; (iii) an a: / mx: mechanism evaluates against the publisher's own A / MX records — these mechanisms generally DO NOT cover forwarder infrastructure, so forwarded mail evaluates to spf=fail at the second-hop receiver; (iv) a ptr: mechanism is RFC 7208 §5.5-DEPRECATED — using it makes forwarder-induced spf=permerror more likely and degrades the receiver's ability to distinguish a forwarding-failure diagnostic outcome from a malformed- record diagnostic outcome; (v) an exists: mechanism is generally macro-expanded per RFC 7208 §7 — forwarder-induced macro-evaluation produces spf=permerror / spf=temperror outcomes the receiver MUST distinguish per RFC 6376 §3.4 vs RFC 7208 §2.6.7; (vi) the trailing all mechanism's qualifier (+all / -all / ~all / ?all) determines the receiver-side outcome when none of the upstream mechanisms match — forwarder-induced ~all-softfail produces a DMARC-engine-treats-as-pass under relaxed mode WITH DKIM-aligned-pass to bridge, while -all-fail produces a firm reject the DMARC engine cannot rescue without ARC. Read the SPF-mechanisms spoke alongside this forwarding-issues protocol diagnostic when the operator's RUA stream surfaces forwarder-induced SPF-fail / SPF-permerror / SPF-softfail rows that need per-mechanism attribution — the spoke is the AUTHORITATIVE per-mechanism evaluation-behaviour reference operators reach for to determine WHICH mechanism token in their published record is the load-bearing cause of the forwarding-failure-class diagnostic outcome this page catalogues.
• SPF for Google Workspace — the GMAIL-WORKSPACE-RECIPIENT-AUTO- FORWARDING-LOSS-SECOND-HOP-BREAK-FOR- WORKSPACE-TENANT-OUTBOUND-VIA-_SPF.GOOGLE.COM- INCLUDE-AUTHORED-RECORD companion to this SPF-forwarding-issues protocol diagnostic. Where THIS page documents the canonical second-hop-break protocol mechanic (RFC 7208 envelope-MAIL-FROM-IP-changes-at- forwarder, the recipient-side auto- forwarding scenario, the mailing-list / vacation-forwarder / corporate-to-personal forwarding patterns, the DKIM-rescue mechanism + ARC-trust-anchoring), the SPF-for-Workspace spoke is the WORKSPACE- TENANT-OUTBOUND-AUTHORING companion documenting the SPF authoring discipline that determines whether Workspace-tenant outbound mail can survive the auto- forwarding loss scenarios this page catalogues. The four-axis SPF-FORWARDING- VS-WORKSPACE-SPF comparison exposes the structurally-distinct WORKSPACE-FORWARDING- FAILURE-OUTBOUND-PROFILE roles: (i) Gmail "Forwarding and POP/IMAP" is the single most common recipient-side auto-forwarder in the consumer ecosystem — Workspace-tenant outbound mail is the dominant sender population feeding this forwarding scenario — when a Gmail recipient configures Settings → Forwarding and POP/IMAP → "Forward a copy of incoming mail to" to a non-Gmail address, the forwarder re-emits the original message from Gmail's SMTP infrastructure with Gmail's own envelope-MAIL-FROM and breaks the original Workspace-tenant SPF; the SPF-for-Workspace spoke documents the SPF-authoring patterns Workspace tenants use to coordinate with the DKIM-aligned- pass survival mechanic this forwarding- issues page identifies as the rescue path; (ii) Workspace internal "Routing → Recipient address map" rules are a Workspace-admin-configured auto- forwarder that breaks SPF identically to the Gmail-consumer pattern but at the Workspace tenant boundary — the SPF-for-Workspace spoke documents the Workspace-admin-side auto-forwarder configuration pattern that produces the SPF-fail row class this page diagnoses from the receiver side; (iii) Workspace mailing-list integration via Google Groups produces a Mailman-like Subject-prefix / body-modification pattern that breaks DKIM signatures AND envelope-MAIL-FROM rewriting — the SPF-for- Workspace spoke documents the Google- Groups-as-mailing-list-intermediary SPF-authoring pattern Workspace tenants must align with the DKIM-rescue mechanism this forwarding-issues page identifies; (iv) Workspace- tenant SPF record's ~all-vs--all qualifier choice determines whether forwarder-broken mail produces SPF=softfail (treat-as-pass for DMARC relaxed mode + DKIM rescue) or SPF=fail (firm reject without DKIM-aligned-pass to bridge) — the SPF-for-Workspace spoke documents the qualifier-selection decision tree this forwarding-issues page's downstream "what to do about forwarder-induced SPF-fail" guidance depends on. Read the SPF-for- Workspace spoke alongside this forwarding-issues protocol diagnostic when the operator's RUA stream surfaces forwarder-induced SPF-fail rows attributable to Gmail-side or Workspace-side auto-forwarding — the spoke is the AUTHORITATIVE Workspace- tenant SPF-authoring reference operators reach for to coordinate the outbound SPF record's qualifier selection + envelope-MAIL-FROM authoring with the DKIM-rescue mechanism documented on this page.
• SPF for Microsoft 365 — the M365-TENANT-EXCHANGE-ONLINE-EGRESS- AUTO-FORWARDING-LOSS-SECOND-HOP-BREAK-FOR- M365-TENANT-OUTBOUND-VIA-_SPF.PROTECTION.OUTLOOK.COM- INCLUDE-AUTHORED-RECORD companion to this SPF-forwarding-issues protocol diagnostic. Where THIS page documents the canonical second-hop-break protocol mechanic (RFC 7208 envelope-MAIL-FROM-IP-changes-at- forwarder, the recipient-side auto- forwarding scenario, the mailing-list / vacation-forwarder / corporate-to-personal forwarding patterns, the DKIM-rescue mechanism + ARC-trust-anchoring), the SPF-for-Microsoft-365 spoke is the M365- TENANT-OUTBOUND-AUTHORING companion documenting the SPF authoring discipline that determines whether M365-tenant outbound mail through Exchange Online egress can survive the auto-forwarding loss scenarios this page catalogues. The four-axis SPF-FORWARDING-VS-M365-SPF comparison exposes the structurally- distinct M365-FORWARDING-FAILURE-OUTBOUND- PROFILE roles: (i) Outlook.com "Inbox rules → Forward to" and Exchange Online "Mail flow → Rules" + "Inbox rules" are the dominant recipient-side and admin-side auto-forwarders in the enterprise ecosystem — M365-tenant outbound mail egressing via spf.protection.outlook.com canonical egress IP set (40.92.0.0/15, 40.107.0.0/16, 52.100.0.0/14 and the successor ranges spf.protection.outlook.com publishes via its chain of nested include: + ip4: mechanisms) is the dominant enterprise sender population feeding this forwarding scenario — when an Outlook.com recipient configures Settings → Mail → Rules → Forward, the forwarder re-emits the original message from outlook.com's SMTP infrastructure with Microsoft's own envelope-MAIL-FROM and breaks the original M365-tenant SPF; the SPF-for-Microsoft-365 spoke documents the SPF-authoring patterns M365 tenants use to coordinate with the DKIM-aligned-pass survival mechanic this forwarding-issues page identifies as the rescue path; (ii) Exchange Online Protection "Mail flow → Rules → redirect" + Exchange Online connector- based outbound rerouting are EOP-admin- configured forwarders that break SPF identically to the Outlook-consumer pattern but at the M365-tenant boundary — the SPF-for- Microsoft-365 spoke documents the EOP- admin-side connector + transport-rule forwarder configuration pattern that produces the SPF-fail row class this page diagnoses from the receiver side; (iii) Microsoft 365 Groups + public folders + distribution groups produce a Subject-prefix / List-Unsubscribe- header-injection / body-modification pattern that breaks DKIM signatures AND envelope-MAIL-FROM rewriting — the SPF-for-Microsoft-365 spoke documents the M365-Groups-as-mailing- list-intermediary SPF-authoring pattern M365 tenants must align with the DKIM-rescue mechanism this forwarding- issues page identifies; (iv) M365-tenant SPF record's ~all-vs--all qualifier choice determines whether forwarder-broken mail produces SPF= softfail (treat-as-pass for DMARC relaxed mode + DKIM rescue via Exchange Online auto-signing with d=onmicrosoft.com OR d=customer-domain.com depending on DKIM-CNAME-delegation state) or SPF= fail (firm reject without DKIM-aligned- pass to bridge) — the SPF- for-Microsoft-365 spoke documents the qualifier-selection decision tree this forwarding-issues page's downstream "what to do about forwarder-induced SPF-fail" guidance depends on. Read the SPF-for-Microsoft-365 spoke alongside this forwarding-issues protocol diagnostic when the operator's RUA stream surfaces forwarder-induced SPF-fail rows attributable to Outlook- side or M365-side auto-forwarding — the spoke is the AUTHORITATIVE M365-tenant SPF-authoring reference operators reach for to coordinate the outbound SPF record's qualifier selection + envelope- MAIL-FROM authoring with the DKIM-rescue mechanism documented on this page.
• SPF qualifiers explained (+, -, ~, ?) — the focused deep dive on the four RFC 7208 §4.6.2 qualifier prefixes (+ Pass, - Fail, ~ SoftFail, ? Neutral) whose choice determines whether a forwarding-induced SPF mismatch becomes a hard rejection or a quietly-tagged soft-failure. The qualifier choice at the end of the SPF record (the all token's qualifier prefix) is the single most consequential operator decision for forwarder-tolerance: the canonical ~all default produces SoftFail (RFC 7208 §2.6.5, treated as "marked but delivered" by most receivers) which buys the forwarder some survivability when SRS / ARC are not deployed; conversely -all produces Fail (§2.6.4, treated as "explicit reject" by most receivers) and will be the SMTP-time rejection cause for every forwarded message whose envelope sender is rewritten. The qualifiers page also documents the per-mechanism qualifier prefix overrides (e.g. +include:_spf.google.com -ip4:… ~mx -all mixes Pass, Fail, SoftFail, and Fail across the same record) which let operators express nuanced authorisation logic that single- qualifier-at-end records cannot. Read the qualifiers page when deciding the forwarding-tolerance posture of your SPF record: this forwarding-issues page documents WHY SPF breaks at forwarders, the qualifiers page documents WHICH receiver-side enforcement behaviour each qualifier triggers when the break occurs.
• include vs ip4 vs a vs mx: the four IP-providing mechanisms compared — the focused four-way operator-decision tree on the IP-providing mechanism subset (include: / ip4: / a: / mx:) whose choice indirectly affects forwarding survivability documented on this page. Forwarders that rewrite the envelope sender (the canonical forwarding-breaks-SPF root cause) cannot be authorised by SPF regardless of mechanism choice, but the per-mechanism trade-offs matter when designing the SPF record an ARC-supporting forwarder will preserve in its signed chain: a flat ip4: set is the easiest record for receivers to evaluate quickly without recursive lookups, an include: chain depends on the included provider's flattening posture, and a stale mx:-on-outbound pattern often confuses receivers into rejecting legitimately forwarded mail. Pair with this page when designing a forwarder- friendly SPF record: this page documents WHY forwarding breaks SPF, the include-vs page documents the four mechanism choices the operator picks between when publishing the underlying record.
• SPF lookup limit and flattening — the RFC 7208 section 4.6.4 10- DNS-lookup limit deep dive. Forwarding cannot be solved by authorising every forwarder in your SPF record because the lookup cap prevents it.
• SPF permerror vs temperror — focused diagnostic deep dive on the two SPF error result codes. If you observe spf=fail with intermittent appearance, you may actually be triaging spf=temperror — check this page first.
• SPF DNS record syntax — TXT encoding, character-string boundaries, ABNF — the byte-level syntactic reference for the SPF record this forwarding- issues page operates on. Forwarding decisions interact with the DNS-syntax layer in three ways: (1) operators designing a forwarder-friendly SPF record need to know the 255-octet character-string limit and the multi-string concatenation rule (RFC 7208 §3.3) before adding more include: mechanisms to authorise downstream forwarders, (2) operators republishing an SPF record to ALSO authorise a third-party SMTP-Auth forwarder need to know the single-TXT-RR rule (RFC 7208 §4.5) because publishing a second TXT RR at the apex triggers permerror at every receiver, and (3) ARC-supporting forwarders preserve the upstream SPF record's wire-format in their signed chain — a syntactically-broken record breaks ARC verification at every downstream hop. Read the DNS-syntax reference when republishing an SPF record to accommodate forwarder constraints.
• DNS propagation — the FORWARDER-AWARE-SPF-RECORD-RE- PUBLISH-CYCLE companion to this SPF forwarding-issues page. The DNS propagation spoke is the publisher- side publish-and-verify-cycle reference that bounds how long a forwarder-induced SPF record change takes to materialise at the receiver-side authoritative resolver at FOUR forwarder-induced- SPF-change-propagation dimensions: (i) publisher emits new include: directive for the legitimate-forwarder origin IP → receiver-side authoritative resolver cache invalidates only at TTL expiry → forwarder-second-hop spf=fail false-positive window closes on receiver-resolver cache refresh — the DNS propagation spoke documents the operator-discipline rule that the time-to-receiver-visibility for a new include: directive that legitimately authorises a forwarder origin is bounded by the publisher's TTL choice on the SPF TXT record AND by the upstream receiver-resolver's caching discipline; the spoke documents how the publisher should proactively LOWER the TTL window BEFORE the planned include flush to compress the false-positive spf=fail diagnostic window THIS page documents to a sub-hour receiver-visibility window; (ii) publisher emits new ip4: / ip6: mechanism for a self-published forwarder fleet (e.g. organisation-internal mailbox-to-archive forwarder farm, third-party-forwarder- partner IP range, ESP-to-ESP relay IP) → receiver-side authoritative TXT publish-and- verify-cycle — the DNS propagation spoke documents the cycle for the publisher emitting a new ip4: / ip6: mechanism — same TTL- bounded propagation discipline applies, but the forwarder- fleet case typically requires coordinated publication across multiple SPF records (root domain + subdomain SPF records if the forwarder fleet is delegated under a subdomain per the lookup-budget flattening pattern THIS page's sibling SPF-lookup-limit page documents); the coordinated multi-record propagation is the operationally-most-complex SPF-republishing event the spoke is the discipline reference for; (iii) publisher emits flatten-and-re-include sequence for an obsolete forwarder partner whose IP space the publisher needs to retire from the SPF record → TTL-bounded publish-cycle across BOTH the new flattened SPF and the retiring forwarder partner's published SPF — the DNS propagation spoke documents the cycle for the publisher retiring a forwarder partnership: the publisher publishes the new SPF record with the retiring partner's IP space replaced by either a flattened ip4: equivalent OR an explicit exclusion; receivers cache-invalidate on TTL expiry; the retiring partner may continue to emit mail under the old SPF chain until their cache of the publisher's record also expires — a coordination event the spoke documents the operator-discipline rule for ("retire only when the publisher's cached SPF has propagated below the partner's send-rate floor"); (iv) SPF record TTL choice as forwarder-incident- response-window determinant → low TTL (300s) for active-incident publishers vs high TTL (3600s) for steady-state publishers — the spoke documents the operator- discipline trade-off between authoritative- resolver query load and SPF-change incident- response window — the DNS propagation spoke documents the operator-discipline trade-off for SPF TTL choice: low TTL (300 seconds) gives the publisher the fastest incident-response window for forwarder-induced SPF changes (the receiver sees the new record within 5 minutes of publish), at the cost of authoritative- resolver query load scaling 12× vs the 3600-second baseline; high TTL (3600 seconds) gives the publisher baseline authoritative- resolver query load at the cost of a 1-hour worst-case forwarder- incident-response window; the spoke is the operator-discipline reference for choosing the right SPF TTL value as a function of the publisher's forwarder-incident- history baseline. Read the DNS propagation spoke WITH this SPF forwarding-issues page when authoring the publisher's SPF-change coordination runbook — THIS page is the forwarder-induced-SPF- break diagnostic reference; the propagation spoke is the TTL-bounded-publish- and-verify-cycle operator-discipline reference for safely executing the SPF record changes the forwarding-issues diagnostic ladder recommends.
• ARC headers explained — the canonical RFC 8617 deep dive on the Authenticated Received Chain. The modern preferred answer to forwarding- breaks-SPF and mailing-list-breaks- DKIM.
• Reverse DNS PTR records and FCrDNS — the FORWARDER-SECOND-HOP-IP-IDENTITY- VIA-PTR-LOOKUP investigation companion to this SPF-forwarding-issues diagnostic guide. Where THIS page documents the symptom-to-root-cause diagnostic ladder for the forwarder-induced SPF-fail pattern (envelope MAIL-FROM relayed by a forwarder no longer matches the forwarder's published SPF record at the receiver-side re-evaluation), the reverse-DNS-PTR spoke is the FORWARDER-IP-TO-FORWARDER-ORGANIZATION resolution reference that the receiver-side forwarding-chain debugger uses to pivot from a numeric second-hop egress IP into the forwarder organization's operator-readable identity. The FORWARDING-CHAIN- INVESTIGATION-REQUIRES-FORWARDER-IP-IDENTITY cross-reference establishes FOUR structurally-distinct forwarding-debug dimensions where PTR resolution is the load-bearing pivot: (i) forwarder organization identification at second-hop boundary — the SMTP Received: header chain captures the second-hop egress IP that broke SPF alignment (the envelope MAIL-FROM was the publisher's; the second-hop sender was the forwarder); PTR resolution of the second-hop IP yields the forwarder's organizational identity (Gmail forwarder → PTR resolves to mail-*.google.com; Outlook.com forwarder → PTR resolves to *.outlook.com; Mailman list mediator → PTR resolves to *.mailman.org or the list- operator's domain); the debugger uses this organizational identity to classify the forwarding scenario at the first decision-tree node; (ii) forwarder behaviour-catalog correlation via PTR — once the PTR-derived organization is known, the forwarder-behaviour catalog applies (Gmail forwarders rewrite envelope MAIL-FROM but preserve Subject:; MailMan list mediators rewrite Subject: with list-prefix but preserve envelope MAIL-FROM; Outlook.com forwarders rewrite via SRS to SRS0=... prefix). Each forwarder-organization has a known body / header / envelope-rewrite signature documented in the catalog; the PTR pivot is the prerequisite for selecting which catalog entry applies to the current forwarding-break diagnosis; (iii) forwarder-IP whitelisting decision input for deliverability allowlists — organizations operating legitimate inbound forwarders (corporate- gateway → on-prem-Exchange relay chains; mailing-list subscription routing through known list-operators) may PTR-validate the second-hop forwarder-IP as a deliverability-allowlist input: if the PTR resolves to an expected forwarder- organization AND the forward-confirmed- reverse-DNS (FCrDNS) is bidirectional, the receiver may allowlist the envelope-MAIL-FROM-broken-SPF case as a legitimate forwarding outcome rather than a deliverability-blocking SPF-fail; (iv) mailing-list-mediator vs malicious-relay disambiguation at PTR classification boundary — when SPF-fail surfaces from an unknown second-hop IP, PTR resolution disambiguates legitimate list-mediator from suspicious relay: PTR resolving to a known list- management vendor (listserv.com, mailman.org, GoogleGroups infrastructure) classifies the SPF-fail as a legitimate-mailing-list-rewrite case (recommend ARC or SRS remediation per THIS page); PTR resolving to a residential ISP, dynamic-IP block, or no-PTR-at-all classifies the SPF-fail as a potentially malicious-relay attack candidate (escalate to incident-response). Read the reverse-DNS-PTR spoke when the forwarding-issues diagnostic ladder reaches the "identify which forwarder broke SPF" decision node — the PTR-resolution pivot is the canonical next-step lookup that translates the second-hop numeric IP into the forwarder organizational identity the forwarder-behaviour-catalog indexes against.
• DKIM failures explained — the FORWARDER-REWRITE-DEFEATS-DKIM-BODY- HASH-FAILURE-MODE-CATALOGUE companion to this SPF-forwarding-issues reference. Where THIS page documents the SPF-side forwarder-induced authentication-break (the envelope-MAIL-FROM relayed by a forwarder no longer matches the forwarder's published SPF record, so SPF evaluates to fail at the second-hop receiver), the DKIM-failures- explained spoke documents the STRUCTURALLY-PARALLEL DKIM-side forwarder-induced authentication-break: the forwarder's MTA modifies the message body or header set in transit (mailing-list footer injection, subject-line tag prepending, Content-Type / charset rewriting, header re-folding / re-canonicalization, footer unsubscribe-link rewriting, anti-virus scanner banner injection, malware-scan tag injection, accessibility-banner injection), which invalidates the publisher's DKIM body-hash (RFC 6376 §3.4 bh= tag) or the publisher's DKIM signature-tag canonicalization (c=simple/simple vs c=relaxed/relaxed at signer side disagreeing with second-hop verifier's re-canonicalization). The DKIM-failure-mode catalogue enumerates the DKIM-side body-hash-mismatch failure-mode (RFC 6376 §3.7), alongside the OTHER DKIM failure modes structurally INDEPENDENT of the forwarder-rewrite class (signature-tag syntax invalidity at publisher-authoring time, header-list scoping omission at publisher-configuration time, public-key DNS-resolution failure at DNS- publication time, RSA-key-too-small at cryptographic-floor enforcement time at modern receivers), letting the operator DISTINGUISH the forwarder-induced body-hash-mismatch class (which ARC attestation per RFC 8617 RESCUES at receivers that trust the forwarder's ARC sealer) from the OTHER DKIM-fail classes which ARC structurally CANNOT rescue because they precede the forwarder-introduction point in the authentication chain. Pair this page (the SPF-forwarding-issues canonical reference) with the DKIM-failures-explained spoke (the DKIM-side failure-mode catalogue identifying the forwarder-induced body- hash-mismatch class) when diagnosing a DMARC-fail incident traceable to a forwarder hop — the symptom presents as DMARC-fail (the alignment-passing- disjunction at the second-hop receiver loses both SPF AND DKIM legs), and the operator must classify WHICH structural cause is producing each leg's failure (this page covers SPF-side; the DKIM-failures-explained spoke covers DKIM-side) before selecting the remediation (ARC trust-set adjustment for ARC-friendly forwarders, sender-rewriting scheme for ARC-ignorant forwarders, or publisher-side DKIM-signing-discipline hardening for the non-forwarder DKIM failure modes).
• DKIM canonicalization - the FORWARDER-AND-MAILING-LIST-SURVIVAL- AT-FOUR-c=ALGORITHM-CHOICE-VS-FORWARDER- REWRITE-PROFILE-COORDINATION-DIMENSIONS companion to this SPF-second-hop-forwarder- break diagnostic reference. Where THIS page documents the SPF-side forwarder-induced authentication-break (the envelope-MAIL- FROM relayed by a forwarder no longer matches the forwarder's published SPF record, so SPF evaluates to fail at the second-hop receiver), and where the sibling DKIM-failures-explained spoke catalogues the DKIM-side failure-mode taxonomy, the dedicated DKIM-canonicalization reference documents the STRUCTURALLY-LOAD-BEARING publisher-side c=header/body algorithm-pair-choice whose four coordination dimensions determine whether the publisher's DKIM signature survives the specific class of forwarder/MLM-induced message mutations producing the DKIM-body-hash-mismatch failure-mode this page's SPF-second-hop break diagnostic often co-presents with at the same DMARC- fail incident: (i) c=simple/simple is the cryptographically-strictest pair that treats ANY whitespace mutation / CR-LF normalization / header re-folding / body-byte modification at any intermediate MTA as signature-invalidating - it survives only the most pristine publisher-to-receiver paths and structurally breaks on essentially every MLM and most forwarders that perform ANY whitespace-normalisation transit processing; the DKIM-canonicalization spoke documents the simple-algorithm bit-exact contract and the operator- scenarios where the strict cryptographic guarantee is worth the deliverability penalty; (ii) c=relaxed/relaxed is the maximum-forwarder-survival pair that tolerates leading/trailing whitespace collapse, header field-name case-folding, and trailing empty-line normalisation at the verifier - it survives the broad class of MTA-incidental whitespace mutations that produce the dominant DKIM-fail-on- relayed-traffic root cause this page's SPF-second-hop scenarios co-present with; the DKIM-canonicalization spoke documents the relaxed-algorithm tolerance contract per RFC 6376 §3.4.2 (relaxed header) and §3.4.4 (relaxed body) and the deliverability-driven rationale for the relaxed-pair operator-default; (iii) even c=relaxed/relaxed does NOT survive substantive body modification - MLM footer injection, anti-virus banner injection, unsubscribe- link rewriting, Content-Type/charset rewriting, malware-scan tag injection ALL mutate the body bytes beyond the whitespace-normalisation tolerance scope and invalidate bh= regardless of c=-tag choice; the DKIM-canonicalization spoke documents the body-mutation-class taxonomy that exceeds even the relaxed-body algorithm's tolerance, identifying the forwarder-rewrite scenarios where neither canonicalization-pair choice can rescue the signature and the operator must instead pivot to RFC 8617 ARC attestation as the structurally-correct forwarder-trust-chain remediation; and (iv) the publisher's c=-tag algorithm-pair selection at signing time is a one-shot decision that cannot be adjusted per-message - the operator must choose UPFRONT whether the publisher's mail-stream profile prioritises forwarder/MLM survival (c=relaxed/relaxed - operator-default for general transactional/marketing/personal mail) or cryptographic strictness (c=simple/simple - appropriate ONLY when the mail-stream is confidently pristine-path-only and the signature integrity guarantee is operationally load-bearing); the DKIM-canonicalization spoke documents the operator-decision framework for choosing the c=-tag pair appropriate to each mail-stream's forwarder-exposure profile, closing the publisher-side signing-discipline gap this SPF- forwarding-issues page's DKIM-co-failure co-presentation makes operator-visible.
• DMARC alignment explained — identifier alignment (RFC 7489 §3.1, §6.6.2): strict vs relaxed, organisational domain, and how SPF result codes interact with DMARC alignment. Critical context for understanding what survives forwarding.
• DKIM alignment with DMARC — the FORWARDER-INDUCED-SPF-BREAK-VS- DKIM-ALIGNMENT-AS-OPERATIONAL-FALLBACK- LEG companion to this SPF second-hop forwarding-break diagnostic reference. Where THIS page documents the structural SPF second-hop break mechanism (the forwarder-MTA's MAIL-FROM rewrite OR forwarder-MTA-IP not being authorised by the original publisher's SPF record produces spf=fail at the receiving MTA regardless of any signed-message integrity), the DKIM-alignment-with- DMARC spoke documents the OPERATIONAL FALLBACK LEG that an SPF-broken forwarded message MUST satisfy to fire the DMARC-pass verdict's surviving-leg path: per-message d= signing-domain vs Header-From-domain strict-vs-relaxed alignment under the publisher's adkim= tag. Concretely a mailing-list forwarder that breaks SPF (List-MTA-rewrites- MAIL-FROM-to-list-domain OR List-MTA-IP-unauthorised-by-publisher- SPF) can ONLY survive DMARC via the DKIM-aligned-pass fallback IF the original-sender's DKIM signature survived the list's body-modification (which canonicalization mode the publisher chose, whether the list Subject-rewrites the message, whether the list appends a footer that mutates the body-hash), AND IF the d= signing-domain aligns with the Header-From-domain under the publisher's adkim= tag (strict requires byte- identical match; relaxed requires Organizational-Domain match per the PSL- anchored eTLD+1 algorithm). Without the DKIM-alignment-with-DMARC spoke a forwarder-incident operator reading THIS page recognises the symptom (RUA rows showing spf=fail dkim=pass disp=quarantine for forwarded messages), but lacks the per-mode evaluation-contract reference required to determine WHY a DKIM- surviving forwarded message ALSO fires DMARC-fail when the d= tag chosen by the publisher is byte-mismatched against the Header-From under strict-alignment — this link closes that forwarder- survival-vs-alignment-contract resolution gap at the operational-fallback-leg diagnostic layer.
• DMARC troubleshooting — the cross-cutting failure-diagnosis reference. SPF forwarding failures are among the canonical DMARC-fail root causes.
• DMARC for transactional email — the TRANSACTIONAL-ESP-OUTBOUND-STREAM- AS-LOAD-BEARING-TARGET-OF-RECIPIENT-MAILBOX- RULE-AUTO-FORWARDING-LOSS companion to this SPF-forwarding-issues reference. Where THIS page diagnoses the protocol-neutral SPF-fail- after-forwarding-relay root-cause catalogue across the seven canonical second-hop break scenarios (recipient-mailbox-rule auto- forward, server-side transport-rule redirect, distribution-group cascade- forwarding, mailing-list-mediator-relay, corporate-to-personal vacation forwarder, legitimate-forwarder relay, residential intermediary), the transactional-email deployment spoke documents the FOUR TRANSACTIONAL-CLASS-VS-FORWARDING-FAILURE- PATTERN dimensions whose per-class deliverability impact compounds the forwarding-second-hop SPF-break THIS page catalogues: (i) per-message OTP / MFA / password-reset transactional class as time-sensitive-delivery-target where forwarder-induced SPF-fail produces load-bearing user-experience harm — when a customer's OTP / MFA message is sent to a recipient who has a Gmail-side auto-forwarding rule to a corporate mailbox, the second-hop SPF-fail at the corporate receiver produces a spam-folder- relegation outcome at the very moment the user is trying to complete a sign-in flow — the operationally-binding deliverability harm this page's forwarder-second-hop SPF-break diagnostic ladder must enumerate distinctly for the transactional-message time-bounded delivery contract; (ii) per-customer-domain DKIM-CNAME- delegated signing as load-bearing operational fallback when the transactional ESP egress encounters forwarder-second-hop SPF-break — the per-customer d=<customer-domain> DKIM-Signature stamped at the transactional ESP signing boundary (SendGrid CNAME- delegated s1.domainkey.u123.wl. sendgrid.net, Mailgun mta._domainkey.mailgun.org, Amazon SES scph0825._domainkey.amazonses.com) survives the forwarder-second-hop SPF- break IF the per-customer DKIM signature survives the forwarder's body-canonicalisation (the dual-leg DMARC disjunction the forwarding-SPF-break operationally depends on for survival); (iii) per-ESP-managed bounce-domain configuration vs forwarder-induced envelope-rewriting interaction — transactional ESPs publish per-customer return-path bounce domains (bounce.<customer>.com delegated to ESP-managed MX/A records) so the per-message envelope-MAIL-FROM aligns with the customer's published SPF record — when the forwarder rewrites the envelope-MAIL-FROM, the ESP-managed bounce-domain attribution is lost at the second-hop receiver; THIS page's forwarder-induced envelope-rewriting diagnostic ladder must enumerate the ESP-managed-bounce-domain rewrite case distinctly for transactional ESP customers; and (iv) per-ESP outbound-IP-pool inheritance vs forwarder-IP-pool re-evaluation at the second-hop receiver — transactional ESPs egress through ESP-managed IP pools the per-customer SPF record authorises via include:<transactional-esp-pool> token; when the forwarder re-emits from a forwarder-managed IP pool (the forwarder- organization's MX-IP cohort) the second- hop receiver re-evaluates SPF against the forwarder's IP — NOT the original transactional ESP's IP — producing the canonical second-hop SPF-fail pattern this page diagnoses with the transactional- ESP-specific compounding factor that the operator's include:-cascade budget consumption gives them NO additional SPF-authorisation surface to publish the forwarder-IP-pool from. Read the transactional-email spoke alongside this SPF-forwarding-issues reference when a transactional customer's RUA stream reveals second-hop SPF-fail on time- sensitive OTP / MFA / password-reset messages and the per-customer DKIM-CNAME- delegated signing must be verified as the load-bearing operational-fallback leg of the DMARC disjunction the forwarder- induced SPF-break operationally depends on for survival.
• DMARC forensic reports (RUF / AFRF) — the SPF-FORWARDING-INDUCED-FAILURE-AS- PER-MESSAGE-RUF-AFRF-EVIDENCE-STREAM-FOR- FORWARDER-CHAIN-ATTRIBUTION companion to this SPF-forwarding-issues reference. Where THIS page diagnoses the SPF-fail- after-forwarding-relay root-cause catalogue (RFC 7208 §10.4 mailing-list-manager envelope rewrite / .forward / recipient- mailbox-rule auto-forwarding / Office-365- routed-rule-forward / corporate-gateway- forward / SRS-vs-non-SRS forwarder populations), the DMARC-forensic-reports (RUF) spoke documents the per-message AFRF envelope evidence-stream whose embedded message/rfc822 part preserves the EXACT bytes of the forwarder-rewritten envelope and Received: header chain the incident-response team parses to attribute the SPF-fail event to a specific forwarder-organization. The SPF-FORWARDING-INDUCED-FAILURE-AS- PER-MESSAGE-RUF-AFRF-EVIDENCE-STREAM-FOR- FORWARDER-CHAIN-ATTRIBUTION cross- reference establishes FOUR structurally- distinct forwarder-class-vs-AFRF-evidence- extraction dimensions: (i) mailing- list-manager-rewrite-vs-AFRF-embedded- message-rfc822-Received-header-chain- attribution dimension — MLM forwarders (Mailman, Sympa, ezmlm, listserv) rewrite the envelope-MAIL-FROM to the list's bounce-handling address per RFC 5321 §3.10 (envelope-author rewrite), and inject list-specific Received: headers + List-* MUA headers into the message; the per-message AFRF envelope's embedded message/rfc822 part preserves the EXACT post-MLM byte-shape the receiver-side SPF evaluator processed, enabling the operator's incident-response team to attribute the SPF-fail to a specific MLM-organization via the Received: header MLM-identity-signature catalogue; (ii) recipient-mailbox- rule-auto-forward-vs-AFRF-envelope-X- Original-Recipient-and-Sender-header- attribution dimension — recipient-side mailbox auto-forward rules (Gmail "Forwarding" feature, M365 Inbox Rule auto-forward, Outlook.com forwarding) rewrite the envelope-MAIL-FROM to the forwarding-mailbox's bounce address and inject X-Original-Recipient + X-Forwarded- For + Sender: headers per the receiver-side forwarding-source attribution convention; the per-message AFRF embedded message/rfc822 part preserves these forwarding-source-identification headers the SIRT correlates with the forwarding-tenant-account inventory to attribute the per-recipient SPF-fail to the specific auto-forward rule; (iii) SRS-rewriting-forwarder-vs-AFRF- envelope-SRS0-prefix-attribution dimension — Sender Rewriting Scheme-enabled forwarders (qmail-srs, postsrsd, Exim with SRS patch) rewrite the envelope-MAIL-FROM to a structured SRS0=<hash>=<timestamp>= <original-domain>=<original- local>@<forwarder-domain> form per the SRS specification, preserving the original sender via cryptographic encoding; the per-message AFRF embedded message/rfc822 part preserves the SRS-encoded envelope, enabling the operator's incident-response team to DECODE the original-sender attribution from the SRS prefix and reconstruct the pre-forward authentication chain; (iv) corporate-gateway-forward-vs-AFRF- Authentication-Results-pre-forward- verdict-preservation dimension — corporate gateways (Mimecast, Proofpoint, Barracuda, Cisco IronPort) inject an Authentication-Results header capturing the PRE-FORWARD authentication verdict before relaying the message; the per-message AFRF embedded message/rfc822 part preserves this pre-forward Authentication-Results header, enabling the operator's incident- response team to DIFFERENTIATE between "the original sender authenticated correctly but the corporate gateway forwarded" (legitimate forwarding scenario) vs "the original message was already a forgery and the corporate gateway propagated it" (attack scenario) — the AFRF Authentication-Results preservation is the LOAD-BEARING operational artifact the SIRT uses to classify the per-message forwarding- chain-failure event THIS page's diagnostic ladder produces. Read this RUF-forensic-reports spoke alongside THIS SPF-forwarding-issues reference when authoring the per-forwarder-class incident-response procedure that uses the AFRF evidence-stream as the forensic- grain artifact for attributing per- message SPF-forwarding-break events to the specific forwarder-organization whose forwarding-discipline operator- runbook this SPF-forwarding-issues page documents the per-class diagnostic ladder for.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the SPF-FORWARDING-AS-POLICY-MODE- FALSE-POSITIVE-VECTOR companion to this SPF-forwarding-issues reference. Where THIS page documents the forwarder-induced SPF-break (the envelope-MAIL-FROM relayed by a forwarder no longer matches the forwarder's published SPF record, so SPF evaluates to fail even when DKIM survives), the DMARC policy-modes spoke documents the publisher-side p=none / p=quarantine / p=reject tag whose enforcement decision is the OPERATIONAL CONSEQUENCE of the SPF-fail-after- forwarding-relay this page diagnoses — a publisher-side enforcement dimension structurally DOWNSTREAM of every forwarding-loss scenario this page documents because (i) under p=reject, an SPF-fail verdict against a legitimate forwarded message that ALSO suffered DKIM body-modification at the forwarder (the simple-canonicalization-incompatible relay class) produces immediate receiver-side rejection of the legitimate mail — the SPF-forwarding- issues page is the canonical root-cause reference for this false-positive class, (ii) under p=quarantine, the same SPF-fail-after-forwarding scenario produces inbox-spam-folder placement instead of outright rejection — the operationally-correct staging mode while the publisher works through the DKIM-rescue-path-or-ARC-rescue-path decision this page documents, (iii) under p=none, the forwarding-induced SPF-fail surfaces only as an aggregate-report observation (no enforcement) — the publisher's opportunity to audit forwarding-loss scenarios IN ADVANCE of escalating to p=quarantine or p=reject. Read the DMARC policy-modes spoke when escalating from per-forwarder SPF-break diagnosis into the publisher-side policy-mode strategic decision — particularly when the publisher's domain has a material mailing-list-relay footprint or a receiver-side auto-forwarding population that must be DKIM-rescued or ARC-rescued before any p=reject deployment can proceed without material false-positive rejections.
• DMARC record tags explained — every tag in the DMARC DNS record. Reference for the aspf= SPF alignment modifier (strict vs relaxed) which directly affects what survives forwarding.
• DMARC monitoring — operational reference for ongoing observability of SPF result codes in aggregate (RUA) reports. The recommended SPF result-code SLO budget accounts for legitimate forwarding traffic.
• DMARC aggregate (RUA) reports — the daily XML stream receivers send back. Per-record SPF result codes plus source-IP attribution are surfaced in the auth_results subtree — the primary forensic source for forwarding- prevalence analysis.
• DMARC for Google Workspace — provider-specific deployment guide. Google Workspace seals all forwarded messages with ARC since 2019; downstream receivers trust the chain.
• DMARC for Microsoft 365 — provider-specific deployment guide. Microsoft 365 transport rules support both SRS-style rewriting and ARC sealing for forwarded mail.
• MTA-STS for Microsoft 365 — the M365-TENANT-MTA-STS-AS-TRANSPORT- LAYER-FORWARDING-CHAIN-DEFENSE companion to this SPF-forwarding-issues diagnostic reference. Where THIS page documents the SPF-side forwarding-break-discovery surface (the canonical SRS / ARC / MUNGE / .forward catalogue and the forwarder-IP-republishing problem that breaks the original-domain SPF authority chain at the forwarder boundary), the MTA-STS-for-M365 spoke documents the STRUCTURALLY-ORTHOGONAL transport-layer defense the M365-tenant receiver enforces at the M365-side receive boundary at FOUR structurally-distinct forwarding-chain-vs- MTA-STS-enforcement dimensions: (i) forwarding-chain hop-by-hop MTA-STS- policy-fetch boundary vs SPF-chain hop-by- hop authority-republishing boundary — when a message traverses a multi-hop forwarding chain (original sender → forwarder1 → forwarder2 → M365 tenant receiver), the SPF-side authority breaks at forwarder1's outbound-IP-not-in-original- domain-SPF-record boundary (the problem this page diagnoses), but the MTA-STS-side enforcement is structurally per-hop: forwarder1 → forwarder2 fetches forwarder2's MTA-STS policy at its receive boundary, forwarder2 → M365-tenant fetches the M365-tenant MTA-STS policy at the M365 receive boundary; the SPF authority breaks ONCE at the original-domain boundary, the MTA-STS enforcement applies INDEPENDENTLY at EVERY hop in the chain; (ii) SRS- rewriting at forwarder1 vs MTA-STS STARTTLS-required enforcement at M365-side — the SRS / ARC / MUNGE mitigations on THIS page rewrite the envelope to make the SPF authority chain traceable through forwarding hops, but they do not address the structural transport- security gap that an attacker controlling an upstream router can STRIP STARTTLS between forwarder1 → forwarder2 → M365 receive boundary; the M365-side MTA-STS mode: enforce directive closes the StripTLS attack surface at the final receive hop independent of whether the forwarding chain uses SRS-rewriting, ARC sealing, or naive MUNGE; (iii) forwarding-prevalence-rate per- receiver-domain MTA-STS-policy-fetch-rate observability KPI pair — the per-M365-tenant observability surface for forwarding traffic is the joint per-tenant ratio of (a) forwarder-arriving-message rate (the prevalence-rate this page diagnoses via DMARC-RUA-aggregate analysis) AND (b) per-forwarder-source-IP MTA-STS- TLS-handshake-success-rate (the TLS-RPT- aggregate the M365-MTA-STS-spoke documents); when the forwarding-rate is high but the per-forwarder TLS-handshake-success-rate is low, the M365-tenant operator should prioritise either (a) requesting the forwarder's outbound MTA TLS configuration upgrade OR (b) escalating the M365 MTA-STS policy from mode: testing to mode: enforce to block the forwarder's StripTLS-vulnerable transport pathway; (iv) forwarder IP republishing in original-domain SPF vs forwarder MX inclusion in M365-MTA-STS allow-list — the forwarder-IP-republishing problem this page diagnoses cannot be closed by adding the forwarder IP to the original-domain SPF record (the SPF 10-lookup budget AND the cross-organisational-trust-boundary preclude this), but the M365-tenant MTA-STS policy file's mx: allow-list can include mx: *.mail.protection.outlook.com independent of which forwarder-IP relayed the message — the structural authorisation layers are orthogonal: original-domain SPF authorises sender-IP at the sender-side, M365-tenant MTA-STS authorises receive-MX- hostname at the receiver-side, and the cross-layer compositional logic absorbs the forwarder-IP transparency the SRS/ARC/MUNGE techniques on this page achieve via different mechanisms. Read the MTA-STS-for-M365 spoke when diagnosing forwarding-chain-related M365-tenant transport-layer-enforcement gaps — the MTA-STS-side enforcement complements the SPF-side mitigations documented on this page by closing the transport-layer attack surface that the SPF/SRS/ARC/MUNGE techniques structurally do not address.
• MTA-STS for Google Workspace — the WORKSPACE-TENANT-MTA-STS-AS- TRANSPORT-LAYER-FORWARDING-CHAIN-DEFENSE companion to this SPF-forwarding-issues diagnostic reference. Where THIS page documents the SPF-side forwarding-break- discovery surface (the canonical SRS / ARC / MUNGE / .forward catalogue and the forwarder-IP- republishing problem that breaks the original-domain SPF authority chain at the forwarder boundary), the MTA-STS- for-Google-Workspace spoke documents the STRUCTURALLY-ORTHOGONAL transport-layer defense the Workspace-tenant receiver enforces at the Workspace-side receive boundary at FOUR structurally-distinct forwarding-chain-vs-MTA-STS-enforcement dimensions: (i) forwarding-chain hop-by-hop MTA-STS-policy-fetch boundary vs SPF-chain hop-by-hop authority- republishing boundary — when a message traverses a multi-hop forwarding chain (original sender → forwarder1 → forwarder2 → Workspace tenant receiver), the SPF-side authority breaks at forwarder1's outbound-IP-not-in-original- domain-SPF-record boundary (the problem this page diagnoses), but the MTA-STS- side enforcement is structurally per-hop: forwarder1 → forwarder2 fetches forwarder2's MTA-STS policy at its receive boundary, forwarder2 → Workspace- tenant fetches the Workspace-tenant MTA-STS policy at the Workspace receive boundary; the SPF authority breaks ONCE at the original-domain boundary, the MTA-STS enforcement applies INDEPENDENTLY at EVERY hop in the chain; (ii) SRS-rewriting at forwarder1 vs MTA-STS STARTTLS-required enforcement at Workspace-side — the SRS / ARC / MUNGE mitigations on THIS page rewrite the envelope to make the SPF authority chain traceable through forwarding hops, but they do not address the structural transport-security gap that an attacker controlling an upstream router can STRIP STARTTLS between forwarder1 → forwarder2 → Workspace receive boundary; the Workspace-side MTA-STS mode: enforce directive closes the StripTLS attack surface at the final receive hop independent of whether the forwarding chain uses SRS-rewriting, ARC sealing, or naive MUNGE; (iii) forwarding-prevalence-rate per- receiver-domain MTA-STS-policy-fetch-rate observability KPI pair — the per-Workspace-tenant observability surface for forwarding traffic is the joint per- tenant ratio of (a) forwarder-arriving- message rate (the prevalence-rate this page diagnoses via DMARC-RUA-aggregate analysis) AND (b) per-forwarder-source-IP MTA-STS-TLS-handshake-success-rate (the TLS-RPT-aggregate the Workspace-MTA-STS- spoke documents); when the forwarding-rate is high but the per-forwarder TLS- handshake-success-rate is low, the Workspace-tenant operator should prioritise either (a) requesting the forwarder's outbound MTA TLS configuration upgrade OR (b) escalating the Workspace MTA-STS policy from mode: testing to mode: enforce to block the forwarder's StripTLS-vulnerable transport pathway; (iv) forwarder IP republishing in original-domain SPF vs forwarder MX inclusion in Workspace-MTA- STS allow-list — the forwarder- IP-republishing problem this page diagnoses cannot be closed by adding the forwarder IP to the original-domain SPF record (the SPF 10-lookup budget AND the cross-organisational-trust-boundary preclude this), but the Workspace-tenant MTA-STS policy file's mx: allow-list enumerates the five aspmx- tier hosts (aspmx.l.google.com + four altN.aspmx.l.google.com) independent of which forwarder-IP relayed the message — the structural authorisation layers are orthogonal: original-domain SPF authorises sender-IP at the sender-side, Workspace-tenant MTA-STS authorises receive-MX-hostname at the receiver-side, and the cross-layer compositional logic absorbs the forwarder- IP transparency the SRS/ARC/MUNGE techniques on this page achieve via different mechanisms. Read the MTA-STS- for-Google-Workspace spoke when diagnosing forwarding-chain-related Workspace-tenant transport-layer- enforcement gaps — the MTA-STS-side enforcement complements the SPF-side mitigations documented on this page by closing the transport-layer attack surface that the SPF/SRS/ARC/MUNGE techniques structurally do not address. Together with the parallel M365 MTA-STS spoke above, the two Workspace + M365 MTA-STS spokes form the CROSS-CLOUD ENTERPRISE-MAILBOX-PROVIDER FORWARDING- CHAIN TRANSPORT-LAYER-DEFENSE pair operators consult when SPF-forwarding- diagnostics span mixed-cloud recipient inventories.
• DMARC policy rollout playbook — the 6-month rollout playbook with Phase 1 (p=none monitoring) → Phase 2 (p=quarantine pct=10) → Phase 3 (p=quarantine pct=100) → Phase 4 (p=reject) timeline. Every phase transition depends on forwarding traffic being handled by ARC.
• How attackers bypass DMARC — the threat-side perspective. Lookup of forwarding-related bypass patterns and why SRS / ARC do NOT introduce new attack surface compared with no-DMARC mail.
• Email authentication ecosystem (SPF, DKIM, DMARC, ARC, BIMI) — the cluster-intro pillar tying all five-layer authentication standards together.
• Email authentication glossary — defines SRS, ARC, MAIL FROM, From: header, Authentication-Results, and the rest of the protocol vocabulary this page assumes.
• Why SPF alone is insufficient — the CANONICAL-FORWARDING-AS-LOAD-BEARING- EVIDENCE-OF-SPF-PROTOCOL-INSUFFICIENCY companion to this SPF-forwarding deep dive. Where THIS page enumerates the per- forwarding-vector pathologies (vanity-domain forwarding via SRS, mailing-list bounce- address rewriting, .forward / sieve / Gmail- side filter rules, university / association / community-managed forwarder relay paths, ARC-as-relay-survival-mechanism, the SRS / MAIL-FROM-rewriting interaction with SPF check_host() evaluation at the receiving MTA, the seven distinct SPF- permerror diagnostic signatures and their forwarding-vs-publisher-fault attribution), the why-SPF-alone-is-insufficient spoke is the BROADER STRUCTURAL ARGUMENT companion documenting why FORWARDING is just ONE of seven distinct STRUCTURAL CLASSES of SPF- insufficiency: (i) forwarding- rewrites-the-envelope-MAIL-FROM (this page's focus — the receiving MTA's SPF check_host() evaluates against the forwarder's IP authorized by the FORWARDER's SPF record, not the original publisher's SPF, breaking SPF alignment at every legitimate forwarding hop); (ii) shared-hosting-multi-tenant-IP- cohort-as-publisher-identity where many customer domains egress mail from the same shared-hosting IP making SPF a poor publisher-identifier; (iii) MAIL-FROM-vs-From-header- asymmetry where SPF authenticates the envelope MAIL FROM while DMARC evaluates alignment against the From: header (these can be DIFFERENT domains — SPF-aligned-pass on the envelope domain does not establish that the From: header domain authorized the sending); (iv) cloud-provider-IP-rotation where AWS / GCP / Azure rotate IP assignments to customers on cancellation / re-provisioning timescales, leaving stale SPF authorizations pointing at IPs now allocated to attackers; (v) the 10-DNS-lookup-budget cap (RFC 7208 §4.6.4) collapsing the entire SPF check to permerror when adding a single new third-party SaaS-vendor include: pushes a marginally-under- budget record permanently over the cap; (vi) SPF has NO message-content- integrity guarantee — the SPF check authenticates only that the connecting IP is on a publisher- authorized list, it does NOT authenticate the message bytes (anyone with access to the publisher-authorized IP can send arbitrary forged-content messages); (vii) SPF has NO publication-private- key concept — every check passes based on PUBLIC-only DNS data that any on-path attacker can read, breaking the confidentiality of the publisher's outbound-IP topology in ways DKIM's per-message signature does not. Read the why-SPF-alone-is-insufficient pillar when authoring the operational argument for DEPLOYING DKIM-alignment-with-DMARC alongside SPF — forwarding is the most- operationally-visible SPF-insufficiency proof point, but the broader STRUCTURAL argument that SPF cannot be the SOLE publisher-authentication mechanism is what gates the policy-rollout sequence from p=none through p=quarantine to p=reject.
• DKIM troubleshooting — the FORWARDER-INDUCED-DKIM-RESCUE- PATH-PER-MESSAGE-DKIM-VERDICT-SYMPTOM- DRIVEN-ROOT-CAUSE-ATTRIBUTION companion to this SPF-forwarding-issues protocol diagnostic. Where THIS page documents the SECOND-HOP-BREAK forwarding-failure mechanic AND its DKIM-rescue-mechanism recovery path (envelope-MAIL-FROM-IP- changes-at-forwarder breaks SPF alignment at the second hop, the DKIM-signed-message-survives-forwarder path delivers dkim=aligned-pass at the second-hop receiver and rescues the DMARC verdict, the ARC-trust- anchoring path covers the residual cases where DKIM also breaks), the DKIM- troubleshooting spoke is the SYMPTOM- DRIVEN PER-MESSAGE DIAGNOSTIC companion documenting the operator-facing symptom-to-action sequence run AGAINST the per-message Authentication-Results stamp WHEN the DKIM-rescue path THIS page promotes as the recovery mechanism instead delivers a dkim=fail / dkim=permerror / dkim=none verdict at the second-hop receiver. Concretely, the spoke documents FOUR forwarder-second- hop DKIM-rescue-failure dimensions: (i) forwarder-induced canonicalization mangle producing dkim=fail body-hash- mismatch at the second-hop receiver symptom — when the forwarder rewrites quoted-printable body parts, folds long header lines, or rewrites Subject:/From: header bytes in transit, the troubleshooting page's c=relaxed/relaxed vs c=simple/simple canonicalization symptom-axis pins the body-hash-mismatch verdict to the forwarder rather than to the original signer — the DKIM-rescue path THIS page documents cannot recover from a canonicalization mangle without ARC; (ii) mailing-list-intermediary Subject: [list-name] rewriting producing dkim=fail header-hash- mismatch symptom — when the mailing-list intermediary THIS page documents as a canonical forwarder class rewrites the Subject: header to prepend a list-identifier tag, the troubleshooting page's identify-which-headers-were-signed diagnostic step matches the h=-tag header inventory against the receiver-fetched message bytes and pins the header-hash-mismatch root cause to the list-intermediary's Subject:-rewrite policy; (iii) vacation-forwarder / corporate- to-personal forwarder dkim=permerror NXDOMAIN symptom from per-receiver positive- cache miss against an operator-rotated selector — when the publisher has rotated DKIM selectors in the per-receiver positive-cache window between the original message-send time and the forwarder's second-hop delivery attempt, the troubleshooting page's canonical dig TXT <selector>._domainkey.<d-domain> symptom-to-action walk from multiple geographic resolvers pins the stale- selector root cause; (iv) multi- hop forwarder chain dkim=none symptom from intermediate-relay DKIM-signature-strip policy — when an intermediate forwarder in the multi-hop chain THIS page documents strips the original DKIM-Signature header per a local anti-spam policy, the troubleshooting page's Authentication-Results header-chain reconstruction step identifies the WHICH-INTERMEDIATE-HOP- STRIPPED-DKIM diagnostic outcome and names the per-hop ARC-trust-anchoring fallback path as the SOLE residual recovery mechanism. Read the DKIM- troubleshooting symptom-driven playbook AFTER consulting THIS SPF-forwarding- issues protocol diagnostic to attribute every per-message DKIM-rescue-path failure verdict at the second-hop receiver to the specific forwarder- boundary-induced root cause responsible.
• Email Header Analyzer — paste a raw email header and the tool surfaces the Authentication- Results verdict including the specific SPF result code, the ARC chain status, and the per-hop Received: header chain. The forensic detection workflow from §7 in tool form.
• DKIM-Signature header tag anatomy — the LOAD-BEARING per-message cryptographic-survival companion to this SPF-forwarding-failure catalogue. Where THIS page documents the per-forwarder envelope-rewrite cascade (SRS / .forward / mailing-list-manager re-emission / corporate-gateway rewrite) that COLLAPSES per-message SPF-aligned-pass at the second hop — the DKIM-Signature-header anatomy reference documents the per-message DKIM cryptographic-signature header whose SURVIVAL across the same forwarder hop determines whether the DMARC verdict salvages dkim=pass + aligned=true when SPF collapses. The c= canonicalization tag choice (simple/simple vs relaxed/relaxed), the h= signed-header-list, and the (optional but dangerous) l= body-length-limit tag documented in the anatomy reference are EXACTLY the per-message cryptographic-discipline knobs that determine per-forwarder-hop DKIM survival rate — operators auditing forwarding-induced SPF-failure aggregate-report rows MUST cross- reference the per-message DKIM- Signature header anatomy to confirm the DKIM-side second-leg fallback survives the same forwarder hop the SPF-side first-leg breaks at.
• Email deliverability — the FORWARDER-INDUCED-SPF-FAILURE-AS- LOAD-BEARING-UPSTREAM-CAUSE-OF-PER- PUBLISHER-PER-MAILBOX-PROVIDER-PER- FORWARDED-MESSAGE-DELIVERABILITY- BASELINE-DEGRADATION companion reference. Where THIS page documents the forwarder- induced SPF-failure mechanism (the per- forwarder-hop intermediate-MTA-relayed message whose 5321.MailFrom envelope- sender identity at receipt-at-final- recipient is the original publisher's MailFrom but whose final-hop sending-IP is the forwarder's IP rather than the publisher's authorized SPF inventory, producing per-message receiver-side spf=fail verdict on the per-forwarded- message path), the email-deliverability spoke documents the per-publisher per- mailbox-provider per-day per-forwarded- message deliverability-baseline degradation outcome (the per-publisher per-receiver-mailbox-provider per-day per-forwarded-message Gmail-inbox-vs- spam-vs-bounce delivery-placement-rate aggregate signal degradation), across four per-forwarder-induced-SPF-failure- to-per-publisher-per-mailbox-provider- per-forwarded-message-deliverability- baseline-degradation-coupling dimensions: (i) per-forwarder-hop-spf-fail- verdict-as-load-bearing-upstream-cause- of-per-message-DMARC-fail-at-final- receiver — the per-forwarder- hop spf=fail verdict at the per- forwarded-message receiver-side cascades into per-message DMARC-fail verdict (since DMARC requires identifier-alignment-PASS on at least ONE of SPF-aligned or DKIM-aligned; per-forwarder-hop SPF-fail collapses the SPF-aligned axis); per-message DMARC-fail verdict at receivers honoring the per-publisher DMARC TXT record p=quarantine / p=reject tag-value enforcement directly degrades the per-publisher per-mailbox-provider per-forwarded-message delivery- placement-rate; (ii) per- forwarder-induced-SPF-failure- prevalence-as-load-bearing-input-to- per-publisher-per-mailbox-provider- per-forwarder-path-deliverability- baseline — per-publisher per- mailbox-provider per-day per-forwarder- path deliverability baseline floors on the per-forwarder-path proportion of per-publisher per-forwarded-messages producing per-message DKIM-aligned-pass verdict (DKIM-side second-leg fallback survival rate); per-forwarder-induced- SPF-failure prevalence with DKIM-side second-leg fallback survival rate collapse (forwarder body-modification, forwarder header-modification, per- publisher per-selector key-rotation defects, per-forwarder ARC-signing gaps) cascades to per-publisher per- mailbox-provider per-forwarder-path delivery-placement-rate degradation; (iii) per-publisher-per- forwarder-path-deliverability- regression-as-canonical-forwarder- induced-spf-failure-diagnostic- signal — per-publisher per-day per-mailbox-provider per-forwarder- path deliverability-baseline regressions correlated against per- forwarder-path SPF-failure rate baseline shifts are canonical forwarder-induced SPF-failure diagnostic signals; the per-publisher operator diagnosing per-publisher per- mailbox-provider per-forwarded-message deliverability-baseline degradation MUST correlate the regression window against per-forwarder-path SPF-failure rate baseline shifts to attribute per-publisher per-mailbox-provider per-forwarded-message deliverability degradation to forwarder-induced-SPF- failure root cause vs non-forwarder- path root causes; (iv) per- forwarder-path-allowlist-coordination- as-load-bearing-remediation-action- for-per-publisher-per-mailbox- provider-per-forwarded-message- deliverability-baseline-restoration — per-publisher per-forwarder-path allowlist coordination remediation actions (the canonical SRS / ARC / per-forwarder-path SPF authorization update / per-forwarder-path DKIM- second-leg-fallback strengthening remediation classes) directly restore the per-publisher per-mailbox-provider per-forwarded-message deliverability baseline; per-publisher operators implementing per-forwarder-path allowlist coordination remediation MUST instrument per-publisher per- mailbox-provider per-forwarder-path per-day delivery-placement-rate signals BEFORE AND AFTER each remediation action to validate per-publisher per- mailbox-provider per-forwarded-message deliverability-baseline restoration. Read this WITH the forwarder-induced SPF-failure mechanism reference when the per-publisher per-mailbox-provider per-forwarded-message deliverability- baseline degradation diagnostic sequence reaches the operator's queue: THIS page documents the forwarder- induced SPF-failure mechanism, the email-deliverability spoke documents the per-publisher per-mailbox-provider per-forwarded-message deliverability- baseline degradation outcome whose delivery-placement-rate floor is STRUCTURALLY DEGRADED by the forwarder-induced SPF-failure mechanism THIS page documents.
• DMARC for shared hosting — the PER-TENANT-SHARED-OUTBOUND- RELAY-ENVELOPE-MAIL-FROM-REWRITE- CASCADE companion to this forwarder- induced SPF-failure operator reference. Where THIS page documents the canonical forwarder-induced SPF-failure mechanism catalogue (per-hop envelope-MailFrom rewrite producing post-rewrite spf=fail, SRS-rewrite receiver-side acceptance variance, ARC-rescue per-receiver implementation variance, per-mailbox-provider per- forwarder-path delivery-placement-rate degradation), the shared-hosting spoke is the per-tenant-deployment-execution companion documenting FOUR shared- hosting-SPF-forwarding coordination dimensions whose per-tenant satisfaction gates whether the forwarder-induced SPF- failure modes THIS page documents manifest at the shared-outbound-relay boundary: (i) per-tenant shared- outbound-relay-MTA-IP-reuse is the canonical per-provider SPF-include-chain- prerequisite — Plesk's auto- configured Postfix, DirectAdmin's Exim, ISPConfig's Postfix, Webmin / Virtualmin's Postfix, and CWP's Postfix each provision a shared outbound IP whose IP-reuse across tenants requires every per-tenant SPF record to include the provider's shared-relay include-target (or directly reference the shared IP); the shared-hosting spoke documents the per-panel include-chain authoring discipline that determines whether the per-tenant SPF leg can ever survive the forwarder-induced rewrite at the shared relay boundary; (ii) per- tenant envelope-MailFrom rewrite at the shared outbound relay can BOTH cause AND mitigate forwarder-induced SPF-failure — when the shared- relay rewrites the envelope-MailFrom to the provider's bounce-handling address (Plesk's bounce-detector pattern), post-rewrite spf=pass verdicts succeed against the provider's SPF record but BREAK DMARC SPF-alignment (the spf=-aligned leg of the RFC 7489 §6.6.2 OR-conjunction requires post-rewrite envelope-MailFrom- domain FQDN-equal to the per-tenant RFC 5322 From-domain), making DKIM alignment the sole load-bearing DMARC- pass path for per-tenant traffic through the shared relay; the shared- hosting spoke documents the per-panel per-tenant rewrite policy and the DKIM-alignment-as-load-bearing-leg remediation discipline; (iii) per- tenant per-mailbox-provider per- shared-relay-IP-reputation degradation amplifies forwarder-induced SPF- failure deliverability impact — when one tenant on the shared outbound IP triggers per-mailbox- provider deliverability-baseline degradation (spam complaints, content- filter hits), the per-IP reputation degrades for ALL tenants sharing the per-provider outbound relay, amplifying the per-mailbox-provider per-forwarder- path deliverability impact this page catalogues; the shared-hosting spoke documents the per-panel per-tenant IP-reputation isolation discipline; (iv) per- tenant ARC-rescue per-receiver acceptance variance is bounded by the per-provider per-shared-relay ARC- signing posture — when a per- tenant message traverses Gmail's per-message ARC chain after the shared outbound relay's rewrite, the receiver's per-tenant ARC-rescue outcome is gated by whether the shared-relay-MTA participated as an ARC-signer earlier in the chain; the shared-hosting spoke documents the per-panel per-tenant ARC-signer configuration discipline. Read the shared-hosting spoke ALONGSIDE this SPF-forwarding-issues reference whenever the operator scopes the per-tenant forwarding-failure remediation discipline on Plesk / DirectAdmin / ISPConfig / Webmin- Virtualmin / CWP — the forwarder- induced SPF-failure mechanism THIS page catalogues IS the per-tenant per-message authentication degradation primitive the shared-hosting deployment guide encodes the per- provider per-tenant mitigation execution discipline for.
• Domain Security Checker — verifies your own domains SPF record live from DNS, counts lookups, validates syntax, and flags any of the seven permerror cause classes before they affect production deliverability.
• DNS Record Generator — generates publish-ready SPF, DKIM, and DMARC records for your domain. Built with the forwarding-friendly patterns documented on this page.
• DKIM best practices — the PER-PUBLISHER-DKIM-SIGNING-DISCIPLINE- GREEN-STATE-BASELINE-AS-LOAD-BEARING-SURVIVING- DMARC-LEG-DISCIPLINE companion to this SPF- forwarding-failure operator reference. Where THIS page documents the per-forwarder-hop SPF- leg-failure pattern (the forwarder's envelope- client-IP is not in the publisher's SPF mechanism set, so the per-receiver SPF check produces spf=fail for legitimate forwarded mail), the DKIM-best-practices spoke is the LOAD-BEARING SURVIVING-LEG DISCIPLINE reference documenting the per-publisher per-selector + per-message + per-canonicalization- mode + per-rotation-cadence DKIM-signing baseline whose continuous adherence ensures the DKIM leg survives the forwarder hop and contributes the load-bearing dmarc=pass verdict via the RFC 7489 §6.6.2 OR- conjunction. The SPF-FORWARDING-FAILURE-VS- DKIM-SURVIVING-LEG cross-reference establishes FOUR structurally-distinct per-forwarder-hop per-publisher DKIM-survival-coupling dimensions: (i) the DKIM body-hash canonicalization-mode choice (simple vs relaxed) determines whether forwarder body- rewriting middleboxes (footer-injection, content-transformation, list-server expansion) invalidate the DKIM body-hash — the DKIM-best- practices spoke documents the per-mail-class canonicalization-mode-selection rule (relaxed/ relaxed for marketing, simple/simple for transactional) that determines DKIM survival through forwarder body modifications; (ii) the DKIM signed-headers set choice determines whether forwarder header-rewriting (Subject-line prefix injection, X-* header addition, Received-header insertion) preserves DKIM signature validity — the DKIM-best- practices spoke documents the minimal signed- headers set (From, Subject, Date, Message-ID, To) whose continued cryptographic validity through the forwarder-hop is the DKIM-survival precondition; (iii) the DKIM per-selector key-rotation cadence interacts with forwarder delivery latency — long-tail forwarder-delayed mail (mail forwarded hours or days after origination) requires the per- publisher per-selector retention window the DKIM-best-practices spoke documents (≥7 days post-rotation) so the DKIM verification at the delayed-delivery boundary still finds the per-publisher signing key published; (iv) the per-publisher per-third-party- sender DKIM-re-signing-with-publisher-d-tag pattern (vs the per-third-party-sender per- own-d-tag pattern) determines whether SaaS- relayed mail forwarded through a downstream forwarder preserves the per-publisher-d-tag- aligned DKIM verdict — the DKIM-best-practices spoke documents the per-publisher per-SaaS- sender DKIM-re-signing-with-publisher-d-tag configuration that makes the multi-hop SaaS-then-forwarder path DMARC-pass-survivable via the DKIM-aligned leg. Read the DKIM-best-practices spoke alongside this SPF- forwarding-failure reference when designing a per-publisher per-domain DMARC ramp-step progression plan so the operator's per- forwarder-population coverage assumption accounts for the DKIM-leg survival discipline that bridges the SPF-leg-failure gap this page documents at every forwarder hop where the SPF leg cannot contribute.
• DMARC for cPanel / WHM shared-hosting deployments — the per-cPanel-account per-customer- domain DMARC publication workflow at the WHM Email Deliverability auto-generation flow, the cPanel DNS Zone Editor publication boundary, and the per-cPanel- server shared-outbound-MTA IP block baseline whose per-account egress IPs receive aggregate-XML rows attributed to the cPanel server's shared IP pool. When a cPanel-hosted publisher's mail traverses a per-mailbox cPanel Forwarders-feature alias (Forwarders / Email Routing → forward-to-external- address) the canonical SPF-forwarding- break this page documents fires at the forwarder hop because the cPanel server's outbound IP is not in the forwarded-domain's SPF record — read THIS forwarding-failure reference alongside the cPanel deployment guide when designing per-cPanel-account Forwarders-feature operational discipline so the per-account per-recipient deliverability outcome accounts for the SPF-leg-failure profile this page documents at the per-cPanel-Forwarders- feature alias hop.
• Email spoofing explained — the per-message forwarder-induced SPF-fail-vs-spoofing attribution discipline companion to this SPF forwarding-issues operator-reference. Where THIS page documents the per- message FORWARDER-INDUCED-ENVELOPE- MAIL-FROM-IP-REWRITE second-hop SPF- break diagnostic (the recipient-side auto-forwarder pattern, the mailing- list intermediary body-mutation footprint, the vacation-forwarder + corporate-to-personal pattern, the DKIM-rescue + ARC-trust-anchoring rescue paths), the email-spoofing spoke is the PER-ATTACK-CLASS REFERENCE documenting the per-publisher per-domain attack-surface catalogue whose per-attack-class defender-side mitigation discipline the per-publisher per-domain operator MUST apply to distinguish per-row spf=fail attribution between (i) legitimate per-message forwarder-induced envelope-MAIL-FROM- IP-rewrite (the auto-forwarder attribution pattern THIS page documents), (ii) genuine per-message From-domain- spoofing attack (the canonical attacker pattern the email-spoofing spoke documents), (iii) per-attacker lookalike-domain registration vector (the per-publisher per-portfolio perimeter attack-class), and (iv) per- attacker subdomain-spoofing vector (the per-publisher per-organizational-domain per-subdomain attack-class). Pair this page (the per-message forwarder-induced second-hop SPF-break diagnostic reference) with the email-spoofing spoke (the per-attack-class catalogue reference) when designing the per- publisher per-domain per-message spf= fail attribution-discipline rule-set — the spoke documents the per-attack- class anti-spoofing-mitigation catalogue that is the operationally- grounded per-message spf=fail-vs- spoofing attribution feedback channel.
• DKIM key rotation — the DKIM-AS-SURVIVING-AUTHENTICATION- LEG companion to this per-message forwarder-induced second-hop SPF-break diagnostic reference. Where THIS page documents the per-message forwarder-induced envelope-MAIL-FROM rewrite that breaks RFC 7208 SPF authentication at the second-hop receiver (the connecting-MTA-IP at the receiver is the forwarder's relay-MTA, NOT the original sender's outbound MTA — so the SPF envelope-IP-against-publisher-record evaluation produces spf=fail or spf=softfail against the original publisher's record despite the message being legitimate end-to- end), the DKIM key rotation spoke is the SURVIVING-AUTHENTICATION-LEG companion documenting the per-selector key-publication lifecycle discipline that keeps the DKIM signature — the ONLY authentication leg that survives forwarder rewrites — cryptographically valid across the forwarder hop. DKIM signatures per RFC 6376 §3 are bound to the MESSAGE content (header + body canonicalised per the c=-tag) and the per-selector <selector>._domainkey.< d-domain> TXT-RR — they are INDEPENDENT of the SMTP envelope and the connecting-MTA-IP, so they SURVIVE the forwarder hop that breaks SPF. The DMARC p=quarantine / p=reject verdict for a forwarded message therefore reduces to the DKIM verdict alone (SPF having already failed by definition at the second-hop receiver) — and the DKIM verdict's reliability across forwarded mail depends ENTIRELY on the per-selector key-publication lifecycle discipline the DKIM key rotation spoke documents. (i) A per-selector key rotated mid-flight on the original publisher's DNS WHILE forwarded copies are still in transit (e.g., a mailing-list-manager queue, an Exchange-routed forward, a per-user .forward retransmission) WITHOUT the dual-selector overlap window the rotation spoke documents cascades into per-message dkim=permerror / dkim=fail at the forwarded-mail receiver — which cascades into per-message dmarc=fail at the forwarded-mail receiver (since SPF is broken by the forwarder hop, the only DMARC-pass-eligible leg is the DKIM verdict) — which cascades into per-message quarantine-or-reject of legitimate forwarded mail; (ii) a per-selector key compromised on the original publisher's signing infrastructure that is NOT emergency-revoked per the empty- p=-tag discipline the rotation spoke documents enables an attacker to forge legitimate- looking DKIM signatures that pass the receiver-side verification on forwarded mail — bypassing the per-publisher per-domain DMARC verdict despite the SPF leg being forwarder-broken. Read THIS page when DIAGNOSING per-message forwarder-induced second-hop SPF- break verdicts; read the DKIM key rotation spoke when AUTHORING the per-selector key-publication lifecycle discipline whose stability across the forwarder hop the per- message DMARC-verdict surface THIS page diagnoses depends on as the SOLE surviving authentication leg.
• MX records — the per-forwarder per-MX-host ROUTING- TOPOLOGY companion to this per-message forwarder-induced second-hop SPF-break diagnostic. Where THIS page documents the per-message forwarder-induced second-hop SPF-break failure-mode catalogue — per- forwarder-hop envelope-from rewrite (SRS) / non-rewrite behaviour, per-forwarder- hop per-receiver per-message SPF-verdict attribution against the per-forwarder- hop SMTP-emitter IP, the per-forwarder- hop class taxonomy (.forward forwarders, Sieve forwarders, mailing-list managers, per-recipient redirect rules), DMARC's SPF-alignment-fails-DKIM-alignment-passes rescue path on forwarder hops — the MX- records spoke documents the per-publisher per-domain mail-exchanger-host routing topology that determines the per-message first-hop → forwarder-hop transit path the second-hop SPF-break failure-mode attributes against. The composition operates through three per-publisher per- domain MX-records-and-SPF-forwarder dependencies the per-message DMARC- verdict-rescue path materially relies on: (i) per-publisher per-domain MX-record- published first-hop per-receiver-MX-host priority determines which per-receiver- MX-host receives the per-message envelope first and therefore which per-receiver- MX-host's per-recipient forwarder-rule chain (Exchange Online inbound rules, Google Workspace forwarder rules, Postfix .forward / Sieve scripts) emits the per-message second-hop SMTP delivery the SPF-break failure mode attributes against; (ii) per-forwarder SMTP-emitter MX-record (the forwarder-as- sender's own MX record advertising the forwarder's outbound-MTA-bound inbound rate-limit-and-bounce-handling surface) determines the per-second-hop per- receiver per-message reverse-path bounce- delivery target when the second-hop SPF rejection produces a per-message NDR; (iii) per-publisher per-domain MX-record- published per-receiver-MX-host forwarder-rule emission characteristics (whether the per-receiver-MX-host vendor rewrites envelope-from per RFC 7489 §6.7, emits ARC-AAR / AMS / AS chain headers per RFC 8617, or transparently relays the original SMTP envelope) determines the per-message DMARC-verdict-rescue path between the per-publisher per- domain SPF-verdict-fail-on-forwarder- emitter and the per-message DMARC- verdict-pass via DKIM-alignment-survival through the forwarder hop. Read THIS page when DIAGNOSING per-message forwarder- induced second-hop SPF-break verdicts; read the MX-records spoke when MAPPING the per-publisher per-domain MX-record- published first-hop per-receiver-MX-host routing topology that gates which per- forwarder-rule chain emits the per- message second-hop SMTP delivery whose per-emitter-IP SPF-verdict the per- message DMARC verdict surface this page diagnoses materially attributes against.
• DMARC myths and misconceptions — the FORWARDING-INDUCED-MYTH-DEBUNK- COMPANION to this forwarder-rewrite diagnosis reference. Where THIS page documents the per-publisher per-domain per-forwarder per-receiver envelope-MAIL- FROM-rewrite mechanics (forwarder removes the per-publisher per-domain ip4 / include per-mechanism-token authorisation by rewriting envelope MAIL FROM to the forwarder's bounce subdomain, breaking the per-receiver per-message SPF-aligned-pass verdict the per-publisher per-domain DMARC evaluation per RFC 7489 §6.6.2 alignment- verdict-resolution materially depends on) and the per-message DKIM-alignment-survival rescue path (forwarder preserves the DKIM-Signature body-hash through ARC-AAR / AMS / AS chain emission per RFC 8617 chain-of-custody preservation, allowing the per-message DKIM-aligned-pass verdict to compensate for the broken per-message SPF-aligned-pass verdict the envelope- rewrite forwarder hop produces), the myths-and-misconceptions spoke is the MISCONCEPTION-CATALOGUE companion documenting FOUR forwarding-induced myth classes whose per-publisher per-domain DMARC-deployment-discipline mental-model REBUTTAL is the PREREQUISITE the per- publisher per-domain operator MUST INTERNALISE before reading the per-message receiver-side DMARC-aligned-fail verdict this page diagnoses: (i) myth 11 — "Deploying DMARC will break my mailing lists" — the per-publisher per- domain operator-side misconception that DMARC enforcement (per RFC 7489 §6.7 p=quarantine / p=reject) is the per-message verdict-rejection PROXIMATE CAUSE of forwarded-mailing-list message rejection — when the LITERAL PROTOCOL ROOT CAUSE is the per-mailing-list-forwarder envelope-MAIL-FROM-rewrite-induced per- receiver per-message SPF-aligned-pass verdict break THIS page diagnoses; the myth-11 rebuttal documents the per- publisher per-domain DKIM-alignment- survival rescue path (per RFC 8617 ARC-AAR / AMS / AS chain emission) as the STRUCTURAL per-message DMARC-verdict- rescue mechanism whose per-mailing-list- forwarder per-receiver per-message DKIM-aligned-pass verdict compensates for the envelope-rewrite-induced per-message SPF-aligned-pass verdict break; (ii) myth 3 — "I have SPF and DKIM so I do not need DMARC" — the per- publisher per-domain operator-side misconception that per-publisher per- domain SPF + DKIM publication-discipline ALONE produces the per-receiver per- message envelope-MAIL-FROM-vs-header- From-domain ALIGNMENT verdict that the per-receiver per-message DMARC evaluation per RFC 7489 §3.1 identifier-alignment materially depends on — when the per- forwarder envelope-MAIL-FROM-rewrite hop THIS page documents demonstrates exactly why SPF-pass-on-the-bounce-subdomain alone produces SPF-aligned-FAIL at the per- publisher per-domain organisational- domain-level the per-receiver per-message DMARC verdict requires; (iii) myth 7 — "Going straight to p=reject is fine if my records look right" — the per-publisher per-domain operator-side misconception that per-publisher per- domain SPF + DKIM + DMARC record- publication SYNTACTIC-CORRECTNESS ALONE is sufficient to declare per-publisher per-domain DMARC-enforcement readiness — when the per-publisher per-domain forwarder-traffic-pattern inventory THIS page documents demonstrates that per- publisher per-domain operator MUST first publish at p=none to observe the per-message per-receiver per- forwarder DKIM-alignment-survival rescue- path completeness across the per- publisher per-domain per-forwarder traffic footprint BEFORE ramping to p=quarantine / p=reject enforcement; and (iv) myth 15 — "DMARC failures always mean an attacker" — the per-publisher per-domain operator-side misconception that every per-receiver per-message DMARC-aligned-fail verdict in the per-publisher per-domain RUA aggregate report points at a per- publisher per-domain phishing attacker — when the per-publisher per-domain per- forwarder per-receiver envelope-MAIL- FROM-rewrite-induced per-message SPF- aligned-FAIL verdict THIS page documents is the LITERAL most common per-publisher per-domain DMARC-aligned-fail verdict class in the per-publisher per-domain RUA stream. Pair this SPF-forwarding- issues reference with the myths-and- misconceptions spoke when explaining the per-publisher per-domain forwarder- induced per-message DMARC-aligned-fail verdict class to a stakeholder who has internalised one or more of the four myth classes above — the myths-page documents the PER-MISCONCEPTION-CLASS REBUTTAL-DISCIPLINE the per-publisher per-domain operator MUST DEPLOY at the stakeholder-conversation boundary, and THIS page documents the PER-FORWARDER- HOP per-publisher per-domain PROTOCOL- LEVEL ROOT-CAUSE the per-misconception- class rebuttal-discipline materially attributes against.
• Email security glossary — the SPF-FORWARDER-BREAK-DIAGNOSTIC- VOCABULARY-RESOLVES-TO-CROSS-CLUSTER- EMAIL-SECURITY-TERMINOLOGY-HUB companion to this SPF-forwarding-issue diagnostic- ladder reference. Where THIS page documents the per-publisher per-domain per-forwarder-hop SPF-failure-mode catalogue (mailing-list forwarder MX-IP rewrite breaking SPF-envelope-from authorization, vacation-forwarder per-recipient-policy bounce-rewriting, ESP relay shared-IP-pool SPF-include cascade, per-publisher per-domain SRS sender-rewriting scheme as envelope-sender remediation, per- forwarder-hop DKIM-survives-forwarding as DMARC-aligned-DKIM-pass-rescue, per-forwarder-hop ARC-sealing as complete-chain DMARC-pass preservation), the email-security-glossary spoke is the cross-cluster TERMINOLOGY-RESOLUTION reference whose per-term canonical definitions establish the shared vocabulary every SPF-forwarding-issue discussion structurally depends on at FOUR per-term vocabulary-resolution dimensions: (i) per-term envelope-vs-header-domain vocabulary resolution — the envelope-vs-header- domain vocabulary (RFC5321-MailFrom envelope sender, RFC5322-From header author domain, return-path, bounce address, per-forwarder-hop envelope- sender rewriting, SRS sender-rewriting scheme, DMARC organizational-domain alignment with RFC5322-From) THIS page's per-publisher per-domain SPF-forwarder- break diagnostic-ladder structurally references at every per-forwarder-class diagnostic entry is canonically defined in the glossary spoke; the per-message envelope-vs-header-domain boundary terminology vocabulary that drives every SPF-forwarder-break-decode discussion lives in the glossary's per- term envelope-vs-header-domain entry- set; (ii) per-term ARC-chain vocabulary resolution — the ARC-chain vocabulary (authenticated-received- chain, ARC-Authentication-Results header, ARC-Message-Signature header, ARC-Seal header, per-hop instance i= identifier, RFC 8617 §5 cv= chain- validation outcome keyword set, per- receiver per-sealer Trusted-ARC-Sealers trust-anchor list) THIS page's per- publisher per-domain SPF-forwarder-break diagnostic-ladder references when describing forwarder-mediated DMARC- pass-preservation rescue path is canonically defined in the glossary spoke; the per-hop ARC-chain-mechanics vocabulary that drives every SPF- forwarder-break-DMARC-pass-rescue discussion lives in the glossary's per- term ARC-chain-vocabulary entry-set; (iii) per-term DMARC-alignment vocabulary resolution — the DMARC- alignment vocabulary (organizational domain, RFC5322-From domain, SPF- aligned-pass, DKIM-aligned-pass, aspf= / adkim= alignment-strictness mode, DMARC pass-by-DKIM-only path, DMARC pass-by-SPF-only path) THIS page's per-publisher per-domain SPF-forwarder- break diagnostic-ladder references when describing how DKIM-survives-forwarding provides DMARC-aligned-pass even when SPF-aligned-pass breaks at the forwarder hop is canonically defined in the glossary spoke; the per-message DKIM-as-DMARC-pass-rescue terminology vocabulary that drives every SPF-forwarder-break-mitigation discussion lives in the glossary's per-term alignment-vocabulary entry- set; (iv) per-term forwarder- topology vocabulary resolution — the forwarder-topology vocabulary (mailing- list forwarder, vacation-forwarder, ESP-relay forwarder, corporate-to- personal forwarder, mail-rule-driven forwarder, per-receiver per-recipient- policy forwarding, per-recipient rewriting MTA, per-forwarder per-hop IPv6 vs IPv4 envelope-sender rewriting) THIS page's per-publisher per-domain SPF-forwarder-break diagnostic-ladder references when describing per- forwarder-class regression modes is canonically defined in the glossary spoke; the per-forwarder-class topology terminology vocabulary that drives every operator-side per-forwarder-class- regression-triage discussion lives in the glossary's per-term forwarder- topology-vocabulary entry-set. Read the email-security-glossary spoke alongside this SPF-forwarder-break diagnostic- ladder reference when authoring per- publisher per-domain forwarder-break triage runbooks and per-forwarder-class- coordination documents that need the shared terminology hub.
• Business email compromise (BEC) defender catalogue — the BEC variant + defender-side enforcement-primitive reference covering CEO-fraud / vendor-impersonation / payroll-redirection / cousin-domain- lookalike / compromised-account-replay / thread-hijack-after-account-takeover attack-pattern catalogue and the per- publisher per-domain SPF + DKIM + DMARC + ARC + MTA-STS + BIMI + impersonation- warning-banner defender-side enforcement- primitive stack against per-attack-variant impersonation. THIS page documents the per- publisher per-domain SPF-forwarder-break diagnostic catalogue (SRS-rewrite second- hop alias / Outlook-rule auto-forward / per-mailing-list-MTA shared egress / .forward / per-server-forwarder topology producing per-message envelope-MAIL-FROM rewrite that breaks the SPF authorization chain at the second-hop boundary); the BEC-defender-catalogue spoke is the per- attack-variant defender-side enforcement peer documenting how exactly the per- publisher per-domain SPF-forwarder-break surface this page diagnoses becomes a per- publisher per-domain BEC attack-surface in per-attack-pattern variants — (i) attacker- controlled forwarder-as-second-hop relay amplifies the per-publisher per-domain SPF- leg-failure rate, producing per-receiver- side legitimate-traffic-noise that masks per-attacker direct-spoof attempts; (ii) Outlook-rule auto-forward used by compromised-mailbox-occupant produces per- thread-hijack persistence-mechanism BEC- defenders must catalogue as a per- compromise indicator-of-compromise; (iii) per-vendor-impersonation cousin-domain attacker exploits per-publisher per-domain SPF-forwarder-break-as-evidence-noise to avoid DMARC-aggregate-report attribution of the cousin-domain attack surface; (iv) per-publisher per-domain ARC-Seal mitigates BOTH the per-message SPF-forwarder-break attribution gap AND the per-attack-variant BEC-defender-side trust-anchor-replay evidence stream. Read the BEC-defender- catalogue spoke alongside this SPF- forwarder-break diagnostic-ladder reference when scoping the per-publisher per-domain BEC-defender-side per-attack-variant enforcement-primitive stack that structurally closes the BEC attack-surface the per-publisher per-domain SPF-forwarder- break diagnostic discipline this page documents leaves exposed, when authoring the per-publisher per-domain ARC-Seal- trust-anchor-cohort selection runbook against the per-forwarder-class coordination matrix, or when sequencing the per-publisher per-domain BEC-defender- side DMARC ramp on per-forwarder-class- attributed legitimate-traffic-noise evidence rather than per-row SPF-leg- failure-rate-alone evidence.
• DMARC reporting pipeline — the PER-PUBLISHER-PER-DOMAIN-SPF- FORWARDER-BROKEN-PER-MESSAGE-REJECTION- PATTERN-AS-RUA-AGGREGATE-XML-PER-SOURCE-IP- PER-RECORD-ROW-SPF-LEG-FAILURE-ATTRIBUTION- EVIDENCE-STREAM companion to THIS SPF forwarding-issues reference. Where THIS page documents the per-forwarder-class SPF- forwarder-broken per-message rejection pattern catalogue (the per-message .forward alias-redirect SPF- leg break, the per-list mailing-list Sender-rewriting SPF-leg-substitution, the Sender Rewriting Scheme SRS/SRS0/SRS1 envelope-MAIL-FROM rewrite mitigation, the ARC-chain seal as the per-forwarder per- message DMARC-result-preservation rescue mechanism, and the per-publisher per-domain operator-discipline coordination matrix for forwarder-broken legitimate-traffic-noise distinguishability), the DMARC-reporting- pipeline spoke documents the per-publisher per-domain RFC 7489 §7 RUA aggregate-XML ingestion-and-parsing pipeline (per-receiver per-day per-publisher per-domain RUA aggregate-XML stream consumed at the rua=mailto:-published endpoint, per-record per-source-IP per-disposition row dedup, per-receiver-organisation per-day per-publisher per-domain attribution storage) through which the per-publisher per-domain SPF-forwarder-broken per-message rejection patterns materially render as per-publisher per-domain per-receiver per-day SPF-aligned- pass-rate floor erosion attribution evidence at FOUR per-publisher per-domain SPF- forwarder-broken-vs-DMARC-reporting-pipeline coupling dimensions: (i) per- publisher per-domain RUA aggregate-XML per- source-IP per-record row SPF-leg-result- code distribution as load-bearing per- forwarder-class SPF-forwarder-broken attribution evidence — every per- forwarder-class per-message SPF-forwarder- broken rejection surfaces as a per-receiver per-day per-publisher per-domain RUA aggregate-XML report's per-record row with auth_results/spf/result=fail AND row/source_ip=per-forwarder- egress IP attribution that the per-publisher per-domain DMARC reporting-pipeline parses, deduplicates, and stores at the per-receiver per-day per-publisher per-domain observability boundary — letting the per- publisher per-domain operator attribute per- receiver per-day per-publisher per-domain SPF-aligned-pass-rate floor erosion to specific per-forwarder-class root cause (mailing-list forwarder vs alias-redirect forwarder vs hop-rewriting forwarder) THIS page documents the diagnostic catalogue for; (ii) per-publisher per-domain RUF forensic-report per-message per-source- IP per-failure-reason attribution as per- forwarder-class SPF-forwarder-broken root- cause-attribution evidence — when per-publisher per-domain SPF-forwarder- broken rejection patterns are NOT distinguishable from per-publisher per- domain attacker-driven SPF-leg-spoofing attribution evidence in the per-receiver per-day per-publisher per-domain RUA aggregate-XML report's per-source-IP per- record row distribution alone, the per- publisher per-domain RUF forensic-report stream THE DMARC-reporting-pipeline spoke ingests provides the per-message per-source- IP per-failure-reason attribution evidence the per-publisher per-domain operator needs to distinguish per-forwarder-class legitimate-traffic-noise rejection patterns from per-attacker per-message SPF-leg- spoofing root causes — the per-publisher per-domain operator-discipline-floor for per-forwarder-class legitimate-traffic- noise tolerance materially depends on the per-publisher per-domain RUF forensic- report consumption discipline the DMARC- reporting-pipeline spoke documents; (iii) per-publisher per-domain ARC-chain- recovered SPF-leg-result preservation as per-publisher per-domain RUA aggregate-XML per-record row ARC-aware attribution evidence — when per-forwarder- class SPF-forwarder-broken patterns are ARC-rescued at the per-publisher per-domain downstream receiver via the per-forwarder AAR/AMS/AS chain-of-custody headers documented at THIS page, the per-publisher per-domain RUA aggregate-XML report's per- record row captures the ARC-recovered SPF- leg-result-preservation evidence in the per- receiver per-day per-publisher per-domain attribution-store the DMARC-reporting- pipeline ingests — letting the per- publisher per-domain operator distinguish per-publisher per-domain SPF-forwarder- broken patterns that the per-publisher per- domain downstream-receiver ARC-aware evaluation rescues from per-publisher per- domain SPF-forwarder-broken patterns that per-receiver per-publisher per-domain ARC- rescue gaps fail to recover; (iv) per-publisher per-domain DMARC reporting-pipeline ingestion-discipline- floor as per-publisher per-domain SPF- forwarder-broken pattern-evolution observability surface — the per- publisher per-domain operator reads per- receiver per-day per-publisher per-domain RUA aggregate-XML report-stream rolling- window per-source-IP per-record row SPF-leg- failure-rate trends to observe per- forwarder-class SPF-forwarder-broken pattern evolution (new forwarders entering the per- publisher per-domain legitimate-traffic-noise catalogue, existing forwarders deploying SRS mitigation, existing forwarders deploying ARC seal) at the per-publisher per-domain operator-discipline forecast boundary the per-forwarder-class SPF-leg-rescue discipline THIS page documents materially coordinates against. Read THIS SPF forwarding-issues reference when DIAGNOSING per-forwarder-class SPF-forwarder-broken per-message rejection patterns AND when SEQUENCING the per-publisher per-domain DMARC ramp against per-forwarder-class- attributed legitimate-traffic-noise evidence; read the DMARC-reporting-pipeline spoke when OPERATING the per-publisher per- domain RUA-and-RUF aggregate-and-forensic- report ingestion-and-parsing discipline against per-forwarder-class SPF-forwarder- broken pattern attribution evidence THIS page documents.
• DKIM replay attacks
• TLS-RPT record syntax
• DMARC for Office 365 hybrid — per-publisher per-domain hybrid M365 deployments with on-prem-Exchange- plus-Exchange-Online dual-egress topology are the canonical real-world surface where SPF forwarder-cascade survival THIS page documents materially intersects per- tenant per-accepted-domain SPF authorisation publication-discipline — on-prem Exchange relaying outbound through Exchange Online Protection, hybrid mail-flow connectors routing inbound through on-prem journaling before second-hop delivery to mailbox, third-party mail-relay (Mimecast / Proofpoint / Barracuda) acting as forwarder upstream of the M365 transport pipeline — all multiply per-message envelope-MAIL-FROM-rewriting risk surface the per-tenant SPF include:spf.protection.outlook.com publication discipline + DKIM dual-selector application-layer leg the hybrid M365 spoke documents must compensate for at the per- publisher per-domain composite envelope- and-application-layer dual-egress-and- forwarder-cascade-survival coordination boundary.
• MTA-STS vs DANE — the per-publisher per-domain transport-layer MITM-downgrade-defense protocol-choice decision-matrix companion at four per-forwarder-second-hop-SPF-survival-vs-MTA-STS-vs-DANE coupling dimensions: (i) per-forwarder per-message envelope-MAIL-FROM rewriting per RFC 5321 §3.10 SPF-break-cascade IS structurally parallel transport-evolution failure-mode to per-forwarder per-message STARTTLS-strip MITM-downgrade attack-class — both classes redefine the per-message authentication-and-transport context at the per-forwarder second-hop, both producing per-receiver-side verdict-degradation under per-publisher per-domain publication-discipline mis-coordination, both closed by the per-publisher per-domain MTA-STS mode: enforce publication-discipline vs DANE cert-usage = DANE-EE(3) publication-discipline THIS MTA-STS-vs-DANE decision-matrix companion documents the per-publisher per-domain transport-layer enforcement-mode publication-decision of; (ii) per-forwarder per-message envelope-rewriting SRS Sender Rewriting Scheme per RFC 7505 IS structurally parallel per-publisher per-domain forwarder-cascade survival-discipline primitive to per-publisher per-domain MTA-STS HTTPS-served-policy max_age: + id: rotation cadence per RFC 8461 §3.2 vs per-publisher per-domain DANE TLSA-RR rollover discipline per RFC 7672 §5 — all three per-publisher per-domain second-hop-survival publication-discipline references coordinate at the per-publisher per-domain composite envelope-and-transport-layer second-hop-survival publication-discipline coordination boundary; (iii) per-forwarder per-message envelope-MAIL-FROM-rewriting cascade SPF-aligned-pass survival at second-hop receiver per RFC 7208 §4.6 IS structurally parallel per-message survival-discipline primitive to per-forwarder per-message MTA-STS-enforce STARTTLS-handshake survival at second-hop receiver per RFC 8461 §5 vs per-forwarder per-message DANE-EE-anchored STARTTLS-handshake survival at second-hop receiver per RFC 7672 §3 — all three per-message envelope-and-transport-layer survival-discipline references coordinate at the per-publisher per-domain composite per-message envelope-and-transport-layer second-hop-survival coordination boundary; (iv) per-forwarder per-message envelope-rewriting forwarder-class cascade publication-discipline drift (SRS-mis-deployment / per-source-IP per-day DMARC RUA policy_evaluated/spf=fail attribution-row attribution) IS structurally parallel publication-discipline-drift class to per-publisher per-domain MTA-STS publication-discipline drift (mode: testing-stuck / max_age:-too-short / per-receiver per-policy-domain TLS-RPT sts-policy-fetch-error attribution) vs per-publisher per-domain DANE publication-discipline drift (DNSSEC-RRSIG drift / TLSA-RR-rotation-overlap-window-too-short / per-receiver per-policy-domain TLS-RPT dane-mismatch/dnssec-invalid attribution) the per-publisher per-domain MTA-STS-vs-DANE protocol-choice decision-matrix companion documents the per-publisher per-domain transport-layer publication-discipline drift catalogue of structurally parallel to the per-publisher per-domain SPF forwarder-cascade publication-discipline drift catalogue THIS page documents the per-publisher per-domain envelope-MAIL-FROM-layer second-hop-survival-discipline of.
• DMARC for SaaS senders — the PER-PUBLISHER-PER-DOMAIN-SPF-FORWARDER-CASCADE-ENVELOPE-MAIL-FROM-LAYER-SECOND-HOP-SURVIVAL-DISCIPLINE-AS-STRUCTURALLY-PARALLEL-COMPANION-TO-PER-SAAS-TENANT-PER-CUSTOM-DOMAIN-DMARC-COMPOSITE-VERDICT-SURVIVAL-UNDER-PER-SAAS-PROVIDER-INTERMEDIATE-FORWARDING-CASCADE companion at four per-publisher per-domain SPF-forwarder-vs-SaaS-tenant-DMARC coupling dimensions: (i) per-publisher per-domain SPF forwarder-cascade SRS-rewriting per-message envelope-MAIL-FROM-layer second-hop survival-discipline per RFC 7208 §4.6 IS structurally parallel envelope-MAIL-FROM-layer per-forwarder-class survival-discipline to per-SaaS-tenant per-custom-domain SPF include: macro-expansion per-SaaS-product-tenant per-egress-IP per-message envelope-MAIL-FROM-layer authorization-cascade the SaaS-senders spoke documents the per-tenant per-customer per-custom-domain per-SaaS-product-tenant authorization-cascade publication-discipline of; (ii) per-publisher per-domain SPF forwarder-cascade SRS-rewriting cascade collapse (per-forwarder envelope-MAIL-FROM-rewriting cascade SPF-aligned-fail surfacing as DMARC RUA policy_evaluated/spf=fail attribution) IS structurally parallel envelope-MAIL-FROM-layer per-forwarder-class failure-mode to per-SaaS-tenant per-custom-domain DMARC composite-verdict survival-fail under per-SaaS-provider per-customer-tenant intermediate-forwarding cascade surfacing as per-tenant DMARC RUA attribution distortion the SaaS-senders spoke documents the per-tenant per-customer-onboarding operational-discipline of; (iii) per-publisher per-domain SPF forwarder-cascade SRS-rewriting forwarder-survival-discipline IS structurally parallel envelope-MAIL-FROM-layer per-forwarder-class survival-discipline primitive to per-SaaS-tenant per-custom-domain DKIM application-layer-authentication-leg-survival-discipline under per-SaaS-provider per-customer-tenant intermediate-forwarding cascade — per-SaaS-tenant per-custom-domain DKIM CNAME-delegation publication-discipline preserves per-message DKIM-Signature byte-coverage under per-forwarder-class envelope-rewriting structurally parallel to per-publisher per-domain SPF SRS-rewriting envelope-MAIL-FROM-layer-survival the SaaS-senders spoke documents the per-tenant per-customer per-custom-domain DKIM CNAME-delegation publication-discipline of; (iv) per-publisher per-domain SPF forwarder-cascade publication-discipline drift catalogue IS structurally parallel publication-discipline-drift class to per-SaaS-tenant per-custom-domain DMARC publication-discipline drift (premature ramp surfacing as per-tenant DMARC RUA attribution distortion under per-SaaS-provider per-customer-tenant intermediate-forwarding cascade) the SaaS-senders spoke documents the per-tenant per-customer-onboarding drift-closure operational-discipline of at the per-tenant per-customer composite cross-protocol cross-layer per-message envelope-and-application-layer second-hop-survival publication-discipline coordination boundary.
• Phishing protection — the threat-context companion to this forwarding-diagnostics page. A forwarder that rewrites the envelope MAIL-FROM and breaks SPF is exactly the gap attackers exploit to slip spoofed mail past a half-deployed DMARC policy, so the forwarder-cascade-survival discipline documented here is one leg of the anti-phishing posture — read the phishing-protection guide for the full threat model an enforced SPF-and-DMARC alignment defends against.
• TLS-RPT report format — the PER-INTER-MTA-HOP-TRANSPORT-FAILURE-VISIBILITY companion to this SPF forwarding reference: just as SPF breaks at the forwarder/relay hop because the envelope-MAIL-FROM is rewritten while the message traverses an intermediate MTA, the TLS-RPT report surfaces which of those same inter-MTA hops is failing its STARTTLS handshake — the failure-details[] per-receiving-mx-hostname rows let an operator see exactly which forwarding hop is dropping to cleartext, complementary to seeing which hop broke SPF alignment. Read the TLS-RPT-report-format spoke when diagnosing whether a forwarding path's delivery problem is an SPF-alignment break or a transport-layer STARTTLS failure on the same relay hop.
• DMARC deployment checklist — forwarding breakage is one of the gotchas the checklist tells you to resolve before tightening policy. SPF fails across a forwarder because the envelope is rewritten, so a domain that ramps to p=reject without accounting for its legitimate forwarding paths will reject real mail. The deployment checklist's monitor-and-fix phase is where you use RUA data to spot those forwarding failures and lean on the DKIM leg before enforcing. Read it for the phased ramp this forwarding guide is a troubleshooting input to.
• Microsoft SNDS + JMRP monitoring — SPF PASS does not clear Microsoft's IP-reputation gate: SNDS shows the per-IP GREEN/YELLOW/RED filter verdict Outlook.com assigned to each authorized address and JMRP reports the Junk clicks behind a degraded one.

13. Verify your forwarding setup now

The DMARC Analyzer platform surfaces forwarding-related SPF failures in three places: the Domain Security Checker runs a live SPF lookup against the public DNS and reports any of the seven permerror cause classes plus the live lookup count; the Email Header Analyzer parses pasted Authentication-Results headers and surfaces the specific spf= verdict, the ARC chain status, and the per-hop Received: chain so you can identify exactly which forwarder broke authentication; the dashboard ingests DMARC aggregate (RUA) reports and surfaces per-record SPF result codes plus source-IP attribution at scale so you can monitor the forwarding-traffic prevalence and impact over time.

Check my SPF and ARC setup Analyze a forwarded-mail header Sign up — Free plan