Email Verification API Expects t= Timestamp in Seconds, Not Microseconds

Why does your email verification API care about timestamp format?

You send a verification request. The API returns an error. You check the docs. The response says “Invalid timestamp.” But you used the current time—what’s the problem?

It’s not a logic bug. It’s a unit mismatch. The API expects the timestamp in seconds, not microseconds. A single misplaced zero can break your integration—especially with MailTester’s real-time verification API.

Think of it like sending a key to a lock: if the key is slightly out of sync, the door won’t open, no matter how correct it looks.

Key takeaways

• MailTester’s real-time API requires timestamps in seconds, not microseconds, to validate request freshness.
• A unit mismatch between seconds and microseconds causes immediate API rejection—no retries, no warning.
• Timestamp misalignment is the most common cause of integration failure with MailTester’s real-time API.

What happens when you send microseconds instead of seconds?

You send a timestamp in microseconds—like 1700000000000—and the API reads it as January 1, 2142, not now. Since your request is in the future, it gets flagged as expired or invalid. You’ll see error codes like invalid_timestamp or request_expired in your logs. This isn’t a bug. It’s a requirement.

Why the timestamp format matters

Most email verification APIs expect Unix timestamps in seconds, not microseconds. The difference is literal: 1700000000 seconds is roughly December 14, 2023. But 1700000000000 microseconds is 1.7 trillion microseconds—over 50 years in the future. That’s a clear validity issue.

If you're generating timestamps with JavaScript, you might be using Date.now(), which returns milliseconds. Multiply that by 1000 to get microseconds, but your API wants seconds. So you need to divide the timestamp by 1000 for milliseconds, or by 1,000,000 for microseconds—depending on the system. The key is matching the expected input format.

How to avoid timestamp errors

Let’s say you’re sending a verification request via the MailTester API. You must pass the current time in seconds since the Unix epoch. If you send microseconds, the server interprets that as a future date. The request fails immediately—no retry, no grace period.

Check your code for unintended unit conversion. A timestamp like 1700000000000 is 1.7 trillion—way beyond the current year. It’s not just wrong; it’s meaningless to the API. The API doesn’t guess—you’re responsible for formatting.

Some systems automatically log these issues. If you're seeing request_expired, check your timestamp generation logic before assuming it’s a configuration problem. It’s a common mistake in automated workflows.

For real-time API integration, always use seconds. This isn’t a negotiation—this is what the standard expects. For reference, the Unix epoch is defined in RFC 3339, which specifies date and time formats in internet protocols. While it doesn’t mandate seconds-only timestamps, most modern APIs use them.

If you’re testing this behavior, use the MailTester API to send a sample request with a timestamp set to now (in seconds). It’ll help you validate your implementation without sending thousands of real emails.

How MailTester’s real-time API expects timestamps

You must pass the t= parameter in Unix seconds (UTC), not microseconds. A value like t=1704067200 (January 1, 2024, 00:00:00 UTC) is valid. Any timestamp with more than 10 digits — such as 1704067200123 — will be rejected. This aligns with standard Unix time expectations, as defined in RFC 3339 and commonly used across systems.

What to include in your API request

• Use Unix seconds, not microseconds, for the t= parameter. This is the default format expected by most systems, including MailTester's API.
• Ensure the timestamp is in UTC. Local time offsets will cause validation failures.
• Never use a timestamp with more than 10 digits. If your system generates microseconds (e.g., 1704067200123), truncate to seconds by dividing by 1,000.
• Example: For January 1, 2024, 00:00:00 UTC, the correct value is t=1704067200. You can verify this using any standard Unix timestamp converter.
• Test your request with a known good timestamp before sending bulk traffic. A 400 error response will indicate a timestamp format issue.

Why this matters for deliverability

Timestamps in the API help validate request authenticity and prevent replay attacks. Using the correct format ensures your verification requests are processed immediately, without delays or rejections.

• Invalid timestamps often result in silent drop or immediate rejection — no error message, just no response.
• This is not a MailTester-specific quirk. It follows industry patterns seen in REST APIs that use signed requests.
• Always include the t= parameter in your real-time verification calls — it’s required for authentication and rate limiting.
• Use a reliable library or function to generate timestamps. Many programming languages (like Python’s time.time()) return seconds by default, which matches MailTester’s expectation.
• If you’re integrating with MailTester via integrations or building a custom workflow, ensure your timestamp logic is consistent across systems.

How to verify your timestamp is in seconds, not microseconds

If your email verification API expects a t= timestamp in seconds, not microseconds, confirm your current timestamp is in the correct unit. Most systems use milliseconds by default—like JavaScript's Date.now(). Divide that value by 1000, then use floor() or truncate to convert it to seconds. A simple test with an online Unix timestamp converter can quickly confirm the conversion is correct.

