Retire both objects behind a custom PowerShell anti-spam policy

Source facts

Removing a spam-filter policy through PowerShell leaves its corresponding rule in place; Microsoft directs administrators to remove the orphaned rule separately when it is no longer needed. Removing the rule likewise leaves its policy behind. The default spam-filter policy is different: it has no corresponding rule. Microsoft Learn.

Applicability

Apply this review to custom anti-spam configuration managed through PowerShell. Confirm the exact policy and its associated rule before approving a removal, and identify which protection will cover the recipients afterward.

DSE recommendation

DSE recommends treating retirement as a review of the policy-rule pair. Preserve the current settings, recipient conditions and priority in the change record. Check that the replacement coverage matches the intended population, then remove only the approved custom objects using the documented procedure. Give any intentionally retained object a stated purpose and owner.

Verification

After the authorized change, list policies and rules independently and compare both inventories with the approved target state. Confirm that the retired identities are absent and that the intended remaining rule still references the correct policy. Record recipient coverage and investigate unexpected orphaned objects before closing the change.

Official references

Microsoft Learn: Configure anti-spam policies for cloud mailboxes. Source reviewed September 17, 2026.