Email forwarding in Outlook Admin is configured through the Microsoft 365 Admin Center, the Exchange Admin Center (EAC), or PowerShell, and the fastest path is to open the user’s mailbox, select Manage email forwarding, enter the destination address, and save. That single click hides a dense web of rules, defaults, and federal laws that can turn a simple productivity tweak into a compliance disaster.
Microsoft blocks external auto-forwarding by default under the Outbound Spam Filter Policy, a change rolled out in 2020 and hardened through 2026 to fight Business Email Compromise (BEC). The FBI Internet Crime Complaint Center reported that BEC losses exceeded $2.9 billion in 2024, with malicious auto-forwarding rules identified as a top attack vector. Admins who misconfigure forwarding can trigger HIPAA breaches, SOX violations, SEC 17a-4 retention failures, and state data-breach notification duties within hours.
This guide walks through every supported method, every forwarding type, every legal trap, and every mistake that costs organizations money or data.
Here is what you will learn:
- 🧭 How to configure forwarding in the Microsoft 365 Admin Center, the new EAC, and Exchange Online PowerShell
- ⚖️ Which U.S. federal and state laws govern forwarded email content and retention
- 🛡️ How to keep external auto-forwarding compliant with Microsoft’s anti-phishing defaults
- 📬 The difference between mailbox forwarding, inbox rules, transport rules, and shared mailbox redirection
- 🚨 The seven costliest mistakes admins make and how to avoid each one
Understanding Email Forwarding in Outlook Admin
Email forwarding in the Microsoft 365 ecosystem is not a single feature. It is a cluster of overlapping mechanisms that each behave differently, log differently, and fall under different legal regimes. Admins who treat them as interchangeable create silent compliance gaps that auditors find later.
The term Outlook Admin in 2026 refers to three interfaces: the Microsoft 365 Admin Center, the Exchange Admin Center at admin.exchange.microsoft.com, and Exchange Online PowerShell. Each surface exposes different forwarding controls, and each writes to different audit logs.
Forwarding itself splits into four technical types. Mailbox forwarding sets the ForwardingAddress or ForwardingSmtpAddress attribute on the mailbox object. Inbox rules run client-side or server-side when a message arrives. Mail flow rules, also called transport rules, run on every message at the Exchange Online transport layer. Shared mailbox forwarding uses the same attributes as a regular mailbox but carries extra licensing and delegation nuances.
Why Forwarding Exists and Why It Matters
Forwarding solves real problems. Employees on leave need coverage, departing staff need smooth handoffs, and distribution lists need redirection. The Microsoft Learn documentation on mail flow explains that forwarding is part of the broader mail flow architecture.
Forwarding also creates risk. A forwarded message leaves the tenant boundary, which means tenant-level DLP, encryption, and retention policies may not travel with it. The consequence is that protected health information or material non-public information can land in a Gmail inbox outside the organization’s legal control.
A common misconception is that forwarding inside the same tenant is automatically safe. It is not, because internal forwarding still bypasses mailbox-level journaling in some configurations, which can break SEC 17a-4 record retention for broker-dealers.
The Governing Microsoft Defaults
Microsoft’s anti-phishing policy in Defender for Office 365 blocks automatic external forwarding by default. This default is called AutoForwardMode: Automatic – System-controlled, and it evaluates each tenant’s risk posture.
The consequence of ignoring this default is bounced messages and phantom forwarding loops. A mini-scenario: an admin enables ForwardingSmtpAddress to a personal Gmail account without whitelisting it in the outbound spam policy, and every forwarded message silently non-delivers.
The common misconception is that setting the forwarding attribute is enough. It is not, because the outbound spam filter sits downstream and overrides mailbox-level settings.
Method 1: Forwarding in the Microsoft 365 Admin Center
The Microsoft 365 Admin Center is the easiest surface for one-off forwarding changes. It is designed for Global Admins, Exchange Admins, and User Admins who need to act quickly without touching PowerShell.
To configure forwarding, sign in to admin.microsoft.com, expand Users, select Active users, click the target user, open the Mail tab, and select Manage email forwarding. Enter the forwarding SMTP address, decide whether to keep a copy in the original mailbox, and save.
The Keep a copy checkbox is the single most important decision on this screen. Leaving it unchecked means the original mailbox receives nothing, which breaks eDiscovery holds under the Federal Rules of Civil Procedure Rule 37(e). The consequence is court-ordered sanctions for spoliation of electronically stored information.
Step-By-Step Walkthrough With Screenshots In Mind
Step one is licensing verification. The target user must hold an Exchange Online Plan 1, Plan 2, or any bundle that includes one, such as Microsoft 365 Business Standard, Business Premium, E3, or E5. The consequence of skipping this check is a greyed-out forwarding option and a support ticket.
Step two is destination validation. The forwarding address must be a valid SMTP address that accepts inbound mail from Microsoft’s outbound IP range. The consequence of a blocked destination is a flood of non-delivery reports in the original user’s inbox.
Step three is the audit trail. Every forwarding change writes to the Microsoft Purview Audit log under the operation Set-Mailbox. Admins who disable auditing lose the forensic record that regulators demand during a breach investigation.
Named Example: Maria at a Small Medical Clinic
Maria runs IT for a 40-person orthopedic clinic in Ohio. Her office manager goes on maternity leave, and Maria forwards the manager’s mail to a covering staff member inside the tenant. Because the destination is internal and both users are covered by the tenant’s HIPAA Business Associate Agreement, the forward is compliant under the HHS HIPAA Privacy Rule.
The consequence of forwarding instead to the manager’s personal Gmail would be an impermissible disclosure of protected health information, triggering the HIPAA Breach Notification Rule at 45 CFR 164.400-414. The misconception that personal email is fine because the patient is the employee’s relative does not hold up under HIPAA’s minimum necessary standard.
Method 2: Forwarding in the Exchange Admin Center
The Exchange Admin Center at admin.exchange.microsoft.com gives admins finer-grained control than the Microsoft 365 Admin Center. It exposes mailbox attributes, mail flow rules, and recipient-level configuration in one place.
To set mailbox forwarding in the EAC, open Recipients, select Mailboxes, click the user, choose Manage email forwarding under the Mailbox tab, toggle Forward all emails sent to this mailbox, enter the address, and decide on the Keep a copy option. The EAC confirms the change and writes it to the same audit log as the Microsoft 365 Admin Center.
Creating a Mail Flow Rule for Conditional Forwarding
Mail flow rules, also known as transport rules, forward based on conditions instead of identity. The Microsoft guidance on mail flow rules explains that these rules evaluate every message at the transport layer.
A rule might redirect all messages containing the word invoice to the accounts payable team. The consequence of a poorly scoped rule is a privacy leak, because a rule that fires on the word medical could route personal messages to an unauthorized inbox.
The misconception here is that mail flow rules are safer than mailbox forwarding. They are not inherently safer, because they apply tenant-wide and can move mail the user never intended to share.
Named Example: David the Law Firm Administrator
David administers Exchange for a mid-sized law firm in Texas. He builds a mail flow rule that forwards every message containing a court docket number to the firm’s document management system. Because the rule runs at the transport layer, it bypasses individual mailbox rules and captures every matching message.
The consequence of omitting a conflict-of-interest filter is that a forwarded message could cross an ethical wall, violating the ABA Model Rule 1.10. The misconception that a technical forward does not constitute a disclosure under professional responsibility rules has cost firms their malpractice coverage.
Shared Mailbox Forwarding
Shared mailboxes are a common forwarding target and source. A shared mailbox does not require its own license unless it exceeds 50 GB or needs to send on behalf of the organization, per the Microsoft shared mailbox documentation.
Forwarding from a shared mailbox uses the same ForwardingSmtpAddress attribute. The consequence of forwarding a shared mailbox externally without documentation is that departing employees can redirect months of client correspondence to a personal address, and the admin never sees it until the shared mailbox is audited.
The misconception is that shared mailboxes are exempt from retention policies. They are not, and any forwarded message still triggers retention obligations under Microsoft Purview.
Method 3: Forwarding with Exchange Online PowerShell
PowerShell is the power user’s surface. It scales across hundreds of mailboxes, scripts into CI/CD pipelines, and exposes attributes the graphical interfaces hide.
Connect using the ExchangeOnlineManagement module. The canonical command is Connect-ExchangeOnline -UserPrincipalName [email protected]. After authenticating, the admin has access to Set-Mailbox, New-InboxRule, and New-TransportRule.
The Set-Mailbox Cmdlet
The Set-Mailbox cmdlet writes directly to the mailbox object. The syntax is Set-Mailbox -Identity [email protected] -ForwardingSmtpAddress [email protected] -DeliverToMailboxAndForward $true.
The -DeliverToMailboxAndForward parameter is the PowerShell equivalent of the Keep a copy checkbox. Setting it to $false means messages leave the tenant with no local copy, which can trigger SEC 17a-4(f) violations for broker-dealers who must preserve records in non-rewritable, non-erasable format.
The SEC rule 17a-4 requires electronic records to be retained for specified periods, and the consequence of losing a forwarded message is an enforcement action that can exceed $5 million per offense. The misconception that the destination mailbox’s copy satisfies 17a-4 is wrong, because the rule requires the record to be under the registrant’s control.
Bulk Forwarding Scripts
Bulk operations are PowerShell’s strength. A script can read a CSV of user-to-forward mappings and apply them in one pass, using Import-Csv and a foreach loop.
A poorly tested bulk script once forwarded 4,000 mailboxes to a typo’d external domain at a Fortune 500 company, per reporting by Krebs on Security. The consequence was a week-long incident response and mandatory state notifications under the California Consumer Privacy Act.
The misconception is that PowerShell dry-runs are unnecessary. They are essential, and the -WhatIf parameter exists specifically to simulate changes before committing them.
Named Example: Priya the MSP Engineer
Priya runs a managed service provider serving 60 small-business tenants. She uses a PowerShell script to audit every ForwardingSmtpAddress across all tenants every 24 hours and alerts on any external destination. The script writes to a SIEM, and any unapproved forward triggers a ticket.
The consequence of skipping this audit is an undetected BEC attack, because attackers who compromise an account almost always set a hidden forwarding rule first, per CISA Alert AA20-352A. The misconception that MFA alone stops forwarding-based BEC is false, because token theft and session hijacking bypass MFA entirely.
Legal and Regulatory Framework for Email Forwarding
Email forwarding is governed by a stack of federal laws, state statutes, and industry rules. Admins who treat forwarding as a purely technical decision invite enforcement actions that their legal team has no warning about.
At the federal level, the controlling regimes include HIPAA for health data, GLBA for financial data, SOX for public-company financial records, SEC 17a-4 for broker-dealers, FERPA for educational records, and the FTC Safeguards Rule for any financial institution the FTC regulates.
HIPAA and Protected Health Information
The HIPAA Security Rule requires covered entities to protect electronic protected health information. A forwarding rule that routes PHI to a non-covered destination is an impermissible disclosure.
The consequence is civil monetary penalties that can reach $1.9 million per violation category per year, under the HHS enforcement tiers. A mini-scenario: a nurse forwards patient scheduling email to her personal Gmail to stay on top of things, and three months later a Gmail breach exposes 900 patient names.
The misconception is that HIPAA only covers clinical data. It covers any identifier tied to care, including appointment times, so a forwarded calendar invite can be a breach.
SOX and SEC 17a-4
The Sarbanes-Oxley Act Section 802 criminalizes the destruction of records affecting federal investigations. A forwarding rule that moves financial communications outside the tenant’s retention policy can be construed as obstruction.
SEC 17a-4 requires broker-dealers to preserve communications in WORM format. The consequence of forwarding without preserving the original is a deficiency letter and potential suspension of the firm’s registration.
The misconception that auto-forwarding satisfies preservation is wrong, because the rule requires the original record under the registrant’s custody, not a copy in a third-party inbox.
FTC Safeguards Rule and GLBA
The FTC Safeguards Rule applies to any non-bank financial institution, which the FTC has interpreted broadly to include auto dealers, tax preparers, and mortgage brokers. A forwarding rule that sends customer financial data outside the institution triggers the rule’s incident notification duty.
The consequence of a notifiable incident involving 500 or more consumers is a 30-day notice to the FTC. The misconception that forwarding to a personal device for remote work is exempt has led to multiple FTC consent decrees since 2023.
State Data Breach Notification Laws
All 50 states now have breach notification laws. California’s CCPA and New York’s SHIELD Act are the most aggressive, and a mis-configured forwarding rule that exposes personal information triggers both.
The consequence is per-record statutory damages that stack quickly. The misconception that encryption-in-transit between Microsoft and Google satisfies state law is wrong, because state laws focus on the destination’s control, not the transport.
Three Most Popular Forwarding Scenarios
Admins encounter the same three scenarios over and over. Each has a technically correct configuration and a legally correct configuration, and they are not always the same.
Scenario Table 1: Employee Departure
| Forwarding Setup | Compliance Outcome |
|---|---|
| Forward to manager, keep copy, 90-day review | Clean handoff, meets most retention policies |
| Forward to personal email of departed employee | Impermissible disclosure, potential CFAA issue |
| Forward to shared mailbox, delete original account | License saved but eDiscovery hold broken |
Scenario Table 2: Executive Assistant Coverage
| Configuration | Consequence |
|---|---|
| Delegate access with no forwarding | Assistant sees mail, full audit trail preserved |
| Forward all mail to assistant, no copy | Executive loses visibility and record custody |
| Mail flow rule filtering only calendar invites | Precise, auditable, minimizes privacy exposure |
Scenario Table 3: Departing Contractor
| Action Taken | Resulting Risk |
|---|---|
| Disable account, set forwarding to supervisor | Low risk, preserves client continuity |
| Delete account immediately | High risk, mail bounces, client trust damaged |
| Contractor sets forward to personal inbox | Data exfiltration, potential trade secret theft |
Named-Person Examples in Practice
Concrete examples make abstract rules stick. These three personas illustrate the interaction of technical configuration and legal consequence.
James at a Community Bank
James is the IT director at a community bank in North Carolina regulated by the FDIC. A teller requests forwarding of her work email to her personal Yahoo address for weekend access. James denies the request because the FFIEC Information Security Booklet requires financial institutions to control the storage location of customer information.
The consequence of approving the request would be a finding at the next FDIC examination, citing inadequate controls under 12 CFR Part 30 Appendix B. The misconception that bank employees can consent to their own data exposure is false, because the duty runs to customers, not employees.
Aisha at a University
Aisha administers email for a public university. A professor asks her to forward student grade appeals to a co-investigator at a different institution. Aisha refuses because the Family Educational Rights and Privacy Act restricts disclosure of education records.
The consequence of forwarding would be loss of federal funding eligibility for the university. The misconception that academic collaboration is a FERPA exception is wrong, because the legitimate educational interest test applies only within the same institution.
Luis at a Public Company
Luis is a Microsoft 365 admin at a Nasdaq-listed software company. The CFO asks him to forward board email to an outside counsel’s personal Hotmail. Luis escalates because SEC Regulation FD governs selective disclosure of material non-public information.
The consequence of misdirected board email is a Reg FD violation and potential insider trading exposure. The misconception that attorney-client privilege protects the transmission is wrong, because privilege can be waived by using non-firm email systems.
Mistakes to Avoid
Admins repeat the same errors across industries. Each mistake below carries a specific negative outcome that auditors, regulators, or attackers will find.
- Forgetting to keep a copy in the original mailbox. The outcome is broken eDiscovery and potential FRCP Rule 37(e) sanctions.
- Forwarding externally without updating the outbound spam policy. The outcome is silent non-delivery and missed business-critical messages.
- Using inbox rules instead of mailbox forwarding for long-term redirection. The outcome is lost forwarding when the mailbox is migrated or the rule hits its size limit.
- Skipping the Microsoft Purview audit log review. The outcome is undetected attacker-installed forwarding rules during a BEC incident.
- Forwarding shared mailboxes without documenting the delegation. The outcome is an orphaned forward that survives employee offboarding.
- Ignoring state breach notification thresholds. The outcome is missed statutory deadlines and stacked per-record penalties.
- Failing to test PowerShell bulk scripts with -WhatIf. The outcome is mass misconfiguration affecting every mailbox in the tenant.
- Assuming internal forwarding is exempt from journaling rules. The outcome is a gap in SEC 17a-4 record preservation.
- Forwarding encrypted messages through transport rules. The outcome is stripped encryption and exposed content at the destination.
- Trusting MFA to prevent forwarding-based BEC. The outcome is token-theft attacks that install persistent forwarding rules.
Do’s and Don’ts of Outlook Forwarding
Clear rules help admins act fast under pressure. These do’s and don’ts are drawn from Microsoft’s security baseline for Exchange Online and federal guidance.
Do’s
- Do enable Microsoft Purview auditing tenant-wide because it captures every
Set-Mailboxchange and satisfies regulatory logging duties. - Do review forwarding reports weekly because attacker-installed rules often survive password resets and MFA enforcement.
- Do use mail flow rules for conditional routing because they provide a central, auditable control point.
- Do document every external forward because auditors will ask for the business justification during examinations.
- Do test PowerShell changes with -WhatIf because a single typo can affect thousands of mailboxes in seconds.
Don’ts
- Don’t forward to personal webmail because it places regulated data outside the tenant’s control and bypasses DLP.
- Don’t disable outbound spam filtering to enable forwarding because it removes Microsoft’s BEC defenses tenant-wide.
- Don’t rely on client-side inbox rules because they only run when Outlook is open, leading to intermittent forwarding.
- Don’t forward without a documented retention plan because SEC, HIPAA, and SOX all require preservation of the original.
- Don’t assume internal forwards are automatically compliant because cross-department forwarding can violate need-to-know policies.
Pros and Cons of Each Forwarding Method
Each method has strengths that fit different operational needs and compliance postures.
Pros of Mailbox Forwarding
- Writes to the mailbox object, so it survives client restarts and device swaps.
- Logs to Microsoft Purview under
Set-Mailbox, giving a durable audit trail. - Honors the Keep a copy option, preserving eDiscovery readiness.
- Works with shared mailboxes and resource mailboxes, not only user mailboxes.
- Integrates with Microsoft Defender for Office 365 anti-phishing controls.
Cons of Mailbox Forwarding
- Applies to every inbound message, which can over-share private content.
- Requires Exchange admin permissions, which slows self-service scenarios.
- External destinations are blocked by default, requiring policy changes.
- Does not filter by sender or subject without combining with mail flow rules.
- Can be abused by attackers who gain Global Admin or Exchange Admin roles.
Pros of Mail Flow Rules
- Evaluates conditions at the transport layer, catching every message.
- Supports complex logic like sender domains, keywords, and attachments.
- Runs centrally, independent of individual user actions.
- Produces detailed message trace logs for forensic review.
- Can integrate with Microsoft Purview DLP for automatic policy enforcement.
Cons of Mail Flow Rules
- Tenant-wide scope increases blast radius of a bad rule.
- Complex rules can conflict, producing unpredictable mail flow.
- Require careful testing, because typos can redirect large volumes of mail.
- Change management overhead is higher than a mailbox attribute change.
- Some advanced conditions require Exchange Online Plan 2 or E5 licensing.
Key Entities in the Forwarding Ecosystem
Understanding the forwarding ecosystem requires knowing the players. Each organization, tool, and role plays a distinct part.
Microsoft provides the platform, the defaults, and the security controls documented at Microsoft Learn. The Office of Civil Rights at HHS enforces HIPAA and publishes breach data through its Breach Portal. The Securities and Exchange Commission enforces SOX and 17a-4 through its Division of Enforcement.
The Federal Trade Commission enforces the Safeguards Rule and unfair-practices actions under the FTC Act Section 5. The Cybersecurity and Infrastructure Security Agency publishes BEC and forwarding-rule advisories at CISA.gov. State attorneys general enforce data breach notification laws and coordinate through the National Association of Attorneys General.
Inside an organization, the Global Admin, Exchange Admin, Compliance Admin, Security Admin, and User Admin all play roles. Each has distinct permissions under Microsoft’s role-based access control model, documented at Microsoft Learn role permissions.
Detailed Process for Enabling External Forwarding
Enabling external forwarding is a multi-step process because Microsoft blocks it by default. Admins who shortcut any step end up with silent non-delivery or a compliance gap.
The first step is risk assessment. The admin must document the business justification, the data categories involved, and the applicable regulatory regime. The consequence of skipping this step is an unsupported change during an audit.
The second step is policy configuration. The admin navigates to the Microsoft Defender portal and edits the outbound spam filter policy. The Automatic forwarding rules setting has three values: Automatic – System controlled, On – Forwarding is enabled, and Off – Forwarding is disabled. Each has distinct consequences for tenant security posture.
The third step is destination allowlisting. The admin adds the destination domain to a remote domain configuration using Set-RemoteDomain. The consequence of skipping allowlisting is inconsistent delivery across the Microsoft 365 network.
The fourth step is user or mailbox configuration using any of the three methods above. The fifth step is verification, sending a test message and confirming receipt at the destination, plus checking the audit log for the expected entry.
Form-Level Detail in PowerShell
The Set-Mailbox cmdlet has three forwarding-relevant parameters. ForwardingAddress accepts an internal recipient object, ForwardingSmtpAddress accepts any SMTP address, and DeliverToMailboxAndForward controls the keep-copy behavior.
Setting ForwardingAddress to a recipient that gets deleted leaves an orphan attribute that blocks the mailbox from being restored cleanly. The consequence is extended outages during user lifecycle events. The misconception that null-ing the attribute fixes it is wrong, because the mailbox must be re-mail-enabled in some orphan scenarios.
Relevant Court Rulings and Enforcement Actions
Courts and regulators have already addressed forwarding-related misconduct. These precedents shape how admins should think about risk.
In the FTC action against Drizly, inadequate access controls that allowed credential misuse led to an enforceable consent order binding the CEO personally. The analogous forwarding risk is that an admin who enables external forwarding without MFA enforcement faces similar personal exposure.
In Van Buren v. United States, the Supreme Court narrowed the Computer Fraud and Abuse Act’s exceeds authorized access clause. The consequence for forwarding cases is that purely policy-based violations may not be criminal, but they remain civilly actionable and regulatorily enforceable.
The SEC Off-Channel Communications sweeps that began in 2021 resulted in more than $3 billion in penalties against major financial firms through 2025. Forwarding to personal email is squarely within the scope of these enforcement actions.
State-Level Nuances After Federal Rules
State law layers on top of federal law. Admins must track both, because the stricter standard usually controls.
California’s CCPA and CPRA give consumers a private right of action for certain breaches, meaning a forwarding misconfiguration can produce a class action. New York’s SHIELD Act imposes reasonable safeguards duties on any business holding New York residents’ data.
Illinois’s Biometric Information Privacy Act has produced nine-figure class actions, and forwarded messages containing biometric identifiers fall within scope. Texas’s Data Privacy and Security Act took effect in 2024 and applies to businesses processing Texas residents’ personal data.
The consequence of treating federal compliance as sufficient is a 50-state patchwork of missed obligations. The misconception that headquarters location determines applicable law is wrong, because state laws follow the data subject, not the business.
FAQs
Can admins set up email forwarding for another user without that user’s consent?
Yes. Global Admins and Exchange Admins can configure forwarding on any mailbox in the tenant, but employment policies and some state laws require notice or consent, so legal review is wise.
Is external auto-forwarding blocked by default in Microsoft 365?
Yes. Microsoft blocks external auto-forwarding under the default outbound spam filter policy, and admins must explicitly change the setting or add exceptions to allow it.
Does forwarding preserve a copy in the original mailbox automatically?
No. The Keep a copy option must be enabled explicitly in the admin centers or by setting DeliverToMailboxAndForward to $true in PowerShell, otherwise the original mailbox receives nothing.
Can a user set up forwarding without admin involvement?
Yes. Users can create inbox rules in Outlook that forward messages, but tenant policies, mail flow rules, and outbound spam filters can override or block those rules.
Do shared mailboxes support forwarding?
Yes. Shared mailboxes support the same ForwardingAddress and ForwardingSmtpAddress attributes as user mailboxes, and the same external-forwarding restrictions apply.
Is forwarding to personal Gmail compliant with HIPAA?
No. Personal Gmail is not covered by a HIPAA Business Associate Agreement with the covered entity, so forwarding PHI to personal Gmail is an impermissible disclosure under the HIPAA Privacy Rule.
Does mailbox forwarding survive a mailbox migration?
Yes. The ForwardingSmtpAddress attribute is part of the mailbox object and migrates with it, but admins should validate the attribute after migration to catch corner cases.
Can mail flow rules forward based on subject line content?
Yes. Mail flow rules support conditions on subject lines, sender, recipient, keywords, attachments, and many other message properties through the Exchange Admin Center or PowerShell.
Is PowerShell required to configure forwarding in Microsoft 365?
No. The Microsoft 365 Admin Center and the Exchange Admin Center both support forwarding configuration, but PowerShell is faster for bulk changes and exposes advanced parameters.
Do forwarded messages trigger Microsoft Purview DLP policies?
Yes. DLP policies evaluate messages at the transport layer, so forwarded messages are inspected and blocked or audited if they match a DLP rule before they leave the tenant.
Can attackers use forwarding rules as a persistence mechanism?
Yes. BEC attackers routinely install inbox rules that forward financial communications to external addresses, which is why CISA advisories recommend continuous forwarding-rule audits.
Is there a way to audit every forwarding rule in a tenant at once?
Yes. The PowerShell command Get-Mailbox -ResultSize Unlimited | Where-Object {$_.ForwardingSmtpAddress -ne $null} returns every mailbox with a forwarding address set and is the foundation of most audit scripts.