How to troubleshoot T-Online.de email deliverability issues and 550 errors?
Michael Ko
Co-founder & CEO, Suped
Published 25 Jul 2025
Updated 27 May 2026
11 min read
Summarize with
A T-Online.de 550 error means Telekom's inbound mail system rejected the message during SMTP delivery. The fix starts with the full, unmodified bounce, not a shortened dashboard copy. If the bounce says something like 550 grey defer DKIMr and also says the message was rejected because of spam or virus classification, treat it as a content or message-classification problem first, then verify DKIM, SPF, DMARC, IP reputation, and sending logs.
The fastest path is practical: get the raw SMTP transcript from the ESP or MTA operator, test a plain control email to the same T-Online.de recipient, compare it with the failing campaign, and remove risky content until the message passes. After that, confirm DMARC domain matching and sender reputation so the next campaign does not hit the same block.
This order separates a receiver-side policy rejection from a sender-side issue. Suped can help with authentication, reporting, alerting, and blocklist monitoring, but the exact T-Online.de rejection evidence still has to come from the system that connected to Telekom's mail server.
What the T-Online.de 550 error means
A 550 response is a permanent SMTP rejection for that delivery attempt. In a T-Online.de case, the important part is the text after the status code. A line saying the message was rejected due to spam or virus classification points to content, URL reputation, attachment handling, MIME structure, authentication signals, or sender reputation. A line mentioning DKIM can mean the receiver used DKIM as part of its filtering decision, but it does not automatically prove that DKIM alone caused the rejection.
Do not send anonymized bounces to postmaster teams
If the bounce replaces the real IP, timestamps, diagnostic IDs, mailhost values, or German error text with placeholders, the postmaster team loses the data they need.
- Required: Ask the ESP for the full SMTP rejection text, including the original diagnostic code.
- Required: Include the real sending IP, timestamp with time zone, envelope sender, recipient domain, and message ID.
- Avoid: Do not replace diagnostic tokens with generic placeholders before escalation.
Example of the kind of bounce detail to preservetext
550-(grey defer DKIMr) 550-Your IP: 203.0.113.10 550-Mailhost: mailin21.mgt.mul.t-online.de 550-Timestamp: 2026-05-27T09:26:49Z 550-Your message has been rejected due to spam or virus classification. 550-If you feel this is inapplicable, report the above error codes.
The phrase grey defer DKIMr can be confusing because it contains words that sound temporary and authentication-specific, while the SMTP status is still 550. Do not diagnose from that fragment alone. Treat the complete rejection text and nearby test messages as the evidence.
First checks to run
Start with controlled comparisons. Send one minimal plain-text email, one normal template without tracking links, and one copy of the failing message. Use the same sender domain, the same sending IP pool, and a T-Online.de test recipient where possible. If the plain message arrives and the campaign fails, the issue is probably message-specific. If every message fails, widen the investigation to authentication, IP reputation, throttling, or a receiver-side block.
- Bounce: Collect the full, unmodified rejection from the platform running the outbound MTA.
- Control: Send a short plain-text message with no links, images, attachments, or tracking.
- Compare: Add the original HTML, links, images, and headers back one group at a time.
- Authenticate: Confirm SPF, DKIM, and DMARC domain matching for the exact visible From domain.
- Escalate: Open a support case with the ESP and include raw bounces and test timestamps.
Flowchart showing the order for diagnosing T-Online.de 550 delivery failures.
For a live message-level view, send the exact message to an email tester and compare the result with the T-Online.de bounce. That does not reproduce Telekom's private filtering, but it exposes broken headers, missing authentication, bad MIME structure, and obvious content problems before postmaster escalation.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
How to tell whether it is content, IP, or authentication
The quickest clue is whether another message with the same sending setup reaches T-Online.de. If one template fails and another passes, inspect that template first: wording, URLs, redirects, tracking domains, images, attachments, HTML, and personalization output.
Content-related pattern
- Control: A plain-text message reaches T-Online.de.
- Template: Only one campaign, language version, or HTML variant fails.
- Links: One destination, redirect, or tracking domain appears only in rejected mail.
- Fix: Strip the message down, then add elements back until the rejection returns.
Infrastructure-related pattern
- Scope: Every message from one IP or stream fails.
- Auth: SPF, DKIM, or DMARC fails or does not match the sender domain.
- Reputation: The sending IP or domain appears on a blocklist or blacklist.
- Fix: Correct DNS, slow volume, and escalate through the ESP with raw evidence.
For authentication, check the same domain that the recipient sees in the From header. SPF passing on the bounce domain is useful, but DMARC depends on a match with the visible From domain. DKIM is often the cleanest domain-matched signal for marketing and product mail because it survives forwarding better than SPF.
|
|
|
|---|---|---|
Plain passes | Content | Remove links and HTML |
All fail | IP or auth | Check DNS and logs |
DKIM fail | Signature | Rotate selector |
550 spam | Filtering | Isolate content |
Listed IP | Reputation | Pause stream |
Use the result pattern to choose the next action.
If the problem points to infrastructure, check the domain with a domain health check. I use that kind of check to catch expired DKIM selectors, SPF lookup failures, missing DMARC records, strict policy mistakes, and DNS publishing errors before opening a support ticket.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
What to ask your ESP for
If you send through a marketing platform, lifecycle platform, or relay, the vendor operating the outbound MTA has the detail T-Online.de needs. A dashboard bounce summary often hides or rewrites the fields that matter. Ask for the raw SMTP response exactly as their MTA received it, plus delivery logs around the failing timestamps.
- Transcript: Request the unmodified SMTP reply, including all 550 continuation lines.
- Route: Ask which sending IP, pool, MTA hostname, and return-path domain were used.
- Headers: Get a copy of the exact RFC 5322 headers for a failed message.
- Classification: Ask whether their deliverability team sees related blocks at other German mailbox providers.
- Remediation: Ask whether they recommend pausing, reducing volume, changing content, or moving traffic.
Support request template for your ESPtext
Subject: Need raw T-Online.de SMTP rejection details Please provide the full unmodified SMTP transcript for these failures. Recipient domain: t-online.de Sending domain: example.com Visible From: mail@example.com Approximate time: 2026-05-27 09:20-09:40 UTC Observed response: 550 spam or virus classification Please include the sending IP, MTA hostname, return-path domain, Message-ID, DKIM selector, and any internal event IDs.
Once you have the raw data, the postmaster conversation changes. Instead of asking for a broad unblock, you can provide a precise event: IP, timestamp, recipient domain, diagnostic ID, and sample message. That is the level of detail most receiver teams need before they can search logs or confirm a classification problem.
When the ESP and sending platform are different
Some setups split responsibility between the campaign platform and the infrastructure provider. In that case, start with the platform you log into, but ask them to route the case to the team that operates the MTA connection to the receiver. The owner of that MTA has the authoritative bounce.
Authentication checks that matter for T-Online.de
Even when the first symptom looks content-related, authentication has to be clean. A receiver can combine content scoring with SPF, DKIM, DMARC, rDNS, HELO identity, and historical reputation. A borderline message with strong authentication has a better chance than the same message with a broken DKIM signature or a return path that does not match the sender domain.
Minimal DMARC record for monitoringdns
Name: _dmarc.example.com Type: TXT Value: "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"
For a domain already sending important mail, I prefer to monitor before changing enforcement. Suped's DMARC monitoring shows which sources pass SPF and DKIM, whether they match the visible From domain, and which unapproved sources are sending as the domain. That gives you evidence before moving from p=none to stricter policy.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Check DKIM at the selector level, not only at the domain level. If an ESP signs with s1 today and s2 tomorrow, both selectors need valid DNS. Also confirm the signature domain matches the visible From domain or an organizational-domain match accepted by DMARC.
If the bounce explicitly mentions DKIM and you see failures in your reports, use DMARC monitoring to compare passing and failing sources over time. That is more reliable than checking one test email and assuming all production mail behaves the same.
Content isolation for spam or virus classification
When T-Online.de accepts one email and rejects another from the same sender, I treat the rejected email as a specimen. The goal is not to guess which word triggered a filter. The goal is to isolate the smallest change that flips the result.
- Baseline: Send a plain-text version with the same subject and sender.
- HTML: Add the HTML body without external images or tracking links.
- Links: Add destination links one at a time, including redirects and unsubscribe links.
- Assets: Add images, attachments, calendar files, and hosted assets last.
- Personalization: Test recipient-specific fields for malformed links, broken HTML, or bad fallback text.
Message elements to isolate
Use staged tests to find which part of the message changes the delivery result.
Low
Medium
High
Pay close attention to URL reputation. A clean sending IP does not protect a message that links to a compromised domain, new tracking hostname, unusual redirect chain, or distrusted file host. Also inspect rendered merge tags because broken personalization can create invalid URLs.
If you discover that only one campaign is rejected, do not keep resending the same failing content to many T-Online.de recipients. That can turn a content issue into a reputation issue. Pause the segment, test with controlled seed addresses, then resume only after the message changes.
Reputation and blocklist checks
A T-Online.de spam classification can still be influenced by IP and domain reputation. Check whether the sending IP, return-path domain, visible From domain, and tracking domains appear on a blocklist or blacklist. Also check whether complaint rates, recent list imports, inactive recipient volume, or sudden volume changes line up with the first rejection time.
Do not chase only one blocklist result
A single blocklist or blacklist listing is evidence, not a full diagnosis. Pair it with bounce timing, authentication results, campaign changes, complaint metrics, and ESP logs. If the listing is on a high-impact blocklist and the T-Online.de failure started at the same time, pause affected streams while you investigate.
Suped's blocklist monitoring is useful here because it keeps domain and IP reputation checks next to authentication monitoring. That matters when a deliverability problem crosses categories: a failing DKIM selector, a new tracking domain, and a blacklist event can all appear in the same week.
Blocklist checker
Check your domain or IP against 144 blocklists.
Spamhaus
0Spam
Cisco
NoSolicitado
URIBL
abuse.ro
ALPHANET
Anonmails
Ascams
BLOCKEDSERVERS
Calivent Networks
EFnet
JustSpam
Kempt.net
NordSpam
RV-SOFT Technology
Scientific Spam
Spamikaze
SpamRATS
SPFBL
Suomispam
System 5 Hosting
Team Cymru
Validity
www.blocklist.de Fail2Ban-Reporting Service
ZapBL
2stepback.dk
Fayntic Services
ORB UK
technoirc.org
TechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftIf you find a listing, fix the underlying cause before requesting removal. For marketing mail, that often means suppressing inactive addresses, removing old imports, stopping repeated retries to hard-bouncing recipients, and separating transactional traffic from higher-risk promotional campaigns.
When to contact T-Online.de postmaster
Contact the postmaster team after you have evidence they can use. A request with the sending IP, full SMTP response, exact timestamp, diagnostic IDs, recipient domain, Message-ID, and actions already taken is much stronger.
Postmaster escalation templatetext
Subject: T-Online.de 550 rejection review request Hello, We are seeing 550 rejections for mail from example.com to t-online.de. Sending IP: 203.0.113.10 MTA hostname: mta01.example.net Timestamp: 2026-05-27 09:26:49 UTC Message-ID: <sample-message-id@example.com> DKIM selector: s1 Visible From domain: example.com Full SMTP response: [paste unmodified response] Actions taken: - Confirmed SPF, DKIM, and DMARC domain match - Tested plain-text control message - Removed suspect URL and retested - Checked IP and domain blocklist status Please review whether this rejection is caused by a content classification, reputation issue, or authentication signal.
If the ESP can escalate through its receiver-relations or deliverability team, use that route in parallel. They can provide cleaner logs and explain MTA-level details.
For broader 550 diagnostics, it helps to compare this case with common SMTP 550 causes because not every 550 is a spam classification. Some are mailbox, policy, relay, or domain errors.
Views from the trenches
Best practices
Preserve raw bounce text before sharing tickets, because hidden tokens prevent log searches.
Test a plain control message first, then add template parts until the rejection returns.
Escalate through the ESP team that owns the MTA connection and outbound delivery logs.
Common pitfalls
Treating every 550 as an IP block can miss a template, URL, or attachment problem.
Sending anonymized bounces to postmasters removes the data needed for diagnosis.
Retrying rejected campaigns too widely can make a narrow content issue affect reputation.
Expert tips
Ask for the MTA transcript, Message-ID, sending IP, DKIM selector, and exact UTC time.
Compare passing and failing variants using the same domain, IP pool, and recipient domain.
Pair blocklist checks with DMARC reports so reputation and authentication stay connected.
Marketer from Email Geeks says T-Online.de cannot use a bounce that has had diagnostic tokens, IP data, and normal error text replaced with placeholders.
2025-05-02 - Email Geeks
Marketer from Email Geeks says a spam or virus classification that affects one template but not another points to content before an IP-wide block.
2025-05-02 - Email Geeks
The practical fix path
For T-Online.de 550 errors, I would not start by asking for a generic unblock. I would start by proving what changed. Get the raw bounce, test a plain message, isolate the failing content, then verify SPF, DKIM, DMARC, IP reputation, and sending logs. If a clean control message lands, focus on the campaign. If all mail fails, focus on infrastructure and reputation.
Suped is our product, and for most teams it is the best overall DMARC platform for this workflow because it keeps DMARC monitoring, hosted SPF, SPF flattening, hosted MTA-STS, blocklist monitoring, and deliverability alerts in one place. It does not replace the ESP's raw SMTP transcript, but it gives you the authentication and reputation context needed to decide whether the problem is your domain setup, sending infrastructure, or message content.
The cleanest resolution usually comes from pairing both sides: Suped for ongoing visibility and issue detection, plus the ESP's deliverability team for MTA-level evidence and receiver escalation.
