I have a possible solution for you. As RFC 7208, Section 4.6.4 states:
Some mechanisms and modifiers (collectively, "terms") cause DNS
queries at the time of evaluation, and some do not. The following
terms cause DNS queries: the "include", "a", "mx", "ptr", and
"exists" mechanisms, and the "redirect" modifier. SPF
implementations MUST limit the total number of those terms to 10
during SPF evaluation, to avoid unreasonable load on the DNS. If
this limit is exceeded, the implementation MUST return "permerror".
The other terms -- the "all", "ip4", and "ip6" mechanisms, and the
"exp" modifier -- do not cause DNS queries at the time of SPF
evaluation (the "exp" modifier only causes a lookup at a later time),
and their use is not subject to this limit.
When evaluating the "mx" mechanism, the number of "MX" resource
records queried is included in the overall limit of 10 mechanisms/
modifiers that cause DNS lookups as described above. In addition to
that limit, the evaluation of each "MX" record MUST NOT result in...
You could make sure you put enough includes and other DNS overhead in your dangerous SPF record to make sure it fails the 10 DNS lookup standard. add the MX directive and throw in the includes for services (Google, Salesforce) until your SPF record fails SPF Survey for exceeding 10 DNS lookups. Your dangerous SPF record will then look valid but it will fail for a reason that most people don't know about, thus both SPF and DKIM will fail.
Providing I understood your question correctly, this should yield the result you want. Is this the sort of solution you were looking for or did I misunderstand something?
v=spf1 -all
then? Also, having no MX record and ideally no A/AAAA record either for the domain might help too to signal to others that this domain will not be used for email. But at the end these are all just signals and MTA are not required to look for these signals when accepting a mail.+SPF
and-DKIM
results in+DMARC
, rather than-DMARC