Email DNS Records Explained: MX, SPF, DKIM, DMARC and PTR

Applies to: Any domain and mail service; lookups tested with dig 9.20.29 (Debian 13), zone checks with BIND named-checkzone 9.20, DKIM key from opendkim-genkey 2.11

Email uses five kinds of DNS records. MX says which server receives mail for your domain. SPF, DKIM and DMARC are TXT records that let receiving servers check that mail claiming to be from your domain is genuine. PTR (reverse DNS) gives your sending server's IP address a name. MX is all you need to receive mail; to send mail that reaches the inbox you need all five.

The records at a glance

• MX, name example.com: 10 mail.example.com. (where to deliver mail)
• SPF, TXT at example.com: v=spf1 mx ip4:192.0.2.25 -all (which servers may send)
• DKIM, TXT at SELECTOR._domainkey.example.com: v=DKIM1; k=rsa; p=... (public key that verifies message signatures)
• DMARC, TXT at _dmarc.example.com: v=DMARC1; p=none; rua=mailto:... (what to do when checks fail, and where to send reports)
• PTR, in the reverse zone of the IP: 25.2.0.192.in-addr.arpa points to mail.example.com (set by whoever owns the IP)

This lab zone with all of them passed named-checkzone (the DKIM key is shortened here):

@       IN MX  10 mail.example.com.
mail    IN A   192.0.2.25
@       IN TXT "v=spf1 mx ip4:192.0.2.25 -all"
_dmarc  IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
mail._domainkey IN TXT ( "v=DKIM1; h=sha256; k=rsa; "
          "p=MIIBIjANBg...(shortened)...QIDAQAB" )

MX record: where your mail is delivered

Each MX record has a priority and a host name. Sending servers try the lowest number first and fall back to higher ones. Gmail's MX records show this (live lookup):

$ dig +short MX gmail.com
20 alt2.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.

• The MX value must be a host name with an A or AAAA record, never an IP address and never a CNAME. BIND's checker warned about both in our lab: '192.0.2.25': MX is an address and MX 'mail.example.com' is a CNAME (illegal).
• With no MX record at all, senders deliver to the domain's own A or AAAA address (the "implicit MX" in RFC 5321). Do not rely on that: publish an MX.
• A domain that never receives mail can say so with a "null MX" (RFC 7505). example.com does this, together with an SPF record that allows no senders:

  $ dig +short MX example.com
  0 .
  $ dig +short TXT example.com
  "v=spf1 -all"
  ...

SPF record: which servers may send for you

SPF is one TXT record at the domain itself, starting with v=spf1. It lists the IPs and services allowed to send mail for the domain and ends with -all (reject the rest) or ~all (soft fail). Gmail's record simply hands over to Google's shared list:

$ dig +short TXT gmail.com
...
"v=spf1 redirect=_spf.google.com"

Rules from RFC 7208 that trip people up:

• Only one SPF record per domain. Two TXT records that start with v=spf1 give a "permerror" and SPF fails. When you add a new mail service, add its include: to the existing record.
• At most 10 DNS lookups. Every include, a, mx, ptr, exists and redirect counts, including the ones inside included records. ip4: and ip6: do not count, so list your own server IPs that way. For a server with many IPs, see how to write an SPF record for several IP addresses.

DKIM record: the key that checks signatures

DKIM signs each outgoing message with a private key on the mail server. The matching public key is published as a TXT record at SELECTOR._domainkey.yourdomain; the selector is a label your mail server or provider chooses, so you can have several keys. You never write this record by hand: you copy it from your control panel, mail provider or key generator. This is what opendkim-genkey -b 2048 -d example.com -s mail produced in our lab (shortened):

mail._domainkey	IN	TXT	( "v=DKIM1; h=sha256; k=rsa; "
	  "p=MIIBIjANBg..."
	  "...QIDAQAB" )  ; ----- DKIM key mail for example.com