Check your system’s timestamp output format

Let’s say you’re using JavaScript. Date.now() returns the current time in milliseconds since the Unix epoch. If your API expects seconds, you’ll need to convert it. For example, 1712345678000 (milliseconds) becomes 1712345678 (seconds) when divided by 1000. Many libraries and frameworks default to milliseconds, so it’s easy to mix them up.

Check the documentation for your programming language or library. For instance, Python’s time.time() returns seconds, while Unix timestamps in some systems may be microseconds. Use trusted sources like the RFC 2301 for precise timestamp conventions, and verify your code’s output matches expected standards before sending.

Validate with a reliable tool

Use a straightforward Unix timestamp converter to test your value. Paste your current timestamp—say, from Date.now()—into a tool like unixtimestamp.com to see if it aligns with seconds or microseconds. If you see a number in the millions or billions with a long decimal, it’s likely in milliseconds or microseconds.

If your value matches the expected second-based format, you’re set. If not, apply the division by 1000 and recheck. This small step prevents authentication failures when sending emails through systems that enforce strict timestamp formats.

Once your timestamp is in seconds, proceed with sending. For full email deliverability confidence, run a test with our inbox placement tester to see how your messages land in real inboxes—before they go out.

Common timestamp conversion pitfalls in code

You must convert timestamps to seconds before sending them to the email verification API—JavaScript’s Date.now() returns milliseconds, so divide by 1000. Python’s time.time() returns seconds with decimals; use int(time.time()) to truncate. Never send microseconds or formatted strings with leading zeros or decimals—these cause validation errors.

JavaScript: Milliseconds must be converted to seconds

• Use Math.floor(Date.now() / 1000) to convert milliseconds to seconds.
• Never pass Date.now() directly—it returns values like 1712345678912, which are 1,000× too large.
• Double-check your timezone handling: timestamp systems often assume UTC. If your code uses local time, results may drift.

Python: Handle fractional seconds properly

• Use int(time.time()) to strip fractional components—this ensures a clean integer.
• Don’t use round(time.time())—it can introduce rounding errors in edge cases.
• Use datetime.utcnow().timestamp() if you’re working with timezone-aware code; it outputs seconds since epoch, but still requires integer conversion.

Always test your output against a known correct timestamp—tools like unixtimestamp.com let you verify your conversion is correct. A single misplaced decimal or stray zero can trigger an API rejection even if everything else is correct.

String formatting issues are especially tricky: sending "1712345678.912" or "00001712345678" will fail. The API expects a raw integer—no decimals, no padding. Your code should never format the timestamp as a string before sending it.

Bulk verifications with high-volume senders often fail silently due to timestamp formatting errors—this isn’t usually obvious until you see a spike in "invalid" responses across many addresses. Let’s make it easy: validate your timestamp logic before sending data at scale. You can test your API integration with real verification requests to catch these issues early.

How to fix timestamp issues in different programming languages

You need to pass timestamps in seconds, not microseconds, to the email verification API. Most languages default to milliseconds or microseconds; use Math.floor(Date.now() / 1000) in JavaScript, int(time.time()) in Python, time() in PHP, time.Now().Unix() in Go, and Time.now.to_i in Ruby. This ensures your API requests use the expected format and avoid validation failures.

Convert timestamps correctly across languages

Timestamps in API requests must reflect seconds since the Unix epoch. If your code generates microseconds, you’ll get an error. Here’s how to convert reliably across common languages:

Using the wrong timestamp format is a common source of API errors. Double-check that your timestamp is in seconds before sending a verification request. For real-time bulk verification with accurate delivery outcomes, use the MailTester email verification API—it handles validation at scale with 98.9% accuracy. Ensure your integration uses the correct time format to avoid silent failures.

For testing if your timestamp is correct, use a tool like Epoch Converter to validate your time values against Unix epoch standards. This helps catch issues early, especially when moving code between environments.

Why using seconds is the industry standard for API requests

You need to pass timestamps in seconds, not microseconds, because the industry-wide standard for API time validation—across OAuth, JWT, and SMTP authentication—relies on Unix timestamps in seconds. Using seconds reduces data overhead, simplifies parsing, and aligns with how most systems measure time. Attempting to include microseconds adds unnecessary complexity and increases the risk of misalignment, especially under high load or network latency.

Smaller payloads, fewer parsing errors

Each microsecond adds three extra digits to a timestamp. That may seem small, but in bulk API calls—like verifying thousands of email addresses at once—those extra bytes add up. Smaller payloads mean faster transmission and less processing overhead on both client and server. This directly impacts performance and reduces the chance of parsing issues, especially when systems expect a clean, predictable format.

