I just learned through a support case (where a spoofed malicious email was allowed through, bypassing DMARC checks despite having an inbound DMARC verification rule) that the only time an inbound DMARC verification rule is even TRIGGERED is when DMARC actually "fails" (because the domain's various records for SPF and DKIM don't have the proper servers allowed)..

Unfortunately, I also learned that, when the sending domain does not actually HAVE a DMARC record to check, such a "failure" is technically not possible... because 'DMARC record does not exist' DOES NOT EQUAL a "fail", and there is no "does not exist" scenario that is currently allowed for regardless of the action ("honour txt record", "quarantine", or "reject") chosen for the rule.

What this means is that a spammer has the ability to send all the spoofed email they want from (and potentially to!) your OWN domain without your inbound DMARC rule doing anything to stop it.

This is NOT due to a misconfiguration of YOUR OWN records for DMARC. It is a failure of the sending domain's LACK of a DMARC (or SPF/DKIM records, as appropriate). (Furthermore, and similarly, though, I was also educated by Support that the SAME THING would be true if the SPF record didn't exist, or if there were NO DKIM records either (the message would just skip DMARC checks and be allowed through).

Currently we are technically using the email appliances - however, my understanding is that this is how the feature works in Sophos Central as well, so, I'm submitting this now in hopes it will be fixed, in advance of our possible transition to that service from the appliances.

The solution I'm suggesting is to have an option to treat a "non exist" as a "failure" so that DMARC verification can actually be triggered. Maybe there can just be options to override the handling of when the DMARC, SPF, or DKIM records do not exist... we could just pick 'quarantine'?