Rate Limiting, Deliverability, and Your Email API

Why Rate Limiting Matters More Than You Think

You've built something great. Your product sends emails—transactional confirmations, lifecycle sequences, drip campaigns. Everything works in testing. Then you scale. Suddenly emails queue up. Some never arrive. Others land in spam. Your sender reputation tanks. ISPs throttle your IP. You're locked out.

This isn't a failure of your email provider. It's a failure to respect the rules that keep the email ecosystem functioning.

Rate limiting isn't a limitation. It's a contract between you and the internet's mail servers. Break it, and you lose deliverability. Respect it, and your emails land where they belong: the inbox.

When you send email at scale through an API—whether it's Mailable's headless email platform or any other provider—you're operating within constraints set by Internet Service Providers (ISPs), authentication systems, and reputation networks. Understanding those constraints isn't optional. It's the difference between emails that arrive and emails that disappear.

This guide walks you through the mechanics of rate limiting, how it connects to deliverability, and how to design client code that respects both without sacrificing speed.

Understanding Rate Limits: The Basics

A rate limit is a cap on how many emails you can send in a given time window. Simple concept. Critical execution.

Most email providers—including Mailable—enforce rate limits at multiple levels:

Per-second limits: How many emails your account can send in a single second. Typical range: 10–100 emails/second depending on your plan and sender reputation.

Per-minute limits: Total emails in a 60-second window. Usually 10x your per-second limit.

Per-hour and per-day limits: Cumulative caps that prevent you from blasting your entire subscriber list in one go, even if you stay within per-second limits.

Per-recipient limits: Some providers throttle how many emails can go to the same domain (Gmail, Outlook, Yahoo) in a time window. This prevents your IP from looking like it's hammering a single provider's servers.

Why these constraints exist:

• ISP protection: Mail servers need to reject spam without rejecting legitimate mail. A sudden flood from an unknown sender looks like an attack.
• Reputation preservation: Your sending IP has a reputation score. Sending too fast, too much, or to too many invalid addresses damages it. Once damaged, recovery takes weeks.
• Compliance: SPF, DKIM, and DMARC authentication systems have their own rate-related behaviors. Sending faster than your infrastructure can authenticate looks suspicious.
• Resource management: Email servers are shared resources. One sender can't monopolize them.

Break rate limits, and you trigger throttling: ISPs slow your delivery, queue your mail, or reject it outright. Your bounce rates spike. Complaint rates rise. Your sender IP gets blocklisted. You're now fighting to recover reputation instead of shipping emails.

How Deliverability and Rate Limiting Connect

Deliverability—the percentage of emails that reach the inbox instead of spam or bounce—depends on sender reputation. Rate limiting directly impacts reputation.

ISPs use several signals to judge a sender:

Bounce rates: If you send to invalid addresses, bounces climb. High bounce rates signal poor list quality, which tanks reputation. Rate limiting forces you to validate addresses before sending and pace your sends so bounces don't spike.

Complaint rates: When recipients mark your email as spam, that complaint goes back to the ISP. If your complaint rate exceeds ~0.1%, ISPs throttle or block you. Sending too fast to unengaged subscribers increases complaints. Rate limiting prevents you from carpet-bombing inactive users.

Authentication alignment: SPF, DKIM, and DMARC require your sending infrastructure to prove ownership of the domain. If you send faster than your authentication system can handle, some emails fail authentication. Failed authentication = spam folder. Rate limiting gives authentication systems time to work.

IP warming: New sending IPs have no reputation. You can't send 100,000 emails from a new IP on day one. ISPs will reject most of them. You need to gradually increase volume—a process called IP warming. This is enforced rate limiting by reputation, not by the provider.

According to 2026 email deliverability trends and observations, ISPs are increasingly aggressive about filtering based on sender behavior patterns. Sudden spikes in volume, irregular sending patterns, and high bounce rates are immediate red flags. Rate limiting—when respected—prevents these patterns from forming.

