How to resolve SMTP 421 errors with Web.de and GMX.net due to rate limiting?
Published 4 Aug 2025
Updated 25 Jul 2026
12 min read
Summarize with
Updated on 25 Jul 2026: We updated this guide for current WEB.DE and GMX sender requirements and added full-response diagnostics with safer queue recovery.
To resolve SMTP 421 errors from Web.de and GMX.net, stop or drain the affected queue, slow both new sends and retries, read the complete SMTP response, verify authentication and reverse DNS, and check whether a shared sending IP is the real problem. Restart volume with a dedicated Web.de and GMX.net throttle only after fresh deferrals have returned to a stable baseline. On a shared ESP pool, ask the ESP to investigate the affected IPs and provider response before changing routes.
Web.de and GMX.net can continue seeing pressure after new campaign volume falls because the MTA is still opening connections and retrying deferred messages. A sender can reduce new mail to five messages per minute and still keep tripping the limit if the old queue retries aggressively. 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. SMTP 421 is generic, so the status code alone does not prove rate limiting. When the final response line says too many messages arrived in a short period, the practical response is to send less, open fewer connections, and stop rapid retries to the same destination.
Illustrative Web.de or GMX.net rate-limit deferraltext
421-web.de (mxweb113) Nemesis ESMTP Service not available 421-Service unavailable 421-Reject due to policy restrictions 421-Please try again later. Too many messages have been received 421-in a short period of time. Please try again in a few hours 421-and reduce the sending rate. 421 For explanation visit <provider diagnostic URL>
Treat an explicit short-period or sending-rate response as a rate problem with a possible trust component. Partial acceptance followed by deferrals points to throttling, but it does not identify the exact trigger. IP reputation, a sudden volume change, poor recipient quality, complaints, or repeated connection attempts can all affect the receiver's decision.
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 keep throttling while that pressure remains.
- Queue: Pause new Web.de and GMX.net traffic before old deferred mail expires.
- Retry: Use exponential backoff with jitter for these domains instead of frequent fixed retries.
- Connections: Limit concurrent sessions to the shared MX group, not only the message rate.
For senders seeing the same pattern at other mailbox providers, the broader mechanics are similar. The guide on sending rate limits explains the connection and retry side in more general terms.
Read the full SMTP response
WEB.DE and GMX return multi-line SMTP responses. The final line contains the decisive detail and normally includes a provider diagnostic URL with incident parameters. An NDR is generated by the sending server, so a shortened bounce notification can omit the line needed to classify the event.
- Capture: Save the raw SMTP transcript, final response line, timestamp, sending IP, recipient domain, and queue or message ID.
- Classify: Use the response text and diagnostic URL to separate rate limiting from a temporary service issue, blocklist or blacklist event, and authentication policy failure.
- Retry: Keep automated retries for a genuine 4xx response, but apply a slower destination-specific schedule while the condition remains.
- Escalate: Give the exact response and diagnostic URL to the ESP or provider contact instead of sending only a screenshot of a generic 421 bounce.
Do not confuse 421 with DMARC rejection
A 421 response remains retryable. A 554 response that cites the sender domain's DMARC policy is permanent for that message and needs an authentication or alignment fix, not a slower retry schedule.
Triage before changing volume
Before reducing volume again, determine whether the limit follows the destination domain, sending IP, message stream, or MTA behavior. A sender can have acceptable global reputation while Web.de and GMX.net still have little history for the local stream. That changes how slowly the stream should restart.
|
|
|
|---|---|---|
Some accepted | Throttle | Slow queue |
Same final line | Provider policy | Follow case URL |
Shared IP | Pool risk | Ask ESP |
Old queue | Retry storm | Back off |
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 shows that deferrals can appear even when the sender considers the volume modest. Use the provider's current response text as the primary diagnostic evidence.
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. Put those domains under their own queue policy, then lower both destination concurrency and message rate. Reducing only the campaign throttle leaves the deferred queue free to keep 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 increasing backoff and jitter, not synchronized bursts. Do not add new messages while the queue is growing.
- Cap: Start with one or two connections for the shared MX group while reputation is being rebuilt.
- Segment: Send essential transactional mail first, then engaged marketing recipients. Hold dormant recipients out of the restart.
- Measure: Track accepted, deferred, expired, and permanent failures separately for each destination domain and sending IP.
Illustrative destination queue policytext
# Pseudoconfiguration: map these controls to your MTA or ESP web.de: max_connections=1, rate_delay=30s gmx.net: max_connections=1, rate_delay=30s retry_schedule=30m,1h,2h,4h retry_jitter=enabled retry_max_age=<your documented delivery SLA>
These values are starting controls, not published Web.de or GMX.net limits. The useful pattern is one small lane, increasing retry intervals, randomized retry timing, and clean measurement. Keep the MTA's retry age consistent with the delivery SLA so temporary mail does not expire after an arbitrary 24-hour cutoff. Raise volume only after new 421 responses fall and accepted mail stays stable.
Internal restart bands
Compare fresh 421 responses and queue growth with the stream's last stable baseline. These are operating signals, not provider limits.
Raise
Stable
Fresh deferrals are at or below the stable baseline and the queue is draining.
Hold
Rising
Fresh deferrals have risen, but accepted mail continues and the queue remains controlled.
Stop
Growing
The deferred queue is growing or messages are approaching the retry-age limit.
Check the technical sender identity
WEB.DE and GMX currently require a static sending IP, valid reverse DNS, a valid HELO/EHLO hostname, standards-compliant messages, and a valid DKIM signature aligned with the visible From domain. SPF is recommended, and DMARC should cover the sender domain. Check the exact affected message and route because acceptance at another mailbox provider does not prove compliance on this path.
Message checks
- Headers: Date, From, and Message-ID fields are valid and RFC compliant.
- From: The visible sender uses a domain the organization controls.
- DKIM: The signature passes and its domain aligns with the visible From domain, at least in relaxed mode.
- Unsubscribe: Bulk mail has a clear unsubscribe path, with RFC 8058 one-click support where applicable.
Infrastructure checks
- IP: The delivering server uses a static IP, not a dynamic or dial-up range.
- PTR: Reverse DNS resolves to a sensible FQDN associated with the sending organization.
- HELO: The SMTP greeting uses that valid FQDN.
- DNS: The sending domain has a valid MX or A record so replies can be routed.
- SPF: The sending IP is authorized without DNS lookup or evaluation errors.
A missing or malformed Date or Message-ID header can add another negative signal. The same applies to generic PTR names, HELO/PTR mismatches, an unexpected envelope sender, or a DKIM signature that passes without aligning to the visible From domain.
Headers and records to inspecttext
Date: Sun, 26 Jul 2026 17:34:53 +1000 Message-ID: <20260726173453.12345@example.com> 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 an external view of the message, send a representative copy through the email tester and compare its authentication result with the headers from the affected ESP or MTA route.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Run a broader domain health check before contacting a postmaster team. It confirms DMARC, SPF, DKIM, and common DNS problems before asking the receiver or ESP to investigate the delivery route.
Shared IPs versus dedicated routing
On a shared IP pool, Web.de and GMX.net can throttle the IP because of traffic that has nothing to do with one brand. The sender sees a 421 response, but the receiver sees one IP delivering mail for many customers. Shared pools are harder to troubleshoot when German volume is small because one sender's positive engagement cannot offset every other stream on the IP.
A Mailgun log screen filtered to Web.de and GMX.net 421 delivery attempts.
The fix depends on the sending setup. On a shared pool, open an ESP ticket with samples, timestamps, sending IPs, message IDs, the complete SMTP response, and its diagnostic URL. Ask whether Web.de or GMX.net is throttling the IP, what other pool-level signals are present, and what remediation the ESP recommends. A route or IP change should follow the investigation, not replace it, because the same list or sending pattern can throttle the next IP.
Shared IP pool
- Benefit: It suits small or irregular volume that cannot maintain a dedicated IP.
- Risk: Other senders can damage the IP reputation the stream inherits.
- Fix: Ask the ESP to investigate the IP, show provider-specific logs, and remediate the pool.
Dedicated German routing
- Benefit: The sender controls volume, PTR, reputation, and provider-specific pacing.
- Risk: A new dedicated IP needs steady volume and a controlled warmup.
- Fit: Use it only when German volume is consistent enough to maintain reputation.
Blocklist and blacklist checks also matter. A 421 rate limit is not the same as a blocklist hit, but a shared IP pool can carry mixed reputation signals. Continuous blocklist monitoring helps identify IP or domain listings that can compound throttling.
Rebuild Web.de and GMX.net volume
After the queue is calm and the technical checks are clean, restart these domains as a separate sending lane. A global warmup plan for Gmail, Microsoft, or Yahoo does not prove that Web.de and GMX.net can accept the same pace. Provider-specific trust depends on the history each receiver sees.
Illustrative seven-day restart
Example internal caps only. Raise a cap when accepted mail is stable and fresh 421 responses remain at baseline.
Daily Web.de and GMX.net cap
These caps are deliberately conservative examples, not provider limits. Start with recent double opt-in recipients who have engaged, suppress invalid and inactive addresses, and keep essential transactional messages ahead of promotional traffic. Good consent and list hygiene reduce unknown-user responses and complaints that can contribute to another throttle.
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 at the stable baseline and the queue is not growing overnight.
- Complaints: Complaint and inactive-recipient signals remain controlled, and unsubscribe requests are processed promptly.
- Identity: No DKIM alignment, PTR, HELO, header, or envelope sender problems appear in samples.
If a fresh wave of 421 responses appears after raising the cap, return to the last stable level. Pushing through a throttle creates more aged mail and increases the chance that deferred messages expire.
How Suped fits this workflow
Suped's product brings DMARC reporting, SPF and DKIM diagnostics, blocklist and blacklist checks, and related deliverability signals into one workflow. During a 421 incident, that evidence helps separate an authentication or DNS fault from an ESP pool problem or provider-specific sending pattern.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For Web.de and GMX.net incidents, Suped can confirm whether the affected domains authenticate and meet DMARC alignment requirements, show domain-level failures, and keep the DNS evidence beside the delivery investigation. Automated issue detection can point the team to a record or authentication change while the ESP handles queue controls and shared-IP routing.
- DMARC: Track policy, alignment, authentication pass rates, and unexpected sources with DMARC monitoring.
- SPF: Check that each active sender is authorized and that SPF evaluation stays within DNS lookup limits.
- Alerts: Notify the team when authentication failures or reputation signals change during a restart.
- Evidence: Pair domain diagnostics with SMTP responses, IPs, timestamps, and message IDs in the incident record.
Suped does not control an ESP's shared IP pools or MTA retry schedule. It provides authentication and DNS evidence for the next action, such as fixing alignment, correcting DNS, requesting pool remediation, creating a dedicated lane, or holding volume while 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, DKIM alignment, DMARC, and 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 acceptance elsewhere proves Web.de and GMX.net checks will pass cleanly.
Treating shared IP reputation as brand reputation hides pool-level sender problems.
Expert tips
Create a separate German mailbox provider lane with its own queue and retry rules.
Restart with recently engaged double opt-in recipients before adding inactive segments.
Keep full SMTP responses, IPs, timestamps, diagnostic URLs, and message IDs ready.
A 2022 Email Geeks discussion identified domain matching and reverse DNS as important checks for Web.de and GMX.net delivery.
2022-05-11 - Email Geeks
A 2022 Email Geeks discussion recommended stopping fresh sends and restarting slowly instead of feeding an active retry loop.
2022-05-11 - Email Geeks
Resolution checklist
The fastest practical resolution is to capture the full SMTP response, stop feeding Web.de and GMX.net with fresh mail, slow the retry lane, and verify that the sending identity meets current requirements. For traffic on a shared IP pool, give the ESP IP-level evidence and ask for a pool investigation. Use a dedicated route only when German volume is steady enough to maintain it.
Once the lane is stable, keep Web.de and GMX.net under their own pacing rules. A provider-specific queue policy prevents a short deferral burst from turning into expired mail, local processing errors, and another reputation reset.
