DNS Records for Email — A Complete Guide

Why DNS Records Matter for Email

Every email you send or receive depends on DNS records configured for your domain. DNS records determine where emails are delivered, who is authorized to send them, and how the sender's identity is verified. Misconfigured DNS leads to bounced emails, failed authentication, or your domain being exploited for phishing.

This article covers all DNS record types relevant to email — from MX records through authentication TXT records to reverse DNS. For each type, you'll find an explanation, example, and actionable recommendations.

MX Records — Where Emails Are Delivered

An MX record (Mail Exchange) tells sending servers which mail server should receive email for your domain. Without an MX record, your domain cannot receive emails.

How MX Records Work

When someone sends an email to info@yourdomain.com, the sending server queries DNS for the MX records of yourdomain.com. DNS returns one or more mail servers with priority values. The server with the lowest priority number (= highest priority) is tried first.

MX Record Example

yourdomain.com.  3600  IN  MX  10 mx1.mailserver.com.
yourdomain.com.  3600  IN  MX  20 mx2.mailserver.com.

• Priority 10 — primary server (mx1.mailserver.com)
• Priority 20 — backup server (mx2.mailserver.com), used when the primary is unavailable

MX Records for Common Services

Since 2023, Google Workspace requires only 1 MX record (smtp.google.com with priority 1). The legacy 5-record setup still works — see the Google Workspace documentation for details.

MX Record Rules

• MX records must point to a hostname, not an IP address — RFC 5321, Section 5.1
• The target hostname must have its own A record (or AAAA for IPv6)
• MX records must not point to a CNAME — this violates RFC 2181
• If you don't use a domain for email, set up a null MX: priority 0, target . (dot)

TXT Records — Authentication and Verification

A TXT record is a versatile DNS record type that stores text data. For email, TXT records publish authentication policies — SPF, DMARC, and domain ownership verification.

SPF Record

SPF (Sender Policy Framework) defines which servers are authorized to send email from your domain. It is published as a TXT record on the root domain.

yourdomain.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

This record authorizes sending through Google Workspace and SendGrid. Everything else is rejected (-all).

Key rules:

• A domain may have only one SPF record — multiple records cause a PermError (RFC 7208, Section 4.5)
• Maximum 10 DNS lookups during evaluation (RFC 7208, Section 4.6.4)
• Step-by-step guide: How to Create an SPF Record

DMARC Record

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM to the From header address and defines how to handle unauthenticated emails. It is published as a TXT record on the _dmarc subdomain.

_dmarc.yourdomain.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:yourdomain.com@rua.spfmonitor.com; pct=100"

Step-by-step guide: How to Set Up DMARC

Domain Ownership Verification

Many services (Google Workspace, Microsoft 365, marketing platforms) require domain ownership verification by adding a specific TXT record:

yourdomain.com.  3600  IN  TXT  "google-site-verification=AbCdEf123456"

Unlike SPF, you can have multiple TXT records on a domain for different purposes — verification records, SPF, and others coexist without conflict.

CNAME Records — DKIM and Delegation

CNAME (Canonical Name) records create an alias from one domain name to another. For email, CNAME records are primarily used for DKIM signatures.

DKIM Records

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email. The recipient verifies the signature using a public key published in DNS. DKIM records are placed on a subdomain in the format {selector}._domainkey.yourdomain.com.

Most email services require a CNAME record that delegates DKIM to their infrastructure:

selector1._domainkey.yourdomain.com.  3600  IN  CNAME  selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com.

This example shows DKIM delegation for Microsoft 365 — the CNAME points to a key managed by Microsoft.

Some services require a direct TXT record with the public key:

mail._domainkey.yourdomain.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Step-by-step guide: How to Set Up DKIM

BIMI Record

BIMI (Brand Indicators for Message Identification) displays the sender's logo in the recipient's email client. It is published as a TXT record on the default._bimi subdomain:

default._bimi.yourdomain.com.  3600  IN  TXT  "v=BIMI1; l=https://yourdomain.com/logo.svg"

BIMI requires a working DMARC policy set to quarantine or reject.

PTR Records — Reverse DNS

A PTR record (Pointer) is a reverse DNS record — it maps an IP address back to a domain name. Receiving mail servers use PTR records to verify that the sending server has a valid reverse DNS entry.

Why PTR Records Matter

Many mail servers (including Gmail) reject or penalize emails from servers without a valid PTR record. The PTR record should match the HELO/EHLO hostname (the greeting the mail server uses to identify itself when establishing a connection) of the sending server.

Who Manages PTR Records

PTR records are not managed by the domain owner but by the IP address provider (hosting company, ISP, or cloud provider). If you run your own mail server:

1. Contact your IP address provider
2. Request a PTR record for your server's IP
3. The PTR should point to a hostname that has a matching A record resolving to the same IP (forward-confirmed reverse DNS)

If you use a service like Google Workspace or Microsoft 365, PTR records are managed by the provider — no action needed on your end.

How DNS Records Work Together

When an email is delivered, the receiving server performs a series of checks that depend on different DNS records:

1. MX lookup — the sending server determines where to deliver the email
2. SPF check — the receiving server verifies that the sending IP is authorized in the SPF record of the envelope sender domain
3. DKIM verification — the receiving server retrieves the public key from DNS and verifies the signature in the email header
4. DMARC evaluation — the receiving server checks alignment (domain matching) and applies the policy from the DMARC record
5. PTR check — the receiving server verifies the reverse DNS of the sending server

Any missing or misconfigured record can result in undelivered email or spam classification.

DNS Record Checklist for Email

Use this checklist to audit your domain's DNS configuration:

• MX records — point to the correct mail servers, targets have valid A records
• SPF record — single v=spf1 TXT record, includes all legitimate senders, stays within the 10 DNS lookup limit
• DKIM records — CNAME or TXT records for each sending service with the correct selector
• DMARC record — TXT record on the _dmarc subdomain with a defined policy and report address
• PTR record — if running your own server, reverse DNS matches the server hostname
• No conflicts — no duplicate SPF records, no CNAME on the root domain alongside MX

Common DNS Mistakes for Email

Missing MX Record

Without an MX record, emails fall back to the domain's A record (RFC 5321). This only works if a mail server is running at that IP — which is not the case for most web servers.

Duplicate SPF Records

The second most common issue. An administrator adds a new SPF record instead of editing the existing one. Result: PermError — SPF check fails for all emails.

CNAME at the Root Domain

A CNAME record at the root domain (yourdomain.com) is technically invalid and can conflict with MX and TXT records. Some DNS providers work around this with proprietary solutions (Cloudflare CNAME flattening, Route 53 alias records), but avoid it for email-related records.

Low TTL on Stable Records

MX records and authentication records rarely change. A TTL of 300 seconds (5 minutes) creates unnecessary DNS traffic. Use a TTL of 3600 (1 hour) or higher for stable records.

Forgotten DKIM After Migration

When switching to a new email service, administrators often configure new MX records but forget to update DKIM records. The old DKIM key stops working, and DKIM verification starts failing.

DNS Records Require Ongoing Maintenance

DNS configuration changes over time — you add services, switch providers, rotate DKIM keys. A one-time check is not enough. Regular DNS monitoring catches issues before they affect your email deliverability.

Check your complete DNS configuration with the SPFmonitor domain analyzer — it verifies MX, SPF, DKIM, DMARC, and other records in one place.