Description
To ensure the successful deployment of Shield to a domain, a few prerequisites must be met. DNS and tenant configuration changes are verified at every step. Preparing for deployment will ensure a smoother and more successful deployment.
This article assumes you have already added your not-for-resale (NFR) domain to Shield. Customer organizations cannot be added to Shield until your NFR domain is added. Please see Pre-flight checklist for deploying Shield to your NFR domain before using this article.
Prerequisites for All Customers
Decrease the TTL on DNS records
You must add or update DNS records as part of Shield's deployment. If the TTL is set to a long interval, you may get stuck on a deployment step for several hours, waiting for cached DNS data to expire.
The TTL (time to live) of a DNS record instructs DNS lookups to cache data for a specific amount of time before checking the authoritative server for updates. This improves DNS efficiency across the internet but can also create a delay when verifying DNS changes on other services.
- Many DNS host providers have default TTL settings of 1 hour to as high as 4 hours.
- To ensure the records propagate quickly, make the TTL changes the day before deploying or at least 4 hours before deploying.
- Please change the TTL to the shortest time allowed by the DNS host provider for:
- SPF (a TXT record)
- You will set the TTL back to the DNS host provider's defaults after deploying Shield.
Prepare all email-enabled domains in the M365 tenant
- Microsoft allows the addition of multiple domains to a tenant. The deployment process will recognize only email-enabled domains reported by Microsoft's API.
- Shield is applied to all addresses in M365 tenant domains selected for Shield deployment.
- Domains with email addresses, whether licensed or otherwise, must be configured to mail enablement to Microsoft's API.
- Click the domain name if you see 'No services selected' on an email-enabled domain.
- Go to DNS Records and Manage DNS. Follow the guide to add DNS records for the domain.
- Adding the Exchange and Exchange Online Protection service is necessary for Shield to recognize the email-enabled domain.
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.
Disable Microsoft's First Contact Safety Tip
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.
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 Customers currently using CloudFilter
Follow instructions in Prerequisites for Migrating CloudFilter Domains to Shield.
Updated