"How common is it to have receiver systems set so that SPF hard fail will reject messages even if they otherwise pass DKIM and DMARC, but to accept them on the DKIM pass if the domain uses SPF soft fail?"
SPF checking is/can be done at the MAIL FROM part of the conversation; it's keyed to the RFC5321.From domain. DMARC checking can't happen till after DATA, since it's keyed to the RFC5322.From domain. This means that SPF checking and a failure result can happen before DMARC ever enters the picture. I don't know how common it is for mailbox providers to honor SPF -all, but any that do would be doing so correctly in this scenario. On Thu, Dec 6, 2018 at 8:57 PM Autumn Tyr-Salvia <tyrsal...@gmail.com> wrote: > Hello Mail Operators, > > My job is to help large organizations figure out their email > infrastructure and authenticate everything legitimate with the goal of > going to DMARC p=reject. A customer recently reported an issue to me about > receiver behavior that I hadn't heard before, so I wanted to reach out to > get a feel for whether this is more widespread than I realized or if this > particular receiver is behaving strangely. > > It's a bit of a long story why things are set up in the way they are for > this particular situation, and in the interests of not writing a novel > here, I'm going to cut to the chase: > > Customer is sending messages that pass DKIM with first party signing, so > they pass DMARC. Unfortunately, SPF fails, and the SPF record uses a -all, > so it's a hard fail. There is an SPF entry at the sending subdomain, and > the SMTP MAIL FROM domain is aligned, but the SPF record does not include > the sending IPs. There are complicated reasons why they can't just do that > easily. > > DMARC requires only one aligned method of authentication to pass, either > SPF or DKIM. Since these messages pass with aligned DKIM, they pass DMARC. > In theory, all should be good, right? > > We have received reports that a particular organization they are sending > to is seeing the SPF hard fail and choosing not to further evaluate DKIM, > and is rejecting these messages on SPF hard fail alone. I don't have the > bounce message handy, but it said something like "SPF hard fail: your > organization's security policy does not permit this message." The > organization they're sending to is a small nonprofit, but the MX record > shows that they are using GoDaddy's hosted email. > > When one of the email admins involved had the recipient ask their email > vendor about it, they were explicitly told that if senders use an SPF -all, > if messages fail SPF, they will not accept them even if they pass DKIM and > DMARC. As a consequence, I had them try setting the domain to use a soft > fail ~all and test, and initial reports say that delivery was successful. > > I have a lot of experience with SPF, though admittedly, I don't have as > much experience with SPF failures (I see a lot of cases of no SPF, or > passing but not aligned SPF, but comparatively few actual failures), but I > haven't heard this distinction between hard and soft fail modes before. > > How common is it to have receiver systems set so that SPF hard fail will > reject messages even if they otherwise pass DKIM and DMARC, but to accept > them on the DKIM pass if the domain uses SPF soft fail? > > Given this situation, the customer is now considering whether they want to > move every domain they own to SPF soft fail instead, so I wanted to ask > around and get a feel for how common this is before they change all of > their many domains. > > > Thanks, > > Autumn Tyr-Salvia > atyrsalvia@agari > tyrsalvia@gmail > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > -- *todd herr* *postmaster www.sparkpost.com <http://www.sparkpost.com>* *twitter* @toddherr @sparkpost *tel* 415-578-5222 x477 *mobile* 703-220-4153 *email* todd.h...@sparkpost.com <firstname.lastn...@messagesystems.com>
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
