Every Deliverability Engineering Audit check

Without programmatic SPF validation, you have no guarantee that your sending domain's SPF record is correctly published — or published at all. RFC7208 alignment is a prerequisite for DMARC enforcement: if SPF fails, email from your domain reaches the spam folder or is rejected outright. Manual DNS management introduces silent misconfiguration: a deployment that adds a new sending IP without updating the SPF record will quietly fail authentication for weeks before anyone notices the deliverability drop.

Why this severity: Critical because an absent or misconfigured SPF record causes immediate authentication failure, breaking DMARC alignment and triggering spam classification or outright rejection at major mailbox providers.

A hardcoded DKIM private key is a secret embedded in source code — readable by anyone with repository access and impossible to rotate without a code deployment and DNS change happening in exact coordination. CWE-321 (hard-coded cryptographic key) and CWE-338 (weak PRNG for key material) both apply. When a DKIM key is compromised, the only remediation is to publish a new key under a new selector and retire the old one; with a static selector and no secrets manager, that operation requires a full deployment cycle, during which your signing infrastructure is either broken or still using the exposed key.

Why this severity: Critical because a compromised DKIM private key allows adversaries to forge authenticated email from your domain, and a static selector makes key rotation operationally infeasible without a deployment and DNS coordination window.

A DMARC record at `p=none` is monitoring mode only — it generates aggregate reports but does not instruct receiving mail servers to reject or quarantine spoofed email. Attackers can send phishing email appearing to come from your domain and it will land in inboxes unchallenged. RFC7489 requires `p=quarantine` or `p=reject` before DMARC provides any actual protection. Google's bulk sender guidelines for 2024 mandate DMARC enforcement for domains sending more than 5,000 messages per day; senders without enforcement face increasingly aggressive filtering at Gmail.

Why this severity: Critical because `p=none` provides zero spoofing protection — your domain can be impersonated in phishing campaigns with no technical barrier, and Gmail's bulk sender requirements mandate enforcement-level DMARC for high-volume senders.

SPF authenticates the envelope sender (Return-Path), not the visible From header. When an ESP handles bounces from a different domain than your From address — e.g., From is `noreply@company.com` but Return-Path is `bounce@esp-platform.net` — SPF passes for the ESP's domain but fails alignment with your From domain. Under strict DMARC (adkim=s; aspf=s), misaligned SPF causes DMARC to fail even when SPF itself passes, per RFC7489-s3.1. The practical result is that emails landing in Gmail and Outlook are more likely to be filtered, defeating the purpose of your authentication stack.

Why this severity: High because Return-Path misalignment causes SPF alignment failure under strict DMARC, undermining authentication across major mailbox providers even when SPF itself passes for the ESP's bounce domain.

BIMI (Brand Indicators for Message Identification) displays your company logo directly in Gmail and Apple Mail inboxes, making authenticated email visually distinct from spoofed mail. For high-volume B2C senders, brand recognition in the inbox measurably increases open rates and recipient trust. BIMI requires a DMARC policy at `p=quarantine` or `p=reject` as a prerequisite, meaning it also validates that your domain's authentication stack is at enforcement level. Absence of BIMI is a missed opportunity for inbox differentiation at the accounts where it matters most — Gmail and Apple Mail — per the 2022 BIMI specification.

Why this severity: Info because BIMI absence has no deliverability impact and is only relevant for high-volume B2C senders who have already achieved DMARC enforcement and consistent brand sending.

Sending at full volume from a new IP or domain on day one is the single most common cause of catastrophic deliverability failure for email platforms. ISPs track the ratio of wanted-to-unwanted email per IP; a new IP sending 100,000 messages before establishing reputation triggers spam classification at Gmail, Yahoo, and Outlook simultaneously, often with blocks that take weeks to reverse. The industry-standard remediation is a 2–4 week progressive warm-up starting at dozens of sends per day and doubling every few days — enforced by code, not a spreadsheet. Without automated enforcement, a scheduled job or a marketing push will bypass any manual volume intention.

Why this severity: High because launching at full sending volume from a new IP or domain routinely causes permanent reputation damage that requires weeks of suppressed sending to recover from, blocking all outbound email during the recovery period.

