DNS Records specific to mail services
Completed
There are several ways that mail services depend on DNS, some through "true" record types, such as MX records, some using specially formatted TXT records. Some are fairly complex, so I'll link to separate DNS Community posts for them; others are less complex, so I'll describe them in this post.
Two mail related records are used to specify what servers should receive mail for addresses in a domain and what servers are allowed to send mail from the domain. The MX record tells where to send mail, and the SPF record (a specially formatted TXT record) specifies what servers are allowed to send mail ‘from’ the domain; they are more complex than the others. Additionally there is a fairly new update to MX records, called a "NULL MX Record". Because they're more complex, there are separate articles on these:
MX Records:
https://dns.ultraproducts.support/hc/en-us/community/posts/26476845210395-MX-Records
NULL MX Records:
https://dns.ultraproducts.support/hc/en-us/community/posts/26150271295003-NULL-MX-Records
SPF Records:
With those out of the way, there are two other record types now commonly used as part of the mail process, the DMARC and DKIM records. Both are specially formatted TXT records. DKIM (an acronym for "Domain Keys Identified Mail") records provide a way to verify that a message actually is intact and "as sent" by providing a public key that can be used to verify a message signature. DMARC (an acronym for "Domain Message Authentication Reporting and Conformance") records tell outside mail servers what to do if someone tries to send mail from a host not named in the domain's SPF record or if a DKIM signature fails.
The DKIM record provides the public half of a public/private key pair which is used to sign outgoing mail from the domain. NOTE: while this provides for a "cryptographic" signature, it does NOT mean that the message itself is encrypted; it is a key that can be used to verify that the message is intact.
DKIM records are TXT records with the domain name ending with "_domainkey.zone.name" (e.g. "_domainkey.example.com"); it's possible to add a "selector" ahead of that. For example, you might want different keys for marketing and engineering, so you might have "marketing._domainkey.example.com" and "engineering._domainkey.example.com". The rdata for a DKIM record, as well as the mechanism for signing and for selecting which DKIM record to use, are somewhat complex and best handled by the mail team, not the DNS team. The same is generally true for testing DKIM records. But it can be useful to have an idea of how to check that DKIM is working as expected. One method often recommended for looking at DKIM validity is to send DKIM signed mail to a gmail account, then to look at the headers. (Using gmail from a browser, you can click the menu at the right of the header line, and select "Show original"; with luck, you'll see something like:
DKIM: 'PASS' with domain amazon.comIf it fails the DKIM process, the mail will probably either not appear or will be in your spam folder.
A somewhat more robust site for testing DKIM configuration is:
You can send email and get an evaluation of whether it passes both DKIM and SPF testing. Sending mail to their site with a made up address (they even offer a random address to test with) will let you see how their mail system sees it, looking at the original mail headers, whether it passed DKIM evaluation, whether it passes SPF evaluation and what it's SpamAssassin score is. (SpamAssassin isn't a "mail record" in the same sense as DKIM or DMARC records, but it's often of interest to your mail team.)
DMARC (Domain Message Authentication Reporting and Conformance) records tell what to do if incoming mail fails either DKIM or SPF checks. It allows requesting that the bad messages be quarantined, requesting that they be completely rejected,, or requesting that the actually be delivered anyway. It also allows requesting a notification if there are problems, so your mail team can work on whatever is wrong.
DMARC records are another stylized TXT record, with the name "_dmarc.domain.name"; the rdata (the data part of the record) must begin with "v=DMARC1; " followed by your policy for what to do with offending email. There can be further configuration, such as requesting reports of problems, and directives about how strictly to apply policies. Almost all of this is basically in the domain of your mail team, not your DNS team.
As an example of a DMARC record Vercara's is a TXT record for _dmarc.vercara.com with:
"v=DMARC1; p=quarantine; rua=mailto:aggregate@vercara.com; ruf=mailto:forensic@vercara.com; sp=reject"In this DMARC record, the policy is "quarantine", meaning that the sender (Vercara) thinks that bad mail should be delivered, but to a junk or spam folder, so people are aware that it's probably not good. (As mentioned earlier, you can also request that it be delivered normally (though outside initial testing periods, that would be strange), or completely rejected.)
This DMARC record also requests two sorts of reports of problems. They have keys starting with “ru” (for Reporting URI) One is configured to request an aggregate report with "rua=" (the "a" is short for “Aggregate”); it says send a daily report of DKIM and SPF issues to a particular mail address. The Vercara DMARC record also specifies an "ruf=" (the "f" is for “Forensic”) report; that's a more detailed report about each email "from" vercara.com that fails either DKIM or SPF checks. Finally this DMARC record specifies "sp=reject", which specifies Vercara's Subdomain Policy (reject means "if the mail says it's from a subdomain under vercara.com, reject it.)
There are quite a few other things which can be done with DMARC records (e.g. you can specify that the rua= report should be sampled, not including every email.)
As mentioned earlier, the actual details within the DMARC record really fall into the domain of your mail team, though they may need a bit of help actually creating or modifying the record.