|
Size: 3667
Comment:
|
Size: 3696
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 65: | Line 65: |
| Like DMARC records, '''DMARC report records''' are specially-named and specially-formatted TXT records. They should be published as subdomains like `NAME._report._dmarc`. 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`. | 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`. |
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
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.