DKIM t=y and s flags explained

What does DKIM t=y testing mode actually do?

You've seen a DKIM signature with t=y in the header and wondered: is this real or just a test? If your emails are failing to pass DKIM checks, and you're tweaking your setup, you're probably working in testing mode.

The t=y flag isn't a bug — it's a deliberate signal. It tells receiving servers: "This DKIM signature is part of a test, not a production validation." It's like showing a driver's license photo during a practice driving session. Legitimate, but not enforceable.

When t=y is present, the server validates the signature's syntax and structure, but doesn't treat it as definitive proof of authenticity. This allows senders to test configuration changes without risking deliverability.

Key takeaways

DKIM t=y signals that a signature is part of a test, not a live validation.
Receiving servers accept the signature for testing but don't enforce it as proof of sender authenticity.
Use t=y during DKIM configuration or troubleshooting to verify syntax without affecting production deliverability.

Why does an email with DKIM t=y fail to deliver?

You’re sending an email with DKIM t=y — but it fails to deliver because that flag signals a test signature, and many mail servers treat it as a red flag. Even if the cryptographic key is valid, the presence of t=y often triggers rejection or spam filtering, especially if no formal DKIM policy allows test signatures for your domain. It’s not just a technical detail — it's a deliverability risk.

DKIM t=y is a signal — not a feature

The t=y tag in DKIM signatures is meant for testing only. It tells the receiving server: "This signature is not meant for production use." But most mail systems see that signal as a sign of incomplete or misconfigured setup, especially if no DMARC policy explicitly permits test records. You can’t just leave t=y in place after testing and expect consistent delivery.

Spam filters and inbox providers use signature behavior to assess sender reliability. A persistent t=y flag suggests the sender hasn’t finished their configuration or lacks proper authorization. This can trigger automated rejection — some providers block messages with test signatures outright. Even if the key is valid, the server may not trust the domain’s intent to send reliably.

How to avoid delivery failure

Once you're done testing, always remove the t=y flag from your DKIM signature. If your domain doesn’t have a DMARC policy that allows test signatures (which you can verify using a standard tool like MxToolbox), then t=y is treated as invalid. Even trusted senders using t=y in their testing phase may see their messages marked as suspicious.

Let’s be clear: DKIM signatures with t=y should never go live in production email streams. The flag may be useful in development, but it undermines trust at scale. If you’re unsure whether your setup is properly configured, use an email verification tool to test your outgoing mail. Tools like MailTester’s inbox placement tester can help you confirm whether messages are reaching inboxes — and detect where delivery fails due to configuration issues like test signatures. Always verify the full chain: SPF, DKIM, DMARC, and the presence of any test flags.

What role does the s flag play in DKIM testing?

The s flag in DKIM specifies the signing domain, which must match the domain in the DKIM-Signature header for verification to succeed. If s is missing or set incorrectly—say, to a non-existent or mismatched domain—the signature fails, even if the cryptographic key is valid. This is especially important in testing, where you might use a non-production domain like test.example.com to validate alignment without affecting your main sending domain.

Why the `s` flag matters in real-world testing

During DKIM testing, the s flag helps isolate and validate alignment between the signing domain and the From address domain—critical for inbox placement. If your test setup omits s or sets it to a different domain than the one in the signature, the verifier will reject the signature, creating a false negative. This is common when testing email flows across multiple domains, such as in agency or partner campaigns.

Let’s say you're testing a newsletter that sends from [email protected], but signs with mailing.example.com. In that case, s=mailing.example.com must be set correctly in the DKIM header. If it's not, the verification will fail regardless of the key’s validity. The s flag ensures the verifier knows which domain is responsible for the signature.

How to test DKIM with the `s` flag safely

You can use a test domain—like test.example.com—in the s flag to simulate real DKIM behavior without impacting production. This is common in development workflows or when using tools like MailTester’s inbox placement tester to validate deliverability across inboxes. The tool checks alignment, signature integrity, and header structure, including the s flag’s consistency across the chain.

