// 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 like203-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
- 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. - Check blacklists. Enter the IP at
/blacklists. - Check your domain. Use
/domain-scannerto confirm SPF and DMARC are published and valid. - Read the bounce link to the GMX or WEB.DE postmaster page for the exact case.
How to fix it
- 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. - Create the matching A record. In your domain's DNS, make
mail.yourdomain.compoint to the same IP. - 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. - Do not send from a home connection. Use your provider's outgoing server or a sending service instead.
- Authenticate with SPF, DKIM and DMARC.
- Fix any blocklist listing after removing its cause.
- 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
- No reverse DNS (PTR), or it does not matchReverse DNS gives a name to your server's IP address. Without it, or if it does not point back, your server looks like an infected home computer.
- Your emails land in Gmail's spam folderWhen Gmail sends your emails to spam, the cause is almost always authentication, reputation or content. Here is how to find which one and fix it.
- Your emails land in Outlook or Hotmail junkOutlook.com, Hotmail and Live send many new senders to Junk. Check your setup, then use Microsoft's free sender tools: SNDS, JMRP and the delist portal.
- Gmail bounce "550 5.7.26": unauthenticated emailGmail refused your email because it could not confirm it comes from your domain. SPF, DKIM or DMARC is missing or failing. Here is how to fix it.
- Bounce "550 5.7.1": message rejected or blocked by policyA 5.7.1 bounce means the receiving server refused your email on purpose. Learn to read bounce messages, find the real reason and fix it.