On 12/6/2024 6:43 AM, Alex Shakhov | SH Consulting via mailop wrote:
Hello, a few months ago, I was asked to audit emails and integrate a
new system for a company. The first thing I did was configure DMARC
reporting (replaced v=DMARC1; p=none;) and after two months of
analyzing their email traffic, I detected some spoofing activity along
with a messy SPF record and a misconfigured DKIM setup for Mimecast,
which they use to route outbound emails. The spoofed traffic was
small, just <10 emails over two months.
I reached out to their team and suggested adding the missing DKIM,
cleaning up their SPF record, and enforcing DMARC. I supported my
recommendations with detailed documentation and report. However,
instead of collaborating, they silently revoked my DNS access, removed
the DMARC policy I had set up, implemented the missing DKIM records,
and configured a free Postmark DMARC record. They then set the DMARC
policy to reject. The SPF record remained unchanged.
A week later, I received a spoofed email from their domain with an
encrypted attachment. Surprisingly, my Google Workspace didn’t filter
it, and it landed directly in my inbox. I figured out that
- The 'To' field was empty.
- DMARC was set to reject, but the email passed validation.
- SPF passed with 170.10.133.179 (a Mimecast relay).
- DKIM was missing.
Their SPF record was still a complete mess, packed with unnecessary
IPs and services, although within the 10 DNS lookup limit. I have
strong reasons to believe that the combination of their improperly
configured SPF record and Mimecast's SEG setup allowed these spoofed
emails to appear legitimate and bypass filtering.
I can’t say with 100% certainty that my explanation covers everything,
but this is definitely one version worth considering.
For reference, here’s their SPF record:
v=spf1 include:us._netblocks.mimecast.com
<http://netblocks.mimecast.com/> include:spf.protection.outlook.com
<http://spf.protection.outlook.com/> ip4:207.46.163.247
ip4:74.126.9.238 ip4:72.52.238.74 ip4:207.158.48.193/26
<http://207.158.48.193/26> ip4:209.216.210.32/28
<http://209.216.210.32/28> ip4:198.37.147.129
include:support.zendesk.com
<http://support.zendesk.com/> include:amazonses.com
<http://amazonses.com/> include:_spf.smtp.com <http://spf.smtp.com/> ~all
Thank you for your attention.
So, it passed SPF alignment and authentication for the RFC5321.mailfrom
with their domain, and the encrypted message/attachment was sent from
Mimecast?
If they use Mimecast's Secure Messaging, it would be expected; as you
stated, they route outbound mail through Mimecast anyway, and is allowed
explicitly in their SPF record.
I'm not sure I'm following what the perceived problem is in this
scenario. If the above assumptions (based on your statements) are true,
SPF passed alignment/authentication, which satisfies DMARC's criteria.
Was the expected behavior for it to be rejected, or go to spam? You may
also want to double check your workspace authentication/spoof
configuration, just in case. Although, if it's authenticated/aligned as
it would seem, it likely won't make any difference.
- Mark Alley
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
