The solution I would suggest is to put spfv2/pra records in
a sub-domain
such as _marid.company.com. While it would be nice to recommend that
people begin allowing TCP DNS queries, it is unlikely that
the highest
volume sites would ever want to implement such.
I think it was brought up earlier that using a prefix like
_marid would break the use of wildcards (can't do
_marid.*.example.com). But it wasn't clear (to me, at least)
whether wildcards would work in this application, even
without the prefix. Wildcard support would be very nice to
have, to provide symmetry with wildcard MX records for
incoming mail. Can anyone clear up whether adding the prefix
breaks wildcards, or were they already broken?
The situation with the prefix is as follows:
1) Standard (i.e. AXFR communicatable wildcards) do not work for ANY
Sender-ID use case. A wildcard only produces a match if there is
no data whatsoever in a node. This means that this type of
wildcard cannot be used to make any assertions about machines
that have a domain name entry.
2) Synthetic wildcards work fine, but are not supported in the AXFR
interchange format.
3) Prefixing does not prevent the use of wildcards, but if a
wildcard is used the advantage of using a prefix is lost.
I.E. *.example.com will match _spf1.example.com and
_spf2.example.com
4) Some tools do not support prefix use - this is not a major concern
since I would expect sender-id to be promoted mainly through
purpose driven tools not through grovelling TXT entries.
My opinion is that we should move to a prefix if we introduce a new
version identifier. Otherwise we should not. There is a value to
using a prefix but it is not by itself sufficient to make a change
worthwhile.