{
	"id": "58c70297-6d70-4442-90b3-4c11a395b9a6",
	"created_at": "2026-04-06T01:29:58.619626Z",
	"updated_at": "2026-04-10T03:21:27.725327Z",
	"deleted_at": null,
	"sha1_hash": "4f36690ec51e589a05883bbc683f9f6ef6d485d4",
	"title": "Anti-spoofing protection - Microsoft Defender for Office 365",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 92731,
	"plain_text": "Anti-spoofing protection - Microsoft Defender for Office 365\r\nBy chrisda\r\nArchived: 2026-04-06 00:18:26 UTC\r\nAll organizations with cloud mailboxes include features to help protect against spoofed (forged) senders Spoofing\r\nis a common technique used by attackers. Spoofed messages appear to originate from someone or somewhere\r\nother than the actual source. This technique is often used in phishing campaigns designed to get user credentials.\r\nAnti-spoofing technology in Microsoft 365 specifically examines forgery of the From header in the message body\r\n(also known as the 5322.From address, From address or P2 sender), because email clients show the From header\r\nvalue as the message sender. When Microsoft 365 has high confidence the From header is forged, the message is\r\nidentified as spoofed.\r\nThe following anti-spoofing technologies are available in the built-in security features for all cloud mailboxes:\r\nEmail authentication: An integral part of any anti-spoofing effort is the use of email authentication (also\r\nknown as email validation) by SPF, DKIM, and DMARC records in DNS. You can configure these records\r\nfor your domains so destination email systems can check the validity of messages that claim to be from\r\nsenders in your domains. For inbound messages, Microsoft 365 requires email authentication of sender\r\ndomains. For more information, see Email authentication.\r\nMicrosoft 365 analyzes and blocks messages based on the combination of standard email authentication\r\nmethods and sender reputation techniques.\r\nDiagram showing Microsoft 365 anti-spoofing checks.\r\nSpoof intelligence insight: Review detected spoofed messages from senders in internal and external\r\ndomains during the last seven days. For more information, see Spoof intelligence insight.\r\nAllow or block spoofed senders in the Tenant Allow/Block List: When you override the verdict in the\r\nspoof intelligence insight, the spoofed sender becomes a manual allow or block entry that only appears on\r\nthe Spoofed senders tab on the Tenant Allow/Block Lists page at\r\nhttps://security.microsoft.com/tenantAllowBlockList?viewid=SpoofItem. You can also manually create\r\nallow or block entries for spoof senders before spoof intelligence detects them. For more information, see\r\nSpoofed senders in the Tenant Allow/Block List.\r\nAnti-phishing policies: In the built-in security features for all cloud mailboxes and in Microsoft Defender\r\nfor Office 365, anti-phishing policies contain the following anti-spoofing settings:\r\nTurn spoof intelligence on or off.\r\nTurn unauthenticated sender indicators in Outlook on or off.\r\nSpecify the action for blocked spoofed senders.\r\nhttps://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-spoofing-protection?view=o365-worldwide\r\nPage 1 of 5\n\nFor more information, see Spoof settings in anti-phishing policies.\r\nAnti-phishing policies in Defender for Office 365 contain addition protections, including impersonation\r\nprotection. For more information, see Exclusive settings in anti-phishing policies in Microsoft Defender for\r\nOffice 365.\r\nSpoof detections report: For more information, see Spoof Detections report.\r\nMicrosoft 365 organizations with Defender for Office 365 (included or in add-on subscriptions) have Real-time detections (Plan 1) or Threat Explorer (Plan 2) to view information about phishing attempts. For more\r\ninformation, see Microsoft 365 threat investigation and response.\r\nTip\r\nIt's important to understand that a composite authentication failure doesn't directly result in blocking a message.\r\nMicrosoft 365 using a holistic evaluation strategy that considers the overall suspicious nature of a message along\r\nwith composite authentication results. This method is designed to mitigate the risk of incorrectly blocking\r\nlegitimate email from domains that might not strictly adhere to email authentication protocols. This balanced\r\napproach helps distinguish genuinely malicious email from message senders that simply fail to conform to\r\nstandard email authentication practices.\r\nSpoofed senders in messages have the following negative implications for users:\r\nDeception: Messages from spoofed senders might trick the recipient into giving up their credentials,\r\ndownloading malware, or replying to a message with sensitive content (known as business email\r\ncompromise or BEC).\r\nThe following message is an example of phishing that uses the spoofed sender\r\nmsoutlook94@service.outlook.com :\r\nPhishing message impersonating service.outlook.com.\r\nThis message didn't come from service.outlook.com, but the attacker spoofed the From header field to\r\nmake it look like it did. The sender attempted to trick the recipient into selecting the change your\r\npassword link and providing their credentials.\r\nThe following message is an example of BEC that uses the spoofed email domain contoso.com:\r\nPhishing message - business email compromise.\r\nThe message looks legitimate, but the sender is spoofed.\r\nConfusion: Even users who know about phishing might have difficulty seeing the differences between real\r\nmessages and messages from spoofed senders.\r\nThe following message is an example of a real password reset message from the Microsoft Security\r\naccount:\r\nhttps://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-spoofing-protection?view=o365-worldwide\r\nPage 2 of 5\n\nMicrosoft legitimate password reset.\r\nThe message really did come from Microsoft, but users are conditioned to be suspicious. Because it's\r\ndifficult to the difference between a real password reset message and a fake one, users might ignore the\r\nmessage, report it as spam, or unnecessarily report the message to Microsoft as phishing.\r\nMicrosoft differentiates between two different types of spoofed senders in messages:\r\nIntra-org spoofing: Also known as self-to-self spoofing. For example:\r\nThe sender and recipient are in the same domain:\r\nFrom: chris@contoso.com\r\nTo: michelle@contoso.com\r\nThe sender and the recipient are in subdomains of the same domain:\r\nFrom: laura@marketing.fabrikam.com\r\nTo: julia@engineering.fabrikam.com\r\nThe sender and recipient are in different domains that belong to the same organization (that is, both\r\ndomains are configured as accepted domains in the same organization):\r\nFrom: cindy@tailspintoys.com\r\nTo: steve@wingtiptoys.com\r\nMessages that fail composite authentication due to intra-org spoofing contain the following header values:\r\nAuthentication-Results: ... compauth=fail reason=6xx\r\nX-Forefront-Antispam-Report: ...CAT:SPOOF;...SFTY:9.11\r\nreason=6xx indicates intra-org spoofing.\r\nSFTY is the safety level of the message.\r\n9 indicates phishing.\r\n.11 indicates intra-org spoofing.\r\nCross-domain spoofing: The sender and recipient domains are different, and have no relationship to each\r\nother (also known as external domains). For example:\r\nFrom: chris@contoso.com\r\nTo: michelle@tailspintoys.com\r\nMessages that fail composite authentication due to cross-domain spoofing contain the following headers\r\nvalues:\r\nhttps://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-spoofing-protection?view=o365-worldwide\r\nPage 3 of 5\n\nAuthentication-Results: ... compauth=fail reason=000/001\r\nX-Forefront-Antispam-Report: ...CAT:SPOOF;...SFTY:9.22\r\nreason=000 indicates the message failed explicit email authentication. reason=001 indicates the\r\nmessage failed implicit email authentication.\r\nSFTY is the safety level of the message.\r\n9 indicates phishing.\r\n.22 indicates cross-domain spoofing.\r\nFor more information about Authentication-Results and compauth values, see Authentication-results\r\nmessage header fields.\r\nMailing lists (also known as discussion lists) are known to have problems with anti-spoofing protection because of\r\nhow they forward and modify messages.\r\nFor example, Gabriela Laureano ( glaureano@contoso.com ) is interested in bird watching, so she joins the\r\nmailing list birdwatchers@fabrikam.com , and sends the following message to the list:\r\nFrom: \"Gabriela Laureano\" \u003cglaureano@contoso.com\u003e\r\nTo: Birdwatcher's Discussion List \u003cbirdwatchers@fabrikam.com\u003e\r\nSubject: Great viewing of blue jays at the top of Mt. Rainier this week\r\nAnyone want to check out the viewing this week from Mt. Rainier?\r\nThe mailing list server receives the message, modifies its content, and replays it to the members of list. The\r\nreplayed message has the same From address ( glaureano@contoso.com ), but a tag is added to the subject line,\r\nand a footer is added to the bottom of the message. This type of modification is common in mailing lists, and\r\nmight result in false positives for spoofing.\r\nFrom: \"Gabriela Laureano\" \u003cglaureano@contoso.com\u003e\r\nTo: Birdwatcher's Discussion List \u003cbirdwatchers@fabrikam.com\u003e\r\nSubject: [BIRDWATCHERS] Great viewing of blue jays at the top of Mt. Rainier this week\r\nAnyone want to check out the viewing this week from Mt. Rainier?\r\nThis message was sent to the Birdwatchers Discussion List. You can unsubscribe at any time.\r\nTo help mailing list messages pass anti-spoofing checks, do the following steps based on your circumstance:\r\nYour organization owns the mailing list:\r\nCheck the FAQ at DMARC.org: I operate a mailing list and I want to interoperate with DMARC,\r\nwhat should I do?.\r\nhttps://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-spoofing-protection?view=o365-worldwide\r\nPage 4 of 5\n\nRead the instructions at this blog post: A tip for mailing list operators to interoperate with DMARC\r\nto avoid failures.\r\nConsider updating your mailing list server so it supports ARC. For more information, see http://arc-spec.org.\r\nYour organization doesn't own the mailing list:\r\nAsk the maintainer of the mailing list to configure email authentication for the domain that the\r\nmailing list is relaying email from. The owners are more likely to act if enough members ask them\r\nto set up email authentication. While Microsoft also works with domain owners to publish the\r\nrequired records, it helps even more when individual users request it.\r\nCreate Inbox rules in your email client that move messages to the Inbox.\r\nUse the Tenant Allow/Block List to create an allow entry for the mailing list to treat it as legitimate.\r\nFor more information, see Create allow entries for spoofed senders.\r\nIf all else fails, you can report the message as a false positive to Microsoft. For more information, see Report\r\nmessages and files to Microsoft.\r\nAdmins of organizations that regularly send email to Microsoft 365 need to ensure the email is properly\r\nauthenticated. Otherwise, it might be marked as spam or phishing. For more information, see How to avoid email\r\nauthentication failures when sending mail to Microsoft 365.\r\nIn Microsoft 365, senders in user allowlists bypass parts of the filtering stack, including spoof protection. For\r\nmore information, see Outlook Safe Senders.\r\nIf possible, admins should avoid using allowed sender lists or allowed domain lists in anti-spam policies. These\r\nsenders bypass most of the filtering stack (high confidence phishing and malware messages are always\r\nquarantined). For more information, see Use allowed sender lists or allowed domain lists.\r\nSource: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-spoofing-protection?view=o365-worldwide\r\nhttps://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-spoofing-protection?view=o365-worldwide\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-spoofing-protection?view=o365-worldwide"
	],
	"report_names": [
		"anti-spoofing-protection?view=o365-worldwide"
	],
	"threat_actors": [],
	"ts_created_at": 1775438998,
	"ts_updated_at": 1775791287,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4f36690ec51e589a05883bbc683f9f6ef6d485d4.pdf",
		"text": "https://archive.orkl.eu/4f36690ec51e589a05883bbc683f9f6ef6d485d4.txt",
		"img": "https://archive.orkl.eu/4f36690ec51e589a05883bbc683f9f6ef6d485d4.jpg"
	}
}