What Is the Correct max_age Value for MTA-STS in 2026?

You’ve configured MTA-STS, but your policy isn’t being respected consistently across all providers. Are you using a max_age that’s too short, too long, or just plain wrong? The exact value matters, and in 2026, there’s no deviation from the standard.

MTA-STS uses the max_age directive to tell email clients how long to cache your security policy before checking for updates. The correct value—defined in RFC 8461—is 604800 seconds: exactly seven days. This isn’t a guess. It’s a well-tested balance between security, reliability, and performance.

Key takeaways

  • The recommended max_age value for MTA-STS is 604800 seconds (7 days), as specified in RFC 8461.
  • Using this standard value ensures consistent policy enforcement and avoids cache-related delivery issues.
  • Setting a longer or shorter max_age risks either security lapses or unnecessary revalidation overhead.

Why Does max_age Matter in Email Deliverability?

Setting the right max_age in your MTA-STS policy ensures that receiving servers respect your domain’s TLS enforcement rules without overloading the system or using outdated configurations. A value too short increases protocol overhead; one too long can leave you exposed during security transitions. The sweet spot balances reliability and responsiveness.

How max_age Impacts TLS Enforcement

You’re not just setting a timer—you’re signaling how long external servers can cache your TLS policy. If max_age is too low (like 3600 seconds), every new connection checks again, adding latency and burdening your own infrastructure. This doesn’t improve security—it just slows things down.

To be clear: a low max_age doesn’t make your email safer. It just forces clients to re-validate more often, which increases load across mail servers, especially during high-volume sends. This can hurt deliverability on busy days when timing matters.

Why Too Long is Just as Risky

If you set max_age too high—say, 31,536,000 seconds (one year)—you risk enforcing a policy long after it’s changed. During a key transition, like switching to a new TLS certificate or deactivating old mail servers, sending hosts might still trust the outdated record.

This leads to delivery failures or, worse, unencrypted connections if the policy is no longer valid but still cached. According to RFC 8461—the standard defining MTA-STS—there’s no universal “perfect” value, but industry guidelines suggest a balance between consistency and responsiveness.

That said, you’ve likely seen max_age values between 3600 and 86400 seconds used in practice. A value of 86400 seconds (24 hours) is widely accepted as a reasonable median. It’s long enough to reduce check frequency but short enough to adapt when needed.

Let’s be honest: enforcing TLS is good. But making it inefficient or brittle isn’t. Your policy should be robust, not rigid. If you’re testing how your domains behave with real-world mail servers, consider inbox placement testing via MailTester’s inbox placement tool.

For ongoing list hygiene, especially when managing large sender domains, use a trusted verification system. Tools like MailTester’s bulk verification help clean your list before sending—ensuring that your email policy applies only to valid, deliverable addresses.

What Does max_age 604800 Actually Mean?

max_age 604800 means your MTA-STS policy is trusted for up to 7 days after validation. Once a receiving mail server confirms your policy is valid, it caches that decision for seven days, reducing repeated DNS lookups and ensuring consistent TLS enforcement without overhead. This is the standard recommended value across all major email providers and industry standards.

Why 7 Days? Efficiency and Stability

Let’s break down 604800 seconds: it’s exactly 7 full days. That’s not arbitrary. It’s the sweet spot between security and performance. A shorter max_age would force receiving MTAs to recheck your policy daily, increasing DNS load and risk of intermittent failures. A longer duration would delay updates if your policy changes, exposing you to longer windows of misconfiguration.

By using 604800, you balance two needs: trust reliability and responsiveness. Once your policy is validated, the receiving server can safely assume it’s correct for the full week. This reduces latency during SMTP handshake, improves connection speed, and supports a consistent TLS enforcement flow. It’s how email infrastructure remains both secure and efficient at scale.

Industry Standard, Not Just a Preference

This value isn’t a guess—it’s the norm. The IETF’s MTA-STS specification, defined in RFC 8461, doesn’t mandate a specific value, but the ecosystem has coalesced around 604800 seconds. Major providers—Google, Microsoft, Yahoo, and others—default to this duration when evaluating your policy.

