Firewall Ports Required for Office 365 Migration
Configuring firewall rules is a critical prerequisite for a successful Office 365 migration. During mailbox migration, the migration application communicates continuously with Exchange Online and other Microsoft 365 services to authenticate users, discover mailbox settings, transfer mailbox data, and verify migration status. If required network ports or Microsoft service endpoints are blocked, migration requests may fail, experience timeouts, or operate with reduced performance.
The primary communication channel for Office 365 migration is encrypted HTTPS traffic over TCP port 443. Depending on the migration scenario, additional services such as DNS, SMTP, Microsoft Entra ID, Exchange Web Services (EWS), Microsoft Graph, and Autodiscover also require network connectivity. Firewalls, proxy servers, SSL inspection devices, or restrictive outbound filtering policies can interrupt these communications even when Internet access is available.
Before starting a migration using EdbMails Office 365 Migration Software, administrators should verify that all required outbound ports are open, Microsoft 365 endpoints are accessible, DNS resolution is functioning correctly, and security devices do not block encrypted traffic. Performing these checks before migrating production mailboxes helps reduce connection failures and minimises migration interruptions.
Why Firewall Ports Are Required During Office 365 Migration
Office 365 mailbox migration consists of multiple communication stages rather than a single network connection. Each stage relies on specific Microsoft services that exchange information securely over standard Internet protocols.
During a migration, the migration application typically performs the following operations:
- Authenticates administrative credentials with Microsoft Entra ID.
- Connects to Exchange Online services.
- Resolves mailbox locations through the Autodiscover service.
- Retrieves mailbox information and folder structure.
- Transfers mailbox data through encrypted HTTPS sessions.
- Synchronises incremental mailbox changes.
- Validates migration status and mailbox availability.
Because these operations communicate with Microsoft cloud services, outbound Internet connectivity is generally sufficient. Inbound firewall ports are not required for standard Office 365 mailbox migrations initiated from within the organisation's network.
Exchange Online communication
Exchange Online is the primary destination for mailbox migration. The migration application establishes secure HTTPS connections to Exchange Online to read mailbox metadata, create migration sessions, transfer mailbox content, and verify migration completion. Reliable connectivity to Exchange Online endpoints is essential throughout the migration lifecycle. Interruptions in connectivity can result in incomplete mailbox synchronisation, retry operations, or migration failures.
Authentication through Microsoft Entra ID
Every migration session begins with user or application authentication. Microsoft Entra ID validates the migration account and issues authentication tokens that authorise access to Exchange Online resources. If communication with Microsoft Entra ID is blocked by the firewall or proxy server, authentication requests fail before mailbox migration can begin.
Secure HTTPS communication
All mailbox migration traffic between the migration application and Microsoft 365 is encrypted using Transport Layer Security (TLS) over HTTPS. Encrypted communication protects mailbox content, authentication tokens, and administrative operations while data is transmitted across public networks. Deep packet inspection, SSL interception, or certificate replacement performed by network security appliances may interfere with TLS negotiation and should be evaluated before large-scale migration projects.
Microsoft service endpoints
Microsoft 365 services are hosted across multiple geographically distributed datacenters. Rather than relying on a fixed set of IP addresses, Microsoft recommends allowing access to Microsoft 365 service endpoints and URLs, as these may change over time. Where possible, firewall policies should permit outbound communication to Microsoft 365 endpoints instead of maintaining static IP address allow lists. This approach reduces administrative overhead and aligns with Microsoft's endpoint management recommendations.
Firewall Ports Required for Office 365 Migration
The following ports are commonly used during Office 365 mailbox migration. The required ports depend on the migration type, source environment, authentication method, and services involved.
Port Protocol Direction Service Purpose Requirement 443 TCP Outbound HTTPS Secure communication with Exchange Online, Microsoft Entra ID, Microsoft Graph, EWS, Autodiscover, and Microsoft 365 services Required 53 TCP/UDP Outbound DNS Resolves Microsoft 365 service endpoints, Autodiscover records, and Exchange Online hostnames Required 80 TCP Outbound HTTP Limited use for HTTP redirects, connectivity checks, and certificate validation. Application data is not migrated over HTTP. Optional 25 TCP Outbound SMTP Used when validating or testing SMTP mail flow. Not required for mailbox data migration itself. Scenario-dependent 587 TCP Outbound SMTP Submission Used when authenticated SMTP communication is required during specific migration or relay scenarios. Scenario-dependent 123 UDP Outbound NTP Synchronises system time to support accurate TLS certificate validation and authentication. Recommended 143 TCP Outbound IMAP Required only for IMAP-based mailbox migrations from supported source systems. Migration-specific 993 TCP Outbound IMAPS Secure IMAP communication when migrating mailboxes using IMAP over TLS. Migration-specific 110 TCP Outbound POP3 Required only when migrating from POP3-based mailbox environments. Rarely required 995 TCP Outbound POP3S Secure POP3 communication over TLS for legacy migration scenarios. Rarely required Understanding the required ports
TCP Port 443 (HTTPS)
TCP port 443 is the primary communication channel for Office 365 migrations. It supports secure authentication, mailbox access, Autodiscover requests, Exchange Web Services (EWS), Microsoft Graph API calls, and Exchange Online data transfer. Blocking this port prevents communication with Microsoft 365 services and typically causes authentication failures, mailbox connection errors, or migration timeouts.
TCP/UDP Port 53 (DNS)
DNS resolution is required to locate Microsoft 365 service endpoints, Exchange Online resources, and Autodiscover records. Incorrect DNS configuration or blocked DNS queries can prevent the migration application from resolving service hostnames, resulting in connection failures before mailbox migration begins.
TCP Port 80 (HTTP)
Although mailbox data is not transferred over HTTP, port 80 may be used for HTTP redirection, certificate validation, and connectivity checks performed by Windows or Microsoft services. Organisations should not rely on HTTP for mailbox migration traffic.
SMTP, IMAP, and POP Ports
Ports such as 25, 587, 143, 993, 110, and 995 are required only for specific migration scenarios. For example, IMAP migrations require ports 143 or 993 depending on whether TLS encryption is used, while SMTP ports may be necessary for mail flow validation or relay configuration. These ports are not mandatory for standard Exchange Online mailbox migrations that use HTTPS over port 443.
Common Office 365 Services That Use These Firewall Ports
Several Microsoft 365 services participate in an Office 365 migration. Although most communication uses HTTPS over TCP port 443, each service has a distinct role in authentication, mailbox discovery, data transfer, or synchronisation. Understanding these services helps administrators identify connectivity issues more efficiently.
Exchange Online
Exchange Online is the primary mailbox service in Microsoft 365 and is responsible for storing mailbox data, calendars, contacts, tasks, archives, and public folders. During migration, the migration application establishes secure HTTPS connections to Exchange Online to:
- Create mailbox migration sessions.
- Read and write mailbox data.
- Synchronize incremental mailbox changes.
- Verify mailbox availability after migration.
- Retrieve mailbox properties and folder hierarchy.
If Exchange Online endpoints are inaccessible, mailbox migration cannot proceed even if authentication succeeds.
Microsoft Entra ID
Microsoft Entra ID provides identity and authentication services for Microsoft 365. Before mailbox access is granted, the migration account must authenticate successfully and obtain the required access tokens.
Communication with Microsoft Entra ID is used for:
- User authentication.
- OAuth token issuance.
- Administrator authorization.
- Application authentication where supported.
Firewall restrictions, proxy authentication failures, or Conditional Access policies can interrupt the authentication process before mailbox migration begins.
Autodiscover
The Autodiscover service enables migration applications to locate Exchange Online mailbox endpoints automatically.
During migration, Autodiscover is used to:
- Locate mailbox service URLs.
- Identify mailbox configuration settings.
- Determine available Exchange services.
- Validate mailbox connectivity.
If Autodiscover requests fail, the migration application may be unable to locate the destination mailbox even though the mailbox exists.
Exchange Web Services (EWS)
Exchange Web Services (EWS) is commonly used by migration tools to access mailbox content in Exchange Online and supported Exchange Server environments.
EWS provides access to:
- Email messages.
- Calendar items.
- Contacts.
- Tasks.
- Folder hierarchy.
- Mailbox metadata.
Although Microsoft Graph is increasingly used for Microsoft 365 integrations, EWS continues to support many mailbox migration scenarios. If EWS access is restricted by firewall rules, proxy policies, or Exchange configuration, mailbox data retrieval may fail.
Microsoft Graph
Microsoft Graph provides a unified API for accessing Microsoft 365 resources. Depending on the migration scenario, Graph may be used for:
- User and mailbox discovery.
- Microsoft Entra ID object validation.
- Directory lookups.
- Administrative operations.
- Application-based authentication.
Graph communication also uses HTTPS over TCP port 443 and requires successful authentication through Microsoft Entra ID.
SMTP
SMTP is not used to transfer mailbox data during a standard Exchange Online migration. However, it may be required for:
- Mail flow validation after migration.
- Testing outbound email delivery.
- SMTP relay configuration.
- Hybrid Exchange deployments.
Blocking SMTP traffic does not usually prevent mailbox data migration, but it can affect post-migration mail flow validation.
IMAP and POP
IMAP and POP are relevant only when the source environment uses these protocols for mailbox migration.
- IMAP (143/993): Used for migrating email messages from IMAP-compatible mail systems.
- POP3 (110/995): Used only in limited legacy migration scenarios. These protocols do not support migration of calendars, contacts, tasks, folder permissions, or mailbox rules. For Exchange-to-Exchange or Microsoft 365 migrations, HTTPS over port 443 remains the primary communication protocol.
DNS
DNS resolution is essential throughout the migration process. Before connecting to Microsoft 365 services, the migration application resolves hostnames such as Exchange Online, Autodiscover, Microsoft Entra ID, and Microsoft Graph endpoints.
Common DNS-related issues include:
- Incorrect DNS server configuration.
- Stale DNS cache.
- Internal DNS forwarding problems.
- Firewall restrictions affecting DNS queries.
Reliable DNS resolution is a prerequisite for successful migration.
Network Time Protocol (NTP)
Although NTP does not transfer mailbox data, accurate system time is important for secure authentication. Microsoft Entra ID authentication tokens and TLS certificates rely on synchronised system clocks. Significant time differences between the migration server and Microsoft services can result in:
- Authentication failures.
- Certificate validation errors.
- OAuth token rejection.
- Secure connection failures.
Synchronizing systems with a trusted NTP source helps prevent these issues.
How Firewall Rules Affect Office 365 Migration
Firewall configuration directly influences migration performance, reliability, and authentication. Restrictive network policies can interrupt communication with Microsoft 365 services even when Internet connectivity appears to function normally.
Blocked HTTPS traffic
Blocking outbound HTTPS traffic on TCP port 443 prevents communication with Exchange Online, Microsoft Entra ID, Microsoft Graph, and other Microsoft 365 services.
Typical symptoms include:
- Unable to connect to Exchange Online.
- Authentication failures.
- Mailbox discovery errors.
- Migration session failures.
- HTTP 403 or HTTP 401 responses.
- Connection timeout messages.
Authentication failures
Authentication requests must reach Microsoft Entra ID without interference.
Common causes include:
- Proxy authentication failures.
- Conditional Access restrictions.
- SSL interception.
- Invalid TLS certificates.
- Blocked Microsoft authentication endpoints.
Authentication issues usually prevent migration from starting rather than interrupting an active mailbox transfer.
Mailbox connection failures
Even after successful authentication, mailbox connections can fail if Exchange Online endpoints are inaccessible.
Administrators may observe:
- Mailbox not found errors.
- Unable to retrieve mailbox information.
- Folder enumeration failures.
- Incremental synchronisation errors.
These issues often indicate endpoint filtering rather than mailbox configuration problems.
Slow migration performance
Migration throughput depends on stable, uninterrupted network communication.
Firewall-related factors that can reduce performance include:
- Deep packet inspection.
- Traffic shaping.
- Bandwidth limitations.
- High network latency.
- Proxy server bottlenecks.
- Frequent connection resets.
Review firewall logs alongside migration reports to determine whether network devices are delaying HTTPS traffic.
SSL inspection and TLS interception
Many enterprise firewalls inspect encrypted HTTPS traffic by decrypting and re-encrypting TLS sessions.
While this improves security monitoring, SSL inspection can interfere with:
- Certificate validation.
- OAuth authentication.
- Secure Exchange Online communication.
- Microsoft Graph requests.
Where organisational security policies permit, exclude Microsoft 365 endpoints from SSL inspection to avoid certificate validation or authentication issues.
Proxy server configuration
Organizations that route Internet traffic through proxy servers should verify that migration applications can communicate with Microsoft 365 services without interruption.
Validate that the proxy:
- Allows outbound HTTPS traffic.
- Supports Modern Authentication.
- Does not modify Microsoft certificates.
- Has sufficient bandwidth for migration workloads.
- Does not terminate long-running HTTPS sessions.
How to Validate Firewall Connectivity
Before starting a production migration, verify that network connectivity to Microsoft 365 services is functioning correctly.
1. Verify DNS resolution
Use tools such as nslookup or Resolve-DnsName in PowerShell to confirm that Microsoft 365 service hostnames resolve successfully.
Verify:
- Exchange Online hostnames.
- Autodiscover records.
- Microsoft Entra ID endpoints.
- Microsoft Graph endpoints.
2. Test network connectivity with PowerShell
The Test-NetConnection PowerShell cmdlet verifies connectivity to specific ports.
Example:
Test-NetConnection outlook.office365.com -Port 443
A successful test confirms that the destination host is reachable and that TCP port 443 is accessible.3. Test SMTP connectivity
Where SMTP validation is required, use Telnet or PowerShell to verify connectivity to the appropriate SMTP endpoint.
Successful SMTP connectivity confirms that firewall rules permit outbound SMTP communication for the configured scenario.
4. Use Microsoft Remote Connectivity Analyser
Microsoft Remote Connectivity Analyser can validate Exchange Online connectivity, Autodiscover functionality, and authentication. It helps identify DNS, certificate, authentication, and network configuration issues before migration.
5. Run Microsoft 365 network connectivity tests
Microsoft provides network assessment tools that evaluate connectivity between the client network and Microsoft 365 services. These tests can identify latency, routing issues, DNS problems, and endpoint accessibility that may affect migration performance.
6. Review firewall and proxy logs
If connectivity tests fail, examine firewall and proxy logs for:
- Blocked outbound connections.
- SSL inspection events.
- TLS negotiation failures.
- Proxy authentication errors.
- Connection timeouts.
- Microsoft endpoint filtering.
Reviewing these logs alongside migration reports helps determine whether failures originate from the network infrastructure or the migration configuration.
Common Firewall-Related Migration Issues
The following table lists common firewall and network issues that can affect Office 365 mailbox migrations, along with their possible causes and recommended resolutions.
Issue Possible Cause Resolution Unable to connect to Exchange Online TCP port 443 is blocked, Microsoft 365 endpoints are inaccessible, or outbound HTTPS traffic is restricted Verify outbound firewall rules, confirm access to Microsoft 365 service endpoints, and test connectivity using Test-NetConnection. Authentication fails before migration starts Microsoft Entra ID endpoints are blocked, Conditional Access policies restrict the migration account, or SSL inspection interrupts OAuth authentication Validate Microsoft Entra ID connectivity, review Conditional Access policies, and exclude Microsoft authentication endpoints from SSL inspection where appropriate. Autodiscover cannot locate mailboxes DNS resolution failure, incorrect Autodiscover records, or firewall restrictions prevent access to the Autodiscover service Verify DNS configuration, confirm external name resolution, and test Autodiscover connectivity using Microsoft's Remote Connectivity Analyzer. Slow mailbox migration Deep packet inspection, bandwidth limitations, proxy bottlenecks, high network latency, or excessive concurrent migration jobs Review firewall performance, monitor available bandwidth, reduce concurrent migrations if necessary, and validate network latency to Microsoft 365 endpoints. Migration stops with timeout errors Firewall session timeout, proxy timeout, unstable Internet connection, or interrupted HTTPS sessions Increase session timeout values where appropriate, verify proxy configuration, and ensure persistent HTTPS connectivity throughout the migration. DNS lookup failures Internal DNS configuration issues, blocked DNS traffic, or stale DNS cache Verify DNS server configuration, clear the DNS cache if required, and confirm successful resolution of Microsoft 365 service endpoints. SMTP connectivity tests fail Port 25 or 587 is blocked or restricted by firewall policies or the Internet service provider Confirm whether SMTP connectivity is required for the migration scenario and update outbound firewall rules accordingly.
Firewall Best Practices Before Office 365 Migration
Preparing the network infrastructure before migrating mailboxes helps reduce connectivity issues and improves migration reliability.
Allow outbound HTTPS traffic
Ensure that TCP port 443 is open for outbound communication. Exchange Online, Microsoft Entra ID, Microsoft Graph, Exchange Web Services (EWS), and Autodiscover all rely on encrypted HTTPS connections.
Allow Microsoft 365 service endpoints
Microsoft recommends allowing traffic to Microsoft 365 service URLs and endpoints instead of creating static IP address allow lists. Service endpoints are updated periodically, whereas IP addresses may change over time.Review Microsoft endpoint publications regularly and update firewall policies as required.
Verify DNS resolution
Confirm that internal DNS servers can resolve Microsoft 365 service hostnames correctly.
Verify:
- Exchange Online endpoints
- Autodiscover records
- Microsoft Entra ID authentication endpoints
- Microsoft Graph endpoints
Reliable DNS resolution is essential before starting mailbox migration.
Review proxy configuration
If Internet traffic passes through a proxy server, verify that the migration application can establish uninterrupted HTTPS connections.
Confirm that the proxy:
- Supports Modern Authentication.
- Does not modify Microsoft TLS certificates.
- Allows long-running HTTPS sessions.
- Has sufficient bandwidth for migration traffic.
Security Considerations
Firewall configuration should balance connectivity requirements with organizational security policies.
Administrators should follow these security practices:
- Apply the principle of least privilege by permitting only the outbound traffic required for Microsoft 365 services.
- Avoid opening unnecessary inbound firewall ports for Office 365 mailbox migrations.
- Restrict administrative access to authorized migration accounts.
- Monitor firewall logs for blocked Microsoft 365 connections and unusual network activity.
- Enable logging on firewall and proxy devices to assist with troubleshooting.
- Keep firewall firmware and security policies up to date.
- Review Microsoft 365 endpoint updates periodically to ensure firewall policies remain current.
- Remove temporary firewall exceptions after migration if they are no longer required.
Maintaining secure outbound connectivity while minimising unnecessary exposure helps protect the environment without affecting migration operations.
Conclusion
Proper firewall configuration is a fundamental prerequisite for a successful Office 365 migration. Most migration activities rely on secure outbound HTTPS communication over TCP port 443, supported by services such as Microsoft Entra ID, Exchange Online, Autodiscover, Exchange Web Services, Microsoft Graph, and DNS. Incorrect firewall rules, restrictive proxy configurations, SSL inspection, or DNS resolution issues can lead to authentication failures, connection errors, reduced migration performance, or incomplete mailbox synchronisation.
Administrators should verify firewall rules, allow Microsoft 365 service endpoints, validate DNS resolution, test network connectivity, and review proxy settings before starting production migrations. Performing these checks reduces migration risks and simplifies troubleshooting if connectivity issues occur. This Knowledge Base article from EdbMails provides technical guidance to help administrators configure the required firewall ports before starting an Office 365 migration.
Frequently Asked Questions
Which firewall port is mandatory for Office 365 migration?
Does Office 365 migration require port 443?
Is port 25 required for Office 365 mailbox migration?
Which outbound firewall ports should be opened?
How can I test firewall connectivity before migration?
What happens if HTTPS traffic is blocked?
