The Date header

The Date header records when the sender's software considered the message finished and ready to send, written as local time plus an offset from UTC, for example Mon, 26 Oct 2026 09:14:05 -0400. To get UTC, subtract the offset: 09:14:05 minus (−4 hours) is 13:14:05 UTC. The sender's own device or software sets this value, so it can be wrong (a bad clock) or deliberately faked. The way to check it is to compare it with the timestamp your provider wrote in its first inbound Received: header, which comes from a clock you trust.

Date: Mon, 26 Oct 2026 09:14:05 -0400

The format

RFC 5322 §3.3 defines the date-time syntax:

[day-of-week ","] day month year hour ":" minute [":" second] zone

• Day of week (Mon … Sun) is optional, but if present it must match the date.
• Day is one or two digits; month is a three-letter English abbreviation (Jan … Dec); year is four digits.
• Time is 24-hour hh:mm, with optional seconds. Second 60 is allowed for leap seconds.
• Zone is +hhmm or -hhmm: the offset from UTC.

Every message must have exactly one Date field (RFC 5322 §3.6). It's one of only two mandatory headers, along with From.

What the time means

RFC 5322 §3.6.1 says Date is the moment the author (or their software) declared the message complete and ready to send: typically when you press Send. It is explicitly not the time the message was transmitted. If you write an email on a plane with no connection, the Date reflects when you hit Send, even if it leaves your outbox hours later. Scheduled-send features and outbox queues can produce similar gaps, and how each mail app sets Date for a scheduled message varies.

Time zones and offsets

The zone tells you how far the local time is from UTC (RFC 5322 §3.3):

• + means ahead of UTC (east), - means behind (west).
• The first two digits are hours, the last two minutes. +0530 is 5 hours 30 minutes ahead; -0930 is 9 hours 30 minutes behind.
• +0000 means the time is in UTC.
• -0000 is special: the time is UTC, but the sending system is signaling that it doesn't know its local zone.

Offsets don't name a zone. -0400 could be US Eastern Daylight Time or several other places. Don't assume a location from the offset alone.

Converting to UTC by hand

UTC = local time − offset. Flip the offset's sign and add it.

Watch the date roll over, as in the last two rows: large offsets near midnight move the UTC time into a different day.

Obsolete forms

Older or sloppy software still produces forms the current standard has moved to an "obsolete" section that readers must accept but writers mustn't produce (RFC 5322 §4.3):

• Named zones: UT and GMT mean +0000. The US names are fixed offsets: EST −0500, EDT −0400, CST −0600, CDT −0500, MST −0700, MDT −0600, PST −0800, PDT −0700.
• Military single-letter zones (A–Z, except J): an old specification defined them inconsistently, so RFC 5322 §4.3 says to treat them as -0000 (unknown) unless you know otherwise. Z is often meant as UTC, but don't rely on it.
• Other names like CET, BST or IST were never standard. They're ambiguous (IST can mean India, Ireland or Israel) and should be treated as unknown.
• Two-digit years: 00–49 mean 2000–2049; 50–99 mean 1950–1999. Three-digit years get 1900 added.
• Extra comments and whitespace between parts of the date.

SMTP servers may not use these obsolete forms in the dates they write into Received: lines (RFC 5321 §4.4), so trace timestamps should always have numeric offsets. Obsolete forms in Date aren't proof of anything bad, but they do say something about the sending software, and a supposedly modern corporate message with EST and a two-digit year is unusual.

Why Date can be wrong or forged

Date is written by the sender's mail app or sending script. Nothing on the way checks it:

• Wrong clocks. A device with a bad clock or wrong time zone produces a wrong Date. You'll see the right time with the wrong offset (an hour out around daylight-saving changes), or a date years in the past.
• Deliberate backdating or future-dating. Spammers sometimes set future dates to keep a message at the top of date-sorted inboxes. Forgers backdate messages to fit a story, for example to "prove" an instruction was sent before a deadline.
• Re-sent or replayed messages. A message sent again with the original headers keeps its original Date.

If the message has a DKIM signature that covers date in h= and passes, the Date hasn't been changed since signing. That still doesn't mean the signer's clock was right. The signature's own t= tag records when it was signed, from the signing server's clock, which is another useful comparison point.

Checking Date against Received

The reliable timestamp is in your provider's first inbound Received header: the topmost line where your provider accepted the message from an outside server. Its date comes from your provider's clock.

1. Convert both times to UTC.
2. Compare. Normally the Received time is a few seconds to a few minutes after Date.

How to read the gap:

• Seconds to minutes later: normal.
• Hours later: usually a queued or delayed message, an offline sender, greylisting or a scheduled send. The other Received: lines will show where the time went; see why is my email delayed.
• Date is after the Received time: the sender's clock is fast, or the Date was set to the future on purpose. A few minutes is clock drift; days is suspicious.
• Days or years earlier: a wrong clock, a re-sent old message, or a backdated forgery. For a message that matters, such as a disputed payment instruction, this is worth investigating.

Example:

Received: from out.example.net (out.example.net [203.0.113.40])
        by mx-in-3.mail.example.org with ESMTPS id 7Hq2Xc;
        Mon, 26 Oct 2026 13:14:08 +0000
Date: Mon, 26 Oct 2026 09:14:05 -0400

Date in UTC is 13:14:05, Received is 13:14:08: three seconds apart. That's completely consistent.

The analyser lays out the Received chain as a timeline with the delay between hops, which makes it quick to find the first trustworthy timestamp to compare against.