SPF verdict none for hosted domains

[paul.fritzsche1]

Hello everyone,
we have some issues with SPF check and our ESA hosted domains. Our goal is, to reduce forged identities (espacially PRA identity which is shown by Outlook).

Our requirements:

- "v=spf1 ... -all" is already (and correct) set and we don't want to set an extra "spf2.0/pra ... -all" TXT-RR in DNS (this would be an option with SPF/SIDF Conformance Level "SIDF-compatible")
- We set SPF/SIDF Conformance Level to "SIDF" on all HAT policies (this provides the capability: "SPF v1.0 records are treated as spf2.0/mfrom,pra." which is fine).
- DKIM and DMARC would be complex options for the future, but not at the moment.

Problem: Now, SPF check is working fine for external domains/identities, but not for by our company hosted domains (e.g. Receiving Domains listed in SMTP-Routes).

Examples:

SPF: pra identity jdoe@external.com Fail headers from
SPF: pra identity jdoe@internal.com None headers from

Why ESA is not performing the SPF check for external delivered emails, when pra/mailfrom/(helo) identity domains are the same as our hosted domains?

[dmccabej]

Hello Paul,

Are you able to provide any message tracking examples for the behavior you're referring to?

Thanks

-Dennis M.

[paul.fritzsche1]

Hello Dennis,

yes. See attached.

Both domains have the same (syntax) SPF-Record in DNS.

SPF for ...bi.de, TXT RR: "v=spf1 mx ip4:.. -all" MX RR points to our Ironport.

[Ken Stieers]

Are you using split dns don't forget to put your spf records in your internal dns servers

[paul.fritzsche1]

Hi Ken,

thanks for your answer. Split DNS was the solution and solved our problem. There are two possible ways:

1. You update your internal DNS RR

2. You specify external DNS server for special domains via ESA (Network > DNS).

[cbalicusto46]

Hi Paul,

We are using a spoof message filter and I'm looking at adding some improvements by integrating SPF (mail from and PRA results).

Just like you, I want to avoid publishing spf2.0 and looking at setting the Conformance Level to "SIDF".

Prior to fixing the issue, were your ESA's DNS configuration set to use external or your internal DNS server?

Thanks,

Conrado

[paul.fritzsche1]

Hi Conrado, we used internal DNS where no data was set for our domains. So, our verdict was always none (nothing to check against). We corrected this by implementing the SPF TXT-RR also in internal DNS.

SIDF is correct for checking PRA und MFROM identities. There are also important references in Cisco User Guide which help a lot to understand how these settings and RFC works.

[cbalicusto46]

Thanks Paul

[dmccabej]

However ESA/DNS/SPF is setup, we don't seem to be finding any records for that domain. At this point I would recommend opening up a TAC case and we can help you take a closer look at the configuration.

Also, while SPF validation is helpful, it doesn't necessarily assist with spoofing attacks. And while the PRA/SenderID result would be looking at the friendly 'From' header, it's pretty much obsolete and rarely used.

Personally, I would recommend either creating a message filter to look at the Mail-From and From headers. Or, if you're using ASyncOS 10+ you can take advantage of Forged Email Detection.

Some Helpful Articles :

1) Quarantine Spoofed Email

2) Forged Email Detection

Thanks!

-Dennis M.