> ## Content Index > Fetch the complete content index at: https://blog-preview.sudowl.com/llms.txt > Use this file to discover other available public pages before exploring further. # T-Online Rejects My Server: "554 Dialup/transient IP not allowed" - URL: https://blog-preview.sudowl.com/t-online-554-dialup-transient-ip-not-allowed/ - Published: 2026-10-29T10:00:00.000Z - Updated: 2026-11-05T18:02:37.000Z - Description: Gmail got my login codes in seconds, t-online.de refused the server. What Telekom checks, how I filed the unblock request and what the log showed. - Author: Lukas - Tags: Linux, Security An app I run for a client sends login codes by mail. You type your address, you get a 6 digit code, you type it in. Then a complaint came in: the code took more than 10 minutes. So I opened the mail log. Gmail was fine. One provider was slow on its own side. One greylisted me. And t-online.de didn't take a single mail. Anyone with a t-online address simply never got a code. **TL;DR:** Telekom's mail servers refuse servers they think are dialup or "anonymous" with `554 ... Dialup/transient IP not allowed`. It's not about SPF or DKIM. Check that your PTR, the A record of that name and your HELO all match, and that you can get from that hostname to a website with a real imprint and contact. Then file the request through the contact form on postmaster.t-online.de, with the exact log line. Telekom doesn't whitelist, they only lift a block, and they don't send a confirmation. You see the result in your own log. For me it took about an hour. ## The setup The app's auth service hands the mail to Postfix on a shared KeyHelp box. That box has one hostname, `server.example.net`, with matching A and PTR, and it sends for several domains. The handoff takes under a second. So whatever is slow happens after Postfix. ## Read the log per provider First thing: grep the log for the recipient domains people complained about, and hide the local part. ```bash grep -E 'to=<[^>]*@(t-online\.de|example-isp\.at)>' /var/log/mail.log \ | sed -E 's/to=<[^@]*@/to=<*@/' | tail -25 ``` What I found, per provider: - **Gmail:** every code mail that day was delivered in 1 to 2 seconds. The Gmail users were logged in 25 to 30 seconds after they asked for a code. GMX and Proton were just as fast. - **One ISP:** accepted every mail in 0.3 seconds. The 10 minutes happened inside their system. Nothing I can do about that. - **Another ISP:** greylisting. First try gets `451 4.7.1 Try again later` at the end of DATA, and Postfix waited 5 minutes before the retry. - **t-online.de:** refused the connection outright. The t-online lines looked like this (IPs replaced): ```text postfix/smtp[...]: A2FE91FE26: host mx02.t-online.de[198.51.100.9] refused to talk to me: 554 IP=203.0.113.10 - Dialup/transient IP not allowed. Use a mailgateway or contact
@rx.t-online.de if obsolete. (DIAL) postfix/smtp[...]: A2FE91FE26: to=<*@t-online.de>, relay=mx00.t-online.de[198.51.100.8]:25, delay=4664, dsn=4.0.0, status=deferred (host mx00.t-online.de[198.51.100.8] refused to talk to me: 554 IP=203.0.113.10 - Dialup/transient IP not allowed. ...) ``` The server isn't dialup. It's a fixed IP in a German data center. Telekom still says no. ## Gotcha: 554 at connect doesn't bounce, it sits in the queue You'd expect a 554 to bounce right away. Here it didn't. Look at the second line: `dsn=4.0.0, status=deferred`. The 554 comes in the greeting, before any mail is sent, and Postfix by default treats that as "try the next MX, then try again later" (that's `smtp_skip_5xx_greeting`, on by default as far as I know). So the code mails piled up in the queue, delays of over an hour, and nobody got a bounce. ```bash postqueue -p | grep -i -B2 t-online ``` That's where I saw one user with 4 code mails waiting. Which brings me to the next problem. ## Gotcha: "send new code" makes it worse The app invalidates the old code when you request a new one. People don't wait. One person asked for 5 codes, another for 4\. When the slow mails finally arrive, only the newest code works and the user thinks the app is broken. Fix in the app: the "send new code" button is locked for 60 seconds with a countdown, and the hint now says the mail can take a few minutes at some providers, check spam, and only the newest code counts. It doesn't fix delivery, but it stops users from fighting their own codes. ## Greylisting: shorter retry For the greylisting ISP the fix is on my side. Postfix waited 300 seconds before the second try. I lowered it: ```bash cp /etc/postfix/main.cf /etc/postfix/main.cf.bak-backoff postconf -e minimal_backoff_time=60s postconf -e queue_run_delay=60s postconf -e maximal_backoff_time=1800s postfix reload postconf minimal_backoff_time maximal_backoff_time queue_run_delay ``` Before it was `300s / 4000s / 300s`. Greylisted codes should now arrive in 1 to 2 minutes instead of 5 to 7\. It's a shared server, so this hits every domain on it. A faster retry after a temp fail hurts nobody, and the backup is one `cp` away. ## What Telekom actually checks Telekom has a postmaster page at postmaster.t-online.de. I read the part for mail server operators. The key paragraph (section 4.1, my translation): > From the hostname (FQDN) of the sending IP, the operator's domain and website with a direct way to contact them must be easy to find (RFC 1912, FCrDNS, EU directive 2000/31/EC article 5). Article 5 of that directive is the one about the information a service provider has to make available, so in practice: an imprint with contact details. The same section recommends that dialup, cloud and other "anonymous" systems use a mail gateway (an SMTP relay) of a suitable provider. Two more things surprised me. The page says Telekom doesn't use SPF for filtering and doesn't evaluate DKIM (with one exception for a branding program). And there's no whitelisting: if you think the reason for a block is gone, you contact them, and they send no confirmation. That's the page as I read it, it may change. So all my SPF, DKIM and DMARC work was irrelevant for this one. What counts is the hostname and what you find behind it. ## Check the server identity ```bash dig +short -x 203.0.113.10 # PTR dig +short A server.example.net # must point back to 203.0.113.10 postconf myhostname # HELO name curl -s -o /dev/null -w '%{http_code}\n' https://server.example.net/ ``` PTR, A record and HELO all matched. Forward-confirmed reverse DNS was fine. More on setting that up in [The first hour on a new VPS](/first-hour-new-vps-ipv6-rdns-port-25/) and [New mail domain from zero](/new-mail-domain-spf-dkim-dmarc-from-zero/). The weak spot was the website. `https://server.example.net/` returned 200, but it was just the panel's login page. `/impressum.html` was a 404\. No imprint, no contact. My first plan was a small imprint page on the hostname. Then I checked the parent domain: ```bash curl -sv -m 10 -o /dev/null http://www.example.net/ 2>&1 | grep -E '^< (HTTP|Location)' curl -sv -m 10 -o /dev/null https://www.example.net/ 2>&1 | grep -iE 'SSL|error|alert' ``` Over http, the parent domain redirects with a 301 to the company website, and that site has a full imprint with address and contact. So the chain hostname, domain, website with imprint already existed. I skipped the new page and put the imprint link into the request. ## Gotcha: the https side was broken The same check showed a problem: https on the parent domain didn't redirect. It died with `tlsv1 unrecognized name`, so the web server there has no certificate for that name. Only http worked. If the person at Telekom types `https://` they see an error. That site isn't on my server, so I passed it on. If you rely on a redirect chain like this, test https too. ## The unblock request At the bottom of postmaster.t-online.de, under "Kontakt", there's a contact form. Name, email, a dropdown for "I am", the message, and a security question (a small sum). In the dropdown pick the option for mail server operator, not customer and not newsletter sender. For a suspended system the page also names a postmaster address at rx.t-online.de as an alternative, and the bounce itself names a contact address. The page asks for IPs, the error message and log extracts. Without the original error they say they can't investigate. So the request had: - the IP and hostname - the exact log line with timestamp and the MX that said it - that it's a fixed server in a German data center, not a dynamic address - PTR, hostname and IP all pointing at each other, plus the HELO name - operator name and the link to the imprint with contact - SPF with `-all`, DKIM and DMARC set up for the sending domains - no open relay, sending only after auth, outbound spam filter (Rspamd) active - what goes through it: transactional mail only, mostly login codes users request themselves, no newsletters, a few dozen mails per day - the impact: users with a t-online address can't log in I wrote it in German, polite, short. After submitting, the page said thanks, they'll handle it as soon as possible. That's it. No ticket number, no mail. ## The result I submitted the form in the afternoon. A bit over an hour later word came back that Telekom had released it. I don't trust "released" until the log says so: ```bash grep -i 't-online.de' /var/log/mail.log | grep -E 'status=|554' | tail -8 ``` The last refusal was at 16:20 UTC. From 16:25 UTC on every t-online mail went out with `status=sent (250 2.0.0 Message accepted.)`. The queue was empty. And the user who was stuck got 6 old code mails at once. All of them deferred, all delivered in one go. Only the newest code worked. If you get unblocked while mails are queued, expect exactly that, and tell your support people. Don't count on an hour every time. They give no status updates, so it could just as well take a week. ## What I'd do next time 1. Read the log per recipient domain first. It's never one cause. 2. Lower the Postfix retry for greylisting, lock the resend button. 3. For t-online: FCrDNS, HELO, and an imprint reachable from the hostname over http **and** https. 4. File the form with the exact log line, then watch your own log. If they had said no, the fallback was a relay with a good reputation, which Telekom recommends for cloud servers anyway. The client's Microsoft 365 was out, that tenant isn't mine to change. For a new mail server, plan for this from day one, along with [DMARC reports](/dmarc-reports-explained-rua-xml/) and enough [RAM for the mail stack](/mail-server-ram-budget-4gb-vs-8gb/). My panel setup is in [KeyHelp as a free Plesk alternative](/keyhelp-free-plesk-alternative/). --- ### Related posts - [WordPress Moved Into a Subdirectory: 500 Error, Wrong URLs and an Admin User From SQL](https://blog.sudowl.com/wordpress-moved-to-subdirectory-500-error/?ref=blog-preview.sudowl.com) - [Website Cert Fine, Mail Cert Expired: Plesk's Stale Postfix SNI Map](https://blog.sudowl.com/plesk-mail-certificate-expired-postfix-sni-map/?ref=blog-preview.sudowl.com) - [New Mail Domain From Zero: SPF, DKIM and DMARC Passing on Day One](https://blog.sudowl.com/new-mail-domain-spf-dkim-dmarc-from-zero/?ref=blog-preview.sudowl.com)