Security systems expect seconds

Most authentication protocols, including OAuth 2.0 and JWT, validate timestamps using second-level precision. These systems reject tokens where the time delta exceeds a few minutes, regardless of whether microseconds are included. The validation logic doesn’t account for microsecond precision—doing so would require custom handling and introduces error margins that aren’t needed. For example, the JWT standard (RFC 7519) specifies time claims in seconds, and any deviation increases the risk of token rejection.

Microsecond timestamps also introduce latency in processing. Some systems treat time validation as a critical path; when microseconds are included, it can trigger premature expiration checks, even if the time is actually valid. This isn’t just theoretical—many email verification APIs, including MailTester’s verification API, rely on clean, second-based time to prevent false rejection of valid requests. The system is designed to work at scale, and precision beyond seconds does not improve accuracy—only complexity.

Let’s be clear: unless your system is explicitly built for microsecond precision (which few are), using seconds is not just preferred—it’s necessary. It’s the baseline for interoperability, performance, and reliability. If your API expects microseconds, it’s operating outside the standard. That’s a recipe for silent failures and hard-to-debug issues at scale. Stick to seconds. It’s what the rest of the ecosystem expects.

How MailTester handles timestamp validation

You must send the t= timestamp in seconds, not microseconds, when using the MailTester verification API. We validate this timestamp against our server time with a 60-second tolerance window. Requests older than 60 seconds or newer than 60 seconds from the current time are rejected to prevent replay attacks, ensuring secure, single-use verification attempts.

Timestamp handling in practice

• MailTester expects the t= parameter in seconds, not microseconds – using microseconds will result in a validation error.
• We compare your timestamp to our server time with a ±60-second tolerance window to account for minor network delays.
• Requests with timestamps older than 60 seconds from now are rejected to prevent replay attacks, which could be used to abuse the system.
• Similarly, timestamps more than 60 seconds in the future are rejected. This stops clients with incorrect clocks or malicious actors from bypassing checks.
• If you're unsure, verify your system's clock is synchronized with NTP (Network Time Protocol) – it’s a standard practice in secure API design, as outlined in RFC 7858 and widely recommended by security providers.

Why this matters for your workflow

Timing is critical when integrating with APIs that handle sensitive operations. If your system’s clock is off by more than a minute—even slightly—the request will fail silently unless you check the error response. This is intentional: it protects your account and ensures only legitimate, time-bound requests get through.

For developers, consistent timekeeping means fewer failed verifications. It's simple: sync your server time, use seconds for t=, and stay within the 60-second window. If you’re building or testing an integration, you can test timestamp behavior using the MailTester API to confirm your implementation works reliably.

Secure API design isn't about complexity—it's about predictable, enforceable rules. Time-based validation is one of the most effective safeguards against abuse.

Best practices for avoiding timestamp mistakes in production

You must ensure your email verification API expects timestamps in seconds, not microseconds—otherwise, even a minor mismatch can cause rejection or delay. Align your time logic early, store reference values as constants, and verify the actual timestamps in logs before sending. This prevents silent failures in high-volume systems where microseconds drift across services.

The root of the problem: microseconds vs. seconds

• Always confirm your API expects timestamps in seconds. A timestamp sent in microseconds (e.g., 1700000000000) will be interpreted incorrectly if the receiving system expects seconds (e.g., 1700000000).
• Store time tolerance as a constant in your codebase—for example, TIMESTAMP_TOLERANCE = 60—to avoid magic numbers and ensure consistent validation.
• Apply timestamp conversion as early as possible in your request pipeline, before any serialization or external calls. Late conversion increases risk of mismatch.
• Log the exact timestamp value before sending it to an external service like MailTester's email verification API. This lets you audit and debug issues without guesswork.
• Use a centralized utility function for formatting timestamps. This ensures consistency across services and reduces the chance of developer error.
• Test your implementation with edge cases: timestamps from different timezones, leap seconds, and system clock drifts. Use tools like RFC 7231 to understand how HTTP date parsing works.
• Validate time sync across your infrastructure. If your servers fall out of sync by more than a few seconds, even correct timestamp formatting won't fix delivery issues.

Why logging matters

Don’t trust third-party libraries to handle time correctly. They may assume a specific time unit or timezone. A log entry showing timestamp=1700000000 (seconds) versus 1700000000000 (microseconds) is the only way to spot a mismatch during debugging.

When you’re processing thousands of emails per minute, a single timestamp unit error can cause cascading failures. Fix it at the source—don’t wait for bounce reports.

