Email Deliverability Check

You find out why mail is not reaching the inbox and what will fix it, with evidence for every finding. Deliverability rests on three things: proving who you are (authentication), being wanted (low complaints, engaged recipients, clean lists), and sending consistently. You diagnose and propose; DNS and sending changes happen only with the owner's go-ahead, because a wrong record can stop every email the business sends, invoices included.

When to use

• "Our emails are going to spam."
• "Open rates suddenly dropped" or "Gmail is bouncing our emails."
• "Are we compliant with the Gmail and Yahoo sender rules?"
• "We're moving to a new email platform / new domain. What do we need?"
• Before the first large send from a new domain.

What you need

• Sending domains and every service that sends as them: the email marketing tool (for example Mailchimp, HubSpot), the help desk, billing, the product, the office mail system. Ask with clarify; missing a sender is the most common cause of DMARC failures.
• Read access to DNS records (public, via dig in the terminal). Changing them needs the owner and whoever runs DNS.
• Metrics from the email tool for the last 90 days: delivered, hard and soft bounces, spam complaints, unsubscribes, clicks, by send. Connected app or the owner's signed-in browser.
• Google Postmaster Tools for the domain (free; the owner verifies the domain) and, if the business uses dedicated IPs, Microsoft SNDS.
• A real recent email received in a Gmail or Outlook mailbox, to read its headers.
• Sending volume per day to each major provider.

Method

1. Define the symptom. Which streams (newsletter, sequences, transactional), which providers (Gmail, Outlook, Yahoo, corporate filters), since when, and what changed around that date (new tool, new domain, list import, big volume jump, content change).
2. Check authentication records. Run the commands in references/deliverability-toolkit.md:
   • SPF: exactly one v=spf1 TXT record on the envelope domain; includes every legitimate sender; no more than 10 DNS lookups; ends in ~all or -all, never +all.
   • DKIM: a valid key at the selector each sending service uses; 2048-bit keys preferred; signing with the organisation's own domain, not only the platform's.
   • DMARC: one TXT record at _dmarc.domain; starts at p=none with a rua address for aggregate reports if not set; alignment means the visible From domain matches the SPF or DKIM domain.
3. Read real headers. Open a delivered message's original source (Gmail: Show original). Check Authentication-Results for spf=pass, dkim=pass and dmarc=pass, and that the d= domain in the DKIM signature matches the From domain. Headers settle arguments that DNS lookups cannot.
4. Check the mailbox providers' sender rules. Since February 2024 Gmail and Yahoo require bulk senders (around 5,000 or more messages a day to their users) to authenticate with SPF, DKIM and DMARC with an aligned From domain, offer one-click unsubscribe in the message headers, honour unsubscribes within two days, and keep spam complaints low (Google asks for under 0.1 percent and treats 0.3 percent as the limit). Microsoft announced similar requirements for Outlook consumer addresses from May 2025, and enforcement has tightened since. Rules change: confirm the current versions with web_search on the providers' own pages and cite them.
5. Read reputation and complaint data. Postmaster Tools spam rate and the compliance or reputation views it currently offers; the email tool's complaint and bounce rates per send. Practitioner thresholds worth flagging: hard bounces above about 2 percent of a send, complaint rates above 0.1 percent, sudden drops in clicks at one provider.
6. Check blocklists. Look up the sending domain and any dedicated IPs on the free public lookup pages of major blocklists (for example Spamhaus). Listings on shared ESP IPs are the ESP's to fix; report them to the owner to raise with the provider.
7. Audit list sources and hygiene. How were addresses collected (consent wording, double opt-in or single, imports, purchased lists)? When were inactive subscribers last removed? Hard bounces must be suppressed at once. People who have not opened or clicked in 6 to 12 months should get a re-permission campaign and then be suppressed; adjust the window to sending frequency. Never mail purchased or scraped lists.
8. Check sending patterns and content. Consistent From name and address; sudden volume spikes; link domains and URL shorteners (avoid shorteners); tracking domain branded to the business; a plain-text part; message size (Gmail clips messages over about 102 KB, hiding the footer and unsubscribe); a visible unsubscribe link and a postal address where the law requires one.
9. Test placement. Send the current template to test accounts you control at Gmail, Outlook and Yahoo (and a business mailbox) and record where it lands. Free header-and-content scoring services exist; label results as indicative.
10. Write the fix plan in order of impact: authentication gaps, bulk-sender rule gaps, list hygiene, sending practice, content. For DNS, write the exact proposed records and the rollout: for DMARC, stay at p=none while reading aggregate reports for 2 to 4 weeks until every legitimate source passes, then p=quarantine (optionally with pct), then p=reject. For a new domain or IP, propose a warm-up that starts with the most engaged subscribers and increases volume gradually.
11. Get approval before any change. Present the plan; DNS edits, suppression of contacts, ESP setting changes and re-permission sends all need the owner's explicit go-ahead. Afterwards, set a cronjob to recheck records and complaint rates weekly for a month.

Output

• Status table: check, current value, expected, pass / fail, evidence.
• Metrics summary: bounce, complaint, unsubscribe and click rates per stream and provider.
• Root causes, ranked.
• Fix plan with exact DNS records (as text, not applied), owner, order and timing.
• Legal note: consent and unsubscribe rules depend on country (for example CAN-SPAM in the US, GDPR and PECR in the UK and EU, CASL in Canada). State which apply and that the owner should confirm with a qualified adviser where there is doubt. Put the status table on a show_card.

Checks before you finish

• Every sending service was identified and checked for SPF and DKIM alignment.
• Conclusions were confirmed with real message headers, not only DNS lookups.
• Provider requirements quoted with source links and dates.
• Proposed SPF stays within 10 lookups; proposed DMARC starts at the right policy step.
• No DNS, list or ESP changes were made without approval.

Pitfalls

• Two SPF records. Multiple v=spf1 records make SPF fail. Merge them into one.
• Jumping to p=reject. Before every sender is aligned, a reject policy blocks legitimate mail, including invoices and password resets.
• Forgetting other senders. The help desk or billing system sending as the domain without DKIM will fail DMARC once it is enforced.
• Blaming content first. Words rarely cause spam placement on their own; authentication, complaints and list quality usually do.
• Trusting open rates. Apple Mail Privacy Protection and image blocking distort opens. Use clicks, replies and provider data.
• Mailing the inactive to "wake them up" at full volume. Re-permission in small batches to the most recent first, then suppress non-responders.