Email deliverability best practices for high open rates consistently emphasize pacing and volume control as foundational. You can't outrun bad sending practices with a better subject line.

The Technical Side: How Providers Enforce Rate Limits

When you integrate with an email API—whether through Mailable's API, MCP, or headless interface—the provider enforces rate limits at the request level.

Typical enforcement:

HTTP 429 responses: When you exceed your rate limit, the API returns a 429 (Too Many Requests) status code. This is your signal to back off.

Retry-After headers: The 429 response includes a Retry-After header telling you how long to wait before retrying. Respect this. Don't retry immediately.

Queue-based systems: Some providers queue excess requests and process them as capacity opens up. Others reject them outright. Know which your provider does.

Distributed limits: If you're sending through multiple API keys or accounts, the provider may track limits across all of them to prevent workarounds.

Here's what a 429 response looks like:

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1640000000

{
  "error": "rate_limit_exceeded",
  "message": "You have exceeded your per-second limit of 100 requests."
}

The headers tell you:

• X-RateLimit-Limit: Your per-second cap (100 emails/second in this case)
• X-RateLimit-Remaining: How many requests you have left in the current window (0 means you're maxed out)
• X-RateLimit-Reset: Unix timestamp when your limit resets

Ignoring this and hammering the API with retries doesn't send more emails. It wastes bandwidth, increases latency, and can get your API key throttled further or revoked.

Designing Client Code That Respects Rate Limits

Your code needs to be rate-limit aware. This means implementing backoff, queueing, and monitoring.

Exponential Backoff

When you hit a 429, don't retry immediately. Implement exponential backoff: wait a bit, then retry. If it fails again, wait longer. Keep doubling the wait until you succeed or give up.

Pseudocode:

function sendEmailWithBackoff(email, maxRetries = 5) {
  let retries = 0;
  let delay = 1000; // Start with 1 second

  while (retries < maxRetries) {
    try {
      const response = await mailableAPI.send(email);
      return response; // Success
    } catch (error) {
      if (error.status === 429) {
        retries++;
        const waitTime = delay * Math.pow(2, retries - 1); // Exponential backoff
        console.log(`Rate limited. Waiting ${waitTime}ms before retry...`);
        await sleep(waitTime);
      } else {
        throw error; // Non-rate-limit error, fail immediately
      }
    }
  }

  throw new Error(`Failed to send email after ${maxRetries} retries`);
}

This prevents thundering herd: if multiple requests hit the rate limit simultaneously, exponential backoff spreads them out instead of having them all retry at once.

Request Queuing

Don't send emails synchronously. Queue them. Process the queue at a pace that respects your rate limit.

If your limit is 50 emails/second, send 50, wait 1 second, send 50 more. This is simple to implement and prevents bursts.

class EmailQueue {
  constructor(emailsPerSecond) {
    this.queue = [];
    this.processing = false;
    this.emailsPerSecond = emailsPerSecond;
  }

  add(email) {
    this.queue.push(email);
    this.process();
  }

  async process() {
    if (this.processing) return;
    this.processing = true;

    while (this.queue.length > 0) {
      const batch = this.queue.splice(0, this.emailsPerSecond);
      const promises = batch.map(email => mailableAPI.send(email));

      try {
        await Promise.all(promises);
      } catch (error) {
        // Handle errors, potentially re-queue failed emails
        console.error('Batch send failed:', error);
      }

      // Wait 1 second before next batch
      await sleep(1000);
    }

    this.processing = false;
  }
}

This queue processes emails in batches, respecting your per-second limit without complex logic.

Monitoring and Alerting

Track your rate limit usage. Monitor how close you are to limits. Alert when you're approaching them.

function checkRateLimitHealth(headers) {
  const remaining = parseInt(headers['x-ratelimit-remaining']);
  const limit = parseInt(headers['x-ratelimit-limit']);
  const percentUsed = ((limit - remaining) / limit) * 100;

  if (percentUsed > 90) {
    console.warn(`Rate limit at ${percentUsed.toFixed(1)}%. Consider slowing sends.`);
  }

  if (percentUsed === 100) {
    console.error('Rate limit exhausted. Backing off.');
  }
}

This gives you visibility into your sending patterns and lets you adjust before hitting hard limits.

IP Warming: The Long Game

If you're sending from a new IP or domain, ISPs don't trust you yet. You need to gradually build reputation through IP warming.

IP warming is enforced rate limiting by reputation:

Days 1–3: Send to your most engaged subscribers only. Small volume (100–1,000 emails/day).

Days 4–7: Expand to moderately engaged users. Increase volume slightly (1,000–5,000/day).

Days 8–14: Include less-engaged users. Ramp volume further (5,000–50,000/day).

Weeks 3–4: Full volume sends to your entire list.

The exact ramp depends on your list size and ISP policies, but the principle is consistent: prove you're a legitimate sender by starting small and growing gradually.

Skip IP warming, and ISPs will reject a large percentage of your mail, tanking your reputation before you've even started. You'll spend weeks recovering.

Email rate limiting solutions and authentication changes for 2026 emphasize that gradual scaling is non-negotiable. ISPs are more aggressive about filtering than ever, and sudden volume spikes are immediate rejection triggers.

Handling 429 Responses Gracefully

When you get a 429, your code needs to handle it without losing emails or degrading user experience.

For transactional emails (order confirmations, password resets, etc.): These must arrive reliably. Queue them and retry with exponential backoff. Don't drop them. If your queue gets too large, scale up your sending infrastructure or upgrade your rate limit.

For marketing emails (campaigns, drips): These can tolerate slight delays. Queue them and process at a steady pace. If a batch fails, retry it. If it keeps failing, log it and investigate.

For lifecycle emails (onboarding sequences, re-engagement): These are time-sensitive but not critical. Queue them, respect rate limits, and let them send gradually. If a user's email arrives 5 minutes late, that's fine.

The key principle: never drop an email to avoid rate limiting. Always queue and retry. Rate limits are about pacing, not rejecting.

Sender Reputation Scoring

Behind every rate limit is a reputation system. Understanding reputation helps you understand why limits exist.

ISPs score senders on:

Bounce rate: Percentage of emails that bounce. Target: <5%. Above 10% and you're in trouble.

Complaint rate: Percentage of recipients who mark you as spam. Target: <0.1%. Above 0.3% and ISPs throttle you.

Engagement rate: Percentage of recipients who open or click. Low engagement signals poor list quality or irrelevant content. ISPs use this to filter.

Authentication: SPF, DKIM, DMARC pass rates. 100% is the goal. Below 95% and you're vulnerable to filtering.

List hygiene: How many invalid addresses you send to. Clean lists = good reputation.

Sending patterns: Consistency matters. Erratic volume, sudden spikes, or unusual timing patterns raise red flags.

Rate limiting forces you to maintain these metrics. If you send too fast, bounces spike. If you send to unengaged users, complaints rise. If you don't warm IPs, authentication fails. Rate limits are guardrails.

According to 2026 email deliverability statistics and critical data for GTM teams, senders who respect rate limits and maintain list hygiene achieve 95%+ inbox placement rates. Those who don't average 60–70%.

Authentication Systems and Rate Limits

SPF, DKIM, and DMARC authentication systems have their own rate-related behaviors.

SPF (Sender Policy Framework): Your SPF record lists which servers can send mail from your domain. When you send an email, the receiving server checks your SPF record. If you're sending from too many different servers or IPs too quickly, some checks fail. Rate limiting prevents this.

DKIM (DomainKeys Identified Mail): Each email gets digitally signed with your domain's private key. If you send too many emails too fast, signature verification can lag, and some emails fail authentication. Pacing prevents this.

DMARC (Domain-based Message Authentication, Reporting, and Conformance): DMARC combines SPF and DKIM and tells ISPs what to do if authentication fails (quarantine, reject, or monitor). If your authentication rate is low due to sending too fast, DMARC policies can cause ISPs to reject your mail.

Rate limiting gives your authentication infrastructure time to keep up. You're not just respecting ISP limits; you're respecting your own infrastructure's capacity.

Choosing the Right Rate Limit for Your Use Case

Different sending patterns need different limits.

Transactional emails (confirmations, notifications): These are event-driven and unpredictable. You need a high per-second limit (50–100+) but a reasonable per-day limit. If you hit your per-second limit, queue and retry. Transactional emails are critical, so invest in higher limits.

Drip campaigns and sequences: These are scheduled and predictable. You can use lower per-second limits (10–20) but need high per-day limits. Spread sends throughout the day to avoid spikes.

Bulk campaigns: These are one-time sends to large lists. You need high per-day limits but can use moderate per-second limits (20–50). Warm up the send over several hours.

Lifecycle emails (onboarding, re-engagement): These are predictable but volume can spike when events occur. Use moderate limits (20–50 per-second) and queue excess sends.

Most email providers, including Mailable, let you choose or upgrade your rate limits based on your plan. Start with a conservative limit, monitor your sending patterns, and upgrade as you scale.

Real-World Example: A Scaling Scenario

You're running a SaaS product. Your signup flow sends a welcome email. You're getting 100 signups/hour. At 100 signups/hour, you're well within typical rate limits (which allow 50–100 emails/second).

Then you get featured in a newsletter. Signups spike to 1,000/hour. Your welcome email queue can't keep up. If you naively send all 1,000 emails as fast as possible, you'll hit rate limits and trigger backoff.

With proper queueing:

1. Signups come in and get queued.
2. Your email queue processes 50 emails/second (your limit).
3. 1,000 emails take ~20 seconds to send.
4. No rate limit errors. No dropped emails. No reputation damage.

Without queueing:

1. Signups come in and trigger immediate sends.
2. Your code fires 1,000 send requests in 2 seconds.
3. You hit the rate limit. 429 errors flood in.
4. Your code retries aggressively. More 429s.
5. Some emails get dropped. Some get delayed by hours.
6. Your reputation takes a hit.

The difference is one function: a queue that respects your rate limit.

Monitoring Tools and Best Practices

Use tools to monitor your sending health. Most email providers, including Mailable, offer dashboards showing:

• Sends per hour/day: Track volume trends.
• Bounce rate: Monitor list quality.
• Complaint rate: Watch for engagement issues.
• Delivery rate: See what percentage of emails arrive.
• Rate limit usage: See how close you are to limits.

Set up alerts for:

• Bounce rate exceeding 5%
• Complaint rate exceeding 0.1%
• Rate limit usage exceeding 80%
• Delivery rate dropping below 95%

Review logs regularly. If you see patterns of 429 errors, your queue isn't processing fast enough or your limit is too low. Adjust your code or upgrade your plan.

Best email deliverability tools for 2026 include built-in monitoring and alerting. Use them. Don't fly blind.

Integration Patterns: API, MCP, and Headless

If you're building with Mailable's API, MCP, or headless email platform, rate limiting works the same way: respect the limits, queue requests, handle 429s gracefully.

API integration: Direct HTTP calls to send emails. Rate limits apply per API key. Queue requests in your application. Handle 429s with exponential backoff.

MCP (Model Context Protocol) integration: If you're using Mailable through an MCP server, the server handles rate limiting internally. Your code still needs to be queue-aware, but the MCP layer abstracts some complexity.

Headless integration: If you're using Mailable to generate templates and sending through your own infrastructure, you inherit the email provider's rate limits (Postmark, Resend, etc.). Respect those limits in your sending code.

In all cases, the principle is the same: understand your limit, queue requests, monitor usage, and handle errors gracefully.

Common Mistakes to Avoid

Mistake 1: Ignoring 429 responses. Retrying immediately doesn't help. It makes things worse. Implement backoff.

Mistake 2: Sending without a queue. Every send request should go through a queue that respects rate limits. Synchronous sending at scale guarantees rate limit errors.

Mistake 3: Blasting unengaged subscribers. High complaint rates tank reputation. Segment your lists. Send only to engaged users. Gradually re-engage inactive users.

Mistake 4: Skipping IP warming. New IPs have no reputation. Warm them up gradually. Skipping this step means 50%+ of your mail gets rejected for weeks.

Mistake 5: Not monitoring. You can't fix what you don't measure. Set up dashboards and alerts. Review them weekly.

Mistake 6: Upgrading without understanding. If you hit rate limits, don't just upgrade your plan. First, understand why. Are you sending too fast? Is your list quality poor? Fix the root cause, then upgrade if needed.

Best Practices for Production Email

Here's what production email systems do right:

Separate queues for different email types. Transactional emails get priority. Marketing emails get lower priority. This ensures critical emails arrive even if marketing campaigns are in progress.

Exponential backoff with jitter. When multiple requests hit rate limits simultaneously, jitter (randomness) prevents them from retrying at the same time, which would cause another spike.

Per-domain rate limiting. Track sends to each domain (Gmail, Outlook, Yahoo) separately. Don't hammer one domain even if you're within your overall limit.

List segmentation. Segment by engagement, domain, geography, or other factors. Send to engaged users first. Gradually include less-engaged users. This maintains reputation.

Regular list cleaning. Remove invalid addresses, hard bounces, and unengaged subscribers monthly. A clean list = high reputation.

Authentication setup. Ensure SPF, DKIM, and DMARC are configured correctly. Monitor authentication rates. Aim for 100%.

Scheduled sends. For bulk campaigns, spread sends throughout the day. Don't send your entire list at once.

Monitoring and alerting. Track metrics hourly. Alert on anomalies. Investigate immediately.

According to email deliverability basics and benchmarks for 2026, these practices are table-stakes. Senders who implement them achieve 95%+ inbox placement. Those who don't average 60%.

The Business Impact of Respecting Rate Limits

Rate limiting isn't a technical detail. It's a business lever.

When you respect rate limits:

• Emails arrive in inboxes, not spam folders. Higher open rates, higher click rates, higher conversions.
• Reputation stays clean. You can send more emails over time without worrying about blocklists.
• Scaling is predictable. You know exactly how many emails you can send per day. You can plan campaigns around that capacity.
• Costs stay reasonable. You're not paying for emails that bounce or get rejected.
• Customer experience improves. Emails arrive when expected. Users trust your notifications.

When you ignore rate limits:

• Emails bounce or get rejected. Customers don't receive critical messages. They churn.
• Reputation tanks. Recovery takes weeks. You're blocked from sending to major ISPs.
• Scaling is chaotic. You hit limits unexpectedly. Campaigns fail. You scramble to fix code.
• Costs explode. You're paying for bounces, rejected emails, and failed sends.
• Customer experience suffers. Emails arrive late or not at all. Users lose trust.

Respecting rate limits isn't a constraint. It's the foundation of reliable email delivery.

Conclusion: Rate Limiting as a Feature

Rate limiting often feels like a limitation. It's not. It's a feature that keeps your emails deliverable and your reputation clean.

When you design client code that respects rate limits—through queuing, backoff, and monitoring—you're not fighting the email system. You're working with it. Your emails arrive faster, more reliably, and at lower cost.

If you're building transactional email, lifecycle sequences, or drip campaigns, Mailable's API and headless platform give you the tools to generate production-ready templates and send them at scale. But the code you write to send those emails needs to be rate-limit aware.

Start with a queue. Implement exponential backoff. Monitor your limits. Warm up new IPs gradually. Segment your lists. Clean your data. And respect the rate limits your provider sets.

Do that, and your emails will land in inboxes. Your reputation will stay clean. Your business will grow. That's the power of respecting rate limits.