Is there a “no-reply” email header?

Question

I often see automated emails postfixed with a message like

Amazon:

*Please note: this e-mail was sent from an address that cannot accept incoming e-

Answer 1

Is there such a header?

No. I'm pretty sure there isn't anything like that; and even if there is, it'd be non-standard and not widely supported, so it'd be pretty much useless at the moment. Even if it were to become standard, any such header would presumably just be informational; and for backwards-compatibility, support would have to be entirely optional for email clients. Clients would be slow to implement it, and many users would still be on old versions of mail clients.

If not, has it ever been discussed by the groups that control email formats?

Probably. People have had a long time to suggest all manner of things with email, but my gut feeling is that it would never be implemented; well... not unless there is a fundamental shift in the ideas of what email is designed to do. I'm sure Google would be much happier if you didn't even have a "Reply" button when they email you, so if anyone is pushing for it, it'll be the people who are already sending from donotreply@...

Email is designed to be sent from real mailboxes. RFC 2822 and RFC 5322 say:

In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message.

To me, that is a clear indication that email is designed as a method for conversation, rather than broadcast.

Probably the biggest killer to any change would be the little bit above that line, which would need to be entirely redefined; which would cause more problems than would be solved:

The originator fields also provide the information required when replying to a message. When the "Reply-To:" field is present, it indicates the address(es) to which the author of the message suggests that replies be sent. In the absence of the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es) specified in the "From:" field unless otherwise specified by the person composing the reply.

Answer 2

No, there's no no-reply header.

However, you can add an empty reply-to header:

reply-to: <>

Which is valid according to RFC 5322, Section 3.6.2. Unfortunately, the RFC never actually specifies what an empty reply-to field means. I think most email clients just ignore it.

Answer 3

RFC 6854 updates RFC 5322 to allow the group construct to be used in the From field as well (among other things). A group can be empty, which is likely the only way you've ever seen the group syntax being used: undisclosed-recipients:;.

Section 1 of the RFC explicitly lists "no-reply" among the motivations for allowing the group construct in the From field:

The use cases for the "From:" field have evolved. There are numerous instances of automated systems that wish to send email but cannot handle replies, and a "From:" field with no usable addresses would be extremely useful for that purpose.

It provides the following example: From: Automated System:;

However, at the end of the same section, the RFC also says:

This document recommends against the general use of group syntax in these fields at this time

In section 3, the RFC clarifies that the group syntax in the From field is only for Limited Use.

Personally, I think this method should not be used – unless we're certain that all relevant clients display the originating domain in some other way (reconstructed from the Return-Path or a new header). Otherwise, this defeats all the efforts towards domain authentication (SPF, DKIM, and DMARC). Introducing an additional header field which causes clients to simply hide the reply button seems the much better approach to me.

The RFC comments on this aspect in section 5:

Some protocols attempt to validate the originator address by matching the "From:" address to a particular verified domain (for one such protocol, see the Author Domain Signing Practices (ADSP) document [RFC5617]). Such protocols will not be applicable to messages that lack an actual email address (whether real or fake) in the "From:" field. Local policy will determine how such messages are handled, and senders, therefore, need to be aware that using groups in the "From:" might adversely affect deliverability of the message.

What a failed opportunity…