Now that DMARC is widely deployed, here are a few useful tricks to have up your sleeve when looking up their relevant DNS records. DMARC resolutions involve both SPF and DKIM resolutions. Often, IT admins will have to troubleshoot SPF and/or DKIM failures to determine why a DMARC record is also failing validation. In Windows, a quick way to check DMARC records is to use nslookup from the good ol’ command prompt. Click “Windows Logo Key + R” to bring up the Run command window and type cmd, hit enter and your command prompt will pop up. Note that nslookup is not exclusive to Windows, it’s just that the example I’m outlining is done in Windows and nslookup is the default query tool.
Let us examine the following screenshot in detail:
Let’s go through them, step by step.
1. Start nslookup
2. While you could do all the DNS lookups using your local DNS server, in this example I specify the DNS server I’d like to query as 220.127.116.11 (a google public DNS server). Often when troubleshooting DNS issues for your own domains, it is helpful to query external DNS servers as your internal DNS servers might not reflect what the world is seeing. The command is server 18.104.22.168
3. All SPF/DKIM and DMARC records are TXT records, so here I specify that I want TXT record responses. The command is set type=TXT
4. I query the TXT records for gmail.com. Here you see the answer “v=sp1 redirect=_spf.google.com”. You could further lookup _spf.google.com’s SPF TXT records by simply typing _spf.google.com. Explaining SPF records is beyond the scope of this article but there are several online SPF validators out there (e.g. http://www.kitterman.com/spf/validate.html) should you want to analyze your SPF record in detail. Briefly, given the IP address of the connecting mail server, by recursively examining the SPF record of the return path (MAIL FROM) domain, one checks for the presence of the IP address in the list of authorized IP addresses in the ip4 or ip6 fields of the SPF record. The following screenshot shows this recursive lookup for gmail.com:
An SPF check is valid if the connecting MTA’s IP address is in the list of authorized addresses. Let us now return to the previous screenshot and continue going through the steps.
5. Here I query the DKIM record for gmail.com. One does this by specifying the selector appended to _domainkey.gmail.com. In this example the selector is 20161025. So the query is done for 20161025._domainkey.gmail.com. Selectors can be found in DKIM records which are in the email headers. The gmail DKIM signature I used for this example was:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
6. Note the s=20161025 part above, is the selector that is used to make the query. The result of the query gives us the public key (p= field) that can be used to decrypt the hash provided in the DKIM signature so that one can validate that the headers and body specified in the DKIM header have not been tampered.
7. Finally, we query for the DMARC policy. This is done simply by prepending _dmarc to the domain gmail.com, to get _dmarc.gmail.com. Of interest here is the p= field. p can be none, reject or quarantine. “none” means, do nothing upon DMARC validation failure, i.e. let the email through. reject means don’t deliver the message. “quarantine” means to send the message to the end users’ quarantine. For a DMARC validation to pass, SPF and/or DKIM validations should pass and the domain from either of the passing algorithms (return path (MAIL FROM) domain for SPF, domain specified in the d= field in the DKIM signature for DKIM) must align with the header from domain. Alignments can be strict or relaxed depending on the presence of adkim= and aspf= fields. If those values are s, it means a strict alignment is required (i.e. the domains must match exactly). If they are r values (the default), subdomains can match the domains too. DMARC records are typically quite simple however with only a p= field and a rua field. The rua field is to specify the email address where daily reports should be sent. Most of the other remaining field are to specify the types and frequencies of the reports the rua email address expects to receive.