Infrastructure

DNS Records for Email

A practical guide to every DNS record type that affects email delivery. Learn what each record does, how to configure it, and how to verify it is working correctly.

DNS and Email: The Connection

The Domain Name System (DNS) is the foundation of email routing and authentication. When someone sends you an email, the sending server queries DNS to find out where to deliver it. When you send email, receiving servers query your DNS to verify your identity and authorization.

Five types of DNS records are directly involved in email delivery: MX records (routing), SPF records (authorization), DKIM records (signing), DMARC records (policy), and PTR records (reverse DNS). Getting all five right is essential for reliable email delivery and a strong sender reputation.

Important note: DNS changes do not take effect immediately. Most records have a TTL (Time to Live) value that determines how long other servers cache the old value. When making changes, you may need to wait up to 24-48 hours for full propagation, although most changes propagate within 1-4 hours.

MX Records

MX (Mail Exchange) records tell the world which servers handle incoming email for your domain. When someone sends an email to user@yourdomain.com, the sending server looks up your MX records to find the destination.

MX Record Format

An MX record consists of a priority value and a hostname. Lower priority numbers are preferred (tried first):

example.com.    IN    MX    10    mail1.example.com.
example.com.    IN    MX    20    mail2.example.com.
example.com.    IN    MX    30    mail3.example.com.

In this example, mail servers will try mail1.example.com first (priority 10). If it is unavailable, they will try mail2.example.com (priority 20), and finally mail3.example.com (priority 30).

Common MX Configurations

Google Workspace:

example.com.    MX    1     ASPMX.L.GOOGLE.COM.
example.com.    MX    5     ALT1.ASPMX.L.GOOGLE.COM.
example.com.    MX    5     ALT2.ASPMX.L.GOOGLE.COM.
example.com.    MX    10    ALT3.ASPMX.L.GOOGLE.COM.
example.com.    MX    10    ALT4.ASPMX.L.GOOGLE.COM.

Microsoft 365:

example.com.    MX    0     example-com.mail.protection.outlook.com.

MX Record Best Practices

  • Always have at least two MX records for redundancy
  • MX hostnames must resolve to A records (IP addresses), never to CNAMEs
  • Never point an MX record directly to an IP address; always use a hostname
  • Keep TTL values reasonable (3600 seconds / 1 hour is common)
  • If you do not want a subdomain to receive email, consider adding a null MX record: subdomain.example.com. MX 0 .
Verify your MX records: Use our MX Lookup tool to check your current MX configuration and identify your email provider.

SPF Records

SPF (Sender Policy Framework) records declare which servers are authorized to send email on behalf of your domain. SPF is published as a TXT record at your domain's root.

SPF Record Format

example.com.    TXT    "v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.50 -all"

SPF Mechanisms

SPF records use mechanisms to define authorized sources. Each mechanism can be prefixed with a qualifier (+, -, ~, ?):

Mechanism Syntax Purpose DNS Lookups
ip4 ip4:203.0.113.0/24 Authorize an IPv4 address or CIDR range 0
ip6 ip6:2001:db8::/32 Authorize an IPv6 address or CIDR range 0
include include:_spf.google.com Include another domain's SPF record 1+
a a:mail.example.com Authorize the A record IPs of a hostname 1
mx mx Authorize the IPs of the domain's MX servers 1+
redirect redirect=_spf.example.com Use another domain's SPF record entirely 1
all -all Catch-all for non-matching sources 0

The 10-Lookup Limit

SPF has a strict limit of 10 DNS lookups per evaluation. Each include, a, mx, and redirect mechanism costs at least one lookup. Nested includes (an included record that itself has includes) count toward your total. Exceeding 10 lookups causes a permanent error (permerror), and many receivers treat this as a fail.

Common problem: Organizations using many third-party services (Google Workspace, Mailchimp, HubSpot, Salesforce, Zendesk, etc.) often exceed the 10-lookup limit. If you are approaching the limit, consider using SPF record flattening or consolidating your include statements. Use our SPF Checker to verify your lookup count.

DKIM Records

DKIM records publish the public key used to verify DKIM signatures on your outgoing email. DKIM records are TXT records published at a specific subdomain based on the selector name.

DKIM Record Location

The record is published at <selector>._domainkey.<yourdomain>. The selector is a label chosen by the signing service. Each email service uses its own selector. For example:

# Google Workspace
google._domainkey.example.com    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."

# SendGrid
s1._domainkey.example.com       TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9..."

# Mailchimp (using CNAME delegation)
k1._domainkey.example.com       CNAME  dkim.mcsv.net

DKIM Record Tags

Tag Required Description
v=DKIM1 Yes Version identifier
k=rsa No (default: rsa) Key type
p=... Yes Public key (base64 encoded). Empty value means key is revoked.
t=s No Strict mode, domain must exactly match (no subdomains)
t=y No Testing mode, receivers should not treat failures differently

Key Length Considerations

DKIM keys should be at least 1024 bits, though 2048-bit keys are now recommended for stronger security. The challenge with 2048-bit keys is that the encoded public key is longer than the 255-character limit for a single DNS TXT record string. Most DNS providers handle this by splitting the key across multiple strings within the same record, which is valid per the DNS specification.

