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 now require inbound messages to include an RFC-compliant From address as described in this topic. This enforcement was enabled in November 2017.

Notes:

  • If you regularly receive email from organizations that have malformed From addresses as described in this topic, 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 5321.MailFrom address (also known as the MAIL FROM 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 5322.From (also known as the 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 topic.

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.

    These are some additional considerations for the EmailAddress value:

    • Only one email address.
    • We recommend that you do not separate the angle brackets with spaces.
    • Don't include additional text after the email address.

Examples of valid and invalid From addresses

The following From email addresses are valid:

  • From: sender@contoso.com

  • From: <sender@contoso.com>

  • From: < sender@contoso.com > (Not recommended because there are spaces between the angle brackets and the email address.)

  • From: "Sender, Example" <sender.example@contoso.com>

  • From: "Microsoft 365" <sender@contoso.com>

  • From: Microsoft 365 <sender@contoso.com> (Not recommended because the display name is not enclosed in double quotation marks.)

The following From email addresses are invalid:

  • No From address: Some automated messages don't include a From address. In the past, when Microsoft 365 or Outlook.com received a message without a From address, the service added the following default From: address to make the message deliverable:

    From: <>

    Now, messages with a blank From address are no longer accepted.

  • From: Microsoft 365 sender@contoso.com (The display name is present, but the email address is not enclosed in angle brackets.)

  • From: "Microsoft 365" <sender@contoso.com> (Sent by a process) (Text after the email address.)

  • From: Sender, Example <sender.example@contoso.com> (The display name contains a comma, but is not enclosed in double quotation marks.)

  • From: "Microsoft 365 <sender@contoso.com>" (The whole value is incorrectly enclosed in double quotation marks.)

  • From: "Microsoft 365 <sender@contoso.com>" sender@contoso.com (The display name is present, but the email address is not enclosed in angle brackets.)

  • From: Microsoft 365<sender@contoso.com> (No space between the display name and the left angle bracket.)

  • From: "Microsoft 365"<sender@contoso.com> (No space between the closing double quotation mark and the left angle bracket.)

Suppress auto-replies to your custom domain

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

  • Choose an email domain that can't receive email. For example, if your 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.

You can't override the From address requirements for outbound email that you send from Microsoft 365. In addition, Outlook.com will not allow overrides of any kind, even through support.

Other ways to prevent and protect against cybercrimes in Microsoft 365

For more information on how you can strengthen your organization against phishing, spam, data breaches, and other threats, see Top 10 ways to secure Microsoft 365 for business plans.