= Email DNS Records = For a public email server, a set of [[Protocols/DNS|DNS]] records are effectively mandatory. <> ---- == 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]]). ---- == 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. [[Email/MTA|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:postmaster@somewhereelse.com"`. 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:postmaster@somewhereelse.com"`) These will prevent spoofing of the domain. ---- CategoryRicottone