[dmarc-ietf] Re: Revisiting SPF upgrade

[Douglas Foster <[e-mail]>]

For domain owners, others have cleverly suggested an SPF policy of the form:
?term1 ?term2 -all
This will cause DMARC evaluators to detect Pass based on DKIM only, or Fail
for invalid.
SPF-only evaluators will detect SPF Neutral for valid or SPF Fail for
invalid senders.
However, I see no evidence of this strategy in use within my data set.

My interest is how to handle evaluation.  The extension of your idea is to
enforce DKIM-only validation for some senders.   The first step is to
determine which domains are consistently achieving 100% DKIM Pass, which I
can do.   It covers about one third of allowed messages.   The second step
is overcoming fear that DNS TempError results or other factors will occur
often enough to render the strategy unacceptable.    That possibility is
harder for me to assess, due to the level of detail in my dataset.  One
indicator is domains with a mix of signed and unsigned messages.   The top
20 domains in that list are priority senders  (probably whitelisted)   with
11% of accepted messages failing DKIM.

The fear is strong enough that I have not moved in that direction.



On Sat, Aug 15, 2026 at 9:26 AM Max Hearnden <[e-mail]>
wrote:

> While a change to DMARC would nice, I think that SPF upgrades can be
> mitigated using existing infrastructure.
>
> In order for a message to pass DMARC using SPF (which is susceptible to
> spoofing), the message needs an SPF pass (evaluated for the MAIL FROM
> address) and for the MAIL FROM address to be aligned with the From:
> address.
>
> If a domain wishes for its mail to be only validated using DKIM, then
> that domain must not publish an SPF record with a pass qualifier (+).
>
> As some mail providers also evaluate SPF separately and treat an SPF
> pass as more reputable, the sender might rewrite the MAIL FROM address
> to an unaligned address with a published SPF pass.
>
> As an example, here's a zone file showing the DNS setup required. The
> MAIL FROM address would be rewritten from x@y to x@mail.y.
>
> @ TXT "v=SPF1 ?mx -all"
>
> _dmarc TXT "v=DMARC1;p=reject;aspf=s"
>
> mail TXT "v=SPF1 +a -all"
>
> On 14/08/2026 12: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
> >
>