Without a proper s value, even a correctly signed email will be rejected by strict DMARC policies. This is why RFC 6376, the core DKIM specification, requires s as part of a valid signature. You can review the full specification at IETF RFC 6376.

When testing via API or bulk tools, ensure your test data includes proper s values. Tools like MailTester’s verification API will flag misconfigured DKIM signatures in real time, helping you catch issues before they hurt sender reputation.

How do you know if your DKIM setup is truly valid?

You can confirm your DKIM setup is valid only if both the t=y and s= flags appear in the DKIM-Signature header, and the public key for the selector is correctly published in DNS. Without both, testing mode won’t function, and you’re not validating real-world behavior. Even a single missing piece breaks the chain.

What to check in the DKIM-Signature header

Look for t=y — this flag enables testing mode, which is required for validation tools to assess your setup.
Check that s= is present and matches your DNS selector (e.g., s=mail).
If either flag is missing, your DKIM signature isn’t properly configured for verification testing.

Validate DNS and key consistency

Use a DNS lookup tool like MXToolbox to confirm the public key exists in DNS under the correct selector.
Ensure the public key in DNS exactly matches the one used in the DKIM-Signature header — minor differences (like extra whitespace or encoding) break verification.
Double-check that the selector in the header aligns with the one in your DNS TXT record, especially if you use multiple selectors across domains.

Test with real inbound delivery simulation

Inspecting headers alone isn’t enough. A setup can pass header checks but still fail in real inboxes.
Use a real inbound test service — like MailTester’s inbox placement tester — to send a message to a live mailbox and track delivery, parsing, and spam filtering.
This reveals whether your DKIM is failing due to misconfiguration, alignment issues, or reputation factors that headers alone won’t surface.
Tools that rely only on header inspection miss delivery behavior, which is where most DKIM issues surface in production.

How MailTester helps verify DKIM signatures correctly

When you send emails with DKIM's t=y and s= flags, MailTester checks whether those signatures pass real-world inbox gateways—analyzing raw headers to confirm both flags are present and valid. It catches misconfigured or test-only DKIM setups before they reach production users, preventing deliverability issues.

Validating DKIM-Signature headers in real-world conditions

DKIM's t=y flag indicates a signature is meant for testing, not production use. If it’s present in messages sent to real users, it can trigger filtering or rejection by gateways like Gmail or Microsoft. MailTester sends your emails through actual email infrastructure—using real MX records and routing paths—to verify how gateways treat messages with t=y.

During inbox-placement testing, MailTester extracts and analyzes the full DKIM-Signature header. It checks for correct syntax, proper timestamp handling, and the correct use of flags—particularly ensuring s= points to the right domain and t=y isn’t accidentally sent to live recipients. This mimics what happens in production, not just in theory.

Preventing accidental test DKIM from harming deliverability

Many developers or automation tools insert t=y during testing but forget to remove it before going live. If a test signature slips into a real campaign, it can confuse email receivers. Some systems flag messages with t=y as suspicious or invalid, leading to low inbox placement or outright blocking.

MailTester identifies this risk early. By simulating real delivery, it spots when test signatures are being deployed. You get a clear alert if your message includes t=y and is being sent to an actual inbox. This lets you fix your setup before damaging sender reputation or hitting blocklists.

For teams using automation, API-based workflows, or third-party tools, this validation is especially critical. It's not just about catching syntax errors—like missing a required field in the header—but ensuring the intended behavior of test-mode signatures isn’t misapplied in production. RFC 6376 (the DKIM standard) outlines how these flags should be used, and MailTester aligns with those specifications.

Learn how to ensure your emails are both technically valid and deliverable: test inbox placement with real-world email gateways. Use the real-time verification API to automate header checks across your send list, or verify entire lists in bulk for consistent DKIM health. Keep your delivery strong and your reputation clean.

