1

I am working on a tool that checks SPF records, and would like a way to be able to disable email from a testing subdomain, and its children, so that my test domains are not easy targets for spammers to send from.

I was planning on setting up the domains like this:

  • example.com - My personal domain
  • badspf.example.com - A subdomain that should never send emails
  • *.badspf.example.com - Different broken / dangerous SPF records

I was thinking of using DMARC to block any unsigned emails at badspf.example.com, and then add no DKIM keys, but I do not know how well this would work in the real world.

Is there a better way to do this, and are there any issues with the way suggested above?

jrtapsell
  • 3,169
  • 15
  • 30
  • I'm not sure if I understand your problem. Given that you are willing to use DMARC you don't seem to have problems adding custom DNS records. So why don't you want to add an SPF record like `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. – Steffen Ullrich Jan 20 '18 at 16:02
  • The problem is that for testing I would like to have dangerous SPF records, and check that my tool warns if I test on them, but I do not want to increase the amound of domains usable for sending spam, so I wondered if there is a way to leave the SPF record dangerous, but disable email a different way. – jrtapsell Jan 20 '18 at 16:07
  • 1
    In this case DMARC will not help. It is sufficient for DMARC that either DKIM or SPF matches and given that you want SPF to be dangerous it will probably match. – Steffen Ullrich Jan 20 '18 at 17:42
  • Ah, so `+SPF` and `-DKIM` results in `+DMARC`, rather than `-DMARC` – jrtapsell Jan 20 '18 at 18:00
  • 1
    Yes, if either SPF or DKIM succeeds DMARC succeeds, no matter if the other had failed. – Steffen Ullrich Jan 20 '18 at 19:02

1 Answers1

1

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?

Community
  • 1
Neil Anuskiewicz
  • 126
  • 3
  • I would prefer to have the SPF records not need anything added if possible, but if this is not possible then I think this is the best solution. – jrtapsell Jan 22 '18 at 10:13