How EOP validates the From address to prevent phishing
Tip
Did you know you can try the features in Microsoft Defender for Office 365 Plan 2 for free? Use the 90-day Defender for Office 365 trial at the Microsoft Defender portal trials hub. Learn about who can sign up and trial terms on Try Microsoft Defender for Office 365.
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.MailFromaddress, 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.Fromaddress 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:
| Address | Comments |
|---|---|
From: sender@contoso.com |
OK |
From: <sender@contoso.com> |
OK |
From: < sender@contoso.com > |
OK, but not recommended because there are spaces between the angle brackets and the email address. |
From: "Sender, Example" <sender.example@contoso.com> |
OK |
From: "Microsoft 365" <sender@contoso.com> |
OK |
From: Microsoft 365 <sender@contoso.com> |
OK, but not recommended because the display name isn't enclosed in double quotation marks. |
The following table contains examples of From addresses that aren't valid:
| Address | Comments |
|---|---|
| No From address | When a message arrives at Microsoft 365 or Outlook.com without a From address, we try to assign the MAIL FROM address to the From address to ensure the message is deliverable. Currently, these messages are accepted by the service, even if the original From address is From: <>. |
From: <firstname lastname@contoso.com> |
The email address contains a space. |
From: Microsoft 365 sender@contoso.com |
The display name is present, but the email address isn't 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 isn't 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 isn't 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 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.