Email Deliverability Monitoring: DMARC, SPF, Bounces

Your email provider says the email was sent. Your logs say accepted: true. Your dashboard shows 99.8% delivery. And yet the prospect tells you on a sales call: "I never got it."

Email "delivered" doesn't mean the same thing it did five years ago. Since Gmail and Yahoo rolled out their 2024 sender requirements, a misconfigured DMARC record or a single bad campaign can quietly drop your reputation overnight — and your provider's dashboard will still say everything is fine. The mail server accepted the handoff. SendGrid logged a 250 OK. Postmark shows a green checkmark.

But the email never reached the inbox. It got filtered to spam, deferred, silently rejected by Gmail's filters, or routed to a junk folder no one checks. Your password reset emails stop arriving. Your trial-to-paid drip stops converting. Your customer notifications go missing. And the only signal that something is wrong is a slow trickle of "I never got your email" support tickets weeks later.

This guide covers what to monitor on email deliverability — DMARC, SPF, DKIM, bounce rates, spam complaints, sender reputation, and inbox placement — so you catch deliverability regressions in hours, not weeks, and keep your transactional and marketing email actually reaching inboxes.

Why Deliverability Is Now an Uptime Concern

For most teams, email used to be set-and-forget: configure SendGrid, send mail, check the dashboard occasionally. That model broke in February 2024, when Gmail and Yahoo started enforcing strict sender authentication for any sender doing more than 5,000 messages/day, and softer enforcement for everyone else.

What changed:

DMARC is now mandatory for bulk senders to Gmail and Yahoo. Without it, your email gets rejected or sent straight to spam.
SPF and DKIM alignment is enforced. A passing SPF doesn't help if the domains don't align with the visible sender.
One-click unsubscribe is required. Missing the List-Unsubscribe header? Your reputation drops.
Spam complaint rate is capped at 0.3%. Cross that line and Gmail starts deferring your mail.
A single bad campaign can crater your reputation. Reputation is per-domain and per-IP; once damaged, it takes weeks to recover.

The consequence: deliverability is no longer a marketing problem. It's an uptime problem. If your password-reset emails don't arrive, your product is functionally broken for the user trying to log in. If your invoice emails don't reach the inbox, you don't get paid on time.

And like most uptime problems, the right time to find out about it is before customers do.

"Sent" vs "Delivered" vs "Received"

The single most important conceptual shift: these three are not the same.

Status	What it means	What it doesn't tell you
Sent	Your provider accepted the API call	Whether it reached the receiving server
Delivered	The receiving mail server returned 250 OK	Whether it landed in the inbox
Received (inbox)	The recipient's mail server accepted and placed it in the inbox	Whether the recipient opened it
Engaged	The recipient opened or clicked	Whether they actually read it

Most email provider dashboards track up to "delivered." Almost none track "inbox placement" — the only one that actually matters for whether your message gets read.

A "100% delivered" stat with 60% spam-folder placement is a worse incident than a 90% delivery rate with 100% inbox placement. Your monitoring needs to surface the right layer.

What to Monitor for Email Deliverability

1) DNS Records: SPF, DKIM, DMARC, BIMI

The authentication records that prove your email is legitimate. They live in DNS, which means they can be edited, broken, or accidentally removed by anyone with DNS access.

SPF (v=spf1 ...) — TXT record on your sending domain listing which IPs are allowed to send. Watch for unauthorized changes and the SPF "10 lookup" limit (exceed it and SPF silently fails for all mail).
DKIM (selector record) — TXT record at <selector>._domainkey.<domain> containing the public key for signing. If rotated incorrectly, every email gets unsigned and reputation drops.
DMARC (_dmarc.<domain> TXT record) — The policy that ties SPF and DKIM together. Watch for accidental policy regression (p=reject downgraded to p=none).
BIMI (optional but valuable) — Brand indicator for displaying your logo in supported clients (Gmail, Apple Mail). Requires DMARC at quarantine or reject.

Set up DNS uptime checks on each of these. A monitor that queries the TXT record and validates the content (not just existence) catches misconfigurations early. See DNS Monitoring: The Overlooked Foundation of Website Reliability for the broader DNS monitoring approach.

2) Bounce Rate (Hard and Soft)

Bounces are the most direct deliverability signal — every bounce is an email that did not reach the recipient.

Hard bounces — invalid address, domain doesn't exist, mailbox closed. Permanent.
Soft bounces — mailbox full, message too large, temporary failure. Recoverable.

The numbers that matter:

Hard bounce rate > 2% = list quality problem; sending to invalid addresses damages reputation
Hard bounce rate > 5% = providers will start throttling or blocking
Soft bounce rate > 5% sustained = capacity or reputation issue
Sudden spike in bounces from one ISP (Gmail, Yahoo, Outlook) = reputation problem with that specific provider

Track bounce rate per sending domain, per IP, and per ISP separately. A 2% aggregate bounce rate is fine; a 12% bounce rate to Gmail with 0% to Yahoo is a Gmail-specific reputation crisis.

3) Spam Complaint Rate

Once a recipient hits "Report Spam," your reputation takes a hit. Gmail and Yahoo enforce a strict ceiling.

Gmail's hard ceiling: 0.3% spam complaint rate. Cross it and Gmail starts deferring or rejecting your mail.
Warning threshold: 0.1% — at this level your reputation is at risk
Spike detection — any complaint rate above 2× the rolling 7-day average should alert

Most providers expose complaint data via webhooks (SendGrid, Mailgun, Postmark all do). Capture them and aggregate by domain and campaign.

4) Sender Reputation Score

Your reputation is the cumulative judgment ISPs make about whether to deliver your mail. It's slow to build and fast to damage.

Sources of reputation signal:

Google Postmaster Tools — domain and IP reputation as Gmail sees you; updated daily
Microsoft SNDS — Smart Network Data Services for Outlook/Hotmail
Validity / Talos / Sender Score — third-party reputation aggregators

Monitor each of these on a daily schedule. Alert on any reputation drop from "high" to "medium" (Google), or any score decrease > 10 points (Sender Score).

5) Inbox Placement Rate

The most actionable metric and the hardest to measure from inside your provider.

Approach: seed mailbox testing. Set up a small number of test accounts at Gmail, Outlook, Yahoo, and Apple iCloud. Have your monitoring system send a test email to each on a schedule (every 1–4 hours for transactional sender domains, daily for marketing domains), then check via IMAP whether it landed in the inbox, spam folder, or neither.

Third-party services (GlockApps, Inboxable, Mailgun's Inbox Placement, etc.) automate this with a much larger seed list. For most teams, even a handful of seed accounts catches major regressions.

6) Blocklist Status

Your sending IPs and domains can land on public blocklists (Spamhaus, SpamCop, Barracuda, SORBS, etc.). Once listed, mail to many providers gets rejected outright.

Monitor each sending IP and sending domain against the top 5–10 blocklists
Alert immediately on any listing — every hour you're listed, more mail is being rejected
Most monitoring tools support this; otherwise, MultiRBL and HetrixTools offer free APIs

7) DMARC Reports

DMARC reports are the feedback loop ISPs send you about how authentication is going.

Aggregate reports (rua) — XML summaries sent daily from each ISP. Tell you which messages passed/failed SPF and DKIM alignment.
Forensic reports (ruf) — per-message failure samples. Useful for debugging but most ISPs send few or none for privacy reasons.

Parse aggregate reports daily and alert on:

A new sending IP appearing (could be unauthorized)
A spike in SPF or DKIM failures (could be a forwarder issue or misconfiguration)
A sustained authentication failure rate > 5%

Tools like Postmark DMARC, Valimail, dmarcian, and EasyDMARC parse and visualize these for you. Or build a small parser yourself — the XML format is straightforward.

8) Send Volume Anomalies

A spike or drop in send volume is often the leading indicator of a deliverability incident.

Sudden spike — could be a viral campaign or a bug looping on email sends
Sudden drop — could be a queue stuck, a worker crashed, or your provider throttling
Volume drifting up week-over-week — capacity planning signal; warmup if you're approaching limits

Per-Provider Specifics

SendGrid

