Last Tuesday, a user pinged support at 4:47pm asking why their confirmation email hadn't arrived. We checked the logs. Sent at 2:12pm. Still queued at 4:47pm — over two hours in limbo with a 421 4.7.28 from Gmail. No bounce. No error visible to the sender. Just... stuck. Gmail deciding whether to trust us.

(I'll be honest: we should've caught this faster. We didn't.)

This is the most frustrating kind of email problem. Nothing's broken in the obvious way. Your SPF passes. DKIM is aligned. DMARC is at p=reject. And yet: emails arrive 20 minutes late, or two hours late, or sometimes they just don't arrive during the workday at all and show up at 11pm when nobody's watching.

The culprit is almost always a 4xx deferral — a temporary "not right now" from the receiving server. Here's how to figure out what's causing yours and how to make it stop. (And if you're managing email across multiple domains for clients, this compounds fast.)

What 4xx Deferrals Actually Mean

When your mail server connects to Gmail, Outlook, or any other provider, it gets an SMTP response code after each command. Codes starting with 2xx mean success. Codes starting with 5xx mean permanent failure — the message is rejected and won't be retried. Codes starting with 4xx mean temporary failure — the server is refusing the message right now, but your server should try again later.

The critical distinction: 4xx isn't a bounce. It's a delay.

Your outbound mail server (Postfix, Sendmail, whatever) queues the message and retries according to its schedule. Default Postfix behavior: retry every 5 minutes for the first 30 minutes, then every 15 minutes, then every 30 minutes, up to a max queue lifetime of 5 days. Five days! That means a stubborn 4xx can keep a message in limbo for nearly a week before it either delivers or converts to a bounce. Maddening, honestly.

The Three Flavors of 4xx

Not all deferrals are created equal. In practice, you'll see three patterns.

Greylisting is the friendliest. It's a spam-fighting technique where the receiving server rejects the first delivery attempt from any new sender-recipient-IP tuple, expecting legitimate servers to retry. Spammers often don't bother retrying. The message usually clears on the second attempt, 5-15 minutes later.

You'll see responses like:

450 4.7.1 <recipient@example.com>: Recipient address rejected: Greylisted, try again in 300 seconds

Or sometimes just:

451 Temporary service unavailable, try again later

Greylisting adds a few minutes of delay on first contact. Annoying, but not dangerous. Once your IP has delivered to that recipient successfully, subsequent messages skip the greylist.

Reputation throttling is what Gmail and Microsoft do when they don't trust you — yet. They accept some messages, defer others, and make you prove yourself over time. This is volume-sensitive: send 500 emails in an hour from a new domain and you'll hit it. Send 50 a day for a month first, and you probably won't.

(We learned this one the hard way during our own beta launch. Embarrassing.)

Typical responses:

421 4.7.28 Our system has detected an unusual rate of unsolicited mail originating from your IP address.

Or from Microsoft:

421 4.7.500 Server busy. Please try again later.

The message sounds scary, but it's not a permanent block. Your server retries, eventually the provider lets some through, and if your engagement is good (people open and reply, nobody marks you as spam), the throttling relaxes over days or weeks.

Transient backpressure is the receiving server genuinely being overloaded. This happens during outages, maintenance windows, or when a provider is having a bad day. Nothing to do with your reputation. The server is just saying "I can't handle this right now."

Responses look like:

421 Service temporarily unavailable
451 Resources temporarily unavailable. Please try again later.

These clear on their own once the provider recovers. If you're seeing them across multiple unrelated providers simultaneously, check your own sending infrastructure — you might be the bottleneck.

How to Read Your Deferral Logs

The first step is finding the actual SMTP response. Where this lives depends on your setup.

If you're using JustEmails, check the message log in the dashboard — we surface the last SMTP response for queued and deferred messages. For Postfix, look in /var/log/mail.log for lines containing status=deferred and the response that follows.

What you're looking for:

The response code (421, 450, 451, 452)
The enhanced status code (4.7.1, 4.7.28, 4.7.500)
The human-readable message (this tells you whether it's greylisting, throttling, or something else)

Pattern recognition example. If you see 4.7.1 with "greylisted" or "try again" language, that's greylisting. If you see 4.7.28 from Gmail or references to "unusual rate" or "reputation," that's throttling. If you see 4.4.1 or 4.4.2 with "connection" or "timeout" language, that's network or backpressure.

Quick Fixes for Each Type

For greylisting: Nothing to do on your end except wait. Your mail server will retry and the message will clear. If you're sending time-sensitive transactional mail and greylisting is adding unacceptable delay, consider a sending IP with established reputation (either your own warmed IP or a reputable ESP that pre-warms their infrastructure). Greylisting is less aggressive toward IPs with history.

For reputation throttling: This is where warmup matters. If you're a new sender — new domain, new IP, or just increased volume significantly — you need to ramp slowly.

A reasonable warmup schedule:

Week 1: 50 emails/day
Week 2: 100 emails/day
Week 3: 250 emails/day
Week 4: 500 emails/day
Week 5+: Increase by 25-50% per week until target volume

Critically, warmup only works if your mail is wanted. Sending to bought lists or cold outreach during warmup will tank your reputation faster than sending nothing. Bought lists are poison — I don't care what the list broker promised you. Focus warmup volume on transactional mail (receipts, confirmations, password resets) and engaged subscribers who opted in recently. If you're running outbound campaigns, tools like VeloCalls can complement email with voice — but that's a different deliverability conversation.

For Gmail specifically, Google Postmaster Tools shows your domain and IP reputation. If you're seeing "Low" or "Bad" there, expect aggressive deferrals until you improve it. The path out: consistent volume, high engagement, low spam complaints (under 0.1%), perfect authentication.

For transient backpressure: Wait it out. If it's provider-wide, there's nothing you can do except retry. If it's persistent (hours or days), check provider status pages — Gmail's dashboard, Microsoft's service health, etc. Sometimes they're having issues and haven't announced it yet.

When Volume Spikes Cause the Problem

Here's a pattern we see constantly. Someone sends 200 emails a day for months. Steady. No problems. Then they launch a promotion and try to send 5,000 in an afternoon.

Half defer. Three hours later, support tickets.

The fix is to smooth your sending. Instead of blasting 5,000 emails in 10 minutes, spread them over 4-6 hours. Most transactional email APIs let you set sending rate limits. If you're sending through raw SMTP, implement throttling in your application — a simple sleep between batches goes a long way.

For JustEmails users, the transactional API handles rate limiting per-destination — we slow down automatically when we see 4xx responses from a specific provider. But if you're sending via SMTP directly, you're responsible for pacing.

Strong opinion: if your business depends on time-sensitive email (password resets, two-factor codes, transaction confirmations), you should be sending from a warmed, dedicated IP with established reputation at all major providers. Shared IPs are fine for newsletters. They're a liability for transactional mail because someone else's spam complaint affects your deliverability. The Velocity Digital Labs team learned this building infrastructure for all our products.

Monitoring That Actually Helps

Don't wait for users to tell you their emails are late. Build visibility into your sending.

At minimum, track:

Queue depth over time. If deferred messages are accumulating faster than they're clearing, something's wrong.
Deferral rate by destination domain. Gmail deferrals spiking while Outlook is fine? That's Gmail-specific throttling.
Time-to-delivery for transactional messages. Set an alert if p95 latency exceeds 5 minutes.

Google Postmaster Tools is free and shows reputation trends for any domain sending meaningful volume to Gmail. If you're not checking it monthly, start. We've built a similar integration into JustAnalytics for folks who want deliverability metrics alongside their web analytics — same dashboard, one less tab.

The Velocity Digital Labs infrastructure runs the same monitoring across all our products. When we see Gmail deferrals tick up, we know before any user complains. That 2:12pm message I mentioned at the top? We caught it in logs at 2:47pm and had already started investigating before the user reached out.

The Authentication Prerequisite

One more thing. If your SPF, DKIM, or DMARC isn't correctly configured, none of the above fixes will help. Authentication failures cause deferrals too — and they're often misdiagnosed as reputation problems.

Before you assume it's throttling, verify:

SPF record exists and includes all your sending sources
DKIM is signing messages with a key that validates (send yourself a test and check headers)
DMARC is published and not failing alignment

We've got a guide on setting up custom domain email from scratch if you need the basics. For the DMARC ramp specifically — moving from p=none to p=reject without breaking your own mail — our DMARC guide covers the multi-week process.

Deferrals are frustrating because they're invisible to senders and recipients alike. The message isn't bouncing. It isn't in spam. It's just... not there yet.

But here's the thing: with the right logs, the right monitoring, and a warmup strategy that matches your volume, you can turn "emails arrive eventually, I guess" into "emails arrive in under 30 seconds, every time."

That's the baseline. That's what you should expect. Anything less is a bug you can actually fix. For those building SaaS products that send email, tracking these metrics in DevOS keeps deliverability visible alongside your other ops dashboards.

Frequently Asked Questions

What's the difference between a 4xx deferral and a 5xx bounce?

A 5xx bounce is permanent rejection — the receiving server won't accept that message, period. A 4xx deferral is temporary: the server is saying "try again later." Your mail server queues the message and retries on a schedule (typically every 15-30 minutes for the first few hours, then less frequently). Most 4xx deferrals resolve within 1-4 hours. If retries exhaust the queue timeout (usually 24-72 hours), the message converts to a permanent failure and bounces back to the sender.

How do I know if I'm being greylisted vs rate-limited?

Greylisting typically shows a 4xx with language like "try again later" or "temporarily deferred" on the first delivery attempt for a new sender/recipient/IP combination, and clears on the second or third attempt within 5-15 minutes. Rate limiting shows codes like 421 with messages referencing "too many connections" or "sending rate exceeded," and affects all messages to that provider once you hit the threshold. Greylisting is per-tuple and resolves quickly; rate limiting is volume-based and requires you to slow down or wait out a cooldown window.

Why do emails to Gmail arrive hours late but other providers are instant?

Gmail is aggressive about throttling senders with low reputation or inconsistent volume patterns. If your domain is new, your IP has limited history, or you spiked volume suddenly, Gmail may defer most of your messages and drip them through slowly. Check Google Postmaster Tools for your domain reputation — if it shows "Low" or "Bad," Gmail is intentionally slowing your mail. Other providers may have higher thresholds or less aggressive deferral policies, so the same sending pattern produces different outcomes across mailbox providers.

Can warming up a domain actually fix deferral problems?

Yes, if the root cause is reputation or volume-related throttling. Warmup means starting with low daily volume (50-100 emails) and increasing gradually over 4-8 weeks while maintaining high engagement (opens, replies, low spam complaints). This builds sending reputation with major providers. But warmup won't fix greylisting (which is per-server policy), authentication failures (SPF/DKIM/DMARC issues), or content-based filtering. Diagnose the specific 4xx codes first — warmup is the fix for reputation throttling, not a universal solution.

Try JustEmails

Unlimited custom domain email hosting for $49/year flat — unlimited domains, unlimited mailboxes, 10 GB storage, full IMAP/SMTP. Built for agencies, freelancers, and anyone managing email across more than one domain.

Start your 7-day free trial → · How it compares

Fix Email Delays: 4xx Deferrals and Greylisting Guide