Santronics Online | ![]() |
This wizard helps prepare the ZONE records for DKIM ADSP authorized third party policies. It also allows you test it against various signer domains. Read Description Below
AUTHOR-DOMAIN | The domain part of the email message From: header field |
SIGNER-DOMAIN | The domain in the DKIM-Signature d= tag is the responsible signer of the message. |
1st Party Signature | This is when the AUTHOR-DOMAIN and SIGNER-DOMAIN are the same. |
3rd Party Signature | This is when the AUTHOR-DOMAIN and SIGNER-DOMAIN are NOT the same. |
ADSP is a policy layer for DKIM. It is an optional protocol to help protect domain signers against unauthorized signing (spoofing and phishing).
The following IETF documents provide the details:
New extensions to ADSP offers a way to authorized third party signatures. The ATPS proposal adds an optional tag to the ADSP record called "atps=y". If set, then additional TXT records per signer can be checked for authorization. The ASL proposal combines a simple lite weight method to define a list of allowed signers in a ADSP record tag called "asl=".
Example ADSP records: #1 _adsp._domainkey.example.com = dkim=all; #2 _adsp._domainkey.example.com = dkim=all; asl=gmail.com #3 _adsp._domainkey.example.com = dkim=all; atps=y; asl=gmail.com
In example #1, there is no third party authorization preparation. Only example.com can sign its own mail. However, ambiguities in the ADSP specifications can allow for others to sign for example.com.
In example #2, example.com is declaring only itself and gmail.com can sign mail on its behalf.
In example #3, example.com is declaring only itself and gmail.com can sign mail on its behalf. However, with atps=y set, other third party signers may be authorized using atps DNS txt records using a special hashing method to prepare the sub-domain record:
base32(sha1(SIGNER-DOMAIN))._atps.example.com
The SIGNER-DOMAIN is obtain from the DKIM-Signature d= tag value.
This wizard helps prepare the ZONE record for all the ASL/ATPS options. It also allows you test it against various signer domains. The two proposed changes to ATPS:
[_] Add ATPS record value with domain name [_] Support ATPS Sub Domains Lookups
The first one is designed to help with manual editing of zone files to help associate the signer domain ATPS hashes.
The second option allows you to create a single ATPS record for the originating domain sub-domains using a wildcard hashing of the author-domain, i.e. *.example.com.
The ASL draft is still under construction. The following are the steps the ADSP ASL/ATPS verifier will perform:
1) Obtain the AUTHOR-DOMAIN and perform TXT query the ADSP record to obtain the value.: _adsp._domainkey.AUTHOR-DOMAIN 2) If no ADSP record is found (NXDOMAIN), return ADSP=NONE 3) Obtain the SIGNER-DOMAIN and compare with the AUTHOR-DOMAIN If the two domains are the same, return ADSP=PASS, otherwise continue with third party authorization checking. 4) If an asl= tag is present, check the SIGNER-DOMAIN within the asl= list of domains. See section X.XX for asl= parsing rule. If SIGNER-DOMAIN is found in the asl= list, return ADSP=PASS 5) If an atps=y tag is present, perform the steps as outlined in [ATPS] 6) return ADSP=FAIL