# 2048-bit DKIM key split across two strings
selector._domainkey.example.com  TXT  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2"
    "UaGYaOFxMHgSCUxqbIvNS0yxlFEFtbPMGLHLl5+ClK..." )
Check your DKIM: Use our DKIM Record Checker to verify your DKIM key is published correctly, check the key length, and confirm proper formatting.

DMARC Records

DMARC records define your domain's email authentication policy and tell receiving servers what to do when SPF or DKIM checks fail. DMARC is published as a TXT record at _dmarc.yourdomain.com.

DMARC Record Examples

Monitoring only (start here):

_dmarc.example.com    TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Quarantine policy:

_dmarc.example.com    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

Reject policy (maximum protection):

_dmarc.example.com    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensics@example.com; adkim=r; aspf=r"

DMARC Deployment Path

The recommended path for deploying DMARC is gradual:

  1. Start with p=none - This enables monitoring without affecting email flow. Collect and review reports for 2-4 weeks.
  2. Move to p=quarantine; pct=25 - Apply the quarantine policy to 25% of failing messages. Increase the percentage over time.
  3. Move to p=quarantine; pct=100 - Apply quarantine to all failing messages. Monitor for any legitimate sources still failing.
  4. Move to p=reject - Once confident all legitimate email passes DMARC, switch to reject for full protection.

DMARC Reporting

DMARC aggregate reports (rua) are XML files sent daily by receiving servers. They show you which IPs are sending email as your domain, whether those messages passed or failed SPF and DKIM, and the volume from each source. These reports are essential for identifying legitimate senders you may have missed in your SPF or DKIM configuration.

Generate a DMARC record: Use our DMARC Record Generator to build a correctly formatted record, or use our DMARC Checker to validate your existing record.

PTR Records (Reverse DNS)

PTR records provide reverse DNS resolution, mapping an IP address back to a hostname. Many receiving mail servers perform a reverse DNS lookup on the connecting IP and reject or flag email from IPs that do not have a valid PTR record.

How PTR Records Work

Unlike other DNS records, PTR records are not managed in your domain's DNS zone. They are managed by the owner of the IP address, which is typically your hosting provider, ISP, or cloud provider. You will usually need to contact your provider to set up or change PTR records.

# Forward DNS (A record)
mail.example.com    A    203.0.113.50

# Reverse DNS (PTR record, managed in the IP block's zone)
50.113.0.203.in-addr.arpa    PTR    mail.example.com

PTR Record Requirements

  • Every IP address that sends email should have a PTR record
  • The PTR hostname should resolve back to the same IP (forward-confirmed reverse DNS, or FCrDNS)
  • The PTR hostname should be a meaningful name (like mail.example.com), not a generic hostname assigned by the hosting provider
  • The PTR should not contain IP addresses in the hostname (e.g., ip-203-0-113-50.provider.com is not ideal)
Common issue: Many cloud hosting providers assign generic PTR records like ec2-203-0-113-50.compute-1.amazonaws.com. You should change this to a hostname you control. Most providers offer a way to set a custom PTR record through their control panel. Use our Reverse DNS Checker to verify your PTR configuration.

Common DNS Mistakes to Avoid

1. Multiple SPF Records

A domain must have exactly one SPF TXT record. If you have multiple records starting with v=spf1, SPF will fail with a permanent error. Instead of adding a second record, combine all mechanisms into a single record.

# WRONG - Two SPF records
example.com  TXT  "v=spf1 include:_spf.google.com -all"
example.com  TXT  "v=spf1 include:servers.mcsv.net -all"

# CORRECT - Single combined SPF record
example.com  TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net -all"

2. SPF Exceeding 10 Lookups

Every include, a, mx, and redirect mechanism in your SPF record counts toward the 10-lookup limit. Nested includes also count. Exceeding this limit causes SPF to fail.

3. Missing DKIM for Third-Party Senders

If you use multiple email services (marketing platform, CRM, helpdesk), each one should have its own DKIM key configured. Missing DKIM for any sender means those messages will fail DKIM and may fail DMARC alignment.

4. DMARC Without Monitoring

Deploying a DMARC policy of quarantine or reject without first monitoring with p=none risks blocking legitimate email. Always start with monitoring and review reports before enforcing.

5. No Reverse DNS

Sending email from an IP without a PTR record, or with a generic PTR, is a common cause of deliverability problems. Many receivers will reject or deprioritize email from IPs without proper reverse DNS.

6. Using CNAMEs for MX Records

MX records must point to A records, not CNAME records. While some resolvers tolerate this, it violates the DNS specification and can cause delivery failures.

7. Stale DNS Records

When you change email providers, remember to update your MX records, SPF includes, and DKIM records. Leaving old records in place can cause authentication failures or route email to a decommissioned server.

Verifying Your Records

After configuring your DNS records, verify everything is working correctly using our free tools:

Pro tip: After making DNS changes, wait at least 1 hour before running checks, as DNS propagation takes time. If results look unexpected, try again after a few hours. You can check the TTL of existing records to estimate propagation time.
← Back to Guides Next: Understanding Bounce Rates →

Related Tools

MX Lookup SPF Record Checker DKIM Record Checker DMARC Record Checker Reverse DNS Checker

Related Guides

Email Authentication Guide What is Sender Reputation? Improving Email Deliverability

Check Your Domain

Get your free Sender Reputation Score and see how your email configuration stacks up.

Check Now