[dmarc-ietf] Re: Revisiting SPF upgrade

[Douglas Foster <[e-mail]>]

You are right, although the tag I see is different then what you suggested.

After reviewing my logs, I see that a large portion of my ARC data has  a
"smtp.rcpttodomain=" qualifier.
But the data is not useful; if my logs could be believed, I have accepted a
lot of inbound forwarding, much of it fraudulent.    In reality, the
messages come from legitimate senders with complex outbound mail flows.

Consequently, the SPF Upgrade problem is unsolved with ARC, and apparently
unsolvable (short of 100% DKIM2 adoption.)

Doug Foster

.

On Fri, Aug 14, 2026 at 8:38 AM Carlos Horowicz <carlos=
[e-mail]> wrote:

> Sorry if this is too naive, but in your Outlook.com example, if
> Outlook.com hypothetically added an ARC property like
>
> arc-recipient-domain=AttackPartner.com
>
> Wouldn't that expose to VictimDomain.com that the message had originally
> been delivered to AttackPartner.com, hence something seems wrong with the
> aligned SPF PASS at the end ?
>
> -Carlos
> On 14/08/2026 13:10, Douglas Foster wrote:
>
> Awhile back, someone described the SPF upgrade attack to this list,
> particularly mentioning Outlook.com
>
>    - Bad guy initiates an impersonation message claiming to be from
>    Megabank.Com.   Megabank.com is known to be hosted on Outlook.com
>    - The bad guys send the malicious impersonation to his controlled
>    domain AttackPartner.com, which is also hosted on Outlook.com.
>    - AttackPartner.com accepts the message even though it fails SPF and
>    DKIM, because it is part of the attack.
>    - AttackPartner.com auto-forwards the message to VictimDomain.com,
>    preserving the original SMTP address, remaining anonymous.  The message is
>    accepted based on aligned SPF Pass.
>    - VictimDomain.com acts on the message as if it is truly from Megabank.
>
> Ways that the attack might be exposed:
>
>    - If the hosting service rejects the original message because it lacks
>    authentication.
>    - If the hosting service enforces Mail From rewrite, with or without
>    SRS encoding, then the role of AttackPartner.com would be exposed, and SPF
>    Pass would be based on that domain.
>    - If the hosting service created two ARC sets, one that documented the
>    original destination domain and one that documented the final destination
>    domain.   However, destination domains do not generally appear in ARC
>    sets.   ARC was supposed to help us identify forwarding activity.   A
>    forwarder who preserves the Mail From address is indistinguishable from an
>    outbound gateway service, even with ARC.
>
> DKIM2 gives us the destination domain information which ARC lacks, but
> DKIM2 will not be used by a malicious impersonator.
> Even if DKIM2 allows a domain owner to specify that DKIM2 is mandatory,
> the attacker will simply redirect his attacks to a domain which does not
> have this enforcement specified.
>
> So we have no solution and no plan for a solution?
>
> Doug Foster
>
>
> _______________________________________________
> dmarc mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> dmarc mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>