DNS Records for Email Deliverability: Complete Technical Reference

Overview

Email deliverability depends on a chain of DNS records that authenticate the sender, specify authorized mail servers, and provide policy instructions to receiving servers. Misconfigured DNS records are the single most common cause of email delivery failures that are entirely within the sender's control. This reference document covers the five DNS record types relevant to email deliverability: SPF, DKIM, DMARC, MX, and BIMI.

Each section provides the record's purpose, exact syntax with examples, configuration guidance for common providers, and a list of errors that cause delivery failures. This is a technical reference intended for email administrators, DevOps engineers, and deliverability specialists.

1. SPF (Sender Policy Framework)

Purpose

SPF (defined in RFC 7208) allows domain owners to specify which IP addresses and servers are authorized to send email on behalf of their domain. Receiving servers check the SPF record of the sender's domain and compare it against the IP address of the connecting server. If the IP is not listed in the SPF record, the message may be rejected or marked as suspicious.

Record Syntax

SPF records are published as DNS TXT records on the domain's root. The record always begins with v=spf1 and ends with a qualifier mechanism (typically -all, ~all, or ?all).

Basic syntax:

v=spf1 [mechanisms] [qualifier]all

Mechanism Types

Mechanism	Syntax Example	Meaning
ip4	ip4:192.168.1.0/24	Authorize a specific IPv4 address or range
ip6	ip6:2001:db8::/32	Authorize a specific IPv6 address or range
include	include:_spf.google.com	Include another domain's SPF record (delegation)
a	a:mail.example.com	Authorize the IP(s) of a specific hostname
mx	mx	Authorize all IPs listed in the domain's MX records
redirect	redirect=_spf.example.com	Use another domain's SPF record entirely

Qualifier Options

Qualifier	Symbol	Meaning	Recommendation
Fail	-all	Reject mail from unauthorized servers	Use for production domains with established sending
SoftFail	~all	Accept but mark as suspicious	Use during initial setup and testing
Neutral	?all	No opinion on unauthorized servers	Not recommended; provides no protection

Example SPF Records

Google Workspace only:

v=spf1 include:_spf.google.com -all

Google Workspace + Mailchimp + custom server:

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

Microsoft 365 + SendGrid:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

SPF Lookup Limit

SPF evaluation is limited to 10 DNS lookups per record (RFC 7208, Section 4.6.4). Each include, a, and mx mechanism consumes one lookup. Exceeding this limit causes a "permerror" result, which most receiving servers treat as a fail. This is the most common SPF misconfiguration for organizations using multiple email services.

Counting lookups: ip4 and ip6 mechanisms do not consume lookups. include consumes one lookup plus any lookups in the included record. Nested includes can quickly exhaust the 10-lookup budget.

Solutions for exceeding the limit: Use SPF flattening (resolving includes to IP addresses) or SPF macro services that dynamically manage the record. Be aware that flattened records require maintenance when provider IPs change.

2. DKIM (DomainKeys Identified Mail)

Purpose

DKIM (defined in RFC 6376) adds a cryptographic signature to outgoing email headers that allows receiving servers to verify the message was sent by the domain owner and was not modified in transit. Unlike SPF, which validates the sending server's IP, DKIM validates the message content itself.

How DKIM Works

1. The sending server generates a hash of specified email headers and body content.
2. The hash is encrypted using the domain's private key and added to the email as a DKIM-Signature header.
3. The receiving server retrieves the domain's public key from DNS (stored as a TXT record at selector._domainkey.domain.com).
4. The receiving server decrypts the signature using the public key and compares the result to its own hash of the message. If they match, the message passes DKIM validation.

DNS Record Format

DKIM public keys are published as TXT records at a specific subdomain:

[selector]._domainkey.[domain] IN TXT "v=DKIM1; k=rsa; p=[public_key_base64]"

Example (Google Workspace, selector "google"):

google._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhk..."

Key Parameters