Watch: Event Webhook for bounce/complaint/deferred events; suppression list growth
Common failure mode: dedicated IP reputation degrading silently; switch to a fresh IP requires re-warming
API: /v3/messages for sent-message lookup, /v3/suppression/* for suppression lists
Authentication: API key in Authorization: Bearer header — see Monitor Authenticated APIs With Bearer Tokens and Custom Headers

Postmark

Watch: bounce and spam complaint webhooks; the Outbound Stream reputation score
Common failure mode: separating transactional vs broadcast streams; transactional reputation is much more sensitive to volume changes
API: /messages/outbound and /bounces; /stats/outbound/bounces for aggregates

Mailgun

Watch: webhook events for delivered, failed, complained; per-domain reputation
Common failure mode: sending across multiple domains where one drags down the shared IP pool

AWS SES

Watch: CloudWatch metrics for bounce rate and complaint rate (SES enforces a 5% bounce and 0.1% complaint ceiling — exceed and your account gets suspended)
Reputation Dashboard — daily summary in the SES console
Common failure mode: sandbox mode forgotten; account suspension from threshold breaches

Resend

Watch: Activity log, webhook events, per-domain settings
Common failure mode: domain not verified at all (new senders), DMARC alignment incorrect

Self-hosted (Postfix, Haraka, Listmonk, Mautic)

You own everything: monitor the SMTP service uptime, queue depth, deferral rate, and outbound IP reputation manually
See: Email and SMTP Monitoring: Delivery and Uptime for the underlying SMTP-layer monitoring

Domain Reputation Drift

Reputation is the slow-moving variable that ultimately determines deliverability. Track it like you'd track a leading-indicator metric:

Daily snapshot of Google Postmaster Tools domain reputation, IP reputation, and authentication pass rate
Weekly snapshot of Microsoft SNDS color and complaint rate
Quarterly review of your sending patterns vs reputation trends

A reputation that drifts from "high" → "medium" over a month is signaling something specific (a campaign type, a list segment, a content pattern). Catching it early lets you adjust before it goes to "low" and your mail stops arriving.

Warming Up New IPs and Domains

When you switch providers, add a dedicated IP, or send from a new subdomain, ISPs treat you as a new sender. Your reputation starts at zero. Sending high volume immediately gets you rate-limited or filtered.

Standard warmup pattern:

Day 1: 50 messages to your most-engaged recipients
Day 2: 100
Day 3: 500
Day 4–7: double each day to roughly 16,000
Week 2: continue doubling to your target volume

During warmup, monitor:

Acceptance rate per ISP — Gmail might accept 100% while Yahoo defers everything; adjust accordingly
Deferral rate (421 and 450 responses) — temporary rejections that indicate ISP throttling
Spam folder placement via seed accounts — a warmup that lands in spam isn't a warmup at all

Tools like Warmup Inbox and Mailwarm automate this; for transactional senders, a manual rollout is usually fine.

Spike Detection: Bounce Rate vs Send Volume

The single most important alerting pattern: bounce rate spike relative to send volume.

A 2% bounce rate at 100K sends is 2,000 bounces. A 2% bounce rate at 10K sends is 200 bounces. Same percentage, very different impact on reputation. Alert on:

Bounce rate > 2× rolling 7-day average for > 1 hour (sudden quality drop)
Bounce count > 3× rolling 7-day average daily total (spike independent of percentage)
Either above metric for a single ISP (Gmail-only spikes are often the leading edge of a wider problem)

Same logic applies to spam complaint rate. The relative rate (% of sends) matters for reputation; the absolute count matters for ISP attention.

Alerting Thresholds That Actually Work

Email deliverability creates lots of noise — momentary blips, single-recipient issues, ISP-specific oddities. Tune for signal:

DNS authentication

SPF / DKIM / DMARC record missing: page immediately (production-down)
DMARC policy regressed (e.g., reject → none): page within an hour
SPF lookup count > 8: notification (close to the 10 limit)

Bounces

Hard bounce rate > 2% for 1 hour: notification
Hard bounce rate > 5% for 30 minutes: page
Per-ISP hard bounce rate > 5%: notification (one ISP is rejecting you)

Complaints

Spam complaint rate > 0.1%: notification (approaching Gmail's enforcement ceiling)
Spam complaint rate > 0.3%: page (Gmail starts deferring)

Reputation

Google Postmaster reputation drops from high → medium: notification
Sender Score drops > 10 points week-over-week: notification
Blocklist appearance on any monitored list: page immediately

Inbox placement (seed mailbox)

Test email lands in spam at Gmail or Yahoo: notification
Test email fails to arrive at all within 5 minutes: page

See Alert Fatigue: Notifications That Get Acted On for the broader principles.

Setting Up a Deliverability Canary Check

A minimal-but-useful canary:

Maintain a small set of monitoring seed addresses across Gmail, Outlook, Yahoo, and iCloud
From your application's normal sending path, send a test email to each on a schedule (every 1–4 hours)
Connect to each seed mailbox via IMAP and check whether the test arrived, and in which folder
Surface the result as a JSON response from an internal endpoint:

GET https://yourapp.com/internal/email-canary
Authorization: Bearer <monitoring-key>

Returning:

{
  "gmail":   { "delivered": true,  "folder": "inbox",  "elapsed_s": 12 },
  "yahoo":   { "delivered": true,  "folder": "inbox",  "elapsed_s": 8  },
  "outlook": { "delivered": true,  "folder": "spam",   "elapsed_s": 4  },
  "icloud":  { "delivered": false, "folder": null,     "elapsed_s": null }
}

Point an external uptime monitor at this endpoint with content validation that flags any "folder": "spam" or "delivered": false. See REST API Monitoring: Endpoints, Errors, and Performance for the underlying API monitoring patterns, and HTTP Status Codes Explained for how to model unhealthy responses.

For broader inbox-placement coverage, services like GlockApps and Mailgun's Inbox Placement provide larger seed networks.

Connecting Deliverability to the Rest of Your Stack

Email deliverability rarely fails in isolation. Common adjacent failures:

Your provider has an outage — see Third-Party Dependency Monitoring
You're being rate-limited by your provider — see API Rate Limit Monitoring: 429 Errors and Throttling
Webhooks from your provider stop firing — see Webhook Monitoring
Send queue stuck in your application — see Cron Job Monitoring
Multi-region sending issues — see Multi-Region Monitoring: Why Location Matters
SMTP-layer issues at your provider — see Email and SMTP Monitoring

The user-visible symptom — "my emails aren't arriving" — can have a dozen root causes. Layered monitoring catches the right one faster.

Deliverability Monitoring Checklist

For every production sender domain:

SPF, DKIM, DMARC, and (if applicable) BIMI DNS records monitored with content validation
SPF lookup count tracked (alert at 8+)
DMARC aggregate reports parsed daily; alert on auth failure spikes and unknown sending IPs
Bounce rate tracked per ISP, per domain, per IP
Spam complaint rate tracked with 0.1% and 0.3% alerts
Google Postmaster Tools and Microsoft SNDS scraped daily
Sender Score (Validity) checked weekly
Blocklist status checked daily on top 10 RBLs for every sending IP/domain
Seed mailbox inbox placement check every 1–4 hours
Send-volume anomaly detection (spike up, drop, drift)
Per-stream tracking (transactional vs marketing vs broadcast) — they have very different deliverability profiles
Warmup plan documented for any new IP or domain
Provider status page subscribed (lagging indicator only)
Internal /internal/email-canary endpoint with content-validated external monitoring

How Webalert Helps Monitor Email Deliverability

Webalert handles the external monitoring layer of email deliverability:

DNS monitoring — Watch SPF, DKIM, DMARC, and BIMI TXT records; alert on content changes
HTTP monitoring with custom headers — Hit your internal email-canary endpoint with authentication; validate the JSON response shape
Content validation — Alert when "folder": "spam" or "delivered": false appears in your canary response
Response time alerts — Catch delivery latency degradation before it becomes complete failure
Multi-region checks — Confirm DNS and canary endpoints from the regions your sending originates in
1-minute check intervals — Detect DNS misconfigurations within a minute
Multi-channel alerts — Email, SMS, Slack, Discord, Microsoft Teams, webhooks
Status page — Communicate with customers when email delivery is degraded
5-minute setup — Add the records and endpoints, set thresholds, and you're live

See features and pricing for details.

Summary

"Sent" and "delivered" are not the same as "received in the inbox." Your provider's dashboard shows the first two; the third is what actually matters.
Post-2024 Gmail/Yahoo enforcement made DMARC, SPF, and DKIM mandatory for any bulk sender — a missing record now means silent inbox failure, not a warning.
Monitor the full deliverability stack: DNS authentication records, bounce rate per ISP, spam complaint rate, sender reputation across Google/Microsoft/Validity, blocklist status, and inbox placement via seed mailboxes.
Bounce-rate spikes relative to send volume are the strongest leading indicator of a reputation problem; per-ISP breakdown localizes the issue fast.
Each provider — SendGrid, Postmark, Mailgun, SES, Resend, self-hosted — has its own quirks; the underlying monitoring pattern is the same.
Warm new IPs and domains slowly, monitor acceptance per ISP during warmup, and never start a new sender at full volume.
Connect deliverability monitoring to the broader stack: DNS, webhooks, rate limits, and queues all influence whether mail actually arrives.

Email is invisible infrastructure for most products until it stops working. Make the invisible visible — and the "did they get it?" question becomes one you answer with a dashboard, not a support ticket.

Catch deliverability regressions before campaigns silently fail

Start monitoring with Webalert →

See features and pricing. No credit card required.