Common DKIM misconfigurations in testing mode

Leaving t=y in your DKIM signature after testing marks every message as non-production, triggering filters and lowering deliverability. Using the same selector and domain for test and live emails creates conflicting signatures, breaking validation. Not publishing a public key for the test selector causes verification failures, even if the syntax is correct. These mistakes are common but avoidable with intentional configuration.

Testing flags that stay in production

Don’t forget to remove t=y from your DKIM signature after testing. This flag explicitly signals that the message is not intended for real customers, and many email providers treat such messages as low-priority or suspicious.
Messages with t=y in production often get tagged or delayed. If you're testing on a live system, this can harm your sender reputation and inbox placement—especially if the test runs for weeks.
Use t=n (or omit the flag entirely) in production. The t flag is only meaningful during setup and should never persist in day-to-day email streams.

Selector and key management pitfalls

Using the same s (selector) value for test and live domains causes signature collisions. If the public key differs between environments and both are published, receivers may reject messages due to mismatched cryptographic validation.
Even with correct syntax, a test selector’s public key must be published in DNS. If not, DKIM verification fails because the receiver can’t retrieve the key to validate the signature.
Use unique selectors for test and production environments—e.g., test2024 and default. This keeps configurations isolated and avoids conflicts.
Verify your DNS records with an external tool like MXToolbox. This helps confirm that test keys are published and reachable.

The DKIM standard (RFC 6376) explicitly defines the t and s flags and their roles. Misconfiguring them breaks the chain of trust. Always validate your DKIM setup before sending to real recipients.

If you’re unsure about your DKIM setup, use MailTester’s inbox placement tester to check how your email renders in real inboxes across providers. It detects issues like malformed DKIM signatures, incorrect selectors, and misapplied test flags.

Real-world example: When t=y sabotages deliverability

Setting t=y in DKIM can cause legitimate emails to be delayed or filtered, especially at scale. A major e-commerce platform used t=y in a new campaign, sent to 500,000 users, and saw 37% of messages marked as 'tempfail' in DMARC reports — all because the receiving server treated the signature as untrusted due to missing or mismatched verification keys. This isn’t a rare edge case; it’s a known risk when misconfigured.

How t=y caused the failure: the setup

Configure DKIM with t=y for test campaigns — The team enabled t=y on their new campaign to help debug signing issues. It was meant to be a temporary flag, but it wasn’t removed before mass sending.
Send to a large segment of 500,000 users — The campaign went live without auditing the DKIM record. The t=y flag was applied to all messages, including those sent to domains using strict DMARC policies.
Monitor DMARC reports: find 'tempfail' for 37% of recipients — After 48 hours, they reviewed their DMARC reports. Over a third of their deliveries were marked as tempfail, meaning receiving servers were unable to validate the signature and chose to delay or filter the messages.
Diagnose: t=y triggers stricter validation — The flag tells receivers to validate the signature’s public key via DNS and check it aligns with the domain’s key — but only if the key is both present and valid. If any part fails, the result becomes tempfail.
Fix: Remove t=y and retest — After removing t=y and confirming the key was correct, subsequent sends showed zero tempfail rates. Deliverability returned to normal.

Why this happens: the role of verification

When t=y is used, receiving servers expect a valid public key lookup and a successful signature verification at the time of receipt. If the key is missing, expired, or mismatched, the server treats the message as suspicious — even if the send is technically correct.

The 5 steps described in “How t=y caused the failure: the setup”, in order.

According to RFC 6376 (the DKIM standard), t=y is optional and intended for debugging. Leaving it on in production sends a signal that the sender hasn’t fully validated their configuration. Major providers like Gmail and Yahoo have historically used this flag to apply temporary filtering policies to unverified or inconsistently signed mail.

RFC 6376 defines the behavior of t=y, making it clear that it's not a production-ready setting. You should never rely on it in bulk sends.