Parameter	Values	Meaning
v	DKIM1	Version (always DKIM1)
k	rsa, ed25519	Key type. RSA is standard; Ed25519 is newer and more efficient
p	[base64 encoded key]	Public key. If empty, the key is revoked
t	y, s	Flags. y = testing mode; s = strict alignment (selector domain must exactly match From domain)

Key Size Recommendations

RSA key sizes for DKIM: 1024-bit is the minimum accepted by most providers; 2048-bit is the current recommendation; 4096-bit provides additional security but may be truncated by some DNS providers due to TXT record length limits (255 characters per string in DNS). For 2048-bit and above, the key must be split across multiple strings within the TXT record.

DKIM Rotation

DKIM keys should be rotated every 6-12 months. The rotation process requires publishing the new key alongside the old one (using a different selector), transitioning sending to the new selector, and then removing the old key after a grace period (typically 7-14 days to allow in-transit messages to be validated).

3. DMARC (Domain-based Message Authentication, Reporting & Conformance)

Purpose

DMARC (defined in RFC 7489) builds on SPF and DKIM by allowing domain owners to specify how receiving servers should handle messages that fail authentication checks. DMARC also provides a reporting mechanism that sends aggregate and forensic reports back to the domain owner, enabling monitoring of authentication failures.

DNS Record Format

DMARC records are published as TXT records at _dmarc.[domain]:

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

Policy Options

Policy	Tag Value	Receiving Server Action	When to Use
None	p=none	Take no action; deliver normally	Initial deployment; monitoring only
Quarantine	p=quarantine	Place in spam/junk folder	Transitional; after reviewing reports
Reject	p=reject	Reject the message entirely	Full enforcement; all legitimate sources authenticated

Recommended DMARC Deployment Path

1. Week 1-4: Publish p=none with rua reporting. Monitor reports for legitimate sending sources that fail authentication.
2. Week 5-8: Fix authentication for all identified legitimate sources. Confirm SPF and DKIM pass rates above 98%.
3. Week 9-12: Move to p=quarantine; pct=25. Apply quarantine to 25% of failing messages while monitoring for false positives.
4. Week 13-16: Increase to p=quarantine; pct=100, then transition to p=reject; pct=25.
5. Week 17+: Full enforcement at p=reject; pct=100.

Alignment Modes

DMARC alignment determines how strictly the domain in SPF/DKIM must match the From header domain:

• Relaxed (r): Organizational domain must match (e.g., mail.example.com aligns with example.com). Default.
• Strict (s): Exact domain must match (e.g., mail.example.com does NOT align with example.com).

4. MX Records (Mail Exchange)

Purpose

MX records specify which servers are responsible for receiving email for a domain. While MX records primarily affect inbound email delivery, they also indirectly affect outbound deliverability: some receiving servers perform a reverse check to verify that the sender's domain has valid MX records, treating domains without MX records as potentially fraudulent.

Record Syntax

example.com IN MX [priority] [mail_server]

Example with primary and backup:

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

Lower priority values indicate higher preference. Messages are delivered to the lowest-priority (highest-preference) server first; if it is unavailable, the next server is tried.

Best Practices

• Always configure at least two MX records (primary and backup) for redundancy.
• MX records must point to hostnames, not IP addresses (per RFC 5321).
• MX hostnames must have corresponding A records (or AAAA for IPv6).
• Do not point MX records to CNAME records—this violates RFC 2181 and causes delivery failures with some servers.
• Set TTL (Time to Live) to 3600 seconds (1 hour) for a balance between propagation speed and DNS load.

5. BIMI (Brand Indicators for Message Identification)

Purpose

BIMI allows domain owners to display their brand logo next to authenticated emails in supporting inbox clients. BIMI requires DMARC enforcement (p=quarantine or p=reject) as a prerequisite, making it both a branding tool and a deliverability signal. As of March 2026, BIMI is supported by Gmail, Yahoo Mail, Apple Mail (iOS 16+), and Fastmail. Microsoft Outlook has announced support but has not yet fully deployed it.