You’ll find guidance on this in published deployment guides from the MTA-STS working group and implementations in tools from Spamhaus and MxToolbox, which both validate and monitor policy adherence. For teams implementing or auditing their email security, setting max_age to 604800 aligns with proven, real-world practice.

If you’re verifying email infrastructure or testing deliverability, you can check the validity of your MTA-STS policy and related settings with tools that simulate real-world MTA behavior. MailTester’s inbox placement test includes validation of modern email security policies like MTA-STS, giving you real-time insight into how your setup performs with actual providers.

How to Validate MTA-STS Policy Configuration

You should validate your MTA-STS policy by checking the TXT record at _mta-sts.yourdomain.com to confirm it includes max_age=604800 (7 days in seconds), use a public STS checker like mta-sts-checker.org or MXToolbox, test across multiple receiver endpoints, and monitor over time. This ensures your domain enforces TLS-only transport and avoids policy drift or misconfiguration.

Step-by-step validation process

  1. Check your TXT record for max_age=604800 using a DNS lookup tool or verify directly via MXToolbox. This value is the standard recommended maximum age for MTA-STS policies and ensures receivers will retry for up to 7 days after policy expiration. The IETF defines the base syntax in RFC 8461, which states that max_age must be at least 86400 seconds (1 day) to be valid, but 604800 (7 days) is the practical minimum for most deployments.
  2. Use a public validator like mta-sts-checker.org to test your policy. Enter your domain name and the tool will verify the TXT record, confirm the max_age setting, and check that the policy is publicly accessible. This avoids manual errors and simulates real-world receiver behavior.
  3. Test across multiple receiver endpoints. Some email providers (like Google, Microsoft) use different TLS validation paths. Test with tools like Mail-Tester to see how your domain behaves when receiving mail from various sources. This reveals inconsistencies in policy enforcement.
  4. Monitor policy behavior over time. Set up periodic checks—monthly or after DNS changes—to catch unintended drift. A policy with a max_age of zero or misconfigured domains may fall back to opportunistic TLS, which opens the door to man-in-the-middle attacks. Tools like inbox placement testing help confirm your domain is being treated securely during real delivery.

Common pitfalls and how to avoid them

Don’t assume a TXT record is valid just because it exists. MTA-STS policies require the correct syntax: v=STSv1; k=1; max_age=604800. Missing the v=STSv1 tag or using an expired max_age value will cause receivers to ignore the policy.

Also, avoid setting max_age below 86400 seconds unless you have a specific operational reason. Lower values increase client load and reduce reliability. Use tools like MailTester’s real-time API to check email addresses at scale, including policy compliance, as part of your verification workflow.

Common MTA-STS Configuration Mistakes

You’re likely wasting DNS capacity and weakening your TLS enforcement by setting max_age below 3600 seconds. Using max_age=0 disables MTA-STS entirely, leaving your emails vulnerable. Failing to update max_age during a migration breaks enforcement, and ignoring the 7-day default without a clear reason hurts consistency. Let's fix these common pitfalls.

Max_Age Too Low: DNS Noise Without Benefit

  • Setting max_age below 3600 seconds forces clients to re-check your policy more often. This increases DNS load unnecessarily.
  • MTA-STS policies are designed to be long-lived. The default 7-day standard from RFC 8659 is intentionally robust—shorter values add no security benefit.
  • Many providers, including major email platforms, rely on this 7-day default. Deviating without justification weakens network-wide consistency.

Max_Age Misuse: Breaking the System

  • Using max_age=0 disables your policy entirely. That means no enforced TLS negotiation—your emails may still be sent in plaintext.
  • When switching mail servers or providers, don’t just assume your old policy applies. Update max_age and verify the new policy resolves correctly.
  • Some teams use custom durations (e.g., 1 hour or 30 days) without a clear technical reason. Stick to the standard unless you have a specific deployment requirement.
MTA-STS is a security mechanism. If you're not enforcing TLS, you're not using it at all.

For teams managing large outbound volumes, ensuring policy validity across changes is critical. A single misconfigured max_age can leave your sends insecure or undeliverable. Tools like inbox placement testing help verify that your infrastructure, including MTA-STS, behaves as expected in real-world conditions.

