This chapter covers mail flow connectors for third-party integration in Exchange Online, a critical topic for the MS-102 exam. Understanding how to configure inbound and outbound connectors to securely route email between Exchange Online and on-premises or third-party systems is essential for tenant management. Approximately 10-15% of exam questions touch this area, often focusing on connector types, authentication methods, and troubleshooting. Mastery of this topic ensures you can design hybrid mail flow and integrate with services like proofpoint, Mimecast, or custom SMTP applications.
Jump to a section
Think of your Exchange Online tenant as a secure corporate campus with its own internal mail system. Mail flow connectors are like customs inspection lanes at the campus border. When you want to receive packages from a third-party shipping company (e.g., a bulk email service), you set up an inbound connector—a designated lane with pre-approved sender credentials and security checks. The shipping company’s trucks arrive at this lane, present their credentials (TLS certificate and IP address), and are allowed to drop off packages directly into the campus mailroom. Similarly, when your campus needs to send packages via a third-party courier (e.g., a compliance archive), you set up an outbound connector—a lane that routes outgoing mail through a specific gate, perhaps with extra inspection (encryption) and a trusted carrier. Without these connectors, all packages would be rejected at the gate, and your internal mailroom would never see them. The connectors define exactly who can enter, what they can bring, and how outgoing mail is handed off. Misconfigured connectors are like a customs lane that checks passports but not cargo—malicious packages can slip through, or legitimate mail gets stuck in no-man’s-land.
What Are Mail Flow Connectors?
Mail flow connectors in Exchange Online are configuration objects that define how email is routed between your Exchange Online organization and external systems. They are essential for third-party integration because they allow you to control the flow of messages to and from services that are not part of your Exchange organization. Connectors are defined at the organization level and are processed by the transport pipeline.
Why Connectors Exist
Exchange Online, by default, only accepts mail from authenticated senders within your tenant. To receive mail from external systems (like an on-premises Exchange server or a third-party email security gateway), you must create an inbound connector that explicitly trusts the source. Similarly, to send mail to a third-party service that requires specific routing (e.g., a compliance archive or a bulk email provider), you create an outbound connector that defines the destination smart host and authentication requirements. Without connectors, mail from third parties would be rejected with a 550 5.7.1 error, and mail to third parties would be delivered directly via MX records, bypassing any custom routing.
How Connectors Work Internally
Connectors are processed by the Transport service in Exchange Online. When a message arrives from an external source, the transport pipeline checks the message's source IP address and TLS certificate against the inbound connectors. If a match is found, the message is accepted and stamped with the connector's properties (e.g., security restrictions, header preservation). For outbound mail, when a user sends a message, the transport pipeline evaluates the recipient domain against the outbound connectors. If a matching connector exists, the message is routed to the specified smart host rather than being delivered directly to the recipient's MX server.
Key Components and Defaults
- Inbound Connector: Defines who can send mail into your organization. Key settings: - Sender domains: The domains from which the connector accepts mail (e.g., contoso.com). Default: any domain. - Sender IP addresses: List of IP addresses that are allowed to send via this connector. Default: none. - Require TLS: If enabled, the connector only accepts mail over TLS. Default: off. - Certificate subject name: The subject name on the TLS certificate presented by the sender. Used for mutual TLS authentication. - Outbound Connector: Defines how mail is sent to a specific domain or smart host. Key settings: - Recipient domains: The domains to which this connector applies. Default: any domain. - Smart host: The FQDN or IP address of the server that will receive the mail. Default: none (direct delivery via MX). - Route mail through on-premises: If enabled, mail is routed through your on-premises Exchange organization. Default: off. - TLS settings: Options to require TLS, use opportunistic TLS, or no encryption. Default: opportunistic TLS. - Default connectors: Exchange Online creates two default connectors: one for inbound mail from on-premises (if hybrid is configured) and one for outbound mail to on-premises. These are automatically managed by the Hybrid Configuration Wizard.
Configuration Commands
Connectors are managed via the Exchange admin center (EAC) or Exchange Online PowerShell. Key cmdlets:
- New-InboundConnector
- Set-InboundConnector
- Get-InboundConnector
- New-OutboundConnector
- Set-OutboundConnector
- Get-OutboundConnector
- Test-MailFlow (to verify connector routing)
Example: Create an inbound connector that accepts mail from a third-party security gateway at IP 192.168.1.10 with TLS required:
New-InboundConnector -Name "From Security Gateway" -SenderDomains * -SenderIPAddresses 192.168.1.10 -RequireTls $true -TlsSenderCertificateName "*.securitygateway.com"Example: Create an outbound connector that routes mail to a compliance archive at archive.contoso.com:
New-OutboundConnector -Name "To Compliance Archive" -RecipientDomains archive.contoso.com -SmartHosts archive.contoso.com -SmartHostAuthMechanism BasicAuth -UseMxRecord $false -TlsSettings EncryptionOnlyInteraction with Related Technologies
- Hybrid Configuration: In hybrid deployments, connectors are automatically created by the Hybrid Configuration Wizard. The inbound connector trusts the on-premises Exchange servers, and the outbound connector routes mail to the on-premises smart host. Manual modification of these connectors can break hybrid mail flow. - Mail Flow Rules (transport rules): Connectors work in conjunction with mail flow rules. For example, you can create a rule that applies a disclaimer only to messages that arrive via a specific inbound connector. The connector identity is available as a condition in transport rules. - Message Tracking: When troubleshooting, message tracking logs include the connector used for delivery. You can filter by connector name to isolate issues. - Authentication: Connectors support several authentication methods: - IP-based: Whitelisting sender IP addresses. - Certificate-based: Matching the TLS certificate subject name. - Basic Auth: For outbound connectors to smart hosts that require username/password. - None: No authentication (not recommended).
Security Considerations
TLS: Always require TLS for inbound connectors from third parties to ensure encryption. For outbound connectors, use TlsSettings EncryptionOnly or RequireTls to enforce encryption.
IP Restrictions: Limit inbound connectors to specific IP addresses when possible. Avoid using wildcard IP ranges.
Certificate Validation: For mutual TLS, ensure the certificate subject name matches exactly. The connector will reject if the certificate subject does not match.
Troubleshooting
Common issues: - Mail rejected with 5.7.1: The source IP is not in the connector's allowed IP list, or TLS requirement is not met. - Mail not routed via connector: The recipient domain does not match any outbound connector, or the connector is disabled. - Certificate mismatch: The TLS certificate subject name does not match the connector's expected subject.
Use Get-MessageTrace and Get-MessageTrackingLog to see which connector processed a message. The Test-MailFlow cmdlet can verify routing:
Test-MailFlow -TargetEmailAddress user@contoso.com -SourceEmailAddress admin@fabrikam.comIdentify Third-Party Service Requirements
Before creating a connector, gather the requirements from the third-party service. For inbound connectors, you need the sender's IP addresses (or IP range), the domains they will send from, and whether they use TLS. For outbound connectors, you need the recipient domain(s), the smart host FQDN or IP, and the authentication method (e.g., Basic Auth, certificate). Also confirm if the service requires specific TLS settings (e.g., TLS 1.2 minimum). Document these details to avoid misconfiguration.
Create Inbound Connector in EAC or PowerShell
Open the Exchange admin center, go to 'Mail flow' > 'Connectors', and click '+' to add a new connector. Select 'Inbound' and choose 'Partner organization' as the connection type. Enter a descriptive name. In the 'Sender domains' section, specify the domains the third party will send from, or use '*' for any domain. In the 'Sender IP addresses' section, add the exact IP addresses provided by the partner. Configure TLS settings: enable 'Require TLS' and optionally specify the certificate subject name. Save the connector. Alternatively, use PowerShell: New-InboundConnector with appropriate parameters.
Create Outbound Connector for Third-Party
In EAC, add a new connector, select 'Outbound', and choose 'Partner organization'. Enter a name. In 'Recipient domains', specify the domain(s) of the third-party service. Under 'Routing', choose 'Route mail through smart hosts' and enter the smart host FQDN. Set 'Smart host authentication' to the method required (e.g., Basic Auth, certificate). Configure TLS settings: typically 'Force TLS' or 'Offer TLS but only send if TLS is supported'. Save. In PowerShell: New-OutboundConnector with -RecipientDomains, -SmartHosts, -SmartHostAuthMechanism, and -TlsSettings.
Test Mail Flow Using Test-MailFlow
After configuring connectors, verify mail flow using the Test-MailFlow cmdlet. For inbound, send a test message from the third party to a mailbox in your tenant and check message trace. For outbound, send a message from your tenant to the third-party domain. Use Get-MessageTrace to confirm the message used the correct connector. If the message is rejected, check the rejection code: 5.7.1 indicates authentication failure, 5.4.1 indicates routing failure. Adjust connector settings accordingly.
Monitor and Troubleshoot with Message Trace
Regularly monitor mail flow using the Exchange admin center's message trace tool. Filter by the connector name to see all messages that used that connector. Look for patterns of failure (e.g., high deferral rates). Common issues: IP changes at the third party require updating the connector; TLS certificate expiration causes rejection. Set up alerts for connector-related failures using the Microsoft 365 admin center or PowerShell scheduled tasks. Document the baseline performance for each connector.
Enterprise Scenario 1: Third-Party Email Security Gateway
A large enterprise uses Proofpoint as a cloud email security gateway. All inbound email must first pass through Proofpoint before reaching Exchange Online. To achieve this, the enterprise creates an inbound connector that trusts Proofpoint's IP addresses (e.g., 192.0.2.0/24) and requires TLS with Proofpoint's certificate. Proofpoint is configured to forward all mail to Exchange Online's MX endpoint after scanning. Outbound mail from Exchange Online is routed through Proofpoint for outbound filtering via an outbound connector that uses Proofpoint's smart host. This setup ensures consistent security policy. Common issues: Proofpoint IP changes without notice cause mail rejection; TLS certificate mismatch if Proofpoint rotates certificates without updating the connector. The administrator must maintain a change log and test connectors after any third-party update.
Enterprise Scenario 2: On-Premises Archiving System
A financial firm uses an on-premises archiving appliance (e.g., Barracuda Message Archiver). All emails sent and received must be copied to the archiver. The firm configures an outbound connector that routes a copy of all mail (via journaling) to the archiver's SMTP address. The connector uses Basic Auth with a dedicated account. The archiver's IP is whitelisted in Exchange Online's inbound connector to receive journal messages. Performance considerations: journaling can double mail volume; ensure the archiver can handle peak throughput. Misconfiguration: if the outbound connector is set to route all mail to the archiver instead of just journal copies, normal delivery fails. The administrator must use mail flow rules to limit which messages use the connector.
Enterprise Scenario 3: Hybrid Migration with Third-Party SMTP Relay
During a hybrid migration, an organization uses a third-party SMTP relay (e.g., SendGrid) to handle bulk email from legacy applications. An outbound connector is created for the relay's domain with smart host authentication via API key. The relay is configured to accept mail from Exchange Online's IP range. This offloads bulk mail from Exchange Online to avoid throttling. Issues: if the relay's IP changes, outbound mail queues indefinitely. The administrator must monitor the relay's health and have a fallback connector that uses MX delivery if the relay is unreachable.
What MS-102 Tests on This Topic (Objective 1.4)
The MS-102 exam focuses on configuring and troubleshooting mail flow connectors for third-party integration. Specific sub-objectives include:
Creating and managing inbound and outbound connectors via EAC and PowerShell.
Understanding authentication methods: IP-based, certificate-based, and Basic Auth.
Troubleshooting common connector failures: 5.7.1 (authentication), 5.4.1 (routing).
Configuring TLS settings: RequireTls, OpportunisticTLS, EncryptionOnly.
Using Test-MailFlow and message trace to diagnose issues.
Identifying when connectors are needed vs. direct MX delivery.
Common Wrong Answers and Why Candidates Choose Them
Wrong answer: 'Create an inbound connector with the sender domain set to * and no IP restrictions.' Why chosen: Candidates think this is easiest. Reality: This allows any external server to send mail into the tenant, bypassing security. The correct approach is to restrict by IP.
Wrong answer: 'Use an outbound connector to route all mail to a third-party service without specifying recipient domains.' Why chosen: Candidates think a single connector works for all outbound mail. Reality: Outbound connectors apply only to specified recipient domains. For all mail, you need a connector with recipient domain * or use a transport rule.
Wrong answer: 'TLS is optional for inbound connectors from trusted partners.' Why chosen: Candidates trust the partner's internal network. Reality: TLS should always be required to prevent man-in-the-middle attacks, especially over the internet.
Wrong answer: 'The Hybrid Configuration Wizard creates connectors that can be freely modified.' Why chosen: Candidates assume connectors are independent. Reality: Modifying hybrid connectors can break mail flow; the wizard manages them.
Specific Numbers and Terms on the Exam
Default connector names: 'Inbound from on-premises' and 'Outbound to on-premises'.
Error codes: 5.7.1 (AuthenticationRequired), 5.4.1 (NoRouteToDomain).
TLS settings: RequireTls, OpportunisticTLS (default), EncryptionOnly.
Authentication mechanisms: IPBased, CertificateBased, BasicAuth, None.
PowerShell cmdlets: New-InboundConnector, Set-OutboundConnector, Get-Connector.
Edge Cases and Exceptions
Multiple connectors for same domain: If multiple inbound connectors match a sender, the one with the most specific IP range wins. If multiple outbound connectors match a recipient domain, the one with the most specific recipient domain wins.
Connector priority: Connectors are evaluated in order of specificity. For inbound, IP range specificity; for outbound, domain specificity.
Connector disabled: A disabled connector is ignored; messages fall back to default routing.
Third-party changes: If a third party changes their IP or certificate, the connector must be updated immediately to avoid mail loss.
How to Eliminate Wrong Answers
If the question involves 'receiving mail from a partner', look for inbound connector with IP restrictions and TLS.
If the question involves 'sending mail to a partner's smart host', look for outbound connector with recipient domain and smart host.
If the question involves 'hybrid mail flow', look for default connectors managed by wizard.
If the question involves 'troubleshooting 5.7.1', look for IP not in connector or TLS mismatch.
Remember: connectors are always about explicit routing; default behavior is MX delivery for outbound and rejection for inbound.
Inbound connectors require sender IP or certificate authentication; without them, external mail is rejected.
Outbound connectors route mail to a smart host only for specified recipient domains; other domains use MX.
Default hybrid connectors are automatically managed and should not be manually modified.
TLS settings: RequireTls rejects non-TLS; OpportunisticTLS uses TLS if available; EncryptionOnly forces encryption.
Common error 5.7.1 indicates authentication failure; check IP and TLS settings.
Test-MailFlow cmdlet can verify connector routing before production use.
Connectors are evaluated by specificity: most specific IP range (inbound) or domain (outbound) wins.
These come up on the exam all the time. Here's how to tell them apart.
Inbound Connector
Defines who can send mail into your organization.
Requires sender IP addresses or certificate subject name.
Used for receiving mail from third parties (security gateways, on-premises).
If not configured, external mail is rejected with 5.7.1.
TLS can be required to enforce encryption.
Outbound Connector
Defines how mail is sent to specific domains or smart hosts.
Requires recipient domain(s) and smart host address.
Used for sending mail to third parties (archives, relays).
If not configured, mail is delivered directly via MX records.
TLS settings control encryption for outbound delivery.
Mistake
Connectors are only needed for hybrid deployments.
Correct
Connectors are required for any third-party integration, including email security gateways, archiving services, and custom applications. Hybrid deployments are just one use case.
Mistake
An inbound connector with sender domain * allows any domain to send mail.
Correct
The sender domain setting only filters the domain in the From address, but the connector still requires IP or certificate authentication. Without IP restriction, any authenticated sender can use the connector.
Mistake
Outbound connectors override MX records for all domains.
Correct
Outbound connectors only apply to the recipient domains specified. For domains not listed, Exchange Online uses MX records to deliver directly.
Mistake
TLS is automatically enforced if you check 'Require TLS'.
Correct
Requiring TLS means the connector will reject mail if TLS cannot be negotiated. The remote server must support TLS and present a valid certificate. If the certificate subject does not match the connector's expected name, the connection fails.
Mistake
You can modify the default hybrid connectors without impact.
Correct
The default connectors created by the Hybrid Configuration Wizard are essential for hybrid mail flow. Changing them can break free/busy, OOO messages, and mail routing between on-premises and cloud.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
In the Exchange admin center, go to 'Mail flow' > 'Connectors' and add a new inbound connector. Select 'Partner organization'. Enter the sender IP addresses provided by the gateway (e.g., 192.0.2.0/24). Optionally, specify sender domains if the gateway only sends for certain domains. Enable 'Require TLS' and enter the certificate subject name if using mutual TLS. Save. In PowerShell: New-InboundConnector -Name 'Security Gateway' -SenderDomains * -SenderIPAddresses '192.0.2.0/24' -RequireTls $true -TlsSenderCertificateName '*.securitygateway.com'.
In Exchange Online, 'outbound connector' is the term used for what was called a 'send connector' in on-premises Exchange. They serve the same purpose: define how mail is routed to external systems. The naming difference is purely cosmetic; the functionality is identical.
Error 5.7.1 typically means the sender is not authenticated. Check that the sender's IP address is in the connector's allowed IP list. If TLS is required, ensure the sender presents a valid TLS certificate whose subject name matches the connector's TlsSenderCertificateName. Also verify the sender is not using a different IP than expected (e.g., due to NAT). Use Get-MessageTrace to see the rejection reason.
Yes, but you must set the recipient domain to '*' (any domain). However, this will override MX delivery for all domains, which may cause issues if the third-party service is down. It's better to use a connector only for specific domains or use a mail flow rule to route copies.
First, verify the connector is enabled. Check the recipient domains for outbound or sender IP for inbound. Use Test-MailFlow to simulate a message. Check message trace to see which connector was used; if none, the connector may not match. For outbound, ensure the recipient domain is exactly as specified (e.g., 'contoso.com' vs '*.contoso.com').
Deleting the default connectors will break mail flow between on-premises and Exchange Online. Users will not be able to receive mail from on-premises, and outbound mail to on-premises will be delivered directly via MX, bypassing the hybrid routing. You must recreate them using the Hybrid Configuration Wizard.
Yes, outbound connectors can use Basic Auth for smart host authentication. However, Basic Auth is less secure and should be avoided if possible. Use certificate-based authentication or IP whitelisting when available. Inbound connectors do not support SMTP authentication; they rely on IP or certificate.
You've just covered Mail Flow Connectors for Third-Party Integration — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.
Done with this chapter?