Email Deliverability Audit: The 5-Layer Engineering Inspection Framework

An email deliverability audit is a structured diagnostic process that produces a specific, prioritised list of issues causing inbox placement degradation — not a general review of best practices. The distinction matters. Vague guidance about “improving your list quality” or “checking your authentication” does not tell you which specific DNS record is misconfigured, which campaign segment is generating the complaint rate spike, or which ISP is throttling your IP and why. A proper audit produces actionable specifics.

This guide walks through the complete audit methodology in sequence, with the specific tools, checks, and diagnostic logic at each layer. Run this in order — authentication and infrastructure problems at Layers 1 and 2 affect everything downstream, and diagnosing content or engagement issues before confirming your authentication is clean wastes time.

Layer 1: Authentication and DNS — The Non-Negotiable Foundation

Since Gmail’s February 2024 enforcement and Microsoft’s May 2025 requirements, authentication failures do not merely increase spam folder placement — they cause outright 550 rejection at two of the three largest inbox providers. Authentication audit comes first because every other layer depends on it.

SPF Audit

Tool: MXToolbox SPF Record Check (mxtoolbox.com/spf.aspx) or dig TXT yourdomain.com

Check 1 — Single SPF record: Run dig TXT yourdomain.com | grep "v=spf1" and count the results. Any more than one line means multiple SPF records, which produces a PermError on evaluation regardless of content. This single misconfiguration causes SPF failures for the entire domain.

Check 2 — 10-lookup limit: Use MXToolbox or dmarcian’s SPF Surveyor to count the total number of DNS lookups your SPF record generates when fully resolved (including all recursive include: chains). Any count above 10 means some recipients will receive a PermError when evaluating your SPF, causing authentication failures that appear inconsistently across different receivers. This affects around 15–20% of all SPF issues found in professional audits.

Check 3 — IP coverage: Send a test email from every service that sends on your behalf (ESP, CRM, helpdesk, transactional service) and check whether each originating IP appears in your SPF record’s authorised range. Use dig TXT yourdomain.com and trace each include: to its IP ranges.

Check 4 — Alignment: The Return-Path / envelope-from domain in outbound email must align with the From: header domain for SPF alignment to pass under DMARC. Check by viewing full headers of a sent message — the Return-Path domain should match or be a subdomain of your From: header domain.

DKIM Audit

Tool: dig TXT selector._domainkey.yourdomain.com or MXToolbox DKIM Check

Check 1 — Selector discovery: For each sending service you use, find the DKIM selector currently being used. In Gmail (Show Original) or any mail header viewer, look for DKIM-Signature: ... s=selectorname. Query each selector: dig TXT selectorname._domainkey.yourdomain.com.

Check 2 — Key length: Count the characters in the p= value of each DKIM record. Around 200 characters indicates a 1024-bit key (inadequate by 2025 standards); around 350 characters is a 2048-bit key (current standard). Any 1024-bit keys should be rotated immediately.

Check 3 — Signing verification: Send a test message and check the Authentication-Results header:

dkim=pass header.i=@yourdomain.com header.s=mail header.b=AbCdEf...

If it shows dkim=fail, the most common causes are: public key in DNS does not match the private key currently signing, the DNS record was published with line breaks or whitespace corrupting the key, or the signing configuration on your MTA is pointing to the wrong selector.

Check 4 — Per-service isolation: ESPs and transactional email services that send on your behalf should each have their own DKIM signing configuration. If multiple services are all using the same selector, a key rotation at one service can break DKIM for all of them simultaneously.

DMARC Audit

Tool: dig TXT _dmarc.yourdomain.com or easydmarc.com DMARC Check

Check 1 — Record exists: Any domain sending email must have a _dmarc TXT record. As of 2025, the absence of a DMARC record is a compliance failure with Gmail’s, Yahoo’s, and Microsoft’s bulk sender requirements.

Check 2 — Policy level: What does your p= value say? p=none provides monitoring only — zero spoofing protection. Organisations with p=none are providing attackers a confirmed path to send phishing mail that survives all authentication checks. The target state for production domains is p=reject. The audit should identify your current policy and provide a timeline for advancement.

Check 3 — Reporting configured: Without a rua= tag pointing to a monitored address or DMARC reporting service, you receive no aggregate reports and cannot identify authentication failures or unauthorised senders. Check that the rua address is actively receiving and being reviewed.

Check 4 — Alignment mode: If you’re using strict alignment (aspf=s or adkim=s), confirm every sending source is precisely aligned — not just organisationally aligned. Strict mode is appropriate for high-security environments but causes DMARC failures from forwarded email and some ESPs that sign with subdomains.