Before launching high-volume campaigns, verify your email list to avoid sending to invalid or poorly configured domains. You can also use inbox placement testing to check how your messages land in real inboxes before you send. This helps catch issues like DKIM misconfigurations before they impact deliverability.

Best practices for DKIM testing without risking delivery

You can safely test DKIM configurations by using a subdomain, avoiding production lists, and removing the t=y flag before going live. Always validate in a sandbox environment with throwaway addresses. This prevents accidental delivery issues and protects sender reputation. Tools like MailTester’s email checker help verify configurations without sending messages to real inboxes.

Test with isolation and intention

Use a dedicated subdomain like test.yourdomain.com for test DKIM keys. This isolates testing from production mail streams and avoids confusion in DNS records.
Never send test emails to your active customer list. Even a single misdirected message can trigger spam complaints or trigger filtering if receivers flag unexpected traffic.
Use a throwaway email address or a test mailbox (e.g., from Gmail or Outlook) to receive test messages. This ensures you can validate DKIM signatures without risking real user inboxes.
If you're using the t=y flag, remove it before going live. The t=y flag is only for testing and can cause rejection by some providers that see it as a misconfiguration.
Ensure your final DKIM configuration uses only t= or no t= flag. Some mail servers, including those from Google and ProtonMail, reject messages with t=y in production.

Validate without sending

For safer validation, use tools that check DNS records and DKIM signature structures without sending real mail. MailTester’s email checker can analyze a single address for DKIM compliance, including key alignment and DNS resolution, before you ever send. This helps catch issues early.

For bulk testing, MailTester’s bulk verification checks your list for valid domains and DKIM-relevant issues—like mismatched or missing records—across multiple addresses. It reduces the need for live testing in production.

DKIM testing is not about sending emails. It’s about validating signatures in context without exposure.

Following these practices helps avoid delivery disruption and keeps your domain’s sending reputation intact. Misconfigured DKIM can cause bounces, rejections, or even temporary blacklisting. Proper testing reduces that risk significantly.

How to validate DKIM signatures using MailTester

You can validate DKIM signatures using MailTester’s inbox placement test by uploading a sample message with a DKIM-Signature header. The tool checks if the t=y and s= tags are correctly set and returns a Valid status or flags anomalies. This helps catch misconfigurations before they affect live sends.

Upload a message with a DKIM-Signature header to MailTester’s inbox placement test. Use a real message from your system or a test email with a full header. This gives you an exact replica of what your recipients receive.
Check the header analysis in the report. Look for the DKIM-Signature line and confirm that t=y appears—this means the signature is tied to a specific domain (not a catch-all). Also verify that s= is present and matches your selector, as missing or incorrect s= tags cause signature failures.
Review the validation result in the output. If the signature is valid, you’ll see a Valid status. If the tool reports t=y with a caution or warning, it may indicate a mismatch between the domain in d= and the one listed in t=y—a common misconfiguration.
Look for signs of test leakage. If your test emails show t=y but were sent via a staging or test domain, this signals configuration drift. You might be using test keys in production, which can trigger authentication failures and lower sender reputation.

The 4 steps described in “How to validate DKIM signatures using MailTester”, in order.

Why this matters

DKIM is part of the email authentication stack. A malformed or misconfigured t=y or s= can cause your emails to be rejected, especially on strict inbound gateways like Gmail or Outlook. The DKIM specification requires both tags be present and correctly formatted to pass validation.

Use this process to audit your sending pipeline. If you find a test key leaking into production, you can fix your setup before it causes deliverability issues. This step is especially important when rolling out new templates or changing email service providers.

Automate this check

For large-scale validation, use the MailTester API to scan lists of messages or automate header validation in your CI/CD pipeline. This ensures every send maintains proper DKIM alignment before going live.

The difference between DKIM testing mode and production