Domain reputation and IP reputation are independent signals that mailbox providers track and report separately — Google Postmaster Tools explicitly distinguishes them. A domain reputation hit means your content or authentication history is the problem; an IP reputation hit means the specific IP's sending behavior is the problem. If you only track a combined metric, you cannot determine whether to reconfigure content and authentication (domain issue) or rotate to a new IP (IP issue). Without separation, diagnosing and recovering from deliverability problems is guesswork that delays resolution and extends inbox-blocking.

Why this severity: Low because conflating domain and IP reputation metrics slows diagnosis and recovery time rather than causing immediate inbox failure, but the operational cost of undiagnosed reputation problems compounds over time.

Without programmatic integration with Google Postmaster Tools or Microsoft SNDS, you learn about reputation problems by noticing a drop in open rates — days or weeks after the damage occurred. Postmaster Tools reports domain reputation (high/medium/low/bad), IP reputation, DMARC pass rate, and spam classification rate for Gmail traffic. Microsoft SNDS reports IP reputation and complaint rates for Outlook. Both platforms provide the earliest warning signal available before inbox filtering escalates to blocking. Manual monitoring via dashboard login means the signal arrives too late and only when someone remembers to check.

Why this severity: High because reputation degradation at Gmail and Microsoft can block delivery to the majority of a subscriber base within days of a threshold crossing, and automated monitoring is the only way to catch and act on the signal before blocks take effect.

Google's 2024 bulk sender guidelines mandate that senders maintain complaint rates below 0.10% to avoid inbox filtering at Gmail — the platform receiving roughly one-third of all consumer email in the US. Complaint rates above 0.30% result in throttling or blocking. Without code that monitors this rate and fires an alert before crossing the threshold, the first indication of a problem is often a sharp drop in open rates, by which point Gmail's filtering is already active and may persist for days or weeks after the rate is corrected. The 0.08% early-warning threshold gives an action window before the hard limit is breached.

Why this severity: Medium because complaint rate spikes are frequently triggered by specific campaigns rather than systemic failures, and an alert at 0.08% gives time to pause the offending campaign before Gmail's 0.10% threshold triggers automatic filtering.

Reputation monitoring that overwrites the current value on each update cannot answer the question every deliverability incident requires: was reputation already trending down before the campaign that triggered the alert, or did it spike suddenly? Trend analysis distinguishes a gradual erosion (a list quality problem) from an acute spike (a bad campaign or an infrastructure misconfiguration). Without historical rows, you cannot correlate reputation changes with specific sends, detect seasonal patterns, or demonstrate to an ESP's abuse team that a reputation problem is resolved. The operational blind spot shows up worst in post-incident review.

Why this severity: Low because single-row upsert storage does not cause immediate delivery failure, but it eliminates the ability to perform trend analysis or root-cause incident review without external tooling.

Mailbox providers impose strict per-IP connection and message limits that differ significantly: Gmail accepts roughly 250 SMTP connections per hour from a new IP, Yahoo and AOL limit to around 20 connections per hour per IP, and Outlook uses session-based hourly quotas. RFC5321-s4.5.3 makes clear that exceeding these limits results in 421 temporary deferrals. When all recipients are throttled identically — ignoring which ISP is receiving — the system will inevitably over-deliver to restrictive providers, accumulating 421 responses that reduce effective throughput and signal poor sending behavior, eroding IP reputation at the exact providers where limits are tightest.

Why this severity: High because ISP-agnostic throttling causes 421 deferrals and throughput reduction at Yahoo and Outlook specifically, where per-IP limits are tightest, with repeated deferrals contributing to IP reputation degradation.

SMTP 421 and 450 responses are explicit instructions from the receiving mail server to stop sending and retry later — they are not failures to ignore or retry immediately. RFC5321-s4.2.1 specifies that temporary failures must trigger a retry with increasing delay. Retrying at the same rate after a 421 is the sending equivalent of knocking louder when no one answers — it accelerates the point at which the ISP upgrades the temporary block to a permanent one. Systems that treat 4xx responses as hard failures (discarding the message) also lose deliverability: the message is gone, not deferred.

Why this severity: High because immediate retry at unchanged rate after 4xx responses consistently causes escalation from temporary ISP deferral to extended blocking, with message loss occurring when non-retried 4xx responses are incorrectly treated as permanent failures.