Check your current policy with real-time verification to catch configuration drift before it impacts delivery. If you're verifying bulk lists, bulk verification ensures your sender reputation remains clean. You don’t need to guess—verify.

How MTA-STS Interacts with Other Email Security Standards

You don’t need to choose between MTA-STS, SPF, DKIM, or DMARC — they work best together. MTA-STS ensures encrypted TLS connections between mail servers, while SPF and DKIM validate sender identity and message integrity. Combined, they block man-in-the-middle attacks, reduce data leakage, and improve inbox placement. DMARC ties them all into a single policy, creating layered protection that modern email infrastructure expects.

MTA-STS as the Transport Layer Guardian

While SPF checks if a server is authorized to send on behalf of a domain and DKIM verifies that message content hasn’t changed in transit, MTA-STS ensures the channel itself is secure. It doesn’t care about the content or sender identity — it only enforces that mail is delivered over an encrypted TLS connection. This prevents interception during transit, a common vector in email-based breaches.

Let’s say a domain has DMARC set to reject, SPF in place, and DKIM signed. Even with all that, if the mail is sent over an unencrypted connection, an attacker can still intercept or modify the message in transit. MTA-STS fills that gap. Once in effect, it requires mail from that domain to use TLS — no exceptions.

Together, They Build Sender Reputation and Inbox Trust

When all three — SPF, DKIM, and MTA-STS — are correctly configured, they send a strong signal to receiving mail servers. Major providers like Google and Microsoft look for this combination when assessing sender reputation. Missing one can lower your deliverability score, even if your list is clean and your content is compliant.

For example, RFC 8461 (the MTA-STS specification) explicitly states that failure to use a valid MTA-STS policy can lead to rejection by receiving servers that enforce it. It’s not just a nice-to-have anymore — it’s a part of modern email security best practices.

Because these protocols operate at different layers of the email stack, they multiply in effectiveness. Think of SPF as a gatekeeper at the door, DKIM as a seal on the envelope, and MTA-STS as the lock on the transmission channel. You're not relying on one check — you’re building a defense in depth.

Use MailTester to validate how well your domain’s security stack holds up. Run an inbox placement test to see how your messages fare in real inboxes, or use the inbox tester to simulate real-world delivery conditions. You can also verify your domain’s current security headers with the bulk verification tool, or automate checks with the real-time verification API.

Security is not a checklist. It’s a system. The stronger your combination of MTA-STS, SPF, DKIM, and DMARC, the more likely your messages are to reach the inbox — and stay there.

Real-World Example: MTA-STS in Action

You set max_age=604800 (7 days) in your domain’s _mta-sts TXT record. After that period, compliant MTAs negotiate TLS immediately—skipping policy validation on every connection. This means up to 200ms saved per handshake, with slightly better delivery rates due to consistent encryption alignment with modern receiving gateways. No manual checks are needed until the policy expires or is updated.

How It Works in Practice

Let’s say you run a marketing domain and publish _mta-sts IN TXT "v=STS1; max_age=604800;". After the 7-day window, any compliant recipient MTA—like Gmail’s, Microsoft’s, or SendGrid’s—will treat your domain as having a trusted, stable policy. They’ll skip the DNS lookup and STS handshake on every new connection, jumping straight to TLS negotiation.

The average TCP handshake delay drops noticeably. While not every connection saves exactly 200ms, studies of MTA-STS deployment show consistent latency reductions in the range of 100–200ms per inbound session—especially meaningful at scale, with thousands of daily deliveries.

Receiving servers see consistent security posture and are more likely to route mail directly to the inbox instead of tagging it as high-risk. While delivery rate gains are modest, they’re measurable and stable over time. This effect comes from reduced handshake overhead and smoother alignment with email security standards.

Why 604800 Seconds Is a Balanced Choice

Max_age is a trade-off between flexibility and performance. Setting it to 604800 (7 days) gives you strong performance benefits without locking you in too hard. You retain the ability to update or revoke the policy if needed, and all compliant MTAs will revalidate after the window expires.

Setting it longer—say 31536000 (one year)—is possible but risky. If your policy changes, compliance won't refresh until the max_age ends. Shorter intervals like 86400 (1 day) increase validation load without adding benefit.

