Digging through the code of the SPF library we're using in trustymail (which was written by an author of the SPF RFC), I can confirm the following:
The exception class that results in ambiguous being returned is called AmbiguityWarning (i.e. not AmbiguityError).
AmbiguityWarning is raised if strict == 2 (the highest setting) and we receive a truncated UDP reply. (This doesn't apply to trustymail since we use TCP for our DNS queries to avoid this.)
AmbiguityWarning is raised if strict == 2 (the highest setting) and the obsolete default modifier is used.
AmbiguityWarning is raised if strict == 2 (the highest setting), both TXT and SPF (type 99) DNS records are present, and they do not agree.
AmbiguityWarning is raised if strict == 2 (the highest setting), the mx mechanism is used, and there are no MX records present.
AmbiguityWarning is raised if strict == 2 (the highest setting), the a mechanism is used, and there are no A records present.
AmbiguityWarning is raised if strict == 2 (the highest setting), the ptr mechanism is used, and there are no PTR records present.
AmbiguityWarning is raised if strict == 2 (the highest setting), and there is a CNAME loop.
We have been treating these conditions as SPF errors, but it makes more sense to treat them as warnings. Therefore I modified the code so that it logs these conditions as warnings (so that they will appear in the CSV that is attached to the report) but does not label the SPF as "invalid" in response.
treas.gov is one host that was being incorrectly labeled as having invalid SPF, since is uses the mx mechanism but does not have any MX records.
Digging through the code of the SPF library we're using in
trustymail(which was written by an author of the SPF RFC), I can confirm the following:AmbiguityWarning(i.e. notAmbiguityError).AmbiguityWarningis raised ifstrict == 2(the highest setting) and we receive a truncated UDP reply. (This doesn't apply totrustymailsince we use TCP for our DNS queries to avoid this.)AmbiguityWarningis raised ifstrict == 2(the highest setting) and the obsoletedefaultmodifier is used.AmbiguityWarningis raised ifstrict == 2(the highest setting), bothTXTandSPF(type 99) DNS records are present, and they do not agree.AmbiguityWarningis raised ifstrict == 2(the highest setting), themxmechanism is used, and there are noMXrecords present.AmbiguityWarningis raised ifstrict == 2(the highest setting), theamechanism is used, and there are noArecords present.AmbiguityWarningis raised ifstrict == 2(the highest setting), theptrmechanism is used, and there are noPTRrecords present.AmbiguityWarningis raised ifstrict == 2(the highest setting), and there is aCNAMEloop.We have been treating these conditions as SPF errors, but it makes more sense to treat them as warnings. Therefore I modified the code so that it logs these conditions as warnings (so that they will appear in the CSV that is attached to the report) but does not label the SPF as "invalid" in response.
treas.govis one host that was being incorrectly labeled as having invalid SPF, since is uses themxmechanism but does not have anyMXrecords.