Campaigns that dispatch thousands of messages within minutes create volume spikes that look identical to spam runs from the perspective of receiving mail servers. ISPs score sending behavior partly on burst patterns — a sudden jump from zero to 10,000 messages per hour is a reputation signal regardless of content quality. Volume smoothing distributes the same total campaign volume over hours instead of minutes, keeping the per-minute send rate below ISP thresholds and avoiding the spike-and-throttle pattern that damages reputation cumulatively over multiple campaigns.

Why this severity: Low because a single burst event typically results in temporary deferral rather than permanent blocking, but repeated burst patterns train ISP filters to treat the sending IP as a high-risk sender.

Not all campaigns carry the same deliverability risk. A reactivation campaign to a cold list should send at a fraction of the rate appropriate for an active engaged segment. When all campaigns share a single global rate, a high-risk campaign — cold list, broad reach, lower expected engagement — runs at the same throughput as a tight re-engagement campaign, exposing the IP's reputation to the full complaint rate of the worst-performing send. Per-campaign configurable limits let operators deliberately throttle risky campaigns without touching the global settings or pausing the system.

Why this severity: Low because the absence of per-campaign limits does not cause immediate delivery failure, but it removes a key operational lever for managing deliverability risk on a per-send basis without global system changes.

Per-campaign and per-ISP limits are only as safe as their configuration — a misconfigured campaign with no `maxPerHour` and a per-ISP limit set too high can still dispatch thousands of messages per minute if there is no outer bound. A global system rate limit is the circuit breaker: regardless of what any campaign or ISP limiter is configured to allow, the system as a whole cannot exceed this ceiling. This single control prevents a configuration error, a bug in rate limit logic, or a runaway queue worker from causing catastrophic volume spikes that would require weeks of reputation recovery.

Why this severity: Low because the global limit is a safety net that only matters when other rate controls are misconfigured or absent, but its absence means there is no backstop against cascading misconfiguration at other levels.

SMTP 5xx codes (550, 551, 553, 554) are permanent rejections from the receiving server, per RFC5321-s3.6 — the address does not exist, the mailbox is closed, or delivery is permanently refused. Continuing to send to permanently invalid addresses does two things: it increases your hard bounce rate (ISPs track this per IP and per domain), and it confirms to ISPs that you are not maintaining list hygiene. Google and Yahoo both publish hard bounce rate thresholds; exceeding them triggers increasingly aggressive filtering that affects deliverable addresses in the same campaign. Suppression must be immediate, not batched.

Why this severity: High because accumulating hard bounces from repeated sends to invalid addresses directly degrades IP and domain reputation metrics tracked by major mailbox providers, leading to inbox filtering that affects legitimate recipients.

Soft bounces (4xx SMTP responses) indicate temporary conditions — a full mailbox, a server outage, a transient policy block. A single soft bounce warrants a retry. But an address that soft-bounces three or more times within a week is not temporarily unavailable: it is either abandoned, over quota indefinitely, or rejecting your domain specifically. RFC5321-s4.2.1 establishes that repeated temporary failures should eventually be treated as permanent. Without escalation logic, the system will retry indefinitely, accumulating poor delivery metrics and flagging the sending IP as one that ignores bounce signals.

Why this severity: High because repeated soft bounces to the same address without escalation inflate failed-delivery metrics and signal poor list hygiene to mailbox providers, contributing to IP reputation degradation over time.

Hard and soft are a coarse-grained taxonomy that obscures the correct remediation for each failure type. A mailbox-full bounce (452, 552) is a temporary capacity issue — retry in 24 hours. A content-blocked bounce (550 containing 'spam') means a campaign is triggering spam filters — retry will not help; the campaign content must change. A domain-not-found bounce means the sending domain itself is rejected — DMARC or IP reputation requires review. RFC3463 defines enhanced status codes specifically to enable this differentiation. Collapsing all bounces to hard/soft forces engineering to run manual queries against diagnostic messages to recover information that should be structured in the data model.

Why this severity: Medium because routing all hard bounces to the same suppression flow masks content-blocked and policy-rejected failures that require campaign or infrastructure review rather than address suppression.

