Email Deliverability Checklist for Startups

The startup deliverability scorecard

Startups usually discover deliverability after a launch, sales push, or investor update underperforms. The fix is not a subject line trick. It is a clean sending domain, correct authentication, and early warnings before DNS drift breaks mail.

Use this checklist before you scale outbound, invite users, or move transactional mail to a new provider. It follows the standards behind SPF, DKIM, and DMARC, plus the current sender guidance from Gmail and Microsoft. For your own domain, run the free InboxRadar scorecard and compare the grade to each item below.

• Inventory every sender. List Google Workspace or Microsoft 365, your product app, CRM, support desk, newsletter tool, billing system, and any founder inbox tools that send as your domain.
• Separate mail streams when needed. Use clear subdomains for marketing, product notifications, and cold outreach if one stream can hurt another. Do not let a test tool send from the same domain as password resets.
• Use real recipient permission. Mailbox providers weigh complaints and engagement. Authentication proves who sent the message, but it does not make unwanted mail wanted.

1. SPF: authorize every sender without breaking the limit

SPF is the DNS TXT record that says which servers may send mail for a domain. It is often the first record startups copy from a vendor, and also the first one to become stale.

• Publish one SPF record only. Multiple SPF TXT records at the same name can make SPF fail.
• Include every active sender that sends with your domain in the envelope sender, and remove old includes when you leave a tool.
• Stay under the SPF 10 DNS lookup limit in RFC 7208. Includes, redirects, mx, a, ptr, and exists mechanisms count. If evaluation needs too many DNS lookups, receivers can return a permanent error instead of a pass.
• End with ~all while you are still validating sources. Move to -all only when you are confident every legitimate sender is listed.
• Never use +all. It tells receivers that any server is authorized to send as your domain.

When in doubt, use your provider's exact SPF include and avoid flattening unless you have a process to keep IPs current.

2. DKIM: sign mail from each sending system

DKIM adds a cryptographic signature to each message. A receiver can check the signature against a public key in DNS and see whether signed parts of the message changed in transit.

• Turn on DKIM in every sender that supports it, including Google Workspace, Microsoft 365, your ESP, and product email provider.
• Publish each provider's DKIM public key under the selector it gives you, such as selector1._domainkey.example.com. Selectors let multiple tools sign for the same domain without sharing one key.
• Use 2048-bit keys when your DNS provider supports the record size. Gmail requires at least 1024-bit DKIM keys for mail to personal Gmail accounts.
• Check that the visible From domain aligns with either the SPF-authenticated domain or the DKIM signing domain when DMARC is evaluated.
• Rotate DKIM keys through the provider interface rather than editing random DNS values by hand.

DKIM is defined in RFC 6376. The practical test is simple: send a real message, inspect the headers, and confirm it shows dkim=pass for the domain you expect.

3. DMARC: monitor first, then enforce

DMARC ties SPF and DKIM to the visible From domain. It tells receivers the policy you publish for mail that fails DMARC, but receivers still apply their own local filtering.

• Publish a DMARC TXT record at _dmarc.example.com.
• Start with p=none and a reporting address, for example v=DMARC1; p=none; rua=mailto:dmarc@example.com. This lets you see who is sending before you ask receivers to quarantine or reject failures.
• Read aggregate rua reports or send them to a service that can parse XML. They show legitimate tools, spoofing attempts, and alignment failures.
• Move to p=quarantine after your real senders pass. Move to p=reject only after you understand the impact on real mail, including forwarding and mailing lists.
• Remember the pass rule: DMARC passes when SPF or DKIM passes and aligns with the visible From domain. One aligned pass is enough.

DMARC was originally published as RFC 7489. It is now replaced by current RFCs: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. Gmail requires DMARC for senders over 5,000 daily messages to Gmail accounts, and Microsoft documents SPF, DKIM, and DMARC as core authentication controls.

4. DNS, reputation, and blocklist checks

Authentication is the floor. Inbox placement also depends on routing DNS, IP and domain reputation, complaint rate, content, and whether recipients expected the mail.

• Confirm MX records point to the system that receives your company email. Broken MX records do not directly prove outbound spam, but they signal sloppy domain operations and can break replies.
• For servers you control, confirm forward and reverse DNS match. Gmail says sending domains or IPs should have valid forward and reverse DNS records.
• Check major blocklists for your sending IPs and domain. A listing is usually a symptom of compromised mail, bad lists, or sudden volume, not a root-cause fix by itself.
• Keep spam complaints low. Gmail's guidance says keep spam rates reported in Postmaster Tools below 0.30%.
• Increase volume gradually. New domains and new IPs do not have a reputation history, so sudden jumps can trigger rate limits or spam placement.
• Use clear unsubscribe for marketing and subscribed messages. Gmail requires one-click unsubscribe for marketing and subscribed mail from senders over 5,000 messages per day to Gmail accounts.

Mailbox providers like Gmail and Outlook decide inbox, spam, or rejection using their own filters. Microsoft says its systems also evaluate sender reputation, sender history, recipient history, behavior, and other signals. A checklist cannot force placement. It can remove the obvious reasons a legitimate startup gets filtered before the message is even judged on engagement.

5. A 15-minute startup checklist

If you only have one short block of time, run this in order. It catches the highest-impact mistakes first.

• Run your domain through the InboxRadar domain check.
• Fix missing or duplicate SPF, and make sure each active envelope sender is covered.
• Turn on DKIM signing for every mail platform that sends as your domain.
• Add DMARC at p=none with a working rua address, then review reports before enforcement.
• Confirm MX records, reverse DNS for owned sending servers, and major blocklist status.
• Send test messages to Gmail and Outlook, then inspect headers for spf=pass, dkim=pass, and dmarc=pass.
• Document the owner for each DNS record so a future vendor migration does not silently break deliverability.

For related walkthroughs, see the InboxRadar guide library. The best setup is boring: every sender is known, every record has an owner, and drift gets caught before a campaign or product email fails.