all guides

// how to fix

GMX / WEB.DE "554 Transaction failed / Reject due to policy restrictions" and "invalid DNS PTR resource record": fix

GMX and WEB.DE refuse servers without a valid reverse DNS (PTR) or with a poor reputation. How to read the error and fix your server.

What it means

GMX and WEB.DE are two very popular email services in Germany, both run by United Internet (which also runs mail.com and 1&1 / IONOS mail). Their receiving servers are strict. When they refuse your server, the bounce often has several lines starting with 554-. It usually looks like one of these:

554-Transaction failed
554-Reject due to policy restrictions.
554 For explanation visit https://...

554-No SMTP service
554-invalid DNS PTR resource record, IP=203.0.113.10
554 Reject due to policy restrictions.

Some bounces, mostly from WEB.DE, say Requested action not taken: mailbox unavailable together with a note about the PTR record. That wording looks like "this address does not exist", but when it mentions the IP or the PTR record, the problem is your server, not the mailbox.

The bounce usually contains a link to the GMX or WEB.DE postmaster pages. They have pages explaining each case. Open the link given in your own bounce.

Why it happens

Reverse DNS (PTR) problems

This is the most frequent cause. A PTR record is the name attached to an IP address, like a reverse phone book. GMX and WEB.DE expect:

  • a PTR record to exist for your sending IP;
  • that name to point back to the same IP (forward-confirmed reverse DNS);
  • a real server name, such as mail.yourdomain.com, not a generic one like 203-0-113-10.dynamic.isp.example;
  • the name your server announces in its greeting (HELO or EHLO) to be a real, resolvable hostname, ideally the same as the PTR.

Reputation and policy

"Reject due to policy restrictions" without a PTR mention usually points to reputation: the IP is on a blocklist, sends from a home connection, is brand new, or the content and complaints look like spam. Missing SPF, DKIM or DMARC also weighs against you.

How to check

  1. Run a Delivmail test. From the same server, send an email to the unique address on the home page (/). The report shows your sending IP, its PTR name, whether that name points back to the IP, and the HELO name your server used. It also checks blacklists and authentication.
  2. Check blacklists. Enter the IP at /blacklists.
  3. Check your domain. Use /domain-scanner to confirm SPF and DMARC are published and valid.
  4. Read the bounce link to the GMX or WEB.DE postmaster page for the exact case.

How to fix it

  1. Set a PTR record. The PTR is controlled by the owner of the IP, usually your hosting company or VPS provider, not by your domain's DNS. Look for "reverse DNS" or "rDNS" in their control panel, or ask their support. Set it to a name such as mail.yourdomain.com.
  2. Create the matching A record. In your domain's DNS, make mail.yourdomain.com point to the same IP.
  3. Set the HELO name. Configure your mail server to greet with that same name. In Postfix this is myhostname. Many control panels and apps have a "hostname" or "HELO" setting.
  4. Do not send from a home connection. Use your provider's outgoing server or a sending service instead.
  5. Authenticate with SPF, DKIM and DMARC.
  6. Fix any blocklist listing after removing its cause.
  7. If everything is clean and the refusal continues, use the contact form on the GMX or WEB.DE postmaster pages, with the full bounce and your IP.

Check that it is fixed

PTR changes can take from a few minutes to a few hours to be visible. Send a new Delivmail test: the reverse DNS section should show a PTR name that points back to your IP, and the HELO should be a real hostname. Then send again to the GMX or WEB.DE address that bounced. If the cause was reputation, expect a few days of clean sending before everything is accepted.

Check that it is fixed

DNS changes can take from a few minutes to a few hours. Then send a new test email or scan your domain again.

Related guides