Check 5 — Subdomain policy: Does your DMARC record include sp=? Subdomains that do not have their own DMARC records inherit the parent’s policy, but the sp= tag allows different treatment for subdomains. Parked subdomains and non-sending subdomains should have p=reject applied.

PTR / FCrDNS Audit

Every IP that sends outbound email must have a reverse DNS (PTR) record that resolves to a hostname, and that hostname must forward-resolve back to the same IP (Forward Confirmed Reverse DNS). Without FCrDNS, Microsoft’s mail servers typically defer or reject connections from the IP regardless of other authentication status.

Check: dig -x YOUR.SENDING.IP.ADDRESS — note the hostname returned. Then dig A that-hostname — confirm it resolves to the same IP. If the PTR does not exist, or the forward lookup does not match, this must be fixed with your hosting provider or IP owner before attempting reputation recovery.

Layer 2: Infrastructure and IP Health

Blacklist Status

Tools: MXToolbox Blacklist Monitor (mxtoolbox.com/blacklists.aspx), check.spamhaus.org

Run your sending IPs against all major blocklists. Active listings at Spamhaus ZEN, Barracuda BRBL, or SpamCop will cause rejection at any ISP querying those lists. Critically, check which specific Spamhaus list you’re on if listed — SBL, CSS, XBL, and PBL each require different remediation actions (see the Spamhaus removal guide for per-list procedures).

Also check your sending domain against the Spamhaus DBL (Domain Block List) and SURBL. Domain-level blacklisting is distinct from IP-level and affects deliverability even if your IPs are clean.

SNDS (Microsoft Smart Network Data Services)

Register at postmaster.live.com and add your sending IP ranges. SNDS provides Microsoft’s assessment of your IP’s complaint rate and spam trap hit rate for Outlook/Hotmail/Live recipients. A “Red” rating in SNDS means Microsoft is applying aggressive filtering to your email regardless of other reputation signals. SNDS data is IP-level — a domain with clean reputation can still show Red SNDS if the sending IP has accumulated Microsoft complaints.

Gmail Postmaster Tools

If not already set up: add your sending domain at postmaster.google.com and verify via DNS TXT record. Data begins appearing within 24–48 hours of verification at adequate send volume (100+ unique Gmail recipients per day).

For an audit, examine these dashboards:

• Compliance Status: Any “Needs Work” indicators require immediate technical fixes — they’re causing rejection at Gmail
• Spam Rate: Values above 0.10% require investigation; above 0.30% means Gmail is already filtering your mail aggressively
• Delivery Errors: Spikes here indicate the specific dates when authentication or reputation problems began

Sending Pattern Analysis

Review your sending volume history for the past 90 days. Look for:

• Volume spikes — sudden increases that might have triggered throttling at ISPs
• Gaps in sending — periods of minimal activity after which ISPs may have deprioritised your IP’s established patterns
• New IPs or domains introduced without warm-up
• Changes to sending infrastructure (ESP migration, MTA upgrade, new dedicated IPs)

Layer 3: List Quality and Engagement Signals

Hard Bounce Rate Trend

Pull hard bounce rates per campaign for the last 90 days. Look for trend direction (increasing, stable, or decreasing) and any campaigns with significantly higher-than-baseline hard bounce rates.

High hard bounce rates in specific segments or import batches indicate list quality problems localised to those sources. Run those segments through email verification before future sends. Hard bounce rate above 2% in any individual campaign is an emergency signal requiring that segment to be halted and verified before any further sends.

Spam Complaint Rate by Segment

Cross-reference Gmail Postmaster spam rate data against your campaign calendar. The complaint spike dates should map to specific campaigns. Identify which audience segments were included in high-complaint campaigns that weren’t in low-complaint campaigns — this identifies the problematic audience.

If FBL data from Yahoo/AOL is available, examine complaint rates by segment and campaign type there as well. Yahoo complaints are often concentrated in specific list segments (acquired lists, cold outreach segments, re-engagement campaigns sent to very old subscribers).

Engagement Rate Trend by ISP

Break down open rates and click rates by recipient domain for the past 90 days. A significant divergence between, for example, Gmail engagement (25% open rate) and Outlook engagement (8% open rate) indicates ISP-specific filtering is occurring — some recipients are still opening at Gmail while the same emails are landing in spam at Outlook.

This analysis requires tracking data at the recipient domain level. Most ESPs provide domain-level delivery and engagement reporting. If yours does not, a seed list inbox placement test provides equivalent data.

Inactive Subscriber Percentage

