Even after careful monitoring and education, enforcing DMARC p=reject can create operational friction and highlight conflicts in email processes.

I was just accused of breaking email infrastructure by implementing DMARC p=reject, along with complaints about being "peppered to death with charges" every time a new system comes into play by their team.
Before reaching enforcement, we spent several months in p=none, monitoring traffic and reviewing risks. We took time educating stakeholders on email spoofing vectors, phishing methodologies, SMTP fundamentals, and the reputational and security risks that domain spoofing poses to their org.
We addressed all operational risks of enforcement, including SPF failures on forwarded emails, DKIM signatures broken by SEGs, and the requirement for proper SPF/DKIM config on any new email sending platforms.
The objective was to stop the hundreds of spoofed emails abusing their domain each month.
Months later, an employee reported to the exec team they couldn't send emails through a new system, which suddenly called my security expertise into question.
This highlights the fundamental problem with security implementation - tech security controls often conflict with the path of least resistance mentality prevalent in modern business operations.
IMHO, while DMARC, SPF, MTA-STS, etc. provide valuable protections, they'll have limited impact on sophisticated email spoofing until we completely shift away from SMTP toward a blockchain-based email ecosystem with redesigned identity verification at the protocol level.