DNS records for email: MX, SPF, DKIM, DMARC and PTR explained

Email runs on DNS. When someone writes to you, their server asks DNS where to deliver. When you write to them, their server asks DNS whether you are allowed to send, whether your signature is valid and what to do if it is not. Every one of those answers comes from a record in your zone.

This guide covers every record that matters for email, what each one looks like, where it lives, how to publish them in a safe order and how to check they work. If you want the deeper theory behind SPF, DKIM and DMARC, pair it with the email authentication guide.

The records at a glance

How a receiving server reads your DNS

Here is what happens, in order, when your message reaches another provider:

1. Routing. Your server looked up the recipient’s MX record to find where to connect. That record belongs to them.
2. Reverse DNS. The receiver looks up the PTR record for your connecting IP and checks that the hostname resolves back to the same IP.
3. SPF. It fetches the SPF record of your Return-Path domain and checks whether the IP is authorized.
4. DKIM. It reads the selector from the DKIM-Signature header, fetches the public key and verifies the signature.
5. DMARC. It fetches _dmarc for your From domain, checks alignment and applies your policy.

Every step after the first reads a record you control. A gap at any step lowers trust or triggers a rejection such as 5.7.25 (reverse DNS failed) or 5.7.26 (authentication failed).

MX records: where your mail is delivered

MX (mail exchanger) records tell senders which hosts accept mail for your domain. Each has a preference number; lower numbers are tried first.

example.com.   3600  IN  MX  10  mx1.example.com.
example.com.   3600  IN  MX  20  mx2.example.com.
mx1.example.com.  3600  IN  A  198.51.100.10
mx2.example.com.  3600  IN  A  198.51.100.11

Senders try mx1 first and fall back to mx2. Records with the same preference share load.

Good practice:

• Publish at least two MX hosts, or use a provider (Google Workspace, Microsoft 365) whose MX hosts are already redundant.
• Point MX at hostnames with A or AAAA records. Never at a CNAME, never at an IP literal.
• For a domain or subdomain that should never receive mail, publish a null MX (RFC 7505): a single record 0 ..
• With no MX at all, senders fall back to the domain’s A record, which is rarely what you want.

If you send from a subdomain such as news.example.com, it also helps to have a working MX there (or on the Return-Path domain) so bounces and replies have somewhere to go. Some receivers check that the sending domain can receive mail.

A and AAAA records: the addresses underneath

A records map a hostname to an IPv4 address; AAAA records map to IPv6. They do not authenticate anything, but everything else depends on them. MX hosts must resolve through them, and your PTR only counts as forward-confirmed if the hostname it returns resolves back to the same IP.

If you send over IPv6, be aware that Gmail and others apply stricter checks to IPv6 senders: PTR and authentication must be in place or you will see rejections.

SPF: which servers may send as you

SPF is a single TXT record at the domain (or at the Return-Path subdomain your ESP uses). It lists authorized senders and ends with an all rule for everything else.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:_spf.yourprovider.com ip4:198.51.100.20 -all"

Two rules catch most people out:

• One record only. Merge every service into a single v=spf1 string.
• Ten lookups maximum. Every include, a, mx, exists and redirect counts, including nested ones. Exceed it and SPF returns permerror.

The SPF Checker counts lookups for you, and the SPF Generator builds a valid record from a list of services.

DKIM: the public key for your signatures

DKIM keys live at selector._domainkey.yourdomain. The selector is a label chosen by the sending service. Each service gets its own, so you can run several side by side.

google._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx7..."
    "...wIDAQAB" )

s1._domainkey.example.com.  3600  IN  CNAME  s1.domainkey.u1234.wl.esp-example.net.

The first example is a TXT record containing the key directly. The second is a CNAME that delegates the key to your ESP, which lets them rotate it without you editing DNS. Both are normal. Publish whichever form your provider gives you, exactly as given.

Tips:

• Use 2048-bit keys where the provider allows it. They exceed the 255-character DNS string limit, so the value is split into multiple quoted strings in one record. Resolvers join them automatically.
• Do not add extra quotes, spaces or line breaks when pasting. A broken key fails silently.
• Many DNS panels append your domain automatically. Enter s1._domainkey, not s1._domainkey.example.com, or you will end up with s1._domainkey.example.com.example.com.

DMARC: policy, alignment and reports

The DMARC record sits at _dmarc.yourdomain. It tells receivers what to do when mail fails aligned SPF and DKIM, and where to send reports.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1"

Roll it out in three stages:

1. Monitor with p=none. Collect aggregate reports for two to six weeks and identify every legitimate sender.
2. Quarantine with p=quarantine. Failing mail goes to spam. You can use pct= to apply it to a fraction first.
3. Enforce with p=reject. Failing mail is refused. Full spoofing protection.

If reports go to a mailbox on another domain (common with DMARC reporting services), that domain must publish an authorization record such as example.com._report._dmarc.reportingvendor.com. Most vendors do this for you. Build a record with the DMARC Generator and validate it with the DMARC Checker.

PTR and reverse DNS: proving your IP

A PTR record maps an IP address back to a hostname. It is the only record in this guide that does not live in your own zone. It lives in the reverse zone of the IP block (in-addr.arpa for IPv4, ip6.arpa for IPv6), controlled by whoever owns the IP.

20.100.51.198.in-addr.arpa.  3600  IN  PTR  mail.example.com.
mail.example.com.            3600  IN  A    198.51.100.20