DKIM testing mode (t=y) is meant only for internal debugging and should never be used in live email sends. In production, your DKIM signature must use t= or omit the t flag entirely—receiving servers reject t=y signatures unless explicitly allowed. Using t=y in real messages risks being flagged as suspicious or blocked.

Why testing mode exists—and when you should use it

When setting up DKIM, you might use t=y during configuration to validate your signature before going live. It tells receiving servers: "This is a test." But it’s not a real signature—just a signal to mail systems that the signature hasn’t been validated in the wild.

Let’s say you’re using a tool like MailTester’s real-time verification API to test your outbound email setup. You can use t=y temporarily to see if the signing process works, but as soon as you send to real users, you must switch to production mode.

What happens when you use t=y in production

Most recipients’ mail servers ignore t=y signatures entirely. Some even treat them as a sign of misconfiguration or abuse—especially if your domain doesn’t list test signatures in its DKIM policy. According to RFC 6376 (the base DKIM spec), t=y is a reserved testing flag, not meant for live use.

If your domain’s DKIM policy does not explicitly allow test signatures via the s= flag, receiving servers may reject or downgrade your messages. This is why you shouldn’t let t=y slip into customer-facing emails—even accidentally.

That said, some large services like Google and Yahoo allow test signatures if they appear in the domain’s published policy, but only if the domain’s DMARC policy explicitly permits them. If you’re unsure, check your domain’s DNS records using tools like MxToolbox or dmarcanalyzer.com to verify policy compliance.

Once you’re confident, remove t=y from your email flow. Your production DKIM signature should contain either no t= flag (the default) or t= (for testable production—only if your policies allow it). The s= flag, if used, defines which selector (e.g., default, default2) is considered valid for testing, but only when explicitly configured.

Fixing DKIM issues before they impact your sender reputation

DKIM signatures with the t=y test flag indicate a configuration that’s intended for testing, not production. Leaving these in place can cause receiving servers to flag your messages as suspicious, even if the technical setup appears correct.

Use MailTester’s inbox placement tests to catch t=y signatures in real-world environments before you send to large lists. These tests simulate actual delivery conditions, revealing misconfigured or test-only signatures that wouldn’t show up in standard DNS checks.

Ensure SPF, DKIM, and DMARC are aligned and free of test markers. A single t=y signature in a mass send can trigger reputation penalties, reduce inbox placement, and increase the risk of being blocked by major providers.

Sources

DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does DKIM t=y mean?

DKIM t=y indicates the signature is part of a test or debugging process. It tells receivers not to treat it as a production validation.

Can you send DKIM t=y in production emails?

No. Leaving t=y in production emails often triggers spam filters or delivery failures, even if the key is correct.

What happens if the s flag is missing in DKIM?

The signature will fail verification. The s flag specifies the signing domain required for validation.

How do you test DKIM without affecting deliverability?

Use a subdomain, test-only email addresses, and remove t=y before sending to real users.

Can MailTester detect DKIM t=y flags?

Yes. MailTester analyzes raw headers and identifies t=y and s= values during inbox placement testing.

Does DKIM t=y affect DMARC results?

Yes. DMARC policies may fail if t=y is present, as the signature is not considered valid by most gateways.

Should I keep t=y in the DKIM signature during troubleshooting?

Only during internal testing. Remove it immediately before sending to real users.

What is the purpose of the s flag in DKIM?

The s flag specifies the domain responsible for signing, which is essential for domain alignment and verification.

How do I verify my DKIM setup with MailTester?

Send a test message through MailTester’s inbox placement test and review the header analysis for t=y and s= flags.

Why did my emails get filtered with DKIM t=y?

Receiving servers treat t=y as a sign of incomplete or non-production setup, often causing rejection or spam filtering.

Can I use DKIM t=y with DMARC policy=none?

DMARC does not allow t=y to pass validation. Even with policy=none, receivers will still reject test signatures.

Does removing t=y improve deliverability?

Yes. Removing t=y eliminates a known red flag, supporting better alignment and reputation tracking with inbox providers.