RegistryRecords

Overview
There are two records for each Sender's Identity, one controlled by the ID owner, the other controlled by the Registry. If the Identity is example.com, the owner of that ID publishes a TXT record at _auth.example.com. The registry copies that record, validates the data, and adds ratings and other information. The final record is then published as TXT at example.com.xmid.net.

The ID Owner's record is a supplement to, not a replacement for, other authentication records. Typically, ID owners will use this record to let us know what authentication methods they offer, and to tell us the IP addresses authorized to use their ID in a HELO command.

A typical record might look like:
_auth.example.com. TXT "method=SPF,DKIM helo=192.168.92.216-8"
This tells us that example.com offers authentication using methods SPF and DKIM, and that there is only one block of 3 addresses authorized to say HELO this is example.com.

The Registry record derived from this _auth record might look like:
example.com.xmid.net. TXT "svc=X1:A,S2:A mth=SPF+5,DKIM+3 ip4=192.168.92.216-8"
The short form of each keyword is used to save space. The numbers attached to each method are the maximum number of DNS queries needed to run the method. The A ratings were obtained from services X1 and S2.

For more on record syntax and semantics, see the discussion below, try our webtool, or the read the Python script which actually parses these records.

_auth Records
Every record needs a 'helo' block, even if no authentication methods are listed. Before running any methods, we do a quick check to see that the connecting IP is authorized to use the HELO name it has offered in its request for a mail session. That simple check will reject most of the spam.

You may list HELO addresses (or address blocks) in either IPv4 or IPv6 format. If you have already published the addresses you will authorize to say HELO, you need not repeat them here. Just give us a link to those other records, like the following:
_auth.example.com. TXT "helo=mx,a"
Link keywords are case-insensitive, and include MX, A, and SPF. The advantage of using these keywords is that you don't have to remember to change your _auth record when you change the addresses in these other records. 'MX' authorizes as senders all servers listed as receivers in your MX records. 'A' authorizes any address listed in an A record for your domain. 'SPF' authorizes some of the addresses listed in your SPF record. For details see Using SPF Records to List HELO Addresses.

The next most important block in an _auth record is the 'method' block, where you can list all the authentication methods you offer (CSV, SPF, SID, DKIM, etc.). See the example in the Overview above. Method blocks are optional. A simple HELO check may be adequate for your needs. Offering a method does not guarantee that it will be used. Receivers will chose whatever method they prefer. They should not run a method you don't offer, however.

The 'service', 'method', and 'option' blocks are similar to the 'svc', 'mth', and 'opt' blocks for the Registry record described below, with the following limitations:
1) Numbers will be ignored in any method blocks. These are determined by an actual test run.
2) Service names will be taken as suggestions to include in the Registry record, but rating values will be ignored.
3) Option blocks may include the keyword stop. All others will be ignored.

_auth Record Keywords
                                 All words in an _auth record are case-insensitive
helo=     A, MX, SPF, or ip4 CIDR blocks (/24) and ranges (216-8)
service= Rating services
method=   Authentication methods
option=   Optional parameters

Registry Record Syntax and Semantics

&     Continuation character, up to 10 additional records, each with a single TXT string < 256 characters, including the & at the end.

=========== Level One Keywords ===========
svc= Rating services
mth= Authentication methods
opt= Optional parameters
ip4= ip4 blocks as ranges (216-8) or CIDR notation (/24)
ip6= ip6 blocks in :: notation

============ mth blocks ==============
mth=SPF+5,DKIM+3 kw+num,kw+num ...
kw = CSV, SPF, SID, or DKIM
num is the maximum number of DNS queries needed to run the method.

============ svc blocks ==============
svc=S1:A,H2:B    name:rating,name:rating, ...
Ratings can be a single letter, or an integer up to 3 digits.
Special Names:
X1: The default rating service, based on an average of reports from selected
receivers. Objective data only. This may be modified to factor in total volume,
but anything involving human judgement should be left to the Rating Services.
VX:<ID>     Example VX:aol.com
This is a claim that <ID> will vouch for the sender. The claim must be
verified with a query to the vouching ID. If example.org has an authentication
record saying "svc=VX:aol.com", this can be verified with a query to
_vouch.example.org.aol.com.

============ opt blocks ==============
opt=df:3,stop:all,IDlevel:3
df:    This is a default record, ID status 1...8, default is 9
stop: There are no servers authorized to use this ID.
IDlevel: Authentication and reputation records will be kept at a lower level
under this domain name. Used for .us .uk and other country codes.

IDstatus = None # No ID or invalid ID
# 0:    Unknown ID
# 1..6: IDs with default records, varying confidence.
# 7..8: IDs with authoritative records, allowing REJECT
# 9:    Authoritative record of a Registered Sender.

The above groups are stable, but further refinement within each group is still
ongoing. Here are some possibilities from recent implementations:

# 3: New record, may be missing some IPs.
#      No PASS or FAIL, accumulate stats only.
# 6: Mature record, no new IPs for a long time.
#      PASS if IP match. No FAIL. Stats on all.
# 9: Authoritative record of a registered sender.
# 8: Same as 9, but sender has not registered. They have simply published a
#    valid _auth record under their Identity.
# 7: Sender has no _auth record, but has published an unambiguous list of their
     authorized transmitters, e.g. an SPF record ending in "-all".

# 2:    ID with matching PTR record
# 3..5: Transitional records, accumulating IP blocks.
# 6:    Mature record. Still can't reject forgeries,
#           but OK for whitelisting.

#     IDstatus: 0 1 2 3 4 5 6 7 8 9
# auth_status                                  Action:
#          = 0                       x x x     Reject
#          = 9                 x x x x x     Whitelist
#          < 9           x x x                 DNShunt

auth_status is 0 for FAIL, 9 for PASS, and < 9 for anything else.
Reject at HELO is done only for IDs with authoritative records (7..9).
Whitelisting is available for IDs with mature records.
DNS hunts are done as a fallback for IDs that are important, but their records are
not yet mature.