Troubleshooting 5.1.9 DKIM rejection errors from t-online.de
Updated on 14 Oct 2026: We clarified DKIM domain matching and added verification results and DNS checks for t-online.de rejections.
A 5.1.9 (DKIM reject DKIMr) Missing, invalid or non-matching DKIM signature bounce from t-online.de means its inbound system rejected the message because DKIM was missing, failed verification, or did not satisfy its domain-matching check. Investigate DKIM signing, verification, and the signing domain before changing DMARC policy.
The fastest path is to prove four things in order: the outbound platform signed the message, the selector resolves to the correct public DNS key, the signed content still verifies after the final relay, and the DKIM d= domain has the expected relationship to the domain in the visible From address. If those checks pass and t-online.de still rejects sporadically, preserve the samples and escalate with complete SMTP and DNS evidence.
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 identifies DKIM evaluation as the reason for rejection. The remote reply often appears as 559 5.1.9 from a t-online.de MX, although a sending system can wrap it 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)
A rejection at the end of DATA means t-online.de received the message headers and body before declining delivery. Earlier acceptance of the recipient during SMTP did not mean the message was accepted. Check IP reputation and blocklist (blacklist) status when the bounce contains mixed symptoms, but this diagnostic text points first to DKIM verification and the signing domain. A 5xx reply is a permanent rejection for that attempt: correct the cause before resending. This authentication error does not establish that the recipient address is invalid.
For escalation, use the t-online.de postmaster route and include the full diagnostic code, UTC timestamp, sending IP, sender domain, recipient domain, Message-ID, DKIM selector, and public DNS answer captured at the time of failure. Its published contact guidance lists postmaster@t-online.de, or postmaster@rx.t-online.de when the sending system is blocked.
Flowchart for diagnosing a t-online.de 5.1.9 DKIMr rejection through signature, DNS key, body hash, and domain checks.
Do not change everything at once
Changing authentication, content, and routing in one pass removes the evidence needed to identify the cause. Make one change at a time, send a controlled test, and keep the full raw message for comparison.
- Save the rejection notice, raw sent message, and any accepted control copy.
- Test the signing domain, selector, message content, and route as separate variables.
- Record UTC timestamps so both sides can compare the correct log entries.
Most likely causes
The error covers several faults. Missing DKIM means no DKIM-Signature header reached t-online.de. Invalid DKIM means a signature exists, but the public key lookup, signed-header hash, or body hash did not verify. For non-matching DKIM, compare the d= signing domain with the visible From domain and check which signature actually verified. A subdomain difference alone does not establish the cause.
|
|
|
|---|---|---|
No signature | No DKIM-Signature header | Enable DKIM on the actual sending route |
Bad selector | NXDOMAIN or no TXT answer at the active selector | Publish the active key |
Key mismatch | Signature verification fails | Publish the matching public key |
Body changed | Body hash does not verify | Sign after all rewriting |
Signed header changed | Body hash passes, signature fails | Check the h= headers and signing key |
Signing domain mismatch | Valid DKIM with an unexpected d= domain | Check the domain relationship; test exact matching |
Truncated TXT key | Public p= value is incomplete | Republish every key character in order |
DNS lookup failure | SERVFAIL or a resolver timeout | Check authoritative DNS and resolver access |
Duplicate selector keys | Multiple DKIM key TXT records at one name | Publish one key TXT record for that selector |
Common causes to test before escalation
A repeated failure with the same From domain and DKIM subdomain warrants a controlled domain test after signature verification. Compare public DNS responses, message mutation, active selectors, and accepted control samples before attributing the rejection to the receiver.
For WordPress notifications, PHP mail, and cron jobs, check the application's actual submission path. These messages can bypass the route used by regular mailbox mail. Configure the application or its outbound relay to use a DKIM-enabled route for the intended From domain.
Local signing fault
- The same sender fails DKIM at several mailbox providers.
- The selector is missing, malformed, truncated, or published under the wrong name.
- A gateway, footer, or relay changes signed content before delivery.
t-online.de-specific pattern
- Other receivers report a valid signature for the same sending stream.
- Compare the verified DKIM d= domain with the visible From domain.
- An exact-match control passes while the original domain test fails on the same route.
Troubleshoot the DKIM signature and DNS record
Start with the bounce rather than the DNS zone. The bounce identifies the remote MX, exact SMTP status, and rejection stage. An after-DATA rejection shows that the receiver parsed the message before returning the DKIMr error.
- Capture the raw message after outbound signing and the final relay, and confirm that a DKIM-Signature header exists. A Sent folder copy is not reliable evidence of the final transmitted message.
- For every DKIM-Signature header, copy the s= selector and d= signing domain exactly as shown.
- Query selector._domainkey.signing-domain in public DNS and confirm the full public key resolves, including any CNAME target.
- Verify the saved raw message and record the result for each signature, including body hash and signed-header failures.
- Compare the verified DKIM d= domain with the domain after @ in the visible From address. Record whether they match exactly or share an organizational domain.
- If a valid signature still receives DKIMr, test a signature with d= identical to the visible From domain while keeping the IP, content, recipient, and key strength constant.
- Escalate after resolving local verification and DNS faults, attaching the controlled domain-test results even if t-online.de accepts neither sample.
The selector record exists under the signing domain named in the DKIM-Signature header. For s=selector1 and d=example.com, query selector1._domainkey.example.com.
DKIM DNS shapetxt
Name: selector1._domainkey.example.com Type: TXT Value: v=DKIM1; k=rsa; p=<public-key-from-mail-platform>
Query the selector used in the signaturebash
dig selector1._domainkey.example.com TXT dig selector1._domainkey.example.com CNAME
Replace selector1 and example.com with the signature's s= and d= values. If the sender supplies a CNAME, publish the supplied target and confirm that its TXT key resolves. NXDOMAIN means the queried name does not exist; NOERROR with no TXT answer means no key was returned; SERVFAIL or a timeout is a DNS resolution failure. Compare authoritative DNS with recursive answers and record the TTL. Cached old keys and cached missing-record answers persist until their cache lifetimes expire.
Use Suped's DKIM checker after identifying the selector to inspect the published DNS key. A broader domain health check can reveal a separate DNS or policy fault beside the DKIM rejection. A DNS lookup does not verify the signature on a particular message.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
A valid DNS key does not help when signed content changes beyond the signature's canonicalization rules. Link rewriting, appended legal footers, mailing-list changes, security gateways, outbound relays, and MIME-boundary rewrites can invalidate the body hash or a signed header. Apply DKIM after the final outbound content-rewriting step. Simple forwarding that preserves signed content preserves DKIM; a forwarding route that rewrites content requires separate testing.
Check key length and TXT formatting as well. A 2048-bit RSA key often spans more than one DNS TXT character-string. Splitting it into quoted strings is valid when the strings remain in one TXT record and concatenate in order without added spaces. Publish one DKIM key TXT record per selector. Compare the complete public p= value with the value issued by the signing platform, and keep the previous selector published until old signed mail has cleared its delivery window.
Evidence bundle for escalation
- Remote MX, SMTP status, diagnostic text, queue ID, and UTC timestamp.
- Raw post-signing message, visible From domain, every DKIM selector and signing domain, Message-ID, and message size.
- Public TXT/CNAME answers, resolver used, TTL, and lookup timestamp.
- Domain-test results and any accepted control sample sent through the same route.
Read the DKIM verification results
A DKIM-Signature header proves that signing was attempted. A DKIM_SIGNED result does not establish verification; DKIM_INVALID indicates a verification fault. Use the raw message and Authentication-Results added by a trusted receiving system to identify the failing check. Match header.d and header.s to each signature. The result meanings are defined in RFC 8601.
- dkim=none: no signature was available for evaluation; inspect the actual outbound route.
- dkim=fail: inspect the reported reason, especially a body hash mismatch or signature verification failure.
- dkim=temperror: investigate temporary DNS lookup failures and resolver timeouts.
- dkim=permerror: inspect permanent evaluation faults, such as malformed signature or key data.
The bh= tag is the body hash; h= lists the signed headers, including From; c= defines header and body canonicalization. If the body hash passes but the signature fails, inspect the signed headers and key. Under RFC 6376, relaxed canonicalization tolerates specified whitespace and header folding changes, while simple header canonicalization requires exact preservation.
Evaluate multiple signatures separately. A passing relay signature with an unrelated d= domain does not establish DMARC DKIM alignment for the visible From domain. For RSA signing, RFC 8301 requires rsa-sha256, prohibits rsa-sha1, and recommends keys of at least 2048 bits; RSA keys shorter than 1024 bits are invalid.
Test the DKIM signing domain
Compare the DKIM signing domain with the visible From domain when a valid signature still receives DKIMr. A message with From: sender@example.com and d=news.example.com can pass cryptographic DKIM verification and relaxed DMARC DKIM alignment. Test an exact-match signature to determine whether domain matching contributes to the rejection on the affected route.
DKIM verification does not require the signing domain to equal the visible From domain. DMARC passes when at least one successful SPF or DKIM result has the required domain alignment. The DKIMr diagnostic alone does not establish a universal strict-domain requirement at t-online.de.
Changing adkim is not the fix
Setting adkim=s in the DMARC record declares strict DKIM alignment for DMARC evaluation. It does not change the domain placed in the outgoing DKIM d= tag. Change the sender's signing configuration when a controlled test identifies a domain-matching fault.
Controlled domain testtxt
Test A: From sender@example.com, DKIM d=news.example.com Test B: From sender@example.com, DKIM d=example.com Verify each signature and its selector key before sending. Keep constant: sending IP, content, recipient, key strength, and send window
If Test A fails and Test B passes, keep exact matching for that mail stream and record the result. If both fail, inspect public key lookup, body hash verification, signed-header changes, and selector rotation before escalating.
Choose an exact-match sending design
Exact domain matching affects the address recipients see and the DNS zone that holds each DKIM selector. Choose the sending identity before changing selectors so each outbound source uses a stable From domain and matching signature.
|
|
|
|
|---|---|---|---|
Organizational domain | sender@example.com | example.com | Every sender publishes its own selector under example.com |
Dedicated subdomain | sender@news.example.com | news.example.com | The mail stream uses its own From domain and DKIM selectors |
Two designs for an exact-match domain test
For an exact-match design, a dedicated subdomain appears in both places. Signing sender@example.com with d=news.example.com does not produce an exact match. Either sign with d=example.com or change the visible address to use @news.example.com.
- Inventory every application and vendor that sends with the domain.
- Assign a unique selector to each sender while keeping d= identical to the visible From domain.
- Test transactional and marketing streams separately before changing production traffic.
- Keep old selectors available during rotation until delayed messages can no longer reference them.
When to contact t-online.de support
Escalation starts after local cryptographic verification and public DNS checks pass. The useful evidence shows that the same sender, selector, and route pass elsewhere while t-online.de rejects with DKIMr wording, and includes the exact-match test results. A statement that DKIM works elsewhere is not enough when a different route or signature was tested.
A sporadic reject can still result from DNS resolution, an inconsistent outbound pool, or message changes on one route. Compare the failing sample with an accepted sample byte by byte where practical, interpret differences under the signature's canonicalization rules, and record which selector and outbound host handled each message.
Fix locally
Use this path when the evidence shows a defect under the sender's control.
- Publish the active selector and retain old keys through the rotation window.
- Move DKIM signing after every content-rewriting step.
- Correct the DKIM signing domain when controlled tests identify a domain-matching fault.
Escalate outward
Use this path when post-signing verification and controlled tests establish the sender's evidence.
- Only t-online.de rejects the verified sample, including the exact-match domain test.
- Failures do not group by sending IP, selector, route, or content.
- The evidence bundle contains raw samples and timestamped DNS answers.
Fix a local selector, key, signing point, or demonstrated domain mismatch first. If verified messages still fail only at t-online.de, send the evidence bundle through the sending provider and the linked postmaster route before resuming normal sending.
Monitor DKIM failures with Suped
Suped is our DMARC reporting and email authentication platform. During a t-online.de incident, Suped's product helps compare DKIM results by sending source and From domain, monitor failure-rate changes, and keep authentication fixes attached to the affected source. Aggregate DMARC reports from participating receivers provide supporting authentication data; SMTP logs supply the full 5.1.9 diagnostic text and recipient-specific rejection evidence.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Use Suped's DMARC monitoring workflow to check for a broad signing failure, then compare that evidence with t-online.de SMTP bounces. A broad DKIM failure calls for a sender or DNS fix. A receiver-only failure after local verification calls for preserved bounce evidence and a controlled retest. Missing reports or a DMARC pass do not prove t-online.de accepted the message.
- Compare DKIM pass and fail rates for each authorized sending source.
- Review authentication changes against the time the 5.1.9 rejects began.
- Use issue guidance to correct selector, DNS, or domain-matching faults.
- Keep SMTP bounce samples beside source-level DMARC evidence for escalation.
Frequently asked questions
No. The record can be missing, truncated, or wrong, but the error also covers a changed message or a domain-matching fault. Check the raw signature, selector, public key, and the verified signing domain.
The DKIMr bounce alone does not establish a universal strict-matching rule. A signature with d=news.example.com and From sender@example.com can pass relaxed DMARC DKIM alignment. Test an exact-match signature on the affected route after confirming cryptographic verification.
No. The adkim tag changes DMARC DKIM alignment evaluation. It does not change the d= value used by the signing system. Fix the sender's signing configuration when controlled tests identify a signing-domain fault.
No. A DMARC policy change does not repair a missing signature, bad selector, key mismatch, body hash failure, or domain-matching fault. Even a DMARC pass through SPF does not repair failed DKIM or override a receiver's local rejection policy.
Receivers use different local policies and DNS resolvers, and tests sent on different routes do not prove that the rejected copy had the same signature. Compare the final raw messages and selector answers, then test exact domain matching if DKIM verification already passes.
Send the full bounce, UTC timestamp, remote MX, sending IP, Message-ID, visible From domain, every DKIM selector and signing domain, public TXT/CNAME answers, the raw post-signing message, domain-test results, and any accepted control sample.