DNS Record Format

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

Requirements

Requirement	Detail
DMARC policy	Must be p=quarantine or p=reject (not p=none)
Logo format	SVG Tiny PS format (specific SVG profile required by BIMI)
Logo hosting	Must be served over HTTPS from a publicly accessible URL
VMC (optional)	Verified Mark Certificate from DigiCert or Entrust (~$1,500/year). Required for Gmail logo display. Not required for Yahoo.
Logo dimensions	Square aspect ratio, minimum 32x32 pixels, centered on a solid background

BIMI Impact on Deliverability

While BIMI does not directly affect deliverability scoring, it provides two indirect benefits. First, the DMARC prerequisite ensures strong authentication, which independently improves deliverability. Second, brand logo display increases recipient recognition, which correlates with higher open rates (our data shows 8-12% open rate improvement for senders with BIMI logos versus those without) and lower spam complaint rates.

Common DNS Configuration Errors

The following are the 12 most common DNS configuration errors we observe in deliverability audits conducted through the WarmySender platform:

1. Multiple SPF records on the same domain. DNS allows only one SPF TXT record per domain. Publishing two records causes both to fail. Merge all mechanisms into a single record.
2. Exceeding the SPF 10-lookup limit. Each include counts as one or more lookups. Use SPF flattening or consolidate services.
3. Using +all as SPF qualifier. This authorizes every server on the internet to send as your domain. Always use -all or ~all.
4. DKIM key truncation. 2048-bit keys are too long for a single DNS TXT string. They must be split into multiple 255-character strings within one record. Some DNS providers handle this automatically; others require manual splitting.
5. DMARC set to p=none indefinitely. Monitoring mode provides no protection. Establish a timeline to progress to quarantine and then reject.
6. Missing DMARC rua tag. Without aggregate reporting, you cannot monitor authentication failures or identify unauthorized senders. Always include an rua address.
7. MX records pointing to CNAME records. This violates RFC 2181 and causes intermittent delivery failures that are difficult to diagnose.
8. Missing reverse DNS (PTR) for sending IPs. Many receiving servers reject or penalize connections from IPs without valid PTR records. Ensure every sending IP has a PTR record matching the server's hostname.
9. DKIM selector mismatch. The selector in the DNS record must exactly match the selector configured in the mail server. A common error is changing the selector in DNS without updating the server configuration.
10. Low TTL on authentication records. Setting TTL below 300 seconds causes excessive DNS lookups and can trigger timeout errors during SPF evaluation. Use TTL of 3600 seconds for SPF, DKIM, and DMARC records.
11. DMARC subdomain policy (sp) omission. Without sp, subdomains inherit the parent domain's policy. If you use subdomains for different purposes (marketing, transactional), set explicit subdomain policies.
12. Stale DKIM keys. Keys published more than 12 months ago should be rotated. Compromised keys allow unauthorized signing that bypasses DMARC.

Diagnostic Checklist

Use this checklist when diagnosing email delivery failures related to DNS:

1. Verify SPF record exists and is syntactically valid: dig TXT example.com
2. Count SPF lookups (must be 10 or fewer): Use mxtoolbox.com/spf.aspx
3. Verify DKIM record exists at the correct selector: dig TXT selector._domainkey.example.com
4. Verify DMARC record exists: dig TXT _dmarc.example.com
5. Check DMARC alignment (relaxed vs strict): Review adkim and aspf tags
6. Verify MX records point to valid hostnames: dig MX example.com
7. Confirm MX hostnames resolve to A records: dig A mail.example.com
8. Check reverse DNS for sending IP: dig -x [IP_ADDRESS]
9. Send test email to mail-tester.com and review the full report
10. Check Google Postmaster Tools for domain reputation status

Citation

Mitchell, S. (2026). DNS Records for Email Deliverability: Complete Technical Reference. WarmySender Research. Published March 15, 2026. Available at: https://warmysender.com/blog/dns-records-email-deliverability-complete-technical-reference