Why T-Onlines mailfilter is a problem for the Telekom Customers

"I didn’t get anything!"

You are waiting for an important email. There is nothing in your inbox, and nothing in your spam folder either. So presumably nobody wrote to you? Unfortunately, it is not always that simple.

A message can be rejected as soon as it reaches the mail provider. In that case, it never reaches your mailbox at all. The sender will normally receive an error message—but you, as the recipient, may not notice the delivery attempt at all.

That is exactly what happened when my mail server sent a message to a T-Online address. Around ten days and ten emails followed before Telekom finally agreed to reset the reputation.

For me, this raises a fundamental question: How well do the acceptance rules of major providers work for small, independently operated mail servers—and what are the consequences for your reachability?

Unacceptable for critical/business communication?

Do you use a T-Online address and rely on customers, business partners or applicants being able to reach you through it? My case calls precisely that trust into question: T-Online rejected a regular message from my mail server before it was even transmitted. Nothing reached the recipient—not even the spam folder. Someone writing to you for the first time can therefore fail at a hurdle that you yourself know nothing about. I therefore do not consider T-Online reliable enough as the sole address for important communication—especially not in day-to-day business.

What exactly happened

On 22 July 2026, my mail server attempted to deliver a regular email to an address at t-online.de. The Telekom mail server contacted replied:

554 IP=161.97.137.155 - None/bad reputation.
Ask your postmaster for help or to contact
tobr@rx.t-online.de for reset. (NOWL)

My sending log described the process as “refused to talk to me”.

The remote server refused to continue the SMTP dialogue right at the start. SMTP is the protocol mail servers use to transfer messages to one another. In this case, the connection never got as far as transmitting the message headers and content.

That meant it was not possible to check the DKIM signature or obtain a complete DMARC result for this message. I explain what these mechanisms do below.

The message was not placed in a spam folder either. It was not accepted in the first place.

Technically, such a rejection is provided for: SMTP explicitly permits a connection to be rejected at the outset with error code 554. Other providers also block connections to defend against spam and abuse. Rejection alone therefore does not demonstrate a breach of the email standard. Source: RFC 5321, Section 3.1

For me, the decisive issues are the reason given and the path back to working delivery.

The reason: no activity for a prolonged period

In response to my enquiry, the Telekom team said:

“No activity from the specified IP address had been detected by us for a long time. For security reasons, our systems only accept emails from such IP addresses after their reputation has been checked and reset.”

This response did not cite any specific current spam sending or other abuse from my IP address. Telekom gave prolonged inactivity in relation to its systems as the reason.

The error message “None/bad reputation” alone does not clearly distinguish between no reputation and poor reputation. Only the additional response made it understandable what role the lack of activity played in my case.

This matters to small operators: their own mail server may send messages to T-Online only occasionally. A continuous sending history with every recipient provider does not arise automatically.

Low sending volume does not prove trustworthiness. But neither is it evidence of abuse. If a prolonged pause in sending requires manual review, even occasional legitimate communication becomes an additional operational burden.

Why the spam folder does not help you here

For recipients, the problem is the lack of visibility.

You can open an email placed in the spam folder, review it, mark it as wanted and perhaps see future emails directly as a result. A message rejected before transmission is not available to you for any of that.

With a rejection right at the start, the remote server does not even know the specific recipient address yet. That is transmitted later in the SMTP dialogue. A personal notification therefore cannot readily be associated with this attempt.

This is not the annoying junk mail you have to throw in the bin; it is the postman deciding to throw away letters to you before they even reach your letterbox.

That explains the technical limitation. The practical consequence remains:

You cannot conclude from an empty spam folder that no message has gone missing.

You may notice this with an expected appointment confirmation. You may not with an initial customer enquiry, an application or a quote.

The sender can assess the error message and seek another way to contact you. The recipient may not even know that action is needed.

From the IP address to the operator’s website

For renewed acceptance, Telekom referred me to Section 4.1 of its postmaster FAQ. There, it requires that the hostname of the submitting system can be used to find an operator website with an immediate means of contact. Source: Telekom Postmaster FAQ, Section 4.1

I then set up a redirect for the domain concerned to my business website, which includes legal notice and contact details.

In the subsequent exchange, the team then required comparable reachability via the specific hostname too. It also said the contact route had to work "independently of the mail system concerned". According to that information, an email address within that system was not sufficient.

An independent contact route can certainly make sense in the event of disruption. However, it answers a different question from the technical authentication of an email: it helps reach an operator, but does not confirm the authorisation or safety of a specific message.

The resolution: ten emails and around ten days later

I asked again. In my reply, I referred to the redirect set up to the website with legal notice and contact address, the usual administrative addresses such as postmaster@ and abuse@ and the existing authentication records.

I also questioned the blanket assumption that a contact address within the domain would be unavailable in the event of a disruption. The addresses are backed by a cluster infrastructure, where services can move between systems. Being part of the same domain therefore does not necessarily imply a shared failure. Conversely, completely independent reachability does not prove that either.

My final request was specific: what now still prevents acceptance of the emails—and how can the problem be resolved conclusively?

The decisive response from the Telekom email team then came:

“We will arrange for the IP address’s reputation to be reset in our system.”

The change could take up to 24 hours, though experience suggested it would take effect within one to two hours.

Telekom thus ultimately relented—after around ten days and ten emails in total.

This is explicitly part of the story: there was an individual review and, in the end, a commitment to reset the reputation. That commitment alone is not yet proof of subsequently successful delivery.