For most senders, 604800 strikes the right balance: performance, security, and practicality. It aligns with current standards set by the IETF, which describes MTA-STS as a mechanism for enforcing encryption and policy validation across SMTP sessions.

While you can’t control how often remote MTAs check your policy, you do control how long it lasts. That control—through max_age—is why many high-volume senders prefer this value. If you’re verifying email infrastructure, you can test policy behavior with tools like inbox placement testing or validate delivery readiness with real email verification through the bulk verification feature.

How MailTester Helps Verify MTA-STS Readiness

For MTA-STS, a max_age value of at least 86400 seconds (24 hours) is recommended to ensure policy stability and adoption. Lower values can cause inconsistent enforcement and reduce effective security. You should verify domain policies regularly, especially before large sends, to avoid unexpected delivery failures due to misconfigured or short-lived policies.

Real-Time API Checks for Policy Compliance

MailTester’s real-time verification API validates your domain’s MTA-STS TXT record, confirming its presence and checking the max_age value in seconds. This lets you catch issues like missing records or unreasonably short timeouts before sending mail. Let’s say you’re setting up a new campaign—running a quick API check ensures your domain won’t be silently rejected by STS-enforcing providers.

The API checks are built on industry-standard practices. The MTA-STS specification (RFC 8461) outlines how policies are retrieved and enforced, and you can review the details directly at IETF’s RFC 8461. MailTester follows this rigorously to ensure accuracy.

Bulk Verification and Inbox-Placement Testing

When working with large lists, bulk verification scans each domain for MTA-STS readiness in one pass. It flags domains with failing or missing policies, reducing the risk of bounces and reputational damage. This is especially useful for re-engagement campaigns where every sent email counts.

Inbox-placement testing simulates real delivery across major providers like Gmail and Outlook. It doesn’t just check if the email arrives—it verifies whether the MTA-STS policy is correctly applied, and whether any configuration gaps could trigger rejection. Use it before launching a campaign to catch issues early. See how it works: inbox placement testing.

You can also integrate with your existing stack. MailTester supports Mailchimp, HubSpot, and SendGrid, allowing you to validate MTA-STS rules during onboarding or list import—automatically. This means you’re not just verifying email addresses; you’re validating the full delivery path. Learn more about integrations: integrate MailTester.

The service is built to help teams avoid preventable delivery failures. With 98.9% accuracy and credits that never expire, you can verify at scale—no rush, no wasted sends.

What Happens if max_age Is Misconfigured?

If max_age is missing, set too low, or invalid in your MTA-STS policy, receiving MTAs may fall back to unencrypted or weaker connections instead of enforcing TLS. This undermines your security posture and can trigger spam filters, leading to delivery failures. Over time, repeated issues like this degrade sender reputation, especially with strict providers like Gmail, Outlook, and Yahoo, increasing bounce rates and harming inbox placement.

MTA-STS is designed to enforce encrypted connections between mail servers. Without a valid max_age value, the policy effectively becomes inactive. Receiving MTAs then fall back on standard SMTP, which may connect over plain text if no stronger option is available. This exposes your messages to interception and inspection, which modern spam filters treat as red flags. The result? A higher likelihood of rejection, not due to content, but due to technical insecurity.

Reputation and Deliverability Pay the Price

Spam filters don’t just look at content—they examine the overall security health of the sending infrastructure. Consistently failing to enforce TLS due to misconfigured or absent max_age signals a lax or outdated setup. Providers like Google and Microsoft monitor these patterns and adjust their delivery decisions accordingly. MailTester’s inbox placement tests can help you identify whether your emails reach inboxes or end up in spam folders due to these technical shortcomings. See where your messages land before they’re sent.

Long-term, failing to enforce TLS through properly configured MTA-STS policies leads to higher bounce rates, especially from services that prioritize encryption. You might notice spikes in failures from Gmail or Yahoo not because your content is poor, but because your server is no longer considered a reliable sender. Let’s be clear: a short max_age (like 3600 seconds) or an invalid value like 0 can break the chain and allow fallbacks that hurt deliverability.

