[jeroenhd]

DMARC still has some issues. From a few years ago: https://i.blackhat.com/USA-20/Thursday/us-20-Chen-You-Have-N...

> Unfortunately, neither SPF nor DKIM provides a complete solution for preventing email spoofing. SPF authenticates the HELO/MAIL FROM identifier and DKIM authenticates the d= field in DKIM-signature header: neither of them authenticates the From header displayed to the end-user, which means that even if an email passes SPF and DKIM validation, its From address can still be forged.

A lack of DMARC+ on an email domain is definitely a problem, but DMARC+ alone still doesn't solve the "is this the real sender" problem.

[karmelapple]

We literally just ran into another issue with SPF: the SPF Lookup Limit [1] , which could cause receiver servers to bounce your email back with an "SPF PermError".

If your SPF record causes receiving mail servers to lookup too many domains, some receiving mail servers will reject your email, even when the email itself passes all SPF/DKIM/DMARC checks.

The tricky part of that to diagnose - which [1] talks about, and links to a tool to diagnose it [2] - is that there may be additional lookups that the servers you list in your SPF cause to happen.

So you could have an SPF record with only 4 servers, but if one of those servers causes 7 additional lookups, you might have over 10 SPF lookups. 10 seems to be a growing-in-popularity limit on SPF lookups.

So even if you have SPF, DKIM, and DMARC setup, make sure you don't have too many lookups caused by your SPF record!

1. https://easydmarc.com/blog/spf-too-many-dns-lookups-error 2. https://easydmarc.com/tools/spf-lookup

[Rookie42]

Hey - Managing SPF RFC limits in large environments can be rather challenging - given the limit of 10 entries. (especially before you adopt DKIM)

Some vendors such as ProofPoint offer services such as SPF hosting, which allow you to work around this constraint. (https://www.proofpoint.com/au/resources/solution-briefs/proo...)

[rst]

As a practical example -- it's pretty common for companies to delegate email to a provider like Gmail. Some infosec folks consider this best practice, and Google will allow you to configure DMARC to say that only messages originating from their servers are legit.

However, this does mean that anyone who can suborn Google's mail servers can use them to spend spoof emails that DMARC will rate as legitimate -- and last month, there was announcement of vulnerabilities (since fixed) which allowed a third party to abuse email-forwarding features to do exactly that. See https://arxiv.org/pdf/2302.07287.pdf

[Rookie42]

It inst perfect, but it doesn't need to be unless your risk is disproportional to the market. Risk will always be there, you just need to manage it inline with your corporate risk tolerance - and implementing DMARC to P=Reject is most likely going to (very likely exceed) that approach.

Yes, some companies have elevated risk here (Banks, Payment Processors, Social Media companies) - but honestly most don't.

Btw - this is as much an acceptance as a survival strategy - nothing will ever be perfect, not without significant cost & impact elsewhere. Survival of the fittest these days is managing (and please the understanding of) risk better than others