Plan an application integration with Exchange Server
Identify an Exchange deployment, choose an approved sending or receiving path, and verify the administrative boundary before changing mail flow.
Reviewed
Connect to Exchange by first deciding whether the application needs to submit messages, receive mail for a dedicated address, or access an existing mailbox. Those jobs need different permissions. A working employee login is not permission to turn the organization’s mail server into an application relay.
Identify the deployment
Ask the mail administrator whether the target mailbox is on Exchange Server, Exchange Online, or part of a hybrid deployment. These articles cover an existing on-premises Exchange Server environment. Exchange Online uses different administration and authentication paths; a Microsoft Graph example is not a drop-in API for an on-premises mailbox.
Run this read-only inventory in an authorized Exchange Management Shell, not ordinary PowerShell without Exchange cmdlets:
Get-ExchangeServer |
Format-Table Name,Edition,AdminDisplayVersion,ServerRole
Get-AcceptedDomain |
Format-Table Name,DomainName,DomainTypeKeep the results internal. Check the installed build against Microsoft’s Exchange Server documentation and supported servicing requirements. An integration guide does not establish that an older deployment is safe or supported.
Match the workflow to a connection
| Application need | Start with | Required review |
|---|---|---|
| Submit mail as an organizational identity | Administrator-approved authenticated SMTP submission | TLS, authentication, sender permissions, quotas, and outbound policy |
| Receive messages for one application address | Dedicated mailbox with approved forwarding | Data ownership, external forwarding policy, recipient scope, and retention |
| Read or alter existing mailbox content | A supported mailbox API for the actual deployment | Delegation, protocol support, identity policy, and least-privilege access |
| Send independent product notifications | A separate application-delivery service | Verified application domain, consent, bounces, and operational ownership |
For SMTP, inspect connectors before requesting a change:
Get-ReceiveConnector |
Format-List Identity,Bindings,RemoteIPRanges,AuthMechanism,PermissionGroupsMicrosoft’s Receive connector reference explains how local bindings, remote address ranges, authentication, and permissions combine. A connector accepting anonymous inbound mail is not automatically an authorized external relay.
Agree on a bounded first test
Document one source application, one approved sender, a controlled test recipient, the expected route, and a rollback owner. Use a dedicated service identity instead of a staff member’s password. Do not grant broad mailbox access or change the domain’s MX records just to prove that an application can receive one message.
The acceptance test must include a permitted send or forward, rejection of an unauthorized source, and a traceable result in Exchange. Also establish what happens when the application is down. A missing webhook or a temporary SMTP failure should not silently discard business mail.
Where MailKite fits
If the job is application sending or inbound webhooks rather than organizational mailbox access, use a separate verified domain/subdomain with the MailKite quickstart. If Exchange must keep the mailbox, forward a dedicated mailbox to MailKite with administrator approval. Neither path installs an Exchange adapter or bypasses Exchange policy.
Next, follow authenticated SMTP sending if mail must originate through the existing server. These are documented integration paths, not claims of a released Exchange-specific MailKite SDK.
References