A feedback loop (FBL) complaint fires when a recipient hits the 'Report Spam' button in their email client — Yahoo, Comcast, and other providers forward these reports to the sender via RFC5965 ARF-formatted emails. ESP platforms (SendGrid, SES, Mailgun) deliver FBL events directly via webhook. If the application does not process these events and add the complaining address to the suppression list immediately, the system will send again to someone who has explicitly marked the email as spam — guaranteeing a second complaint from the same address. Repeat complainers are among the strongest signals ISPs use to classify a sending IP as spam-originating.

Why this severity: High because CWE-345 (insufficient verification of data authenticity) applies to FBL processing — unverified or unprocessed complaint events allow repeat sends to explicit complainers, directly accumulating the complaint rates that trigger ISP filtering.

Individual bounce and complaint event rows tell you what happened; per-campaign and per-domain aggregate metrics tell you which campaigns and which domains are causing the problem. A campaign that achieves a 5% bounce rate damages reputation differently from one achieving 0.5% — but without precomputed aggregate metrics, identifying the high-bounce campaign requires an ad-hoc query that no one runs until the deliverability crisis is already underway. Per-domain aggregates enable the question: is the bounce rate increasing consistently for a specific sending domain, indicating DNS authentication drift, or is it isolated to specific campaigns, indicating list quality problems?

Why this severity: Low because the raw events are still stored and queryable, but the absence of precomputed aggregates means actionable signals only surface through manual analysis rather than automated alerting.

Sending campaigns or transactional email from the company's primary domain — the same domain used for employee email and the public website — means a single deliverability incident puts all corporate communication at risk. A reputation hit on `company.com` from a marketing campaign can cause `ceo@company.com` to land in spam at Gmail. RFC7489-s3 describes this failure mode implicitly: DMARC policy applied to the primary domain affects all mail from that domain, marketing or not. Domain isolation using a sending subdomain (`mail.company.com`) confines reputation impact to the sending infrastructure and leaves corporate email unaffected by campaign performance.

Why this severity: High because using the primary corporate domain for bulk sending creates a single reputation failure point — a bad campaign can block all company email, including transactional and employee-to-recipient communications, at major mailbox providers.

Marketing email and transactional email have fundamentally different engagement profiles. Marketing email generates higher complaint rates, lower open rates, and more unsubscribes than password resets, receipts, and account alerts. When they share an IP and sending domain, the reputation damage from a poorly-performing campaign delays or blocks the delivery of time-sensitive transactional messages — password resets that users are actively waiting for, order confirmations that trigger support tickets when delayed. Traffic separation is the architectural guarantee that a bad marketing campaign cannot block the transactional email infrastructure.

Why this severity: Low because traffic mixing does not cause immediate problems when campaigns perform well, but a single high-complaint marketing campaign creates a direct path to delayed transactional delivery for the same users who filed the complaints.

At volumes above 100,000 emails per day, a single sending IP becomes both a performance bottleneck and a single point of reputation failure. A block on one IP stops all sending until it is manually removed and replaced — a process that can take hours. IP pool management distributes sending load across multiple IPs and allows the system to automatically exclude a blocked or high-bounce IP and continue sending through healthy ones, without downtime or engineering intervention. Reputation-weighted or least-used selection also prevents one IP from absorbing a disproportionate share of sends while warm-up periods complete on others.

Why this severity: Low because single-IP architectures are acceptable at lower volumes, but above 50,000 emails per day a single IP block creates a total sending outage that requires manual intervention to resolve.

DNS records for email authentication — SPF, DKIM, DMARC, MX, BIMI — are the foundation of your deliverability infrastructure, and incorrect changes to any of them can cause immediate authentication failure or domain spoofing exposure. When DNS is managed exclusively through a web UI, there is no change history, no peer review, no rollback, and no audit trail. A DKIM selector changed in the provider console without a corresponding key update in the secrets manager, or an SPF record that inadvertently drops an authorized sender, will cause delivery failures across your entire subscriber base. RFC1035 records defined as infrastructure-as-code follow the same review process as code changes, providing the same safety guarantees.

Why this severity: Info because unversioned DNS management increases operational risk and recovery time from misconfiguration rather than causing an immediate delivery failure, but its impact becomes critical the moment a misconfiguration occurs.