How to Use Latency Percentiles Over Time to Detect ISP Throttling or Filtering
Use latency percentiles over time to detect ISP throttling or filtering in real email delivery.
Why standard email delivery metrics fail to catch ISP throttling
You send an email. It shows as delivered. No bounce. No error. But your open rate is lagging. Your inbox placement is slipping. You’re frustrated—because your delivery metrics tell you everything’s fine, even as your audience engagement dips.
That’s because traditional delivery checks only track success or failure—never time. A message that arrives 48 hours late gets counted the same as one that lands in 5 seconds. ISP throttling hides in that silence. Delays, not bounces, are the signal.
Without tracking latency percentiles over time, you miss the slow bleed: a gradual degradation in delivery speed that erodes sender reputation, harms inbox placement, and cuts engagement—without ever triggering an alert.
Key takeaways
- Standard delivery reports show only success/failure, not delivery timing, making ISP throttling invisible.
- Latency increases over time—especially in the 90th percentile—often signal throttling before bounces appear.
- Monitoring latency trends allows teams to detect subtle drops in delivery performance before they impact deliverability and engagement.
What latency percentiles reveal about ISP behavior
Latency percentiles like p50, p90, and p99 show how delivery times are distributed across your email stream, not just average delays. A rising p99 latency—where the slowest 1% of deliveries get progressively slower—often signals that an ISP is throttling or filtering traffic, especially when paired with low bounce rates. If you see consistent increases in top-tier latency without a spike in failures, it’s a red flag for intentional delay or selective queuing.
Why percentiles beat averages for spotting ISP issues
Average latency can mask extreme delays. If 99% of messages arrive on time but one delivery takes 30 seconds, the average still looks low. But p99 captures that 1% of slow cases. When p99 steadily climbs over days or weeks, it shows degradation at scale—what ISPs do when they’re rate-limiting or applying queuing policies.
Consider: a stable p50 with a rising p99 suggests traffic isn’t being lost, but being delayed. This is common with throttling, where ISPs slow down incoming volumes from certain senders without dropping messages. It’s also seen during filtering, where messages are placed in lower-priority queues based on reputation.
Monitoring these trends over time—especially across different ISP domains—helps you spot behavioral shifts before deliverability drops. RFC 5321, which governs SMTP, outlines the expected response times for message transfer, and deviations can indicate non-compliant handling by an ISP.IETF RFC 5321 does not specify exact thresholds, but defines acceptable timeframes for delivery steps. When observed delays exceed those norms significantly, it may point to deliberate interference.
Let’s say your p99 latency jumps from 1.5 seconds to 8 seconds over a week across a major ISP. If bounce rates remain under 0.5%, and no technical issues are on your end, this pattern strongly correlates with throttling. Some ISPs throttle high-volume senders during peak hours or when they detect bulk patterns.
How to act on percentile trends
Use latency percentiles as early warning signals. If you notice p99 trending upward, investigate the targeted ISPs and analyze message timing patterns. Cross-reference with delivery logs and routing headers, especially if your mail stream includes both legitimate and high-volume segments.
For teams using automated email campaigns, testing inbox placement across different providers can help isolate which ISPs are delaying messages. Tools like MailTester’s inbox placement tester verify inbox delivery patterns, including timing and filtering behavior—complementing your latency analysis with real-world inbox results.
How to collect and structure latency data for ISP analysis
You can detect ISP throttling or filtering by tracking time-to-delivery per email using real-time SMTP logs or provider APIs. Group these measurements by ISP (derived from the recipient’s domain), day, and hour. Store each result with a timestamp, delivery status, SMTP response code, and delivery time in milliseconds. This structured data allows you to identify consistent delays or anomalies that signal intentional filtering.
Step-by-step data collection process
- Use SMTP logs or email provider APIs to capture delivery timing. Every time you send a message, record the exact moment the SMTP transaction completes and the delivery response is received. This timestamp is your baseline for measuring delivery speed. This is the only reliable way to quantify latency across real-world email routes.
- Extract the ISP domain from the recipient's email address. For example, from
[email protected], extractgmail.com. Use this domain to group data by ISP. This makes it possible to compare delivery performance across different providers, like Gmail, Outlook, or Yahoo, even when they share similar network infrastructure. - Aggregate data by calendar day and hour. Group deliveries into hourly buckets and daily intervals. This reveals patterns such as peak-hour delays or overnight throttling. For instance, if messages to
gmx.netconsistently take 45 seconds to deliver between 10–11 AM on weekdays, that’s a red flag not visible in raw, ungrouped logs. - Record delivery status, SMTP response codes, and time in milliseconds. For each message, log: whether it succeeded, failed, or was postponed; the specific SMTP code (e.g., 250 for success, 421 for temporary failure); and the actual latency in milliseconds. This enables correlation — e.g., repeated 421 responses at high latency may indicate throttling during connection attempts.
- Store data in a time-series database or structured log file. Use systems like PostgreSQL, Elasticsearch, or CloudWatch to index records by ISP, date, and hour. This allows efficient querying and visualization (e.g., plotting latency over time per ISP). The storage format must support efficient filtering and aggregation across dimensions.
Why structure data this way?
Without grouping by ISP and time, delays are indistinguishable — you can’t tell if a slow message arrived because of a misconfigured server or deliberate ISP throttling. By isolating performance by domain and time window, you expose behavioral patterns. The SMTP standard (RFC 5321) defines how delivery attempts should be logged, making consistency across systems possible. For context, RFC 5321 requires delivery status codes to be returned in real time, which supports accurate measurement.
For teams using automated email campaigns, this data helps isolate deliverability issues before they impact engagement. You can use tools like MailTester’s bulk email verification to clean lists before sending, reducing invalid or high-latency deliveries at the source. With clean, verified data and proper tracking, deviations become identifiable and actionable.
Calculate and interpret latency percentiles over time
You can detect ISP throttling or filtering by tracking delivery latency percentiles—p50, p90, and p99—over time for each ISP. A rising p99 across multiple days, especially above 300ms for three or more consecutive days, indicates worsening delays that may stem from intentional filtering or congestion.
Step-by-step process
- Collect delivery time data per ISP and time window — For each ISP (e.g., Gmail, Yahoo, Outlook) and daily time window, record the time from email send to first delivery acknowledgment (e.g., SMTP reply, bounce). Use a consistent timing method, such as measuring from the moment SendGrid or AWS SES confirms sending.
- Sort delivery times for each ISP per time window — Once you have the data, sort all delivery times in ascending order for each ISP and day. This allows accurate percentile computation.
- Compute p50, p90, and p99 — For each sorted set, calculate the 50th, 90th, and 99th percentiles. p50 (median) shows typical performance; p90 captures near-worst-case delays; p99 identifies extreme outliers, often linked to throttling or routing issues.
- Plot trends over time — Visualize p99 across consecutive days. A steady upward trend—especially beyond 300ms—suggests the ISP is introducing or increasing delays, which may signal throttling or traffic filtering.
- Compare to baselines — Define normal thresholds: 50ms p99 is acceptable in most cases. If p99 exceeds 300ms for three or more days, investigate further. The difference between daily p99 values is often more telling than absolute numbers.
What to watch for in your data
ISP throttling often shows up first in p99. A jump from 100ms to 400ms in p99 over two days, while p50 remains stable, suggests only a small number of emails are being delayed severely—common with filtering policies or rate limiting. This pattern is documented in industry monitoring reports by tools like Spamhaus and MXToolbox, which observe similar anomalies during network congestion or anti-abuse actions.
For email systems, consistent p99 spikes correlate with reduced inbox placement. If you're sending to major providers and see these trends, you’re likely affected—whether via infrastructure issues, throttling, or content scrutiny.
Use real-time tools to verify sender reputation and detect anomalies early. MailTester’s inbox placement tester helps simulate delivery paths and identify latency or filtering patterns across ISPs without sending to real users.
What a rising p99 latency over time actually means
A consistently rising p99 latency—especially over days or weeks—typically signals that an ISP is intentionally delaying delivery. This is strong evidence of throttling, not just congestion. High-volume senders or those flagged for spam-like behavior often trigger this response. It’s not a random delay; it’s a deliberate, observed pattern used to assess sender reputation before full delivery.
Why p99 matters more than average
While average latency can be skewed by outliers, p99 reflects the slowest 1% of deliveries. If that number climbs steadily, you’re seeing a systemic issue—something’s not just slow, it’s being monitored. ISPs use this delay to test for automation, volume spikes, or potential abuse without outright blocking messages.
Think of it like a security checkpoint that slows down every third passenger after a certain threshold. It’s not stopping anyone, but it’s watching. That’s exactly what happens during throttling: the ISP isn’t filtering your email—yet—but it is delaying it enough to evaluate your behavior.
Filtering vs. throttling: understanding the difference
Filtering usually results in immediate rejection or quarantine. It’s a binary action—message accepted or blocked. Delays aren’t typical. If your emails are being held for hours or days, it’s not filtering. It’s throttling. This distinction is critical when diagnosing deliverability issues.
According to research from Return Path (now Validity) and other industry studies, delay-based throttling is commonly used by ISPs like Gmail and Yahoo when they detect behavior inconsistent with normal email patterns.
Let’s be clear: if your delivery times aren’t just slow—they’re getting worse over time—this is not network noise. You’re being watched. ISPs use rising p99 as a tool to manage sender load. It’s not punishment yet, but it’s a warning sign.
Before you assume it’s routing or infrastructure, map latency over time. Correlate it with sending volume and content patterns. You can test whether this issue is sender-side or ISP-side with inbox placement checks. Try MailTester's inbox placement tests across major providers to see if your messages are being delayed or blocked.
How ISPs throttle: the mechanics behind delayed delivery
ISPs sometimes delay message delivery by queuing emails for minutes or even hours—without rejecting them—by accepting the SMTP connection and completing the handshake, but postponing actual delivery. This isn’t a bounce, nor is it a block; it’s a strategic throttle used when a sender’s volume spikes or reputation shifts, often to protect their own infrastructure or filter incoming spam.
SMTP success doesn’t mean timely delivery
When an ISP throttles, the SMTP session ends successfully—your server gets a 250 OK response. That’s why tools that only check for hard bounces miss it entirely. The message was accepted, but it’s stuck in a queue, sometimes for hours. This delays inbox placement and can hurt campaign timing, especially for time-sensitive content.
Let’s be clear: this isn’t filtering, not exactly. It’s not that the email is rejected or marked as spam—it’s simply delayed. The queue is often based on sender reputation signals, such as sudden spikes in volume, spikes in complaint rates, or IP address history. High-volume senders, especially those sending to known high-risk domains, frequently hit this threshold.
Why throttling is hard to detect without real-time metrics
Standard bounce reports say nothing about delay. A 200+ ms latency spike in your outbound logs might look normal—but when you start tracking latency percentiles over time, you see patterns: consistent delays at 10-minute or 1-hour intervals, especially during peak sending hours. That’s a red flag of ISP throttling, not network congestion.
You can test this behavior with deliverability tools that simulate real inbox placement across major providers. For example, you can use MailTester to validate that a message reached the inbox, even if it took 47 minutes—something standard SMTP logs won’t reveal. Test inbox placement across Gmail, Outlook, and Yahoo to see real delivery timing, not just SMTP success.
While RFC 5321 defines the SMTP protocol, it doesn’t govern delivery timing. So ISPs are free to queue messages as they see fit. This is documented in industry analyses like those from Spamhaus and MxToolbox, both of which cite timing-based throttling in response to sending anomalies.
Using MailTester’s inbox placement testing to validate ISP throttling
You can use MailTester’s inbox placement tests to detect ISP throttling by tracking latency percentiles over time. These tests send real emails to actual ISP inboxes, recording delivery speed and final status. A steadily increasing p99 latency with no bounces in a batch indicates throttling — not delivery failure — because the message arrives late but is accepted. This is a clear signal the ISP is delaying messages, often during high-volume sending periods.
How latency percentiles reveal throttling patterns
- Run regular inbox placement tests through MailTester’s inbox tester to simulate real-world delivery across major ISPs.
- Each test logs the time from submission to inbox arrival, giving you an accurate delivery time for each recipient.
- Aggregate those delivery times into latency percentiles (p50, p90, p99) to spot trends — not just average delays, but worst-case scenarios.
- Monitor p99 (99th percentile) over time. A spike in p99, especially when bounce rates stay at 0%, is a red flag for throttling, not failure.
- Compare results across multiple test runs. Consistent high p99 with zero delivery failures strongly suggests the ISP is intentionally delaying messages, not rejecting them.
Why this matters for sender reputation and deliverability
ISPs throttle senders not to block, but to manage volume and spam risk. If you’re not catching this early, your messages may arrive too late to be relevant, harming engagement and possibly triggering feedback loops. Unlike a hard bounce, throttling doesn’t alert you — but it still damages delivery quality.
MailTester’s real-time testing reflects actual ISP behavior. Unlike automated spam score checks, it measures real delivery delays in live inboxes. For context, standards like RFC 5321 define SMTP transaction timing, but ISPs may extend that timing during policy enforcement. A p99 over 20 minutes, with zero bounces, aligns with known throttling thresholds in industry reports on email delivery performance.
Use your inbox placement data as a diagnostic tool. When p99 climbs and engagement drops, you now know why — you’re being throttled. Adjust send volume, warm up IPs more slowly, or engage with the ISP via feedback loop tools. This visibility gives you control where automated tools fail.
For more precise detection, combine inbox placement tests with domain reputation checks using MailTester’s email checker or bulk verification via bulk verification to clean your list before sending — ensuring latency issues aren’t from bad addresses.
How to correlate latency trends with sender reputation signals
If your email latency p99 is rising while spam complaints, bounce rates, and engagement stay low, it’s a sign ISPs may be throttling your messages rather than rejecting them outright. This discrepancy—high delay with no delivery failure—suggests active filtering or queuing based on sender reputation. You can verify whether your IP or domain is flagged by checking reputation signals through tools like MailTester.
When latency spikes point to throttling, not delivery failure
Normal delivery delays are often due to network issues or recipient server load. But when p99 latency increases consistently across multiple ISPs while bounce rates remain under 0.5% and engagement metrics stay high, that’s a pattern suggesting deliberate throttling. Some ISPs slow down or delay messages from senders with poor reputation, even if the email technically passes all technical checks.
Spam complaints or hard bounces typically correlate with high latency, but not always. If neither is rising but latency climbs, the sender’s reputation is likely the trigger. This is consistent with industry observations that ISPs use reputation-based rate limiting as a de facto spam control mechanism.
Validate reputation and isolate the root cause
Let’s be honest: you can’t diagnose throttling by latency alone. You need to cross-check with sender reputation data. Use MailTester’s email checker to validate a single address’s validity and check if it’s on known blocklists. For bulk testing, run your entire list through the bulk verification tool to clean invalid and risky addresses before sending.
For deeper insight, use MailTester’s inbox placement test to see how your messages land across major providers. This reveals whether emails arrive late, go to spam, or are silently throttled. Combined with your latency data, you’ll see a clear picture: high p99 + good deliverability but poor placement? Likely throttling. High p99 + high bounce? Probably a technical or reputation issue.
Reputation is more than a score—it’s behavior. ISPs monitor sending patterns over time. If your IP has a history of low engagement or poor sender alignment, even small increases in latency can trigger rate limiting. Tools like Spamhaus and the IETF’s RFC 5322 help define expected sender behavior. When your latency trends diverge from that baseline, it’s a signal to audit your practices and reputation.
When you spot anomalies in latency and engagement, don’t guess—verify. Use a system that checks the actual path of your emails, not just the headers. That’s what MailTester gives you: visibility into real-world delivery. With that, you can distinguish throttling from technical delay—and fix it faster.
Actionable steps when latency percentiles show ISP throttling
If latency percentiles climb over time—especially during peak sending hours—you’re likely hitting throttling or filtering thresholds imposed by ISPs. Reduce sending volume per hour, gradually warm up new sender identities, and isolate high-latency ISP groups using dedicated IPs to avoid triggering rate-limiting policies. This proactive approach keeps your deliverability in check.
Reduce volume to avoid triggering throttling
- Lower your sending volume per hour to stay below known ISP threshold limits. Many ISPs begin throttling or delaying messages when inbound traffic exceeds 1,000 messages per minute from a single IP, which is common in bulk campaigns.
- Monitor latency trends post-send to confirm if reduced volume correlates with lower latency percentiles. A consistent drop in P95 or P99 latency suggests the threshold was the issue.
- Use tools that provide granular, real-time delivery data to spot abnormal delays. MXToolbox and RFC 5321 (SMTP specifications) provide foundational standards for understanding mail flow behavior across networks.
Warm up IPs and domains across ISPs
- Start with low-volume sends to new IPs or domains—begin at 50–100 messages per day—and increase gradually over 7–14 days. This helps ISPs recognize your sending behavior as legitimate.
- Track latency percentiles during warm-up. Sudden spikes in P95 latency during this period may indicate early signs of filtering or reputation-based throttling by certain ISPs.
- If you're hitting delays from a specific ISP cluster (e.g., mobile carriers or enterprise providers), use separate IPs for those groups to isolate performance issues and avoid collateral damage to other delivery paths.
Use verified, clean lists to prevent triggering defenses in the first place. A single invalid address can trigger suspicion. Bulk verify your list before sending to reduce invalid addresses that might trigger ISP filters.
Why real-time verification helps prevent ISP throttling
Using real-time email verification with MailTester ensures your sends only go to valid, receptive inboxes, cutting down on bounces and improving sender reputation. ISPs monitor bounce rates and engagement closely—high bounce rates signal poor list hygiene, which can trigger throttling or filtering. By verifying addresses before delivery, you reduce the risk of being flagged as a spam source.
Preventing throttling through cleaner sender reputation
Every bounce, especially hard bounces, harms your sender reputation. ISPs like Gmail and Outlook track these signals over time and use them to adjust delivery priority. A clean list means fewer bounces—directly lowering your risk of throttling. MailTester’s 98.9% accuracy helps you catch invalid, risky, or disposable addresses before they damage your metrics.
Let’s say you send to 10,000 addresses. Without verification, 5–15% might be invalid or inactive. That’s 500–1,500 bounces—enough to trigger spam filters. With MailTester, you eliminate those dead ends. Real-time verification flags catch-alls, role accounts, and disposable domains that don’t accept mail, saving you from wasted delivery attempts.
Deliverability starts with list hygiene
Throttling isn’t just about volume—it’s about perceived engagement. If an ISP sees consistent bounce rates or low inbox placement, it may slow down your messages. But if your list is valid and recipients open emails, your reputation stays strong. According to RFC 6655, proper sender reputation management includes maintaining low bounce rates and active subscriber engagement.
MailTester’s API lets you validate addresses in real time as users sign up. The bulk verification tool checks entire lists quickly, filtering out risky addresses. You can also test inbox placement with the inbox tester tool to see how your messages arrive across major ISPs. This gives you confidence your messages reach inboxes—not just servers.
With verified lists, you’re not just improving deliverability—you’re reducing the signals that lead ISPs to throttle. You’re not guessing. You’re acting. A cleaner list means fewer flagged messages, fewer blocked senders, and fewer surprises in the delivery pipeline.
For best results, combine real-time verification with ongoing list maintenance. Use the verification API during onboarding, bulk verification before campaigns, and inbox placement testing to confirm your message lands where it should. These steps are part of a larger strategy rooted in measurable list health.
Conclusion: Latency percentiles are your early warning system
ISP throttling and filtering operate silently—standard metrics like delivery rate or bounce count won’t catch them. But latency percentiles over time reveal the subtle delays that signal intentional interference.
Tracking p90 and p99 latency trends exposes gradual degradation in message delivery speed before it impacts open rates or inbox placement. These shifts are early signs of filtering, allowing you to investigate and act before engagement drops.
Use MailTester’s inbox placement and real-time verification tools to measure delivery health and validate fixes. Proactive checks prevent problems before they reach your audience.
Sources
- Roughly one in six legitimate commercial emails (16.5%) never reaches the inbox globally — 6.7% is filtered to spam and 9.8% disappears without a bounce. — Validity 2025 Email Deliverability Benchmark Report (2025)
- Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)
Keep reading
- Bounce codes and SMTP errors explained (complete guide)
- 421 Service Not Available: Closing Transmission Channel Explained
- Email Verification System That Detects High-Risk Unicode Characters
- How to Fix From Header Invalid Syntax Missing Space After Colon in SMTP
- Email Verification Service Shows 550 5.7.1 for Unverified Domain Sending
Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.
Frequently asked questions
What is ISP throttling and how does it affect email delivery?
ISP throttling delays message delivery without bouncing it. It can reduce inbox placement and hurt engagement, especially for high-volume senders.
How do latency percentiles detect throttling?
A rising p99 latency over time indicates that the slowest 1% of deliveries are getting progressively slower — a hallmark of ISP throttling.
Can email deliverability tools detect ISP throttling?
Yes — if they record delivery time and allow historical analysis. MailTester’s inbox placement tests track both delivery success and time, enabling this detection.
How often should I check latency percentiles?
Daily monitoring during high-volume sends is recommended. Weekly checks are acceptable for low-velocity campaigns.
What’s the difference between throttling and filtering?
Filtering blocks delivery entirely; throttling delays it. Throttling often shows up as high p99 latency with no bounces.
Does MailTester offer real-time latency tracking?
Yes — MailTester’s inbox placement tests include delivery time tracking at the SMTP level, which you can analyze over time.
What’s the minimum data needed to detect throttling?
At least 7 days of delivery time data per ISP, with consistent sending volume, to establish a baseline and spot trends.
How does list hygiene help prevent throttling?
Clean lists reduce bounces and spam complaints, which improves sender reputation and reduces the risk of throttle triggers.
Can I automate latency percentile tracking with MailTester?
Yes — use the real-time verification API and inbox placement test logs to extract delivery time data and build automated alerts.
Is rising latency always due to ISP throttling?
No — network issues or high server load can cause delays too. But consistent p99 growth across multiple days with low bounces points to throttling.
Are there tools that measure latency percentiles for email?
Most email platforms don’t expose delivery times. MailTester and similar deliverability testing tools are among the few that provide actionable latency data.
How accurate is MailTester’s verification process?
MailTester has 98.9% accuracy in verifying email addresses, helping you eliminate invalid and risky addresses before sending.