A 2048-bit key is longer than the 255-character limit of a single TXT string, so it is split into several quoted strings; DNS joins them back together. A DKIM record with an empty p= means the key has been revoked (RFC 6376). We saw this on one of Gmail's older selectors: dig +short TXT 20230601._domainkey.gmail.com returned "v=DKIM1; k=rsa; p=".

DMARC record: the policy and the reports

DMARC is a TXT record at _dmarc.yourdomain. A message passes DMARC when SPF or DKIM passes and the domain that passed matches (aligns with) the domain in the visible From address. The record tells receivers what to do with mail that fails, and where to send reports:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

• p= is the policy: none (only report), quarantine (treat the mail as suspicious) or reject.
• rua= is where daily aggregate reports go. Without it, receivers send no reports.
• sp= sets a different policy for subdomains. Gmail publishes "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"; example.com, which sends no mail, publishes p=reject.
• DMARC is now RFC 9989, which replaced RFC 7489. It removed the old pct= tag and added t=y (test mode, one step softer than the policy) and np= (policy for subdomains that do not exist).

Start with p=none and read the reports until every service that sends as your domain passes. RFC 9989 suggests at least a month at p=none, then the same at quarantine, before reject. It also says a domain with p=reject must sign its mail with DKIM and not rely on SPF alone, and that domains whose users post to mailing lists should not use p=reject. Our guide to publishing DMARC and tightening the policy safely walks through it.

PTR record: reverse DNS for the sending IP

A PTR record maps an IP address back to a name. It does not live in your domain's DNS zone: it is set by whoever controls the IP address, which for a server is your hosting provider. A live example:

$ dig -x 8.8.8.8 +noall +answer
8.8.8.8.in-addr.arpa.	18719	IN	PTR	dns.google.

For a mail server, make the PTR name your server's host name (for example mail.example.com) and make sure that name's A or AAAA record points back to the same IP. Google's guidelines require exactly this: the sending IP must match the IP of the host name in the PTR record. On a Ucartz server, see how to set reverse DNS (PTR) and check forward-confirmed rDNS.

What Gmail requires

According to Google's email sender guidelines, everyone who sends to Gmail needs SPF or DKIM, valid forward and reverse DNS for the sending domain or IP, TLS for the connection, and a spam rate in Postmaster Tools below 0.3%. Senders of 5,000 or more messages a day to Gmail also need SPF, DKIM and DMARC (the policy can be none), a From domain aligned with SPF or DKIM, and one-click unsubscribe for marketing mail.

How to check all your mail records

Run these from any Linux or macOS terminal, replacing example.com, the selector and the IP with your own:

dig +short MX example.com
dig +short TXT example.com | grep spf1
dig +short TXT mail._domainkey.example.com
dig +short TXT _dmarc.example.com
dig -x 192.0.2.25 +short

Your DKIM selector is shown in the DKIM-Signature header of a message you sent, after s=.

Common mistakes

• Two SPF records after adding a newsletter or helpdesk service. Merge them into one.
• MX pointing to an IP address or a CNAME.
• DMARC published at the domain itself instead of _dmarc, or starting with anything other than v=DMARC1.
• Records added at the wrong DNS host. They only count at the name servers your domain actually uses; check with dig +short NS example.com.
• No PTR, or a generic PTR, on a server that sends mail directly.
• Trying to get around a block by switching IP addresses or domains. Fix the cause (authentication, list quality, complaint rate) instead; using IPs to evade blocks or filters is not allowed under the Ucartz acceptable use policy.

Port 25 is open on all Ucartz servers, so you can run your own mail server on a VPS or dedicated server, or choose our email server hosting.

Related articles: cPanel email deliverability: check and fix SPF and DKIM, add Google Workspace MX, SPF, DKIM and DMARC records in cPanel, DKIM signing with OpenDKIM and Postfix, DNS lookup commands: dig, nslookup and host.

Official documentation: Google email sender guidelines, RFC 7208 (SPF), RFC 9989 (DMARC).