Email Deliverability Checklist: SPF, DKIM, DMARC

The short version

Email deliverability starts with proving that your domain is allowed to send the mail it sends. If Gmail, Outlook, Yahoo, or a corporate gateway cannot connect your visible From domain to valid SPF, DKIM, and DMARC results, the message can be filtered, sent to spam, or rejected.

This checklist is for the domain owner who needs a practical scorecard, not a theory lesson. Start by running your domain through the free InboxRadar domain scorecard. Then use the items below to fix the records that decide whether your mail looks trustworthy before content and engagement are even considered.

• Publish one valid SPF TXT record for each envelope sender domain you use.
• Sign every outbound stream with DKIM using a selector you control.
• Publish DMARC on the organizational domain and collect rua aggregate reports.
• Confirm MX, forward DNS, reverse DNS, and TLS are sane for your sending setup.
• Check blocklists and sender reputation after authentication passes.

SPF checklist

SPF tells receivers which servers are allowed to send mail for the envelope sender domain, often seen as the Return-Path domain. The official rule is in RFC 7208, and the two common failure modes are stale senders and records that exceed the DNS lookup limit.

• Use exactly one SPF TXT record at each envelope sender domain, starting with v=spf1. Multiple SPF records for the same name cause permanent errors.
• Include every real sender that uses that envelope sender domain: your email service provider, help desk, billing system, CRM, marketing platform, and any SMTP relay.
• Stay under the 10 DNS lookup limit in RFC 7208. Mechanisms and modifiers such as include, a, mx, ptr, exists, and redirect can consume lookups, including through nested includes.
• Use ~all while you are still finding legitimate sources. Move to -all only after reports and tests show that every real sender is covered.
• Remove old vendors. A forgotten include can authorize mail you no longer control.

DKIM checklist

DKIM signs selected message headers and body content with a private key and lets receivers fetch the public key from DNS. RFC 6376 defines the model: a signing domain, a selector, and a cryptographic signature that can survive forwarding when the signed content is not changed.

• Enable DKIM for each platform that sends as your domain. SPF alone is not enough for modern deliverability.
• Use provider-specific selectors, such as one selector for your workspace mail and another for your marketing platform.
• Publish the TXT records exactly as your provider gives them. A selector mismatch means receivers cannot find the key.
• Prefer 2048-bit keys when supported. Google requires at least 1024-bit DKIM keys for mail to personal Gmail accounts and recommends 2048-bit keys.
• Send a real test message and inspect Authentication-Results. DKIM should pass, and the d= signing domain should match the visible From domain or share its organizational domain when DMARC relaxed alignment is expected.

DMARC checklist

DMARC ties SPF and DKIM back to the visible From domain and tells receivers what the domain owner requests when neither aligned SPF nor aligned DKIM passes. The policy values in RFC 7489 are none, quarantine, and reject.

• Publish DMARC at _dmarc.example.com with at least v=DMARC1; p=none. Add rua=mailto:dmarc@example.com if that mailbox or report processor is ready to receive aggregate reports.
• Read aggregate reports before enforcement. Reports show which IPs and services are sending as your domain and whether SPF or DKIM aligns.
• Do not jump to p=reject until legitimate mail streams pass aligned SPF or aligned DKIM. Some forwarding and third-party flows may need DKIM alignment because SPF can break in transit.
• Move from p=none to p=quarantine, then p=reject when the data is clean. Use pct if you need a gradual rollout.
• Remember that DMARC is not an inbox guarantee. Receivers can still filter authenticated mail under their own spam and abuse policies.

Mailbox provider requirements

Google and Microsoft publish sender rules because authentication is now table stakes, especially for bulk senders. Use official guidance when a detail changes, not a stale blog post.

Google sender guidelines say all senders need SPF or DKIM, while bulk senders need SPF, DKIM, and DMARC. For bulk senders, Google also calls for aligned From domains, valid forward and reverse DNS, TLS, low spam rates, and one-click unsubscribe for marketing and subscribed mail.

Microsoft Outlook high-volume sender guidance says domains sending more than 5,000 messages per day to Outlook.com, Hotmail, and Live addresses need SPF, DKIM, and DMARC. Use Microsoft's current guidance for enforcement details because non-compliant high-volume mail can be junked or rejected.

• Use a real From or Reply-To address that can receive replies.
• Keep complaint rates low by mailing people who asked for the message.
• Make unsubscribe obvious for marketing and subscribed mail.
• Do not rely on authentication to overcome poor list quality, deceptive content, or a damaged sender reputation.

DNS, MX, and reputation checks

Authentication records are the first pass. Delivery still depends on the sending infrastructure and the history attached to your domain and IPs.

• Confirm your domain has the right MX records if people should be able to reply. Broken MX records make a sender look neglected and can break response workflows.
• For dedicated sending IPs, confirm reverse DNS points to a hostname and that hostname resolves back to the sending IP.
• Check that the hostname is tied to your domain or sending provider, not a generic cloud host name.
• Use TLS for mail transport wherever your provider supports it.
• Check major blocklists for your sending IP and domain. If listed, fix the cause first, then request delisting with evidence.
• Watch for drift after every vendor change. A new CRM, support desk, or billing tool often adds a sender before DNS is updated.

For a deeper troubleshooting flow, read why your email is going to spam. For a faster answer, run the domain through InboxRadar and hand the scorecard to whoever manages DNS.