The pair above is forward-confirmed reverse DNS (FCrDNS): the IP points to a name, and the name points back to the same IP. Receivers expect this for every sending IP.

• Use a meaningful hostname on your own domain, such as mail.example.com, rather than a generic cloud default like ec2-198-51-100-20.compute.amazonaws.com.
• Set it through your hosting or cloud provider’s reverse DNS setting, or ask your ESP if you have a dedicated IP with them.
• On shared ESP IPs, the provider handles PTR for you.

Missing or mismatched PTR records trigger throttling and rejections, especially at Microsoft and Gmail. Test yours with the Reverse DNS Checker.

BIMI, MTA-STS and TLS-RPT: the optional layer

Once the core records are solid, three newer standards round out a mature setup.

BIMI

BIMI (Brand Indicators for Message Identification) displays your logo next to your messages in supporting inboxes such as Gmail, Yahoo and Apple Mail.

default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/vmc.pem"

It requires DMARC at quarantine or reject, a logo in the SVG Tiny PS format and, at most major providers, a Verified Mark Certificate or Common Mark Certificate.

MTA-STS

MTA-STS (RFC 8461) tells other servers that mail sent to you must use TLS with a valid certificate. It combines a TXT record with a policy file served over HTTPS.

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20260922"

The policy file lives at https://mta-sts.example.com/.well-known/mta-sts.txt and lists your MX hosts and a mode (testing or enforce).

TLS-RPT

TLS-RPT (RFC 8460) asks senders to report TLS problems when delivering to you.

_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Start MTA-STS in testing mode with TLS-RPT enabled, read the reports, then move to enforce.

A complete example zone

Here is how the records fit together for a company that uses Google Workspace for staff mail, a marketing platform on a news subdomain and its own server for application alerts.

; Inbound mail
example.com.                    3600 IN MX    1  smtp.google.com.

; Outbound authentication on the root domain
example.com.                    3600 IN TXT   "v=spf1 include:_spf.google.com ip4:198.51.100.20 -all"
google._domainkey.example.com.  3600 IN TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
app._domainkey.example.com.     3600 IN TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.             3600 IN TXT   "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com"

; Marketing subdomain, its own SPF and DKIM
news.example.com.               3600 IN TXT   "v=spf1 include:_spf.yourprovider.com -all"
s1._domainkey.news.example.com. 3600 IN CNAME s1.domainkey.yourprovider.net.
news.example.com.               3600 IN MX    10 bounce.yourprovider.net.

; Application server
mail.example.com.               3600 IN A     198.51.100.20
; PTR set at the hosting provider: 198.51.100.20 -> mail.example.com

A few things to notice. The root and the news subdomain each have exactly one SPF record, and each stays well under 10 lookups. Every sending service has its own DKIM selector. One DMARC record at the root covers both, with sp= setting the default for subdomains. The application server’s IP has a PTR record that matches its A record.

How to look up records yourself

Our tools do this for you, but it helps to know the command-line equivalents when you are debugging.

dig +short MX example.com
dig +short TXT example.com
dig +short TXT google._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 198.51.100.20

On Windows, nslookup -type=TXT _dmarc.example.com does the same job. If dig returns nothing for a record you just published, check the host name first (a doubled domain is the usual culprit), then wait for the TTL to expire.

Publishing the records in a safe order

Work in an order that never leaves your mail exposed or blocked.

1. MX and host records. Make sure inbound mail flows and each MX host resolves. Confirm with the MX Lookup.
2. One SPF record. Include every sending service. End with ~all while you confirm.
3. DKIM for each service. Enable custom DKIM in each platform and publish each selector.
4. DMARC at p=none. Start collecting reports.
5. Reverse DNS. Set PTR for any IP you control and confirm FCrDNS.
6. Tighten. Move SPF to -all and DMARC to quarantine, then reject, once reports are clean.
7. Optional extras. Add MTA-STS, TLS-RPT and BIMI.

TTL and propagation

TTL is how long resolvers cache a record, in seconds. After a change, most of the internet sees the new value within one to four hours, with a worst case of 24 to 48 hours set by the old TTL. For planned migrations, lower the TTL to 300 seconds a day ahead, make the change, verify, then raise it back to 3600 or higher. The ESP migration playbook uses this approach when moving providers.

Protecting domains that do not send mail

Spammers love domains that have no email records, because nothing stops them from forging those domains. If you own parked domains, old brand domains or domains used only for websites, publish a “no mail” set:

parked-example.com.         3600 IN MX   0 .
parked-example.com.         3600 IN TXT  "v=spf1 -all"
_dmarc.parked-example.com.  3600 IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
*._domainkey.parked-example.com. 3600 IN TXT "v=DKIM1; p="

The null MX says the domain accepts no mail, the empty SPF record says no server may send for it, and the reject policy tells receivers to refuse anything claiming to come from it. The wildcard DKIM record with an empty key is optional but signals that no valid key exists. The aggregate reports will show you if anyone tries to abuse the domain anyway.

Common DNS mistakes that break email

Checking everything in one pass

After any DNS change, check each record individually with the tools above, then run the domain through the Sender Reputation Checker to see authentication, reverse DNS and blocklist status together. Send a test message to a Gmail account and look at the authentication results in the headers with the Header Analyzer. You want to see spf=pass, dkim=pass and dmarc=pass.

Correct DNS is the foundation, not the whole building. With it in place, turn to list quality and engagement in the deliverability playbook.