DKIM's `t=y` Flag: Why Your Test Record Is a Production Threat

You’re staring at an email header that makes no sense. The message is a blatant phish, a textbook BEC attempt complete with fake urgency from the 'CFO'. Your gut says it’s garbage. But the Authentication-Results header says `dkim=pass`. How?

It’s a scenario that trips up even seasoned analysts. The message sailed past basic checks because the signature was technically valid. The sender exploited a subtle, often-forgotten component of the DKIM standard: the test mode flag.

That little `t=y` in a DNS record, likely left behind years ago during a mail platform migration, isn't just a leftover comment. It’s a declaration to the world’s mail servers that you’re not confident in your own signing. And attackers have learned to use that declaration against you.

Reading the RFC: A Flag for Benign Testing

The test flag was born from good intentions. RFC 6376, the standard that defines DomainKeys Identified Mail, needed a way for administrators to roll out DKIM without immediately breaking email delivery. Misconfiguring a cryptographic signature is easy. A wrong key, an aggressive MTA rewriting a message body, or a simple typo could invalidate every signature, causing legitimate mail to be junked or rejected.

The `t=y` flag was the proposed safety valve. By adding it to your public key record in DNS, you signal to receiving mail servers: 'This domain is in testing mode.' The RFC suggests that receivers should not treat messages with invalid signatures from a testing-domain any differently than they would if the domain weren't signed at all. The operational stake is that it prevents self-inflicted delivery pain during a complicated rollout.

The `t=y` tag is for domains that are not yet ready to fully deploy DKIM. Verifiers MAY wish to treat messages from domains in testing mode differently from other messages. — RFC 6376, Section 3.1

Note the word 'MAY'. That's the crux of the problem. There is no mandatory behavior. A receiver can see the test flag and choose to ignore any DKIM failures. But what about a DKIM pass? To the receiver, a valid signature is a valid signature. The test flag adds a layer of non-binding context that most mail gateways aren't equipped to interpret with nuance. They see `dkim=pass`, and that signal carries weight, regardless of the testing disclaimer.

An Attacker's View: Turning a Test Into a Weapon

A threat actor views a `t=y` record not as a test, but as an opportunity. It provides a path to bypass a critical layer of anti-spoofing defense. Instead of trying to fool a user with a lookalike domain (like `micros0ft.com`), they can send their malicious payload from your *actual* domain, armed with a signature your own infrastructure trusts.

The 'Authenticated Spoof'

The most damaging vector doesn't even involve replaying old messages. Imagine an attacker compromises a tangentially related asset, like a WordPress server with a poorly configured mail plugin. Normally, emails sent from this server would fail DMARC checks because its IP isn't in your SPF record, and it can't generate a valid DKIM signature. But if the attacker discovers a DKIM selector with `t=y` enabled, they have a new plan. They can use the corresponding private key (if it’s also compromised) or find a legitimate but low-security service that uses that key, to sign their *own* malicious emails.

The receiving mail server gets the email. It checks the DNS record, finds the public key, and validates the signature. It passes. The `Authentication-Results` header will note the test mode, but for many inbound filters, `dkim=pass` is a strong positive signal that can outweigh a failing SPF. The presence of a DMARC policy with `p=quarantine` or `p=reject` might be negated because the DKIM check passed and was aligned. The phish lands in the inbox.

Misleading Forensic Signals

For a SOC analyst, this is a nightmare. The headers tell a conflicting story. The `Received` chain shows the email originated from a suspicious IP, but the cryptographic signature says it’s authentic. This confusion delays incident response. Is it a compromised user account? A misconfigured forwarder? Or is it a sophisticated attacker who understands email authentication better than the team that configured it?

Audit Playbook: Hunting for Forgotten Test Flags

You can't fix what you can't find. Forgotten `t=y` records are common because DKIM selectors are not centrally registered; a single domain can have dozens spread across different services, each with its own TXT record. Auditing requires diligence.