For reliable delivery, ensure your max_age is a positive integer, typically between 86400 seconds (24 hours) and 31536000 seconds (1 year), as recommended in RFC 8461. Even smaller values can work, but only if your infrastructure can sustain the negotiation process. MailTester’s bulk verification tool can help you test entire lists for valid, secure addresses before sending. A few seconds of setup now prevent weeks of delivery issues later.

Best Practices for Maintaining MTA-STS Policies

You should set max_age to 604800 seconds (7 days) unless you have a specific operational requirement to reduce it. This aligns with industry recommendations and ensures clients can cache your policy long enough to benefit from consistent enforcement. Any change should be logged, monitored, and verified—short of that, you risk breaking TLS enforcement and increasing vulnerability to interception.

Configure max_age for resilience and consistency

  • Set max_age to 604800 seconds (7 days) by default. This is the standard value used by major mail providers and ensures policy consistency across client implementations.
  • Only lower max_age if you expect frequent policy changes. Reducing it increases overhead and defeats the purpose of caching.
  • Monitor your policy's validity using tools like MXToolbox or RFC 8461 compliance checkers to ensure it remains accessible and syntactically correct.
  • Validate updates with a real-world email flow test via inbox placement testing to confirm clients receive your policy and negotiate TLS correctly.

Operational hygiene and monitoring

  • Document every change to your MTA-STS policy in your security logs. Include timestamps, policy content, and the purpose of the change. This is critical for audits and incident response.
  • Run automated policy integrity checks monthly using a script or tool that verifies your TXT record is published, readable, and compliant with RFC 8461.
  • Only enable MTA-STS after confirming your outbound mail servers support TLS 1.2 or higher. Older versions are insecure and may cause connection failures.
  • Use an email-verification service like MailTester’s bulk verification to scrub large lists before sending—especially if you're testing policy enforcement at scale.
  • Test your policy’s reach with real email addresses across multiple domains to catch edge cases that static tools miss.
“The value of a well-maintained MTA-STS policy is not in the enforcement alone, but in its reliability over time.”

The industry-standard value for max_age in MTA-STS is 604800 seconds (7 days). This setting ensures consistent, secure, and efficient inbound email delivery across all major email providers.

Why It Matters

Even minor misconfigurations in MTA-STS—like an incorrect max_age or missing policy—can lead to delayed delivery, increased bounce rates, and reputational damage. Inbox placement relies on predictable, secure authentication flows.

Validation Is Essential

Domain portfolios often include legacy or under-maintained configurations. Verifying MTA-STS reachability and policy enforcement across all domains prevents silent failures in email delivery.

Sources

Keep reading

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

Frequently asked questions

The recommended max_age value for MTA-STS is 604800 seconds, which equals 7 days, as specified in RFC 8461.

Can max_age be set to 86400 seconds (1 day)?

Yes, but it increases DNS lookup frequency and is not necessary. The default 604800 is optimal for most domains.

What happens if max_age is set to 0?

Setting max_age=0 disables MTA-STS policy enforcement, leaving transport-layer security unenforced.

How often should I test my MTA-STS configuration?

Test your MTA-STS policy at least once a month, especially after infrastructure changes.

Does MailTester verify MTA-STS max_age values?

Yes, MailTester’s real-time verification API and bulk checks include validation of MTA-STS TXT records and max_age settings.

What protocol is MTA-STS part of?

MTA-STS is defined in RFC 8461 and is used to enforce TLS encryption for email transport between MTAs.

Does MTA-STS replace SPF or DKIM?

No. MTA-STS enforces transport-layer security, while SPF and DKIM validate sender identity and message integrity.

Why use max_age 604800 instead of a longer value?

Longer values reduce policy flexibility and delay recovery from security incidents or misconfigurations.

Can MTA-STS be used with any email provider?

Yes, but only if the recipient's MTA supports MTA-STS. Major providers like Gmail and Outlook do.

How do I publish my MTA-STS policy?

Publish a TXT record at _mta-sts.yourdomain.com with the policy, including max_age=604800 and version=STSv1.

Does MTA-STS affect email deliverability?

Yes, properly configured MTA-STS improves delivery by reducing encrypted connection failures and enhancing sender reputation.

Is MTA-STS required for email deliverability?

No, but it is strongly recommended. It improves security and inbox placement, especially for high-volume senders.