How EOP validates the From address to prevent phishing

Phishing attacks are a constant threat to any email organization. In addition to using spoofed (forged) sender email addresses, attackers often use values in the From address that violate internet standards. To help prevent this type of phishing, Exchange Online Protection (EOP) and Outlook.com require inbound messages to include an RFC-compliant From address as described in this article.

• If you regularly receive email from organizations that have malformed From addresses as described in this article, encourage these organizations to update their email servers to comply with modern security standards.

• The related Sender field (used by Send on Behalf and mailing lists) isn't affected by these requirements. For more information, see the following blog post: What do we mean when we refer to the 'sender' of an email?.

An overview of email message standards

A standard SMTP email message consists of a message envelope and message content. The message envelope contains information that's required for transmitting and delivering the message between SMTP servers. The message content contains message header fields (collectively called the message header) and the message body. The message envelope is described in RFC 5321, and the message header is described in RFC 5322. Recipients never see the actual message envelope because it's generated by the message transmission process, and it isn't actually part of the message.

• The MAIL FROM address (also known as the 5321.MailFrom address, P1 sender, or envelope sender) is the email address that's used in the SMTP transmission of the message. This email address is typically recorded in the Return-Path header field in the message header (although it's possible for the sender to designate a different Return-Path email address).

• The From address (also known as the 5322.From address or P2 sender) is the email address in the From header field, and is the sender's email address that's displayed in email clients. The From address is the focus of the requirements in this article.

The From address is defined in detail across several RFCs (for example, RFC 5322 sections 3.2.3, 3.4, and 3.4.1, and RFC 3696). There are many variations on addressing and what's considered valid or invalid. To keep it simple, we recommend the following format and definitions:

From: "Display Name" <EmailAddress>

• Display Name: An optional phrase that describes the owner of the email address.

  • We recommend that you always enclose the display name in double quotation marks (") as shown. If the display name contains a comma, you must enclose the string in double quotation marks per RFC 5322.
  • If the From address includes a display name, the EmailAddress value must be enclosed in angle brackets (< >) as shown.
  • Microsoft strongly recommends that you insert a space between the display name and the email address.

• EmailAddress: An email address uses the format local-part@domain:

  • local-part: A string that identifies the mailbox associated with the address. This value is unique within the domain. Often, the mailbox owner's username or GUID is used.
  • domain: The fully qualified domain name (FQDN) of the email server that hosts the mailbox identified by the local-part of the email address.

  Also:

  • One email address only.
  • We recommend that you don't separate the angle brackets with spaces.
  • Don't include text after the email address.

Examples of good and bad From addresses

The following table contains examples of valid From addresses:

The following table contains examples of From addresses that aren't valid:

Suppress auto-replies to custom domains

You can't use the value From: <> to suppress auto-replies. Instead, you need to set up a null MX record for the custom domain. After you set up the null MX record, all replies are naturally suppressed because there's no published address for the responding server to send messages to.

For the null MX record, choose an email domain that can't receive email. For example, if the primary domain is contoso.com, you might choose noreply.contoso.com. The null MX record for this domain consists of a single period. For example:

noreply.contoso.com IN MX .

For more information about setting up MX records, see Create DNS records at any DNS hosting provider for Microsoft 365.

For more information about publishing a null MX, see RFC 7505.

Override From address enforcement

To bypass the From address requirements for inbound email, you can use the IP Allow List (connection filtering) or mail flow rules (also known as transport rules) as described in Create safe sender lists in Microsoft 365. Outlook.com doesn't allow overrides of any kind, even through support requests.

You can't override the From address requirements for outbound email that you send from Microsoft 365 or Outlook.com.

Other ways to prevent and protect against cybercrimes in Microsoft 365

For more information on how to strengthen your organization against phishing, spam, data breaches, and other threats, see Best practices for securing Microsoft 365 for business plans.