On February 21, 2020 4:46:32 PM UTC, Marisa Clardy via dmarc-discuss 
<dmarc-discuss@dmarc.org> wrote:
>Hello,
>
>This may have already been discussed before, but I couldn't find
>anything
>about it.
>
>In our organization, we provide mail filtering for customers. We had
>SPF
>failures being rejected for a long time, however recently, we
>implemented
>DMARC, and set it so that if a domain has a DMARC policy, it doesn't
>reject
>based on an SPF failure.
>
>Some of our customers have complained about this, specifically in the
>cases
>where p=none. They say that when p=none, we should still reject SPF
>failures.
>
>My manager and I both agree that this isn't the case, based on our
>understanding of DMARC.
>
>Either way, even if we reject SPF failures on p=none, we will need to
>find
>a solution that retains DMARC's ability to report. The biggest problem
>for
>this though is we do SPF failures after the RCPT TO command, and have
>to do
>it there, because we have flags that let specific customers turn off
>SPF
>rejection, so it's not like we can just move the SPF rejection to after
>the
>DATA command.
>
>As such, we were curious about what the greater DMARC community thinks
>about this.

You can do it however makes sense for you.  See RFC 7489 Section 6.7 [1].  

Personally, I'm highly unlikely to publish a DMARC policy other than p=none due 
to high false positive rates.  I have a SPF policy that ends in -all, since I 
have very few problems with SPF false positives.

For myself, I'd certainly prefer you continue to reject SPF failures.

Scott K


[1] https://tools.ietf.org/html/rfc7489#section-6.7

_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Reply via email to