Description
A few prerequisites must be met before deploying Shield to your NFR (not-for-resale) domain to ensure the deployment is successful.
If you receive an error that your domain needs to be ready for Shield deployment, this article is the reference to help identify what is missing or requires reconfiguration.
Need guidance on your deployment? Our Partner Success team is always glad to help! Book time to meet with them via their scheduling link.
Prerequisites for All Partners
Confirm the domain is marked NFR
The partner's Parent domain must be set as Not for Resale in the Mailprotector Console. View a billing statement in the Mailprotector Console to determine if your domain is set to NFR. Note that only a partner's domain can be the NFR domain. No customer domain can act as the Parent domain for Shield. If the partner domain is not designated as the NFR domain, please submit a request for assistance.
Prepare all email-enabled domains in the M365 tenant
Microsoft allows the addition of multiple domains to a tenant. The Shield deployment process will recognize only email-enabled domains reported by Microsoft's API.
To prepare each domain, ensure that its status reports as Healthy. If not Healthy, follow the instructions to change its status to Healthy:
- Visit Microsoft 365 admin center > Settings > Domains
- Click the domain name for each domain that will have Shield users enabled that is not listed as Healthy.
- Go to DNS Records and Manage DNS. Follow the guide to
- Add DNS records for the domain
- Add the Exchange and Exchange Online Protection service
Add 'bounces@' shared mailbox to facilitate forwarding rules
- Microsoft implemented the Sender Rewriting Scheme (SRS) in M365 to resolve SPF problems with autoforwarding to external contacts.
- If you auto-forward any emails to an external email address (PSA applications such as Autotask, CRM applications, etc.), SRS alters the sender to a 'bounces@' type of address.
- Add a shared mailbox with an address of bounces@your-unique-domain.tld to ensure proper delivery of auto forwarded emails.
- NOTE: Replace your-unqiue-domain.tld with the domain you are using in M365.
Update the Anti-phishing Inbound Policy
Microsoft's first contact safety tip is triggered when an email is received from a first-time sender or from someone the user rarely corresponds with. When applied, it can sometimes cause messages to bounce due to DKIM neutral, DMARC fail results, even when the sender’s DNS records are correctly configured. Since Shield’s New Sender banner already alerts users to first-time senders, Microsoft’s First Contact Safety Tip can be safely disabled.
The first contact safety tip should be disabled for all active anti-phishing policies. To navigate to the anti-phishing policies, go to Microsoft Defender > Email & collaboration > Policies & rules > Threat policies > Anti-phishing.
Update the Anti-spam Inbound Policy
Visit Microsoft Defender > Email & collaboration > Policies & rules > Threat policies > Anti-spam > Anti-spam inbound policy (Default) and ensure or update these settings:
- Bulk email threshold set to 7
- Enable spam safety tips set to Off
Disable or uninstall other API-based email security applications
Email security applications should not be run simultaneously. The results of doing so will be unpredictable and potentially cause disruptions in service for all products involved.
Prerequisites for Partners using CloudFilter
Follow instructions in Prerequisites for Migrating CloudFilter Domains to Shield.
Updated