0

I've seen (and think I understand) when DMARC checks fail on SPF because, e.g. the email has been forwarded and such like. But I don't think this is the case here. All checks on sites like MXtoolbox pass, but I get occasional failure reports like this (our web host is SiteGround):

<record>
    <row>
      <source_ip>185.56.87.12</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>    <---- Note failure here
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>domain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>domain.com</domain>
        <result>pass</result>
        <selector>default</selector>
      </dkim>
      <spf>
        <domain>uk53.siteground.eu</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>

The source IP belongs to SiteGround (as confirmed by whois) so this doesn't appear to be a case of email forwarding. On a check on MXtoolbox you can see our SPF records include _spf.mailspamprotection.com:

enter image description here

Which in turn includes 185.56.87.0/24:

enter image description here

So I don't understand why it's saying SPF has failed. Can someone explain it to me?

Improve this question
2
  • If the issue is an occasional fail this will be more likely the recipient rather than the sender.
    – Martin
    Commented Mar 22 at 11:54
  • @Martin I do also see failures reported by outlook on a Microsoft IP address (ironically), as we have an O365 tenant, but I've found other people reporting that and it seems to be an internal configuration issue at MS that they don't seem inclined to fix.
    – Darren
    Commented Mar 22 at 13:21

1 Answer 1

Reset to default
3

The SPF "fail" under "policy_evaluated" in the DMARC report indicates a mismatch between the DMARC domain (from the "From" header) and the SPF domain (from the "Return-Path" header).

It's likely that your email's "From" header is something like From: <[email protected]>, but the "Return-Path" header resembles Return-Path: <[email protected]>. For the DMARC-SPF check to pass, both the domain in the "From" header and the domain in the "Return-Path" header must match.

Another possibility is that the "Return-Path" was empty, prompting the receiving server to use the domain from the HELO/EHLO part of the SMTP conversation. Empty return paths commonly occur in bounce messages and other auto-replies.

Improve this answer
2
  • Thanks. That sounds plausible, but why isn't the domain it's tested against in the report so that's clear?
    – Darren
    Commented Mar 22 at 16:03
  • 2
    @Darren The report states <domain>uk53.siteground.eu</domain> under auth_result > spf, indicating that uk53.siteground.eu is the SPF domain, derived from the "Return-Path" header or, if absent, the HELO/EHLO command. The DMARC domain is identified by <header_from>domain.com</header_from>. DMARC reports are typically more verbose and include a <scope> element specifying which field/domain was used for the SPF check.
    – Andreas
    Commented Mar 22 at 16:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .