Email Security to Make Sure Receved Emails Are From Valid Sources

感冒的梵高 • • 好物分享

SPF, DKIM, and DMARC are often associated with outbound email authentication, but they also play a role in inbound email verification. Here's the breakdown:

 
Related Post:

What SPF, DKIM and DMARC do for Outbound and Inbound emails?

1. SPF (Sender Policy Framework)

  • Outbound: Domain owners publish SPF records in DNS to specify which mail servers are authorized to send emails on their behalf.
  • Inbound: Receiving mail servers check the SPF record of the sender's domain to verify if the sending IP is authorized.
    • This usually will be ok since most of sender domain's spf txt record is allowing any ip.

2. DKIM (DomainKeys Identified Mail)

  • Outbound: The sending server signs emails with a private key.
  • Inbound: The receiving server uses the sender's public key (published in DNS) to verify the signature and ensure the message hasn't been altered.
    • Most of sender domain's DKIM cname records are not configured.

3. DMARC (Domain-based Message Authentication, Reporting & Conformance)

  • Outbound: Domain owners publish DMARC policies in DNS to instruct receivers on how to handle emails failing SPF/DKIM checks.
  • Inbound: Receiving servers enforce DMARC policies (reject, quarantine, or allow) based on the sender's domain's DMARC policy.
    • When your mail server receives an email, it checks the DMARC record of the sender's domain (not yours) to see what the sender wants done if the message fails SPF and/or DKIM alignment.
    • That policy can be:
      • p=none → Just monitor and report.
      • p=quarantine → Treat as suspicious (e.g., send to spam).
      • p=reject → Block the message outright.

      • So the enforcement is based on the sender’s DMARC policy, not the recipient’s.

How MS 365 Secure Inbound Emails?

✅ 1. Block Spoofing Using Microsoft 365 Anti-Phishing Policies

Microsoft’s Anti-Phishing (Defender for Office 365) is the #1 tool for inbound spoofing protection.

How to configure:

  1. Microsoft 365 Defender Portal

  2. Email & collaboration → Policies & rules → Threat policies

  3. “Anti-phishing” policies

  4. Create a new policy with these:

Recommended settings

Setting Recommended
Enable spoof intelligence ✔
Enable mailbox intelligence ✔
Enable domain impersonation protection ✔ Add your domains
Enable user impersonation protection ✔ Add VIP/executives
Automatic actions Quarantine or Reject spoofed messages
Safety tips ON

Spoof intelligence specifically detects legitimate vs malicious spoofed senders.

✅ 2. Use “Spoof Intelligence” to Block or Allow Cases Explicitly

You can see who is spoofing your domain:

Defender Portal → Email & collaboration → Spoof intelligence

You can:

  • Block unauthorized spoof senders

  • Allow legitimate senders (e.g., services that spoof on behalf)

This dramatically reduces false positives and false negatives.

✅ 3. Strengthen Anti-Malware & Anti-Spam Policies

Go to:

Microsoft 365 Defender → Policies & rules → Anti-spam

Inbound anti-spam settings:

  • Spoof detection → High confidence spam → Quarantine

  • Bulk mail threshold → More aggressive (lower number)

  • Enable “Mark as spam when sender-FQDN != HELO/EHLO domain” (optional but effective)

✅ 4. Disable Auto-Forwarding (reduces spoofing abuse)

Admins should block automatic external forwarding:

Admin Center → Settings → Org settings → Mail → Automatic forwarding
Set: Automatic external forwarding = Off (except approved accounts)

Spoofers often combine forwarding + impersonation.

✅ 5. Protect Your Own Domain From Being Spoofed (External)

If attackers spoof your domain outside Microsoft 365, only DMARC can prevent it.

If you use additional gateways (like Proofpoint), ensure:

  • Proofpoint → O365 connectors → SPF/DKIM/DMARC alignment supported

  • DMARC alignment required for inbound

Override Sender's DMARC Policy

Most mail gateways (e.g., Microsoft 365, Google Workspace, Proofpoint) allow administrators to:

  • Ignore the sender’s DMARC policy.
  • Apply custom actions (reject, quarantine, allow) based on your own rules.
  • Use additional signals like reputation, SPF/DKIM results, or internal allowlists.

Best Practice

  • Be cautious when overriding. If you ignore DMARC completely, you weaken anti-spoofing protections.
  • Common approach:
    • Honor p=reject for high-risk domains (banks, payment providers).
    • Override for trusted partners with known misconfigurations.

1 Modify Anti‑Phishing Policy 

  1. Go to Microsoft 365 Defender portal: security.microsoft.com
  2. Navigate to: Email & collaboration → Policies & rules → Threat policies → Anti‑phishing
  3. Edit an existing policy or Create a new one.
  4. On the Actions page, look for:
    • “Honor DMARC record policy when the message is detected as spoof.”; this option allows you to maintain default behavior.
    • To override, adjust the action under “If message is detected as spoof”—for example, select Quarantine or Reject, regardless of the sender’s DMARC setting.

Or it might looks like this screenshot:

2 Use PowerShell to Strengthen Enforcement

Microsoft's default behavior sometimes stamps exceptions (like SCL = –1) which bypass DMARC rejection. To ensure enforcement:

Get-OrganizationConfig | fl Identity,RejectDirectSend
Set-OrganizationConfig -RejectDirectSend $true
  • This setting blocks unauthenticated direct-to-MX mail and supports consistent DMARC enforcement.

3 Transport Rule to Catch DMARC Failures

If stricter control is needed, create a Mail Flow rule:

  1. In the Exchange admin center under Mail flow → Rules, click New rule….
  2. Use More options… to refine:
    • Apply this rule if…: A message header → includes
      • Header name: Authentication-Results
      • Phrase: dmarc=fail action=oreject
  3. Do the following…: choose Reject the message with explanation, Quarantine, or Delete. [prodmarc.com], [blog.matrixpost.net]

This ensures only messages genuinely failing DMARC (not simply flagged as spoof) get blocked.

Override Options:

Layer

Customizable Action

Purpose

Anti‑Phishing Policy

Honor, Quarantine, Reject

Override default “honor DMARC” choice

PowerShell Org Config

RejectDirectSend = true

Prevent bypass via DMARC exceptions like SCL –1

Mail Flow Rule

Quarantine or Reject

Block DMARC-failed messages flagged as action=oreject

Microsoft 365’s Anti-Phishing policy does not override the sender’s DMARC policy directly.

Here’s why:

  • DMARC enforcement is advisory: The sender publishes a DMARC policy (p=none, quarantine, reject) in DNS, but Microsoft 365 does not automatically honor it by rejecting or quarantining messages. Instead, DMARC results are used as a signal in spam/phishing scoring.
  • Anti-Phishing policies influence how spoofed messages are treated (e.g., move to Junk, quarantine), but they do not explicitly enforce the sender’s DMARC policy. They work independently of the sender’s published DMARC instructions.
  • If you want to enforce DMARC strictly, you must use:
    • Mail flow rules (based on Authentication-Results header showing dmarc=fail).
    • Or third-party gateways that honor DMARC policies.

Key Difference

  • Sender’s DMARC policy: Advisory for receivers.
  • Microsoft Anti-Phishing policy: Internal decision-making for spoof detection, not DMARC enforcement.

Others

inbound connector in exchange online

- limit ip addresses
https://blog.51sec.org

版权声明：
作者：感冒的梵高
链接：https://www.techfm.club/p/227749.html
来源：TechFM
文章版权归作者所有，未经允许请勿转载。

THE END
分享
二维码
< <上一篇
下一篇>>