DNS Records for Mail Distribution

When setting up your mail server you’ll need to configure some DNS records to prevent spoofing and improve deliverability.¹ Below is an explanation of all the different records and how to configure them:

MX Records: Mail Server Designation

The mail exchanger record (MX record) specifies a mail server responsible for receiving mail for the domain. MX records consist of the exchanger—a hostname pointing to an address record (A/AAAA)—and a priority, determining the order exchangers are tried in. If multiple records have the same priority, senders must try to spread the load between them.

While senders should technically use the domain’s mail server if no MX record is set, it’s best practice to explicitly define one.

SPF Records: Sender Authorization

Sender Policy Framework (SPF) is a DNS TXT record conforming to a format specified in RFC 7208 that dictates which hosts are allowed to send mail on the domain’s behalf.

SPF records are evaluated from left to right, so the first mechanism to match a host determines the result (pass, fail, neutral, etc.). With that in mind

v=spf1 -a mx -all

would authorize any hosts in the domain’s MX records—excluding those also in its A records—and fail all others. Breaking it down:

• -a Fails hosts in the domain’s A records

• mx Passes hosts in the domain’s MX records

• -all Fails all other hosts

For a simple setup v=spf1 mx -all should work well.

DKIM Records: Message Verification

DomainKeys Identified Mail (DKIM) allows receivers of a message to cryptographically verify that certain parts of it haven’t been tampered with using the public key published in a DNS record. Most commonly, the record consists of only the version identifier and a public key. For example, the first 32 bytes of a DKIM record might look like this:

v=DKIM1;p=MIIBIjANBgkqhkiG9w0BAQ

While rarely used, there are other tags defined in the RFC, for example, setting the key type with k=.

DKIM keys are stored in the _domainkey subdomain using the s= tag in the DKIM signature. In the case of mail.jacobedwards.org, it would be a TXT record under mail._domainkey.jacobedwards.org.

Configuring DKIM on the server is beyond the scope of this document: You must sign messages before transmission, generally with the MTA.

DMARC Records: Verify Message Alignment and Define Message Handling Policies

DMARC records are placed under the dmarc subdomain building upon SPF and DKIM by enforcing alignment checks and a policy for messages that don’t pass SPF and/or DKIM checks.

In the case of SPF, alignment checks ensure the Return-Path domain matches the From domain, whereas with DKIM, the domain in the DKIM signature (d=) is checked against the From domain. By default checks are relaxed—passing as long as they’re under the same controlling domain—but using the aspf and adkim tags, an exact match can be required with strict checking.

The DMARC record consists of key=value tags. There are only two required tags:

• v (required) The version tag must have the value of “DMARC1” and must be included as the first tag
• p (required) The policy tag, one of none, quarantine, or reject. Using none can be useful when first implementing DMARC to ensure proper configuration before potentially flagging or rejecting valid messages
• rua (optional) Set the URI for aggregate reports (e.g. mailto:dmarc@domain.org)

Reporting with the rua tag is very useful in ensuring your policy is behaving as expected. (The interval of these reports can be defined in seconds with ri.) While DMARC also provides message-specific reporting using the ruf tag, implementations are not required to support this and many (including Google) don’t for privacy reasons.

Below is a basic policy which rejects messages that don’t pass the default relaxed alignment checks and specifies an address to send aggregate reports to:

v=DMARC1;p=reject;rua=mailto:dmarc@example.com

PTR Records: Allow Reverse DNS Lookups

PTR records allow reverse DNS lookups: Resolving domain names from IP addresses. PTR records are a little different in that they’re not put in your local zone file, but rather under .in-addr.arpa (or ip6.arpa for IPv6). Who controls it depends on the address, but it’s generally your ISP or cloud provider.

If the exchanger and sending domain share the same IP address, set the PTR record to the exchanger’s domain if only one PTR record can be configured.

To verify your PTR record using dig(1) , use the -x option with your IP address:

$ dig -x $(dig mail.jacobedwards.org A +short) +short
mail.jacobedwards.org.