Email DNS Records
For a public email server, a set of DNS records are effectively mandatory.
Contents
MX Records
An MX record indicates the domain(s) that should receive mail directed to a (sub)domain.
Multiple target domains can be defined and they will be tried in order according to their priority. The standard is to set the primary mail server with priority 10, then the secondary with priority 20, and so on.
Every (sub)domain that should be able to receive mail must have it's own set of MX records.
The target domain of any MX record should resolve to an A or AAAA record, never a CNAME record nor an IP address. The reason being that reverse DNS is separately required (see PTR Records).
PTR Records
Every mail server that is targeted by an MX record must additionally have a PTR record published to ensure that reverse DNS lookups match.
A PTR record is published for an IP address like 1.2.3.4 as 4.3.2.1.ip-addr.arpa. The record then targets the fully qualified domain name of the host at the IP address.
If hosting through a provider, e.g. AWS, it may be necessary to configure the PTR record within their service.
MTAs, when initiating the connection with a mail server, will parse the name that a recipient server declares. They will then look up the IP address of that name and check if the current connection is with that address exactly. If there is a mismatch, some MTAs will drop the connection.
SPF Record
The sender policy framework (SPF) declares which, if any, other domains are allowed to send mail on behalf of a domain. SPF records are TXT records published on all (sub)domains serving as mail servers.
Try: "v=spf1 mx ~all". In this case, mx means that the MX record(s) of the domain should be looked up for allowed addresses. Alternatively:
mx can also be specified like mx:example.com to indicate that the MX record(s) of example.com should be looked up.
a:example.com indicates that the IP address pointed to by the A record of example.com is allowed.
ip4:1.2.3.4 indicates an exact IP address that is allowed.
ip4:1.2.3.4/8 indicates a subnet that is allowed.
See also the ipv6: option.
include:_spf.google.com indicates that the SPF record at _spf.google.com should be read as aprt of this policy. This is used when, for example, an external party with separate SPF administration is authorized to send mail for a domain.
The ~all indicates that failing mail should be accepted but marked as insecure (and possibly sent to Spam inboxes). Alternatives are -all (indicating that failing mail should be rejected) and +all (indicating that any domain can send on behalf of this domain). These directives must be the final part of the SPF value.
DKIM Record
DMARC Record
A DMARC record publishes a DMARC policy. The basic DMARC policy is published as a TXT record on the _dmarc subdomain with a value of "v=DMARC1; p=reject; adkim=s; aspf=s;". This policy dictates that any email failing SPF and DKIM checks should be rejected. (In other words, one or the other must pass.)
The s indicates strict mode. The alternative is relaxed mode, set with an r. The difference is not well defined, but generally means that example.com will match sub.example.com in relaxed mode but not strict mode. Try: "v=DMARC1; p=reject; adkim=s; aspf=s;".
DMARC Report Records
When a DMARC check fails, a report is generated. But because that check failed, it isn't possible to forward this report to the domain itself. Instead, an alternative administrative email should be defined on the DMARC record itself. Try: "v=DMARC1; ... rua=mailto:[email protected]".
Like DMARC records, DMARC report records are specially-named and specially-formatted TXT records. They should be published as subdomains like NAME._report._dmarc with a value of "v=DMARC1". The NAME is a pattern describing external domains that are allowed to send DMARC reports to this domain. In the absence of such an allowance, DMARC reports may be discarded rather than forwarded. Publish as many DMARC report records as is necessary. Alternatively, to accept DMARC reports from any domain, publish a wildcard record at *._report._dmarc.
Disabling mail
In addition to all of the above, the best practice for any domains that should not send mail is to publish:
an SPF record indicating that all mail should be rejected ("v=spf1 -all")
an empty DKIM record ("v=DKIM1; p=")
a strict DMARC record ("v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]")
These will prevent spoofing of the domain.