DNS records for email are the settings in your domain's DNS zone that route your mail and prove it is genuinely from you. The core set is MX (where mail is delivered), SPF, DKIM, and DMARC (the three records that authenticate you), plus a PTR record on the IP you send from. Get all of them right and mailbox providers trust you. Miss one and your mail gets filtered or rejected.
The Domain Name System is the address book of the internet, and email leans on it heavily. When someone mails you, their server queries DNS to find your inbound servers. When you send, the receiver queries your DNS to confirm you are authorized, to verify a cryptographic signature, and to decide what to do if a check fails. None of this is visible to your recipients, but it is the difference between the inbox and the spam folder.
You need MX to receive mail, and SPF, DKIM, DMARC, and a valid PTR record to be trusted when you send. Since 2024 the largest providers require all three authentication records from bulk senders, so treat them as mandatory, not optional.
The DNS records every email domain needs
Six record types do the heavy lifting for email: MX routes your inbound mail, A and AAAA resolve hostnames to IP addresses, SPF and DKIM and DMARC authenticate your outbound mail, and PTR proves the IP you send from. The table below is your at a glance reference for what each one is and where it lives.
| Record | DNS type | Host / name | What it does | Check it with |
|---|---|---|---|---|
| MX | MX | example.com | Names the servers that receive mail for your domain, in priority order. | MX Lookup |
| A / AAAA | A, AAAA | mail.example.com | Resolve your mail hostnames to IPv4 and IPv6 addresses. | MX Lookup |
| SPF | TXT | example.com | Lists the servers allowed to send mail as your domain. | SPF Checker |
| DKIM | TXT | selector._domainkey.example.com | Publishes the public key that verifies your message signatures. | DKIM Checker |
| DMARC | TXT | _dmarc.example.com | Sets the policy and reporting for messages that fail authentication. | DMARC Checker |
| PTR | PTR | in-addr.arpa zone | Maps your sending IP back to a hostname (reverse DNS). | Reverse DNS Checker |
| BIMI | TXT | default._bimi.example.com | Points to your brand logo for mailboxes that display it. | DMARC Checker |
| MTA-STS | TXT | _mta-sts.example.com | Signals that inbound mail to you must use encrypted TLS. | MX Lookup |
| TLS-RPT | TXT | _smtp._tls.example.com | Requests reports on TLS delivery successes and failures. | MX Lookup |
How a receiver uses your DNS records
When your message arrives, the receiving server runs a quick sequence of DNS checks before it decides where to place it. It confirms the connecting IP, checks SPF, verifies your DKIM signature, then evaluates DMARC alignment and applies your policy. Each step reads a record you publish.
The first record in the chain belongs to the recipient: their MX record is what routed your message to the right server in the first place. Everything after that reads your records. If the checks line up, your mail earns the inbox. If they do not, your DMARC policy decides whether it is quarantined, rejected, or simply monitored.
MX routing
The recipient's MX record pointed your message to this server.
Reverse DNS
It checks the connecting IP has a matching PTR record.
SPF check
It confirms your SPF record authorizes that IP to send.
DKIM verify
It validates the signature against your published DKIM key.
DMARC policy
It checks alignment with your From domain and places the mail.
MX records: where your mail is delivered
MX records tell the world which servers accept mail for your domain. Each MX record carries a preference number, and a lower number is tried first. They are the only records on this list that handle inbound mail, and they are defined in RFC 5321.
An MX record pairs a preference value with a hostname, for example 10 mail1.example.com and 20 mail2.example.com. Senders try the lowest number first and fall back to higher numbers if it is unreachable. Records sharing the same number are load balanced. The hostname must resolve to an A or AAAA record, never to a CNAME and never to a bare IP address, which RFC 2181 makes explicit.
- Publish at least two MX records so mail still flows if one server is down.
- Point MX hostnames at A or AAAA records, never at a
CNAMEor an IP literal. - If a subdomain should never receive mail, publish a null MX, a single record of
0 .defined in RFC 7505. - When you have no MX record at all, senders fall back to your domain's A or AAAA record, which is rarely what you want.
A and AAAA records: the addresses behind your mail
A and AAAA records map a hostname to an IP address, A for IPv4 and AAAA for IPv6. They do not authenticate anything on their own, but email depends on them: every MX hostname must resolve to one, and your sending server needs valid forward DNS for reverse DNS to confirm.
Think of A and AAAA records as the foundation the other records stand on. Your MX hostname resolves to an A or AAAA record so mail can reach it. Your DKIM and SPF infrastructure is reached the same way. And your PTR record only counts as forward-confirmed when the hostname it returns resolves, through an A or AAAA record, back to the original IP. Modern receivers increasingly expect a working IPv6 address as well as IPv4 when you connect over IPv6.
SPF: which servers may send as you
SPF, the Sender Policy Framework, is a single TXT record at your domain root that lists every server allowed to send mail as you. Receivers compare the connecting IP against that list. SPF is defined in RFC 7208, and a domain may publish only one SPF record.
An SPF record starts with v=spf1 and ends with an all mechanism that decides what happens to everything not explicitly listed. In between you authorize sources with mechanisms like ip4, ip6, a, mx, and include. A typical record looks like v=spf1 include:_spf.example.net ip4:203.0.113.50 -all. The closing qualifier matters: -all tells receivers to fail anything unlisted, while ~all is a softer signal.
| Qualifier | Name | What receivers do |
|---|---|---|
-all | Hard fail | Reject or filter mail from unlisted sources. The recommended setting once you are confident. |
~all | Soft fail | Accept but mark as suspicious. Useful while you are still finding every legitimate sender. |
?all | Neutral | No opinion. Offers almost no protection and is rarely worth publishing. |
+all | Pass all | Authorizes the entire internet to send as you. Never use this. |
SPF allows at most 10 DNS-querying mechanisms per check. Each include, a, mx, and exists counts, and nested includes count too. Go over and SPF returns a permanent error that many receivers treat as a fail. The SPF Checker counts your lookups for you.
DKIM: a cryptographic signature on every message
DKIM, DomainKeys Identified Mail, adds a tamper-proof signature to each message and publishes the matching public key in DNS. Receivers use that key to confirm the message really came from you and was not altered in transit. DKIM is defined in RFC 6376.
The public key lives in a TXT record at selector._domainkey.yourdomain.com, where the selector is a label your sending service chooses. The record value looks like v=DKIM1; k=rsa; p= followed by a long base64 key. Because each sending service uses its own selector, you can run several DKIM keys side by side and rotate them without downtime. An empty p= value means the key has been revoked.
Use a 2048-bit key where your provider supports it; 1024-bit is the floor. A 2048-bit key is longer than the 255-character limit for a single DNS string, so it must be split into several quoted strings inside one record. Resolvers join them back together automatically, so the split is purely a DNS formatting detail.
Give every sending service its own DKIM selector. A marketing platform, a help desk, and your own mail server should each sign with a distinct selector, so you can add, audit, or retire any one of them without touching the others. Confirm each key with the DKIM Checker.
DMARC: the policy that ties it together
DMARC, Domain-based Message Authentication, Reporting and Conformance, is a TXT record at _dmarc.yourdomain.com that tells receivers what to do when SPF and DKIM do not line up with your From address, and where to send reports. It is the record that turns SPF and DKIM into enforcement, and it is defined in RFC 7489.
A DMARC record starts with v=DMARC1 and sets a policy with p=. The three policies are p=none (monitor only), p=quarantine (send failing mail to spam), and p=reject (block it outright). The rua tag is the address for daily aggregate reports, which show every source sending as your domain. DMARC passes only when SPF or DKIM passes and aligns with the domain in your visible From header.
Start at p=none
Publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com and read the reports for two to four weeks. You are watching, not blocking, while you find every legitimate sender.
Move to p=quarantine
Once your real mail passes and aligns, switch failing messages to the spam folder. Ramp gradually with the pct tag if you want to test on a fraction of mail first.
Enforce with p=reject
When you are confident nothing legitimate fails, move to reject for full protection against spoofing of your domain.
PTR and reverse DNS: proving your IP
A PTR record maps a sending IP address back to a hostname, the reverse of an A record. Many receivers reject or distrust mail from an IP with no PTR or a generic one. PTR records and the forward-confirmed check are described in RFC 1912.
PTR records are different from every other record here in one important way: they do not live in your domain's zone. They live in the reverse zone of the IP block (in-addr.arpa for IPv4, ip6.arpa for IPv6), which is controlled by whoever owns the IP, usually your hosting or cloud provider. To set or change a PTR you ask that provider, often through their control panel.
- Every IP you send from should have a PTR record pointing to a real hostname you control.
- That hostname should resolve, through an A or AAAA record, back to the same IP. This round trip is forward-confirmed reverse DNS, or FCrDNS.
- Use a meaningful name like
mail.example.com, not the generic default many cloud providers assign.
BIMI, MTA-STS, and TLS-RPT: the next layer
Beyond the core records, three newer records improve brand presence and transport security. BIMI shows your logo, MTA-STS enforces encrypted delivery to you, and TLS-RPT reports on it. None are required, but they round out a mature setup.
- BIMI is a TXT record at
default._bimi.yourdomain.comthat points to your logo. It only displays once your DMARC policy is atquarantineorreject, and major mailboxes also require a verified mark certificate. - MTA-STS (RFC 8461) is a TXT record at
_mta-sts.yourdomain.complus a policy file served over HTTPS. It tells other servers that mail sent to you must use TLS encryption. - TLS-RPT (RFC 8460) is a TXT record at
_smtp._tls.yourdomain.comthat asks senders to report TLS delivery successes and failures, so you can spot encryption problems.
How to publish your records in the right order
Add the records in a sequence that never leaves you exposed: get mail flowing first, authenticate next, and only switch on enforcement once you can see that your real mail passes. This order is the safest way to reach a full setup without breaking delivery.
Publish MX and host records
Set your MX records and make sure each MX hostname resolves to an A or AAAA record. Verify routing with the MX Lookup.
Publish one SPF record
Add a single v=spf1 TXT record at your root that lists every legitimate sender, ending in -all or ~all. Keep it under 10 lookups.
Enable DKIM signing
Turn on DKIM at each sending service and publish its selector._domainkey TXT record. Aim for 2048-bit keys.
Start DMARC at monitoring
Publish _dmarc with p=none and a rua address. Read the reports until your real mail passes and aligns, then tighten to quarantine and reject.
Set reverse DNS
Ask your IP provider for a PTR record on your sending IP that points to a hostname resolving back to that IP. Confirm with the Reverse DNS Checker.
Every record has a TTL, the number of seconds resolvers cache it before re-checking. After a change, expect most of the internet to catch up within one to four hours, with a worst case of 24 to 48 hours bounded by the old cached value. Before a planned change, lower the TTL a day ahead so updates take effect quickly.
Common DNS mistakes that break email
Most email DNS problems come from a short list of avoidable mistakes. Two SPF records, a record published at the wrong host, and a missing PTR cause more delivery failures than anything exotic. Knowing them is half the fix.
- Two SPF records. A domain may have only one
v=spf1record. A second one makes SPF return a permanent error and stop working. Merge every mechanism into a single record. - The wrong TXT host. DKIM must sit at
selector._domainkeyand DMARC at_dmarc, not at the root. Pasting either into the wrong host name is a frequent and silent failure. - Missing or generic PTR. Sending from an IP with no PTR, or the default name your provider assigned, gets mail throttled or rejected. Set a real, forward-confirmed PTR.
- MX pointing to a CNAME or IP. MX targets must be plain hostnames that resolve to A or AAAA records. A CNAME or IP literal violates the spec and can break delivery.
- SPF over 10 lookups. Stacking many third-party includes pushes you past the limit and fails SPF. Consolidate or flatten before you hit it.
- Enforcing DMARC too early. Moving straight to
p=rejectbefore your real mail passes and aligns blocks legitimate messages. Always monitor first.
Changing email providers and forgetting to update DNS. Stale MX records, old SPF includes, and dead DKIM selectors route mail to a decommissioned server or fail authentication. Audit every record whenever your sending setup changes.