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.

What happens if my SPF record has more than 10 lookups?

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.

How long do DNS changes take to propagate?

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.

Can I have multiple DKIM records for the same domain?

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.

What is DMARC alignment and why is it important?

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.

Do I need a PTR record for sending email?

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.