How to test your API integration with a valid timestamp

You must send a test request with a t parameter set to the current Unix timestamp in seconds, not microseconds. A valid response with status: success and a verification_id confirms your integration is correctly handling time formatting. Use MailTester’s sandbox endpoint to ensure accuracy and avoid rate limits during testing.

Step-by-step API test setup

1. Generate a current timestamp in seconds. Use a tool like Epoch Converter to ensure you’re passing the Unix timestamp in seconds, not microseconds. For example, t=1704067200 represents January 1, 2024, at 00:00:00 UTC. This is a requirement of the API specification.
2. Send a test request using the sandbox endpoint. Always test with MailTester’s verification API sandbox before going live. This prevents accidental rate limit triggers and lets you validate your setup without impacting real data.
3. Verify the response structure. A successful integration returns {"status": "success", "verification_id": "v123abc"}. If the response includes an error, double-check that t is in seconds — this is a common cause of rejection.
4. Check the timestamp in the response. The API may echo back the t value it received. Confirm it matches your input exactly. Mismatches usually indicate a time format misunderstanding or client-side formatting issue.
5. Validate with a real email address. Use a known good email (e.g., a test account you control) to confirm the full flow — from API call to verification result. This confirms both timestamp handling and address validation logic work together.

Common issues and fixes

Many developers accidentally send microseconds instead of seconds. The API expects Unix seconds. If you're using a library like Moment.js or a JavaScript Date.now() call, remember it returns milliseconds. Convert it: Math.floor(Date.now() / 1000).

If you’re seeing timeouts or 400 errors, verify your Content-Type header is set to application/json and that your HTTP method is POST. The API does not accept GET requests for verification.

For bulk testing, use MailTester’s bulk verification to check multiple addresses at once. This gives you a full audit trail and lets you spot patterns in formatting errors.

Summary: Always use seconds for MailTester’s API timestamp

The `t=` parameter in MailTester’s email verification API must be in Unix seconds, not milliseconds or microseconds. Using any other format invalidates the request and results in an immediate rejection.

A single misaligned timestamp breaks the entire request cycle. Even a minor mismatch—such as passing milliseconds instead of seconds—will cause authentication failures and disrupt integration workflows.

To prevent issues, always use timestamps in seconds. Convert from other units using standard practices: divide milliseconds by 1000, or microseconds by 1,000,000. Verify your system’s timestamp output matches this requirement before sending requests.

Sources

• Belkins' analysis of 7.5 million cold emails sent in 2025 found an average reply rate of just 0.45% measured against total emails sent, with replies declining 20% from the first half to the second half of the year. — Belkins Cold Email Response Rates Study (2025)

Keep reading

• Email verification and list hygiene for deliverability (complete guide)
• Modern Email Verification Platforms Reject RSA-SHA1 Due to a= Mismatch
• Fixing email security verification error due to t= microsecond timestamp
• Email Verification Platform Detecting Embedded CR in Digital Signature b=
• Email Verification API That Checks for h= Tag Canonicalization Skew

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

Frequently asked questions

What format does MailTester’s email verification API expect for the timestamp?

The API expects the `t=` parameter in Unix seconds (UTC), not milliseconds or microseconds. Use integer seconds only.

Why is my API request rejected with a timestamp error?

The most common cause is sending a timestamp in milliseconds or microseconds. Ensure you are using seconds.

How do I convert milliseconds to seconds for the API?

Divide the timestamp by 1000 and use the integer result. For example, 1704067200123 ms becomes 1704067200 seconds.

Does MailTester accept fractional seconds?

No. The timestamp must be a whole integer. Fractional values are rejected.

Can I use a future timestamp with the API?

No. The API rejects any timestamp more than 60 seconds in the future to prevent replay attacks.

How does MailTester validate the timestamp?

It checks the timestamp against server time with a 60-second window. Requests outside this range are rejected.

What should I do if my timestamp conversion is correct but still rejected?

Verify your system clock is synchronized with NTP. A misaligned system clock can cause timestamp errors.

Does MailTester support microseconds in any API field?

No. All timestamps in the API are in seconds. The `t=` parameter must be an integer in seconds.

How can I test my email verification API integration?

Use the MailTester sandbox endpoint with a valid email and a current timestamp to verify functionality.

Can I reuse a timestamp for multiple API calls?

No. Each request must use a unique, current timestamp to prevent replay attacks.

Is there an automatic timestamp feature in MailTester’s API?

No. You must generate and include the timestamp yourself. The API does not manage it on your behalf.

Why not use microseconds for more precision?

Microsecond-level timestamps increase payload size and parsing complexity. Seconds provide sufficient precision for security checks.