The Selector Discovery Problem

First, you need to know which selectors to check. There is no command to list all selectors for a domain. You have to find them. The best source is your DMARC aggregate (rua) reports. These XML files contain data on every message claiming to be from your domain, including the DKIM selector used, if any. Parsing these reports will give you a comprehensive list of selectors seen in the wild.

Other sources include digging through your own sent items to inspect headers, checking documentation from every third-party service that sends email on your behalf (think Salesforce, Marketo, Zendesk), and looking at your internal DNS zones for any records matching the `_domainkey` format.

Manual DNS Interrogation

Once you have a list of potential selectors, you query DNS for each one. The tool of choice is `dig` (or `nslookup` on Windows). You are looking for a TXT record for the hostname `selector._domainkey.yourdomain.com`.

$ dig +short txt s2048._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...; t=y;"

The command above queries the TXT record for the selector `s2048`. The output is exactly what we're looking for: a standard DKIM record, but with `t=y;` appended. This is a live, exploitable misconfiguration. Systematically check every selector you discovered. Any that return a record containing `t=y` goes on your remediation list.

Safe Remediation: Excising the Flag without Breaking Mailflow

Finding the problem is half the battle. Removing the flag without causing an outage is the other half. Rushing to delete the `t=y` tag from a record that corresponds to a broken signing process will turn a potential vulnerability into a guaranteed delivery failure.

Step 1: Verify Signing Health

Before you touch DNS, go back to your DMARC reports. For each selector flagged with `t=y`, you need to answer one question: are messages using this selector consistently passing DKIM authentication? Your aggregate reports should show you the volume and pass/fail percentage for that specific selector. If nearly 100% of the legitimate mail using that selector is resulting in a DKIM pass, you are safe to proceed. If the pass rate is low, you have a different fire to fight. Removing the test flag will just enforce the failures. You need to fix the underlying signing mechanism first.

Step 2: The DNS Edit

The actual fix is deceptively simple. Navigate to your DNS provider's management console. Find the TXT record for the offending selector. Edit the record's value and remove the `t=y;` component. Do not change anything else—not the version, not the key type, and definitely not the public key itself. Save the change.

That's it. You have now promoted your DKIM key from 'testing' to 'production'. You are making a definitive statement that a valid signature from this selector should be trusted, and by extension, an invalid one should be viewed with suspicion.

Step 3: Monitor and Confirm

After the DNS record's Time-To-Live (TTL) expires, use `dig` again to confirm the `t=y` flag is gone from the public record. For the next few days, keep a close eye on your DMARC reports. You're looking for two things: that DKIM pass rates for that selector remain high, and that you haven't introduced any new, unexpected failures. If mailflow remains healthy, the remediation was a success.

From 'Test' to 'Trusted'

The `t=y` flag is a perfect example of a well-intentioned feature creating a long-tail security risk. It serves a legitimate, temporary purpose during initial setup. But when 'temporary' stretches into years, it becomes a permanent liability. An attacker only needs to find one forgotten test record to undermine your entire email authentication posture.

This isn't an indictment of the RFC, but a commentary on operational reality. Security isn't just about deploying controls; it's about maintaining them. DNS hygiene is not a one-time project. It's a continuous process of auditing, validating, and cleaning up the digital debris left behind by platform migrations, decommissioned services, and temporary test configurations.

Every TXT record in your public DNS is a piece of your attack surface. Treat each one as a policy statement being read by both your partners and your adversaries. Make sure it's saying what you think it's saying. Continuous scanning for this and other DNS-based security misconfigurations is crucial, whether you build your own tooling or use a platform like MailSleuth.AI to automate discovery and alerting.

The takeaway

Don't assume 'test' means 'harmless.' In the world of security, anything exposed to the internet is in production. Your task is to find those forgotten test flags before an attacker does and uses them to sign a phishing email so convincing, it even fools your own mail filters.