Migrating from Pineapp to Microsoft Defender for Office 365: a practical three-phase guide

Many Microsoft 365 organizations still route their mail through a third-party filtering service such as Pineapp before it reaches their mailboxes. Often they already pay for Microsoft’s own email protection: Defender for Office 365 is included in Business Premium and E5.

We recently worked with a client who was struggling to manage their email security in Pineapp. With license renewal approaching, we decided together to move fully to Defender for Office 365. The move simplified operations, removed the cost of the extra service and gave them integrated protection. Here is how we did it, so you can follow the same path.

The problem: two systems to run and pay for

Third-party filtering services usually work well, but they add three problems:

• Complexity: two platforms, Microsoft 365 and the external service, with two consoles and two places to look for a missing message.
• Cost: paying twice, for Microsoft 365 and for the external service.
• Inconsistency: two different protection methods create gaps and an uneven user experience.

That was exactly the client’s situation. The IT team was stretched across several systems, and the cost of Pineapp kept growing. We were also already in the middle of rolling out Defender for Endpoint, so extending the same platform to email was the natural next step.

Why Defender for Office 365

• One place to manage: all email security in the Microsoft Defender portal, next to endpoint and identity protection.
• Savings: organizations on Business Premium (which includes Plan 1) or E5 (which includes Plan 2) already pay for Defender for Office 365.
• Integrated protection: Safe Links, Safe Attachments, impersonation protection, and signals shared with the rest of Defender.

We followed Microsoft’s migration guide, which splits the work into three phases: prepare, set up and onboard.

1Prepare

1. Inventory the Pineapp settings. We documented every rule, exception and allow/block list. Once the service ends you lose access to these settings, so this comes first.
2. Review the Microsoft 365 configuration. We went through the tenant’s existing settings to find unnecessary configuration and simplify the mail environment before the move.
3. Check services that send as your domain. The client had two external services sending mail on behalf of their domain. We verified their SPF, DKIM and DMARC records.
4. Mail routing. Pineapp’s routing rules were minimal, so no significant changes were needed.
5. Decide the user experience. Together with the client we set what happens to spam and bulk mail: spam goes to quarantine, bulk mail goes to the Junk Email folder.

2Set up

1. Pilot groups. We created groups of users to test Safe Attachments, Safe Links and anti-spam policies, to see the impact on a small group before rolling out to everyone.
2. Keep the SCL=-1 rule. We kept the mail flow rule that sets SCL=-1 for messages that came through Pineapp. It prevents double filtering during the migration and lets you test the new settings without affecting users’ mail.
3. Analyze with ORCA. We ran ORCA (Office 365 Recommended Configuration Analyzer), a PowerShell module that scans your Defender for Office 365 policies and compares them with Microsoft’s recommendations. Its report gave us a practical list of gaps.
4. Safe Attachments and Safe Links. In Safe Attachments we turned on Dynamic Delivery, so the message body is delivered first and the attachment follows after scanning. High-risk groups such as executives got a stricter policy. In Safe Links we turned on time-of-click checks for every link, including in Teams and Office documents.
5. Tune anti-spam. We migrated the allow and block lists from Pineapp and tuned the Bulk Complaint Level (BCL) threshold to handle marketing mail better without flagging legitimate messages as spam.
6. User reporting. We turned on the built-in Report button in Outlook. Messages users report reach the security team in the Defender portal and help tune the filters over time.

3Onboard

1. Train the security team. We trained the team on Defender for Office 365 tools such as Threat Explorer and Attack simulation training, so they can investigate and respond to threats themselves.
2. Tune spoof and impersonation protection. Based on user feedback and ORCA’s recommendations, we tuned spoof intelligence and impersonation protection to balance protection against false positives.
3. Roll out gradually. We expanded the pilot step by step to the whole organization, adjusting policies along the way based on user reports.
4. Finish the migration. We turned off the SCL=-1 rule, so all filtering moved to Defender for Office 365, and updated the MX records to point directly to Microsoft 365.
5. Connectors for external services. We set up connectors for the services that send mail on behalf of the client’s domain, so their mail keeps arriving as before.

Challenges and lessons learned

• Printers and scanners: devices that sent mail through Pineapp stopped working after the switch. We set up a connector in Microsoft 365 that recognizes the office IP address, so the devices send straight to Microsoft 365 without an external SMTP server. Map these devices during the prepare phase.
• Settings that don’t map one to one: some Pineapp settings had no direct equivalent in Defender for Office 365 and needed a different approach.
• User training: users needed guidance on releasing mail from quarantine and reporting suspicious messages.
• False positives: there were more false positives than expected at first. After tuning the policies they dropped significantly.

Summary

Moving from Pineapp to Defender for Office 365 simplifies management, removes the cost of an extra service and connects email protection to the rest of Microsoft’s security stack. The key is not to rush: inventory the settings, run a pilot with the SCL=-1 rule, tune with ORCA, and switch the MX records last.

Sources

• Microsoft: Migrate to Microsoft Defender for Office 365
• ORCA: Office 365 Recommended Configuration Analyzer