How to resolve SMTP 421 errors with Web.de and GMX.net due to rate limiting?
Matthew Whittaker
Co-founder & CTO, Suped
Published 4 Aug 2025
Updated 22 May 2026
9 min read
Summarize with
To resolve SMTP 421 errors from Web.de and GMX.net, I stop or drain the affected queue, slow both new sends and retries, verify the sender's authentication and reverse DNS, check whether the shared sending IP is the real problem, then restart volume with a dedicated Web.de and GMX.net throttle. If the mail is on a shared ESP pool, the fastest fix is often to have the ESP rotate the throttled IPs or move German mailbox provider traffic to an IP with clean history and correct PTR.
The important part is that Web.de and GMX.net do not see a clean distinction between your first delivery attempt and your retry. Every connection attempt adds pressure. A sender can reduce new mail to five messages per minute and still keep tripping the limit if the MTA keeps retrying old deferred messages aggressively. That is why the fix has to cover queue behavior, connection behavior, and sender identity at the same time.
What the 421 error means
A Web.de or GMX.net 421 response is a temporary deferral, not a final bounce. The receiving system is saying it will not accept the message now. When the text mentions too many messages in a short period of time, the practical reading is simple: send less, connect less, and stop feeding the same destination with rapid retries.
Typical Web.de or GMX.net temporary failuretext
421 web.de (mxweb113) Nemesis ESMTP Service not available Service unavailable Reject due to policy restrictions Please try again later. Too many messages have been received in a short period of time. Please try again in a few hours and reduce the sending rate.
I treat this as both a rate problem and a trust problem. If the recipient provider accepts some mail but defers the rest, that still points to throttling. It also means the provider has not built enough confidence in the sending IP, the domain, or the technical shape of the message stream.
Do not let retries become the traffic
A deferred message that retries every few minutes can turn a small campaign into a constant stream of connection attempts. Web.de and GMX.net can count those attempts against the same receiving limits.
- Queue: Pause new Web.de and GMX.net traffic before old deferred mail expires.
- Retry: Use longer backoff windows for these two domains than for normal destinations.
- Connections: Limit concurrent sessions to the MX group, not only message rate.
For senders seeing the same pattern on other mailbox providers, the broader mechanics are similar. The guide on sending rate limits explains the connection and retry side in more general terms.
Triage before changing volume
Before I reduce volume again, I check whether the limit is attached to the domain, the IP, the message stream, or the MTA behavior. In small new markets, global reputation can look fine while local reputation at German mailbox providers has not been earned yet. That is normal, but it changes how slowly I restart.
|
|
|
|---|---|---|
Some accepted | Throttle | Slow queue |
All deferred | Policy | Check identity |
Shared IP | Pool risk | Ask ESP |
Old queue | Retry storm | Backoff |
Bad PTR | Identity | Fix rDNS |
Compact triage matrix for Web.de and GMX.net 421 errors.
Public sender reports show similar Web.de and GMX.net symptoms in Postfix logs. This ServerFault thread is useful because it shows that these deferrals can appear even when the sender thinks the volume is modest.
Flowchart showing the Web.de and GMX.net 421 troubleshooting path from queue pause to rewarming.
Fix the retry pattern
The first operational fix is to stop treating Web.de and GMX.net like a normal destination while they are deferring. I separate those domains into their own queue policy. Then I lower both per-domain concurrency and per-domain message rate. If I only lower the campaign throttle while leaving retry settings untouched, the old queue keeps hitting the receiver.
- Pause: Stop new campaign traffic to Web.de and GMX.net for several hours, or until the deferred queue is under control.
- Drain: Let deferred messages retry with long backoff, not rapid bursts. Do not keep adding new messages while the queue is aging.
- Cap: Set concurrency to one or two connections for the MX group while reputation is being rebuilt.
- Segment: Send transactional mail first, then engaged marketing recipients, then the colder portion of the list.
- Measure: Track accepted, deferred, expired, and permanent failures separately for each destination domain.
Example domain-level queue policytext
web.de: max_connections=1, max_msgs_per_minute=2 web.de: retry_backoff=30m, retry_max_age=24h gmx.net: max_connections=1, max_msgs_per_minute=2 gmx.net: retry_backoff=30m, retry_max_age=24h
Those values are examples, not universal limits. The point is the shape: one small lane, slow retry, clean measurement. When the 421 rate drops and accepted mail stays stable, I raise volume slowly rather than jumping back to the original daily send.
Suggested restart bands
Use accepted mail and fresh 421 responses to decide when to raise or hold volume.
Healthy
0-2%
Very few fresh deferrals and no queue aging.
Hold
3-10%
Some accepted mail, but the queue is still growing.
Stop
10%+
Deferrals dominate and messages start expiring.
Check the technical sender identity
Web.de and GMX.net are strict about basic sender hygiene. I do not stop at "SPF, DKIM, and DMARC pass somewhere else." I check the exact message that went to the affected provider, because Gmail passing a message does not prove that every German receiver will score it the same way.
Message checks
- Date: Every message has a valid Date header.
- From: The visible sender domain matches the authenticated identity path.
- DKIM: The signing domain is the sender's domain or a controlled subdomain.
Infrastructure checks
- PTR: Reverse DNS exists and maps to a sensible sending hostname.
- HELO: The SMTP greeting uses a real hostname, not a generic placeholder.
- SPF: The sending IP is authorized without DNS lookup failures.
A missing or malformed Date header sounds small, but it can push a message into the wrong bucket. The same goes for a weak PTR, an unexpected envelope sender, or a DKIM signature that passes but uses a domain the receiver does not trust for this stream.
Headers and records to inspecttext
Date: Mon, 09 May 2022 17:34:53 +0000 From: Brand <news@example.com> Return-Path: bounce@example.com DKIM-Signature: v=1; d=example.com; s=s1; _dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" example.com. 300 IN TXT "v=spf1 include:mail.example.net -all"
For a quick external view of the message itself, send a real copy through the email tester and compare its authentication result with the message headers from your ESP or MTA.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
I also like to run a broader domain health check before talking to a postmaster contact. It gives me one place to confirm DMARC, SPF, DKIM, and common DNS problems before asking the receiver or the ESP to act.
Shared IPs versus dedicated routing
If you are sending through a shared IP pool, Web.de and GMX.net can throttle the IP because of traffic that has nothing to do with your brand. You see the 421 response, but the receiver sees one IP sending mail for many customers. That makes shared pools hard to troubleshoot, especially for small German volumes where your own good engagement cannot outweigh another sender's poor behavior.
A Mailgun log screen filtered to Web.de and GMX.net 421 delivery attempts.
The fix path depends on the sending setup. On a shared pool, I open an ESP ticket with samples, timestamps, sending IPs, and the exact SMTP response. I ask whether the IPs are being throttled by Web.de or GMX.net and whether they can rotate the affected IPs out of the pool. If the answer is that this can happen again, I treat that as a routing risk and decide whether German traffic needs a dedicated IP.
Shared IP pool
- Benefit: Easier for small volume and new programs.
- Risk: Other senders can damage the IP reputation you inherit.
- Fix: Ask the ESP to rotate bad IPs and show provider-specific logs.
Dedicated German routing
- Benefit: You control volume, reputation, PTR, and provider-specific pacing.
- Risk: A new dedicated IP needs a slow start and steady mail.
- Fix: Use only engaged recipients until deferrals stay low.
This is also where blocklist and blacklist checks matter. A 421 rate limit is not the same as a blocklist hit, but shared IP pools often have mixed reputation signals. Continuous blocklist monitoring helps catch the IP and domain listings that can compound throttling.
Rebuild Web.de and GMX.net volume
After the queue is calm and the technical checks are clean, I restart these two domains as if they are a new sending lane. I do not use the global warmup plan for Gmail, Microsoft, or Yahoo as proof that Web.de and GMX.net can take the same pace. Local mailbox provider trust is built locally.
Example seven-day restart
Raise only if accepted mail is stable and fresh 421 responses stay low.
Daily Web.de and GMX.net cap
Those caps are deliberately conservative. If you only have 1,500 German recipients, speed is less important than not poisoning the next send. I start with the most recent double opt-in recipients who engaged, exclude dormant addresses, and keep transactional messages ahead of promotional traffic.
When to raise the cap
- Accepted: Most mail is accepted on the first attempt for two sends in a row.
- Deferred: Fresh 421 responses are rare and the queue is not growing overnight.
- Complaints: Complaint, unsubscribe, and inactive-recipient signals stay under control.
- Headers: No authentication, PTR, Date, or envelope sender problems appear in samples.
If you see a fresh wave of 421 responses after raising the cap, roll back to the last stable level. Do not push through it. With rate limiting, forcing the queue usually creates more aged mail and more permanent failures.
How Suped fits this workflow
Suped is the best overall DMARC platform for this type of incident because it keeps DMARC, SPF, DKIM, blocklist checks, and deliverability signals in one workflow. The practical benefit is not another dashboard. It is faster isolation of whether the issue is policy, authentication, DNS, IP reputation, or a provider-specific sending pattern.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For Web.de and GMX.net incidents, I use Suped's product to confirm the sending domains are authenticated correctly, watch for domain-level failures, and separate DNS problems from ESP pool problems. Suped's automated issue detection and steps to fix are especially useful when the team needs to act quickly without turning every 421 response into a manual investigation.
- DMARC: Monitor policy, authentication pass rates, and suspicious domain use with DMARC monitoring.
- SPF: Use Hosted SPF and SPF flattening to keep authorized senders manageable.
- Alerts: Use real-time alerts when authentication failures or reputation signals change.
- MSPs: Manage multiple client domains from one multi-tenant dashboard.
Suped does not replace your ESP's control over shared IP pools, but it gives you the evidence to make the right request: rotate affected IPs, fix DNS, create a dedicated lane, or hold volume until provider-specific reputation recovers.
Views from the trenches
Best practices
Pause fresh Web.de and GMX.net mail before retries turn a small send into pressure.
Check PTR, HELO, SPF, DKIM, DMARC, and Date headers on the exact affected stream.
Ask the ESP for IP-level evidence when shared pool traffic drives the throttling.
Common pitfalls
Lowering campaign speed alone leaves old retries hitting the same receiver limits.
Assuming Gmail acceptance proves Web.de and GMX.net technical checks will pass cleanly.
Treating shared IP reputation as your own reputation hides pool-level sender problems.
Expert tips
Create a separate German mailbox provider lane with its own queue and retry rules.
Restart with engaged double opt-in recipients before adding colder marketing segments.
Keep exact SMTP responses, IPs, timestamps, and message IDs ready for ESP support.
Expert from Email Geeks says Web.de and GMX.net can be strict about technical identity, including DMARC-style domain matching and reverse DNS.
2022-05-11 - Email Geeks
Expert from Email Geeks says stopping fresh sends and restarting slowly is often faster than fighting an active retry loop.
2022-05-11 - Email Geeks
The practical resolution
The fastest practical resolution is to stop feeding Web.de and GMX.net with fresh mail, slow the retry lane, and prove the sending identity is clean. If the traffic is on a shared IP pool, push the ESP for IP-level investigation and rotation. If German volume matters to the business, plan a dedicated route with correct PTR and a slow warmup.
Once the lane is stable, keep Web.de and GMX.net on their own pacing rules. A provider-specific queue policy feels heavy for a small list, but it prevents a short deferral burst from turning into expired mail, local processing errors, and another reputation reset.