Count the percentage of your active list that has not clicked in the last 90 days. Using click (not open) as the engagement metric is important because Apple Mail Privacy Protection generates false open signals for all Apple Mail users. A list where 60% of subscribers have not clicked in 90 days carries significant reputation risk with every send — these addresses dilute the positive engagement signals that protect the other 40% of your sends.

Layer 4: Content and Technical Email Structure

SpamAssassin Score

Send a representative template through mail-tester.com or GlockApps, which run messages through SpamAssassin and provide per-rule scoring. Scores above 3.0 indicate content patterns that will trigger filtering at some ISPs. Common triggers found in professional audits:

• Free link shorteners (bit.ly, t.co) in the message body — these domains are heavily abused and trigger filters
• Excessive exclamation marks and ALL-CAPS in subject lines
• Image-to-text ratio above 60% images — appears as advertising or phishing to filters
• More than 3 links in the message body for transactional email
• Spam keyword patterns — “FREE”, “limited time”, “act now”, “guaranteed” in subject lines

List-Unsubscribe Header

All bulk/marketing email must include a List-Unsubscribe header with both the mailto: and RFC 8058 https: (one-click) versions since Gmail’s and Yahoo’s February 2024 enforcement and Microsoft’s May 2025 extension:

List-Unsubscribe: <mailto:unsub@yourdomain.com>, <https://yourdomain.com/unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Both the one-click URL and the mailto address must be functional and process within two business days.

HTML/Plain Text Rendering

Every HTML email should include a plain-text MIME alternative. When plain text is absent, some ISPs score the message higher for spam, and some email clients render it poorly. Check that your ESP or MTA is generating plain text multipart/alternative for all HTML messages.

Message Size

Gmail clips messages exceeding 102KB and shows a “Message clipped” notice with a link to the full message. This means recipients see a truncated email and must click to view the rest — reducing engagement with tracking pixels and CTAs below the clip. Check the total message size of your templates and reduce image file sizes if exceeding 80KB.

Layer 5: Reputation Monitoring and Ongoing Maintenance

Establishing the Monitoring Stack

A deliverability audit is a point-in-time diagnosis; ongoing monitoring prevents the next degradation from going undetected. The minimum monitoring stack:

• Gmail Postmaster Tools: Check weekly minimum; daily during high-volume campaigns. Set a calendar reminder — there are no built-in alerts.
• Microsoft SNDS: Register your sending IPs and check weekly. SNDS data is delayed by 24–48 hours relative to actual delivery.
• MXToolbox Blacklist Monitor: Subscribe to alerts for your sending IPs. New blacklist listings should generate immediate notification, not be discovered in the next monthly audit.
• Inbox placement testing: Run a seed list test (GlockApps, Inbox Monster, or Litmus) monthly and before any major campaign. Tests show the current inbox/spam/promotions split across major ISPs without waiting for real campaign data.
• Sender Score: Check senderscore.org for your sending IPs monthly. Downward trends over weeks indicate accumulating reputation problems even if no single week shows alarming data.

Audit Frequency

• Full technical audit (all 5 layers): Quarterly, or immediately following any significant deliverability incident
• Authentication spot-check (Layer 1): Monthly — DNS records can be modified by multiple teams and errors introduced inadvertently
• Reputation monitoring (Layer 5): Weekly for core metrics; daily for spam rate during high-volume periods
• Pre-campaign content check: Before any send above 50,000 recipients, run a seed list test

Deliverability Audit Output: The Prioritised Fix List

The output of a completed audit should be a prioritised list of specific issues with specific remediation steps, categorised by urgency:

P0 — Fix immediately (blocking deliverability today): Authentication failures causing rejections (SPF PermError, DKIM fail, DMARC p=reject with failing sources), active Spamhaus SBL/XBL listings, missing PTR records, spam rate above 0.30% at Gmail, multiple SPF TXT records on the same domain.

P1 — Fix within one week (actively degrading deliverability): DMARC at p=none with no advancement plan, 1024-bit DKIM keys, blacklist listings on secondary lists (Barracuda, SpamCop), hard bounce rate above 1% in recent campaigns, Gmail Postmaster showing “Needs Work” on compliance items.

P2 — Fix within 30 days (preventive): SPF lookup count above 8 (approaching limit), missing List-Unsubscribe-Post header on marketing email, inbox placement below 85% at any major ISP, no bounce handling automation for soft bounce escalation.

P3 — Ongoing improvements: DMARC advancement from p=quarantine to p=reject, engagement segmentation improvements, content optimisation for spam score reduction, monitoring frequency improvements.