Microsoft 365 URLs, Endpoints, and Network Requirements for Migration
Microsoft 365 migrations require reliable access to the Microsoft services used for authentication, mailbox connectivity, and migration operations. Firewalls, proxies, web filters, or TLS inspection can interrupt these connections when required Microsoft 365 endpoints are blocked. Because Microsoft updates its endpoint data over time, administrators should use Microsoft’s current endpoint documentation as the authoritative source and confirm that the system running EdbMails can reach the services required for the selected migration workflow.
This page explains migration-relevant URLs and endpoint categories, common network checks, and where to verify Microsoft’s latest published endpoint data before starting an Office 365 migration software workflow.
Why Microsoft 365 IP Addresses and URLs Are Required
Mailbox migration involves secure communication with Microsoft cloud services. The exact endpoints required depend on the migration workflow and the Microsoft 365 services it uses.
Depending on the scenario, administrators may need to permit access for:
- Microsoft Entra ID authentication and OAuth token issuance.
- Exchange Online mailbox connectivity when Exchange Online is the source or target.
- Microsoft Graph API operations where the workflow uses Microsoft Graph.
- Autodiscover requests where the workflow uses Autodiscover.
- DNS name resolution.
- Secure HTTPS communication and migration API requests.
Blocking a service required by the selected workflow can interrupt authentication, mailbox discovery, API operations, or data synchronization.
Microsoft 365 Services Used During Migration
Exchange Online
When Exchange Online is the migration source or target, EdbMails must be able to reach the relevant Exchange Online services to access or write mailbox data.
Microsoft Graph
Microsoft Graph is an API surface for Microsoft 365 resources. Depending on the migration workflow, it may be used for user or object access, validation, permission-related operations, or administrative tasks. Microsoft Graph is separate from OAuth authentication and token issuance.
Blocking Graph endpoints can interrupt Graph API operations used by a workflow.
Microsoft Entra ID (Azure AD)
Microsoft Entra ID supports user and application authentication for Microsoft 365. EdbMails uses modern authentication (OAuth 2.0), and access to the relevant Entra ID authentication endpoints is required for token issuance and sign-in.
Autodiscover
Autodiscover can help locate Exchange mailbox services in workflows that use it. If Autodiscover is required by the selected workflow and cannot be reached, mailbox discovery or connection attempts may be affected.
SMTP Services
SMTP is primarily used for email transport rather than mailbox migration. Organizations may still require SMTP connectivity when validating mail flow or performing post-migration testing.
HTTPS Communication
Core EdbMails and Microsoft 365 web-service communication uses HTTPS over TCP port 443. Other Microsoft 365 services can have additional network requirements, so administrators should verify the current Microsoft endpoint guidance for the services used in their environment.
Migration-relevant Microsoft 365 endpoint examples
Microsoft recommends managing Microsoft 365 connectivity with its published endpoint data rather than relying on a small, permanent static allowlist. The following entries are non-exhaustive examples that may be relevant to migration workflows.
| Example endpoint | Migration relevance / purpose |
| https://login.microsoftonline.com | Microsoft Entra ID authentication and OAuth token issuance. |
| https://graph.microsoft.com | Microsoft Graph API operations where used by the selected workflow. |
| https://outlook.office365.com | Exchange Online service connectivity where applicable. |
| https://outlook.office.com | Microsoft 365 / Exchange Online service connectivity where applicable. |
| https://autodiscover.outlook.com | Autodiscover service requests where used by the workflow. |
| https://office.com | Microsoft 365 service and sign-in workflows where applicable. |
This table is not a complete Microsoft 365 allowlist. Before changing firewall or proxy rules, verify the latest endpoint data in Microsoft’s official Microsoft 365 URLs and IP address ranges documentation. For automated endpoint consumption, Microsoft also provides the Microsoft 365 IP Address and URL web service.
Firewall and Proxy Configuration Best Practices
Before beginning migration, review network security controls on the system running EdbMails and confirm connectivity for the Microsoft 365 services required by the selected workflow.
- Allow required outbound HTTPS traffic, including TCP port 443 for core web-service communication.
- Use Microsoft’s current published endpoint data when configuring firewall, proxy, or web-filter rules.
- Where organizational security policy permits, bypass TLS decryption or inspection for Microsoft 365 domains in accordance with Microsoft network guidance.
- Ensure proxy authentication does not interfere with EdbMails connections.
- Permit DNS resolution for the Microsoft 365 services used by the workflow.
- Review web-filtering policies for blocked Microsoft endpoints.
- Verify sufficient bandwidth and acceptable latency for the migration workload.
Microsoft’s Microsoft 365 network connectivity principles provide additional guidance for Microsoft 365 traffic.
Common Migration Issues Caused by Blocked Endpoints
Incorrect network configuration can produce authentication, connectivity, or API problems during migration.
Common symptoms include:
- Authentication failures.
- Mailbox connection errors.
- Autodiscover failures where Autodiscover is used.
- HTTPS connection timeouts or resets.
- Microsoft Graph API errors where Graph is used.
- Intermittent migration failures or job interruptions.
- Slow mailbox synchronization or repeated retries.
Reviewing firewall logs, proxy logs, and EdbMails migration reports can help identify blocked or interrupted service connections.
Microsoft Endpoint Verification
Microsoft updates Microsoft 365 endpoint data as its services and infrastructure change. The official Microsoft endpoint documentation and web service should therefore be treated as the maintenance authority rather than a static list on this page.
Before a migration project, administrators should:
- Review Microsoft’s latest endpoint documentation.
- Confirm the endpoints required by the selected workload and workflow are allowed.
- Check for endpoint changes before large migration projects.
- Test connectivity from the system running EdbMails.
Best Practices Before Migration
Use an Office 365 migration checklist to organize preparation and verify the environment before migration.
- Verify firewall and proxy rules against Microsoft’s current endpoint guidance.
- Confirm DNS resolution and HTTPS connectivity.
- Validate Microsoft Entra ID authentication.
- Test the services required by the selected EdbMails workflow.
- Perform a pilot migration with a small group of mailboxes.
- Monitor migration logs and network performance throughout the migration.
For the broader sequence of preparation and migration steps, refer to the Office 365 migration guide.
How EdbMails Helps Simplify Microsoft 365 Migrations
EdbMails uses Microsoft Entra ID modern authentication (OAuth 2.0) for supported Microsoft 365 migration workflows. Depending on the selected workflow, it can communicate with Exchange Online, Microsoft Graph, and Autodiscover services. Before migration, confirm that the relevant Microsoft 365 services and endpoints are reachable from the system running EdbMails.
- Modern Authentication: Uses Microsoft Entra ID authentication (OAuth 2.0) for supported Microsoft 365 connections.
- Workflow-dependent Microsoft 365 connectivity: Connects to Exchange Online, Microsoft Graph, and Autodiscover where required by the selected migration workflow.
- Secure web-service communication: Uses HTTPS for core communication with Microsoft 365 services.
- Migration logging: Provides migration logs that can help administrators investigate authentication and connectivity errors.
- Large migration workloads: Supports migration of multiple mailboxes subject to Microsoft service limits and throttling policies.
Note: Endpoint requirements depend on the Microsoft 365 services used by the selected workflow. If a required authentication, API, Exchange, Autodiscover, or HTTPS connection is blocked by a firewall, proxy, web filter, or other network control, the affected migration operation may fail until access is restored.
Conclusion
Reliable Microsoft 365 migration connectivity depends on allowing the services required by the selected workflow and keeping network rules aligned with Microsoft’s current endpoint data. Verify Microsoft’s official endpoint documentation, test connectivity from the EdbMails system, and validate the migration path before moving production mailboxes.
Frequently Asked Questions
Why are Microsoft 365 URLs preferred over IP addresses?
Microsoft publishes Microsoft 365 endpoint data using URLs, domains, and IP ranges, and the data can change as services evolve. Use Microsoft’s current endpoint documentation rather than relying on a permanent static IP list.
Which port is required for Microsoft 365 migration?
Core EdbMails and Microsoft 365 web-service communication uses HTTPS over TCP port 443. Other Microsoft 365 services can have additional requirements, so verify the current Microsoft endpoint guidance for the services used by your workflow.
What happens if Microsoft Graph endpoints are blocked?
If a migration workflow uses Microsoft Graph, blocking Graph endpoints can interrupt Graph API operations such as Microsoft 365 resource or administrative access. OAuth authentication and token issuance are handled through Microsoft Entra ID endpoints.
Should SSL or TLS inspection be enabled for Microsoft 365 traffic?
TLS inspection can interfere with Microsoft 365 connections in some environments. Review Microsoft’s current network guidance and, where organizational security policy permits, bypass TLS decryption or inspection for Microsoft 365 domains.
How often should Microsoft 365 endpoints be reviewed?
Microsoft updates endpoint data as needed. Review the current Microsoft endpoint documentation before migration projects and keep firewall, proxy, and web-filter rules aligned with the latest published data.
