RFC 10080 updates how email should handle the Expires header
News
RFC 10080 now defines use of the Expires header in general Internet email. A sender can include one field containing an RFC 5322 date-time to indicate when it considers the message no longer valid. That date is an expiry hint, not permission to stop delivery, recall the message, or erase it.
The RFC Editor issued the publication announcement on October 30, 2026 at 23:47:01 UTC, which was October 31 at 10:47:01 AEDT in Sydney. The document, Updated Use of the Expires Message Header Field, is a published IETF Proposed Standard that updates RFC 4021. My immediate priority for operators is reviewing existing behavior, especially rules that turn sender-provided dates into rejection or deletion decisions.
What changed with final publication
The older Expires registration in RFC 4021 discouraged general Internet use. RFC 10080 broadens that scope. Time-limited offers, event notices and notifications are examples of suitable messages, rather than categories now required to carry the header.
The news is final RFC publication, not a new Internet-Draft or a newly announced provider rollout. Publication creates no Gmail, Yahoo or Microsoft enforcement deadline and establishes no implementation status for those providers. I would keep standards compliance and deployment evidence separate when planning a release: a published specification gives developers a reference, while support in a particular service still needs its own evidence.
How senders should generate the header
For sending software, the concrete requirement is single-field behavior: a message MUST NOT contain more than one Expires field. The date uses RFC 5322 syntax. The plain text RFC provides the formal definition; this example illustrates a message whose sender-selected validity ends on November 3, 2026 at 17:00 UTC.
I recommend generating the date with the same maintained mail library used for other message dates. Decide which application component owns the value, so a campaign template and a later processing stage do not each append a field. Include tests that inspect the serialized message after every component has finished processing it.
Illustrative message headers with one Expires fieldtext
Date: Sun, 1 Nov 2026 09:00:00 +0000 From: Events <events@example.com> To: Recipient <recipient@example.net> Subject: Registration closes on November 3 Expires: Tue, 3 Nov 2026 17:00:00 +0000
For an event notice, check that the timestamp matches the intended cutoff and timezone. Keep the deadline visible in the message body as well. Registration availability or offer eligibility should remain an application decision, enforced by the relevant system. An email header cannot enforce either condition, and a recipient still needs understandable information when reading a saved copy.
What receiving software can do
Readers can de-emphasize expired messages or hide them. Receiving software MUST NOT reject or discard mail solely because Expires is present or its date has passed. Automatic deletion SHOULD NOT occur unless the mailbox owner deliberately configured it. These distinctions are set out in Section 5.
I would review interface behavior separately from storage behavior. A message disappearing from a default view is different from its underlying copy being deleted. Test both outcomes, including whether someone can recover the message through search and whether a cleanup preference has an understandable scope.
Reader presentation
An expiry indicator or a user-controlled view can help someone distinguish a current notice from an old one. Document the display choice and make it understandable without implying that the sender has revoked access.
Destructive handling
A filter that silently drops a message because its expiry date passed crosses into delivery handling. A cleanup job that deletes stored copies needs a separate review of mailbox-owner choices and retention requirements.
For a mailbox service, I recommend documenting the exact boundary between a display filter, a move operation and permanent deletion. Support staff need that distinction when investigating missing mail. Administrators also need enough logging to identify the rule responsible, rather than guessing that an expired header explains every disappearance.
Why expiry dates need security boundaries
The RFC's security considerations treat expiry values as untrusted. An attacker can choose a past date to reduce visibility or a near-future date to make a message harder to find later. These are described risks, not a report of a new exploit or breach.
The operational concern is evidence handling. If a recipient reports a suspicious message after its stated deadline, investigators still need to understand what arrived and what processing occurred. I recommend checking that expiry-based presentation does not silently remove the material needed to examine a complaint or reconstruct a delivery incident.
Keep expiry outside trust decisions
Expires is not a spam verdict or proof of identity. It does not replace SPF, DKIM, DMARC, content filtering, recipient preferences or retention obligations. Treat a sender-selected date as input to a documented workflow, rather than authority to bypass those controls.
My security review would include the complaint path and any training pipeline that consumes user activity. Verify that hidden or untouched messages are not automatically classified as wanted merely because nobody reported them. This is a review recommendation, not an additional protocol requirement introduced by RFC 10080.
Who should review existing behavior
The affected teams include sending-software developers, MTA operators, mailbox services, email-client developers, retention-policy owners and senders of time-sensitive messages. The review belongs wherever a system creates the field or makes a decision using it. Teams whose software never emits or interprets Expires have a different workload from teams already running expiry rules.
I would assign ownership before changing production behavior. The person controlling message templates often does not control a receiving filter or archive. A short ownership map helps prevent a sender-side update from being mistaken for authorization to change a recipient-side retention policy.
|
|
|---|---|
Sending developers | Syntax and duplicates |
MTA operators | Reject and discard rules |
Mailbox services | Storage and cleanup |
Client developers | Views and preferences |
Retention owners | Evidence preservation |
Time-sensitive senders | Meaningful cutoff dates |
Suggested review ownership, rather than a mandated deployment plan.
For shared systems, record the effective configuration as well as the intended policy. A documented default does not explain an account with a custom rule. Include the mailbox owner's settings in the review and check how administrative retention requirements interact with those choices.
Practical checks for existing implementations
For systems already emitting or parsing Expires, I would start with a controlled set of messages and inspect the complete path. Change one characteristic at a time so that a result can be traced to the header, another filter, or an explicit user preference.
The following checks are an implementation review plan. They do not imply a provider rollout, and the suggested test cases are not a new conformance suite specified by the RFC.
- Generation: Check RFC 5322 date parsing, timezone handling and a single Expires field. Include malformed values and duplicate fields in development tests.
- Transport: Compare otherwise equivalent messages with absent, past and future expiry values. Review any rejection or discard rule whose only trigger is Expires.
- Presentation: Inspect default views and search results. Check that labels explain the sender-selected deadline without implying recall or confirmed danger.
- Cleanup: Review user-selected deletion settings and their scope. Record how the mailbox owner deliberately enabled cleanup and how they can change it.
- Preservation: Check abuse-investigation access and retention obligations. Confirm that a display preference does not accidentally remove a required stored copy.
Keep the original test message and processing logs together. For a malformed value, document the parser's actual result instead of assuming every component interprets it identically. For duplicate fields, fix the emitting software and investigate downstream handling without inventing a receiver rule that the RFC does not specify.
Where authentication testing fits
Expires adds no required DNS record change and promises no inbox-placement advantage. I would test the actual outgoing message after a template or mail-library change, then check authentication independently. Inspect raw headers for the expiry field rather than assuming that a high-level delivery result confirms its syntax or handling.
Suped is our email authentication platform. Its email tester provides authentication and other message checks, while DMARC monitoring helps investigate authentication failures across sending sources. Those workflows remain useful alongside a header change. They do not establish how a recipient implements Expires, and an authentication pass does not establish that a sender-selected deadline is trustworthy.
Review existing rules before expanding use
My next step for an operator already using Expires would be to locate every component that reads it and attach an owner to each resulting action. Prioritize silent discard rules and cleanup jobs, then review presentation. Keep changes small enough that logs and controlled messages can establish what each component does.
For senders considering the field for the first time, choose a message with a genuine cutoff, validate the generated headers and keep the deadline readable in the body. Do not schedule DNS changes or promise recipient-side cleanup on the strength of publication alone.
Frequently asked questions
No. It is a published IETF Proposed Standard RFC, announced on October 30, 2026 UTC. It updates RFC 4021.
No. It supplies a sender-selected expiry hint. It cannot guarantee recall or deletion of a delivered message.
No. Publication does not establish implementation by any particular provider or create a provider enforcement deadline.
Check that the deadline is meaningful, the date has valid RFC 5322 syntax, and the final message contains only one Expires field. Keep the deadline visible in the body.