The final response neither identified a further technical shortcoming nor explained which point had ultimately been decisive. It also remained unclear how another block after a prolonged sending pause could be avoided.

What is particularly sobering for me is the comparison with my earlier attempt: around a year before, I had already tried to resolve the delivery problem with T-Online—without success at the time.

I welcome the current decision. In my view, however, the path to it remains disproportionately burdensome.

What this means for InitInsights

Telekom has committed to resetting the reputation. That puts a specific solution in sight—and I expressly acknowledge that.

My fundamental criticism remains: a delivery problem should be understandable and fixable on the basis of clear criteria. After this exchange, I know that an individual resolution was possible. I still do not know how permanent the approval is or under what conditions action could again become necessary.

I will continue maintaining my mail services, assessing delivery errors and fixing technical problems. However, I cannot and do not wish to make a comparable coordination effort every time another block occurs.

If messages to T-Online are rejected again, I will contact you by another route where possible and ask for an alternative address. Newsletters may also be affected by such rejections.

This incident does not allow any general conclusion about T-Online’s failure rate. For me, however, it is reason to assess a T-Online address critically as the sole channel for important business communication. An additional contact route is sensible here.

A solution in an individual case—open questions about the process

This story ends with a positive commitment. At the same time, it shows how much effort may be required before a small mail server is promised renewed acceptance of its messages.

On my side, there were around ten days and ten emails. On the recipient side, there was no message that could be found or released from the spam folder.

This is precisely where I would like to see improvements: understandable reasons for rejection, unambiguous requirements and a resolution process that is workable for small, infrequently sending systems too.

Approval helps in the specific case. A comprehensible process helps next time too.

What experience have you had with delivery problems of this kind—as a user, business or operator of your own mail server? And how well were you able to establish why a message was rejected and what was needed for a lasting solution?

Ignored technical options

What reverse DNS has to do with it—and where it ends

Reverse DNS can be described as a reverse lookup: a hostname is determined for an IP address. If that hostname in turn resolves to the same IP address, the mapping is consistent.

For my server, this technical chain looks like this:

IP address → mail.jukut.de → same IP address

This is known as Forward-confirmed Reverse DNS.

RFC 1912 describes appropriate forward and reverse DNS mappings. The document does not require a website at the mail server hostname or an external contact channel. It is also published as “Informational”. Source: RFC 1912, especially Section 2.1

The additional website and contact requirement must therefore be assessed as a separate organisational acceptance rule. It does not follow from a correct DNS mapping.

This distinction matters: technical standards, operational contact routes and individual provider rules serve different purposes.

What SPF, DKIM and DMARC do

Understanding my criticism also requires asking which technical trust signals are available.

The three most important terms can be summarised as follows:

• SPF checks whether the submitting IP address is permitted to send for the domain of the technical sender. This technical sender may differ from the address visible in the mail client.
• DKIM uses a digital signature. It makes it possible to check whether the signed parts of a message are unchanged and whether the signature belongs to the stated domain.
• DMARC links this to the visible sender domain. For this, at least one matching SPF or DKIM check must succeed.

These mechanisms help combat certain forms of forged senders. However, they guarantee neither harmless content nor delivery. Attackers can also authenticate their own domains correctly. Reputation, sending behaviour and other filters therefore remain necessary.

For messages to personal Gmail addresses, Google requires, among other things, SPF or DKIM, valid forward and reverse DNS, and TLS. Additional requirements apply to senders of more than 5,000 messages per day, including SPF, DKIM and DMARC. Source: Google Email Sender Guidelines

What Telekom documents on this

In Section 3.5 of its publicly available FAQ, Telekom still states that it uses SPF neither for receiving nor sending. It also says DKIM is neither applied nor evaluated; an exception is mentioned for “Trusted Dialog”. Source: Telekom Postmaster FAQ, Section 3.5

This is initially a statement about the published documentation. It does not replace an independent investigation of all systems currently in use.

However, this description does not make it possible to understand how a regular DMARC check would be implemented: it requires an aligned, successful SPF or DKIM result.

Here, I would like to see a current and unambiguous technical explanation from Telekom.

My specific delivery error does not prove that the lack of use of these mechanisms caused the block. It shows that the connection ended because of the IP assessment before message-specific authentication features could be checked.

Why this affects small operators in particular

Based on my own technical review, all recommended and widely used current methods are configured on my systems, including consistent DNS, SPF, DKIM, DMARC and TLS. There are also abuse protection measures, administrative contact addresses and processing of non-delivery reports.

This provides a comprehensible technical basis for operating mail services.

If an individual operator review is also required after a prolonged sending pause, that creates additional work. For small businesses, associations and private operators, this effort can be substantial relative to their sending volume.

Large sending platforms often have continuous mail traffic and specialised teams. Anyone operating a small mail server must handle such clarifications alongside the actual operation.

An upstream sending service can mitigate delivery problems in practice. Yet the question remains for me: how can independently operated infrastructure reliably participate in email communication?

For this, I would like to see:

• comprehensible criteria for blocks and their removal,
• up-to-date documentation of the authentication mechanisms used,
• as automated a route as possible for correctly operated, infrequently sending systems,
• a clear distinction between technical requirements and additional organisational conditions.

Protection against abuse and practical access must be considered together. A small mail server should have a realistic opportunity to build trust without having to go through a long, individual coordination process.