Troubleshooting 5.1.9 DKIM rejection errors from t-online.de
A 5.1.9 (DKIM reject DKIMr) Missing, invalid or non-matching DKIM signature bounce from t-online.de means its inbound mail system rejected the message because DKIM was absent, failed validation, or did not match what the receiver expected at the end of SMTP DATA. I treat it as a DKIM verification failure first, not as a DMARC policy change first.
The fastest path is to prove four things in order: the outbound platform is signing the message, the selector exists in public DNS, the signed message is not changed after signing, and the signing domain matches the visible From domain closely enough for the receiver path you are testing. If those pass and only t-online.de rejects sporadically across unrelated IPs, domains, and content, collect evidence and escalate it as a receiver-specific or provider-specific issue.
What the 5.1.9 DKIMr error means
The important part of the bounce is not only 5.1.9. It is the phrase DKIM reject DKIMr, because that tells you the rejection happened during DKIM evaluation. In real bounces this often appears as a 559 reply from a t-online.de MX, sometimes wrapped by the sending system as 554 5.1.9.
Typical bounce fragmenttxt
host mx03.t-online.de said: 559 5.1.9 (DKIM reject DKIMr) Missing, invalid or non-matching DKIM signature (in reply to end of DATA command)
That timing matters. A rejection at the end of DATA means t-online.de accepted the SMTP conversation far enough to inspect the message content and headers. The failure is therefore downstream of simple connection acceptance. I still check IP reputation and blocklist (blacklist) status when there are mixed symptoms, but this specific error text points back to the DKIM signature path.
For provider escalation, use the t-online postmaster route and include the full diagnostic code, UTC timestamp, sender domain, recipient domain, message ID, DKIM selector, and the public DNS answer you saw at the time of failure.
Flowchart showing the DKIM rejection path from bounce review to escalation.
Do not change everything at once
When a single mailbox provider rejects and others accept, changing SPF, DKIM, DMARC, content, and routing in one pass removes the evidence you need. I make one change at a time, send a controlled test, and keep the full raw message for comparison.
- Keep samples: Save the rejection notice, the raw sent message, and any accepted copy.
- Change one variable: Test domain matching, content, and selector changes separately.
- Record timestamps: Use UTC timestamps so the sender and receiver can compare logs.
Most likely causes
The error text covers several different faults. Missing DKIM is simple: no DKIM-Signature header reached t-online.de. Invalid DKIM means the signature header exists, but the public key lookup, header hash, or body hash did not verify. Non-matching DKIM usually means the signature is for a domain that does not satisfy the domain relationship expected by the receiver or by DMARC evaluation.
|
|
|
|---|---|---|
No signature | No DKIM header | Enable signing |
Bad selector | DNS returns NXDOMAIN | Publish key |
Key mismatch | Hash fails | Rotate key |
Body changed | Body hash fails | Sign last |
DNS timeout | Intermittent | Fix DNS |
Common causes to test before escalation
The harder case is sporadic failure. If the same platform, selector, and content produce a pass at one receiver and a 5.1.9 reject at t-online.de, I stop treating the bounce as a single DNS typo. I look for lookup timeouts, message mutation after signing, a receiver-specific domain matching rule, or a temporary fault inside the receiver's DKIM checking.
Local signing fault
- Repeatable result: The same sender fails DKIM at several mailbox providers.
- Clear DNS defect: The selector is missing, malformed, or split incorrectly.
- Message mutation: A gateway, footer, or transfer step changes the signed body.
Receiver-specific pattern
- Narrow failure: Only t-online.de rejects while other receivers pass DKIM.
- No stable pattern: Failures do not group by IP, domain, message size, or content.
- Clean retest: A second sample passes with the same selector and routing.
Historical public cases, including an OVH community case, show this exact t-online.de rejection wording in situations where DKIM was missing or not accepted for that route. That does not prove the cause for every current incident, but it makes DKIM presence and public key verification the right first checks.
A practical troubleshooting sequence
I start with the bounce, not the DNS zone. The bounce tells me the MX host, the exact SMTP status, and whether the rejection happens at connection time, RCPT time, or after DATA. For this error, the after-DATA position is the clue that the message was parsed and then rejected.
- Confirm the signature: Open the raw sent message and check that a DKIM-Signature header exists.
- Read the selector: Find s= and d= in the DKIM header and write them down exactly.
- Query public DNS: Look up selector._domainkey.domain and confirm that the public key is visible.
- Verify the sample: Run the same raw message through a DKIM validation path and compare the result.
- Test routing changes: Send a minimal text message, then the normal HTML version, without changing DNS.
- Escalate with proof: Send evidence only after you can show what passed and what failed.
For the DNS check, the record should exist at the selector hostname used by the DKIM-Signature header. The signing domain in d= controls the lookup name, not the visible From header by itself.
DKIM DNS shapetxt
Name: selector1._domainkey.example.com Type: TXT Value: v=DKIM1; k=rsa; p=<public-key-from-mail-platform>
If you need a focused record check, use the DKIM checker after you identify the selector. For a wider pass across SPF, DKIM, and DMARC, run a domain health check so you do not miss a separate DNS or policy problem that sits beside the DKIM failure.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
A valid DKIM DNS record is not enough if the message changes after signing. Common mutation points include link wrapping, appended legal footers, mailing list footers, security appliances, outbound relays, and software that rewrites MIME boundaries. The body hash in the DKIM header is calculated before delivery, so later body changes make a good key look bad.
I also check key size and formatting. A TXT record split incorrectly by a DNS host, a missing quote boundary, or an old selector left behind after rotation creates intermittent-looking failures when different senders use different selectors.
Evidence bundle for escalation
- Bounce data: Remote MX, SMTP status, diagnostic text, queue ID, and UTC time.
- Message data: Raw headers, DKIM selector, signing domain, Message-ID, and size.
- DNS data: Public TXT answer, resolver used, TTL, and lookup timestamp.
- Control sample: Accepted copy sent near the same time through the same route.
Testing strict domain matching
Some senders respond to this error by making the DKIM signing domain exactly match the visible From domain. That is a useful diagnostic, especially when a support team asks for it. It is not proof that t-online.de has a universal public rule requiring exact domain matching in every case.
I run the test anyway because it removes a variable. Send one message with relaxed domain relationship, then one with the DKIM d= value exactly matching the From domain. Keep the same IP, selector strength, content, and recipient. If exact matching fixes the t-online.de path and nothing else changed, you have a practical workaround even before you have a formal policy statement.
Confidence bands for root cause
Use the amount of repeated evidence to decide whether to change DNS, change routing, or escalate.
Low confidence
1 sample
One reject with no raw message and no DNS lookup record.
Medium confidence
3-5 samples
Multiple rejects from one route with selector and DNS evidence.
High confidence
A/B proof
Controlled pass and fail samples with only one changed variable.
If you administer Google Workspace, the Google DKIM guide is useful for confirming whether DKIM is active, whether the TXT value is present, and whether the service has started signing. The same principle applies to any sender: do not assume DKIM is active just because a DNS record exists.
Controlled test matrixtxt
Test A: From example.com, DKIM d=mailer.example.net Test B: From example.com, DKIM d=example.com Keep: IP, content, recipient, sender platform, and send time window
If both tests fail, the issue is not only domain matching. Go back to public key lookup, body hash verification, and message mutation. If only Test A fails, exact domain matching is a strong workaround for this route.
When the evidence points at t-online.de
After local checks pass, the remaining task is evidence quality. A provider cannot debug a receiver's private DKIM verification engine directly, and t-online.de cannot act on a vague statement that DKIM works elsewhere. The useful middle ground is a clean packet of proof: the same sender signs correctly, public DNS answers correctly, other receivers pass, and t-online.de rejects with DKIMr wording.
There is a common trap here: assuming that a sporadic, receiver-specific DKIM rejection has one permanent cause. It can come from a real sender-side issue that only one receiver catches, or it can come from intermittent DNS or receiver-side verification behavior. That is why I separate the mechanical checks from the escalation checks.
Fix locally
Use this path when your evidence shows a real defect under your control.
- Selector defect: Publish the active selector and remove stale references.
- Body hash defect: Move DKIM signing after all content rewriting.
- Domain mismatch: Sign with the same domain used in the visible From address.
Escalate outward
Use this path when controlled samples prove the sender path is sound.
- Receiver-only fail: Only t-online.de rejects the signed sample.
- No route pattern: Failures do not group by sender IP, domain, or content.
- Proof ready: You can provide raw samples and DNS evidence.
For broader context on receiver-specific DKIM behavior, keep a separate runbook for ISP-specific DKIM failures. The same method applies: isolate the exact receiver, prove the signature path, then test one variable at a time.
Where Suped fits
Suped is the strongest practical DMARC platform for most teams dealing with this type of issue because it gives you one place to monitor DMARC, SPF, DKIM, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, blocklist and blacklist status, and deliverability signals. The value during a t-online.de DKIM incident is not only seeing that something failed. It is seeing which source failed, which domains are affected, and what to fix next.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
In Suped's DMARC monitoring workflow, I would track whether the same source is producing DKIM failures at multiple receivers or whether the pattern is concentrated around t-online.de. That distinction changes the next move. A broad DKIM failure means fix signing. A t-online.de-only failure means preserve evidence and run controlled tests.
- Automated detection: Suped identifies authentication issues and gives concrete fix steps.
- Real-time alerts: Teams get notified when DKIM or DMARC failure rates move sharply.
- Hosted controls: Hosted DMARC, SPF, and MTA-STS reduce DNS access delays.
- MSP scale: Agencies can manage many client domains from one dashboard.
Views from the trenches
Best practices
Keep one saved copy of the full bounce, headers, and raw signed message for each rejection.
Test with a simple body and a normal HTML body before changing any production DNS records.
Compare passing and rejected samples by selector, signing domain, sending IP, and size.
Escalate with timestamps, queue IDs, recipient MX, DKIM result, and DNS lookup results.
Common pitfalls
Changing DMARC policy first can hide the DKIM fault instead of proving the actual cause.
Assuming every 5.1.9 reject has the same cause wastes time across mixed senders fast.
Publishing a new DKIM key without confirming the active selector leaves old mail failing.
Testing only one t-online.de mailbox gives a weak signal when failures are intermittent.
Expert tips
Run a strict From-domain match test as a diagnostic, not as proof of t-online policy.
Check DNS from several resolvers so intermittent public-key lookup failure becomes visible.
Send one untouched raw sample through the same path to catch body hash changes clearly.
Separate missing signature rejects from invalid signature rejects in your tracking sheet.
Marketer from Email Geeks says the error appeared sporadically across a sending network, with no stable pattern by IP, domain, or content.
2025-07-03 - Email Geeks
Marketer from Email Geeks says transient DNS lookup failure can make a valid DKIM signature look missing or invalid to one receiver.
2025-07-04 - Email Geeks
What to do next
For a t-online.de 5.1.9 DKIMr rejection, the right answer is not to guess at reputation or rewrite your full authentication setup. Prove the signature exists, prove the selector resolves, prove the signed content stays unchanged, then test exact From-domain matching as a controlled diagnostic.
If the issue is local, fix the selector, key, signing point, or domain match. If the issue remains isolated to t-online.de after clean tests, send a concise evidence bundle through your sending provider and the t-online.de postmaster path. Suped helps keep that workflow practical because it turns scattered authentication reports into source-level issues, alerts, and fix steps.
