Definition
Email DNS records are specific configurations in the Domain Name System that authenticate the origin of email messages and instruct receiving servers how to handle them. The four core authentication records are SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting and Conformance), which work together to prove an email is genuinely from your domain and not spoofed by a third party. MX records direct incoming mail to your mail servers, and PTR records enable reverse DNS lookups.
SPF records list the IP addresses authorised to send email on behalf of your domain. Published as a TXT record, SPF allows receiving servers to check that the sending server's IP is listed in the domain's SPF record. The specification limits SPF DNS lookups to 10 per record, including nested includes — exceeding this limit causes SPF to permanently fail authentication. Many large organisations hit this limit by chaining multiple third-party ESP includes, requiring SPF record flattening or simplification.
DKIM uses public-key cryptography to sign outgoing messages. The sending server signs the email headers and body with a private key, and the receiving server looks up the corresponding public key in the sending domain's DNS to verify the signature. Each email stream should use a separate DKIM selector (e.g., s1._domainkey.yourdomain.com) to allow key rotation without disrupting other streams. DMARC then tells the receiving server how to handle messages that fail SPF or DKIM — none (monitor only), quarantine (send to spam), or reject (block entirely).
Best Practices
Keep SPF lookups under 7 to leave headroom for future additions. Each include: statement counts as one lookup, as do a:, mx:, and ptr: mechanisms. If you exceed 10 lookups, SPF returns a permanent error (PermError) and fails authentication. Use SPF flattening tools to collapse your record if needed.
Use separate DKIM selectors for each email stream. For example, use s1._domainkey.yourdomain.com for marketing, s2._domainkey.yourdomain.com for transactional. This lets you rotate keys per stream without affecting all email at once. Rotate DKIM keys every 6-12 months as a security best practice.
Set DMARC to p=none initially and monitor reports for at least 2-4 weeks before moving to p=quarantine or p=reject. DMARC aggregate reports (from rua= addresses) show authentication pass rates, organisational alignment, and source IPs. Aim for 95%+ DMARC pass rate before tightening the policy.
Set TXT record TTL to 3600 seconds (1 hour) during initial setup to allow quick rollbacks if misconfigured. After confirming correct configuration, increase TTL to 86400 seconds (24 hours) to reduce DNS query load. For MX records, TTL of 3600 seconds is standard.
Test DNS records with dig and nslookup before activating any sending infrastructure. Run dig txt yourdomain.com for SPF, dig txt s1._domainkey.yourdomain.com for DKIM, dig txt _dmarc.yourdomain.com for DMARC, and dig mx yourdomain.com for MX records. Verify values match exactly with no unexpected whitespace.
Frequently Asked Questions
Related Glossary Terms
BIMI
BIMI (Brand Indicators for Message Identification) is an email standard that allows brands to display their logo next to their emails in supported email clients. It requires DMARC enforcement at quarantine or reject policy.
Email DKIM Selector
DKIM selector management involves rotating signing keys across named selectors (default, s1, s2, 2024). Multi-selector strategies allow zero-downtime key rotation every 6-12 months for ongoing email authentication.
Email DMARC Failure
DMARC failure handling processes what happens when SPF and DKIM both fail authentication: p=none monitors, p=quarantine sends to spam, p=reject bounces. Gradual policy escalation with testing prevents false positives.
Email DMARC Report
DMARC reporting provides aggregate (RUA) and forensic (RUF) reports about email authentication results. Aggregate reports show volume, SPF/DKIM results, and disposition. Forensic reports contain full email copies for detailed analysis.
Email Forwarding
The practice of automatically redirecting email from one address to another and how forwarding impacts SPF, DKIM, and DMARC authentication and deliverability.
Email HELO EHLO
The SMTP commands that identify a sending server during connection setup, with HELO hostname configuration critical for email deliverability and reverse DNS alignment.
Frequently Asked Questions
SPF returns a permanent error (PermError) and authentication fails. Receiving servers treat the message as if SPF does not exist. Use SPF flattening to consolidate includes and reduce lookup count, or remove unnecessary mechanisms.
Typically 1-15 minutes for TXT records with standard TTL settings, but some ISPs cache DNS for up to 48 hours. Lowering TTL before making changes speeds up propagation. Use `dig` with `+trace` to verify propagation across the DNS hierarchy.
Yes, each selector points to a different DKIM public key. You can have active and retired selectors simultaneously. This enables key rotation without downtime — add the new selector before switching the signing key.
DMARC alignment requires the domain in the `From:` header to match (or share an organisational domain with) the domain authenticated by SPF or DKIM. Gmail and Yahoo now require alignment for bulk senders. Without it, even authenticated messages may be rejected.
PTR (reverse DNS) is strongly recommended and effectively required for dedicated sending IPs. Most mailbox providers, particularly Gmail, check that the PTR record resolves to a domain matching the HELO/EHLO hostname. Without a valid PTR, deliverability is significantly reduced.