GMX and WEB.DE Bounce Messages: 554 Block Listed, Postmaster Case Links and Unknown Users

A GMX or WEB.DE bounce is easiest to read from the bottom up: the three-digit SMTP code tells you permanent or temporary, and the last line holds a postmaster link that explains the case. GMX publishes this on its postmaster site, written for mail administrators. This post covers what that site says, in our words, as read on 9 November 2026, and which part of a bounce you fix on your server versus on your list.

Check a GMX address →

How GMX bounce messages are built

According to GMX's error messages page, errors fall into two groups:

• 5xx errors are permanent. The problem is persistent, so the message should not be redelivered. Don't retry. Find the cause.
• 4xx errors are temporary. The problem may clear up, and your sending server should be set to retry automatically.

Two details from the same page save time:

1. Read the whole last line. GMX says it holds the details needed for analysis. In the documented example, the last line begins "554 For explanation visit" and ends with a link to a postmaster.gmx.net/en/case page with parameters for that rejection.
2. GMX does not use enhanced status codes such as 5.1.1. If you are used to reading 550 5.1.1 at other providers, you will not see that here.

If your email tool only shows a short summary, go to your own logs. The GMX page advises searching them for the pattern https://postmaster.(gmx|web|mail), because the bounce your tool generates can leave out or alter GMX's wording. The same patterns cover WEB.DE and mail.com.

554 IP address is block listed

The one rejection GMX documents with an example looks like this:

554-IP address is block listed.
554 For explanation visit https://postmaster.gmx.net/en/case?...

It means the connecting server's IP address is on a block list, so GMX refused the connection.

What to do:

1. Open the link in the last line. It explains the cause and the next step. If the case needs action from GMX, the page offers a contact option.
2. Check your IP with the IP blacklist check. Then follow the delisting steps of each list that shows you, using the blacklist removal helper if it helps.
3. Use GMX's blocklisting form if you still need help. Its page says the form reaches the abuse team and asks for the sender address, when you tried to send, the recipient domain, and the exact error or bounce text. It says full mailboxes and configuration errors don't belong there.
4. Find out why you were listed. Mail to many dead addresses is a common reason a sending IP ends up on lists. Cleaning the list matters as much as delisting.

If you send through an email platform on a shared IP, send the full bounce to the platform's support. The block is on their IP, so you can't fix it yourself.

What GMX says senders must do

GMX's requirements page, read today, lists these points. Most rejections that are not a plain block listing trace back to one of them.

Area	What GMX says
Sending IP	Static, not a dial-up or dynamically assigned range
Reverse DNS	PTR must point to a fully qualified domain name, ideally in your own domain; generic provider defaults usually lead to rejection
Block lists	Neither the IP nor the domain should be listed
DNS	The sending domain needs valid MX or A records
HELO/EHLO	A valid fully qualified domain name
Headers	Follow RFC 5321 and 5322; Date, From and Message-ID present; fields like To, Cc and Subject appear only once
DKIM	Required: a valid signature that aligns with the From domain, at least in relaxed mode
SPF and DMARC	Recommended; the page says SPF alone is not sufficient
Bulk mail	Consent from people who opted in, ideally double opt-in; an easy unsubscribe, with RFC 8058 one-click ideal

Check your own setup with the reverse DNS lookup and the email domain health checker. If DKIM is the weak point, DKIM for every sending service covers the usual gaps, and reverse DNS and PTR records for email explains what a good PTR looks like.

The list-hygiene warning in GMX's own words

GMX's page on sender requirements says to avoid invalid, inactive or outdated addresses and to remove undeliverable contacts regularly. It warns that many messages to unknown or deactivated addresses can cause temporary suspension, and permanent rejection in severe cases. It does not publish a bounce-rate number, so there is no threshold to aim just below. The safer plan is to send as few messages to dead addresses as you can.

That is where verification fits. Your server, DNS and authentication are things you set once. The list changes every month, and it is the part that triggers the warning.

Why unknown users are a list problem

When GMX or WEB.DE says a recipient doesn't exist, no setting on your side changes that. The address has to leave your list. Where the mailbox answer is clear, a verifier can tell you before the send:

• Valid: the mailbox accepts mail. Send.
• Invalid: the mailbox doesn't exist. Suppress it.
• Risky or unknown: the answer wasn't clear. Send these in a small, slower group, or leave them out of a first campaign.

Mailbox providers don't all answer checks the same way, which is why a risky group exists at all. How mailbox providers answer verification checks in 2026 goes through it. 550 5.1.1 user unknown covers the same problem at providers that do use enhanced codes.

A short routine for German-language lists

1. Split the list by domain. Pull out gmx.de, gmx.net, gmx.at, gmx.ch and web.de rows. They are often older consumer addresses.
2. Verify the file at /verify, or check single addresses with the WEB.DE email checker.
3. Suppress invalid rows permanently. Keep a record so a later import can't add them back; cold email suppression lists shows a simple way.
4. Send risky rows slowly, after the valid ones have gone out without trouble.
5. Read every 5xx. Paste it into the bounce message analyzer if the meaning isn't clear, and keep the postmaster link from the last line.
6. Re-check old lists before using them again. How often to verify an email list gives a schedule.

If you also mail large French or German consumer providers, Orange and Wanadoo bounce codes and T-Online bounce messages cover those two.

Quick answers

• Is a 4xx from GMX a bounce? No. It is a temporary failure. Your server should retry on its own.
• Will delisting fix everything? Only if the cause is fixed. Repeating the same send to the same list can put you back on a list.
• Does GMX publish a bounce-rate limit? Not on the pages we read. It only warns about many messages to unknown or deactivated addresses.

Try it on your own list

Upload a sample at /verify. The first 100 checks are free with a Google sign-in, no card.

Pro, $39 a month: Unlimited email verification.* Never metered, never cut off. See pricing.

*Fair use: the first 100,000 checks a month at full speed, then slower, never cut off.