Connect Outlook and Microsoft 365 to EspoCRM

How to connect Outlook and Microsoft 365 mailboxes to EspoCRM

You can connect Microsoft 365 mailboxes to a self-hosted EspoCRM in two ways: through IMAP and SMTP settings for the mailbox, or through the Outlook integration, one of EspoCRM's official extensions, which uses secure authentication. The method you can use depends on what your Microsoft tenant allows, so confirm that with your Microsoft 365 administrator before you configure anything in EspoCRM. Once a mailbox is connected, the instance fetches incoming messages, sends replies and new messages from the CRM, and links each email to the records it concerns, such as an account, contact, lead or case. A salesperson can then see the full conversation history on the record itself, without searching a personal inbox.

The first decision is personal or group access. Personal mailboxes suit individual representatives whose correspondence should stay tied to their own identity and who send messages as themselves. Group accounts suit shared addresses such as sales@ or support@, where several people must read the same messages and any of them may reply from the shared address. Ask who reads the mail, who replies to it, and whether replies must come from the shared address. Those answers decide how many accounts you configure and who is granted access to each one. Folder setup, team routing and notifications for shared addresses are covered in the sibling pages on shared inboxes and email-to-case, so settle the mailbox model first.

Before you configure either method, confirm the Microsoft-side details for your tenant. Check whether IMAP and SMTP access is permitted for the mailboxes in scope, whether the Outlook integration needs an app registration and administrator consent, and which users are allowed to grant that consent. Ask whether conditional access or mailbox access policies apply to the account the instance will use. Also confirm that your firewall allows the self-hosted server to reach Microsoft's mail endpoints. Test the setup with one personal mailbox before you connect shared accounts, so any policy problem shows up on a single account first.

Which connection method fits each mailbox

This table compares IMAP and SMTP settings with the Outlook integration, and personal accounts with group accounts, across who each suits, what the administrator configures, what the user does, and what to confirm first. Read each row as a question you need answered before choosing a method for a specific mailbox. The main takeaway is that the connection method and the mailbox type are separate decisions, and both should be settled before any account is created.

Decision point	IMAP and SMTP	Outlook integration
Who it suits	Teams that need a direct mail connection and can manage server settings and credentials themselves	Teams that want sign-in handled through Microsoft and fewer manually stored credentials
What the administrator configures	Incoming IMAP and outgoing SMTP server details, ports, encryption and the account credentials used by EspoCRM	The Outlook extension, its Microsoft app registration and the authentication settings the extension requires
What the user does	Enters or receives mailbox settings for a personal account, then confirms that mail fetches and sends	Signs in with their Microsoft account once the integration is enabled for their user
Confirm before choosing	Which IMAP and SMTP options your Microsoft 365 tenant currently allows for the mailbox, with Microsoft and your tenant administrator	Which extension version and Microsoft authentication settings are supported in your EspoCRM release, with the EspoCRM documentation
Personal mailbox fit	Workable where the tenant permits it and the user is comfortable managing their own connection	Usually the simpler path for an individual user, where the extension is in use
Group or shared mailbox fit	Possible for a shared address, but credential ownership and access review need an explicit owner	Confirm whether the Outlook extension supports the shared mailbox type you plan to use before you rely on it

Setting up a Microsoft 365 mailbox in EspoCRM, step by step

This sequence takes one Microsoft 365 mailbox from tenant confirmation to a verified link between its mail and the right CRM records. Each step ends with a check, so a fault is found where it starts. Run it once per mailbox, beginning with the mailbox that carries the most customer traffic.

Confirm tenant settings and mailbox type with the administrator
The Microsoft 365 administrator decides what EspoCRM can reach, so start with them. Ask them to confirm whether the address is a user mailbox, a shared mailbox or a group address, whether IMAP and SMTP access is allowed for that mailbox, and which sign-in methods the tenant permits for mail clients. Ask who owns the mailbox credentials and where they are stored. Record the answers in a short note that names the mailbox address, its type and the person accountable for it. Done when the administrator has confirmed each item in writing and you can sign in to the mailbox from a mail client outside EspoCRM. That test separates tenant policy problems from EspoCRM configuration problems later.
Choose the connection method for each mailbox
Pick the connection method before you create anything in EspoCRM. The Outlook integration is an official extension that connects the Microsoft account through its own sign-in flow. IMAP and SMTP connect through standard mail protocols and depend on the authentication options your tenant still allows. Read the current EspoCRM documentation for the requirements of each method, then confirm with the administrator that the method is permitted for this mailbox type. Record the decision per mailbox, because a personal mailbox and a shared mailbox may need different methods. Done when every mailbox has one named method and the administrator has accepted it in writing.
Configure the account in EspoCRM
An administrator sets up the chosen method. For the Outlook integration, install the official extension if it is not already present, then follow its setup to connect the Microsoft account. For IMAP and SMTP, enter the server, port, encryption and login values that the tenant and the EspoCRM documentation specify, and keep the password out of shared notes. Assign personal mailboxes to the user who owns them, and assign shared mailboxes to a group account that a team can access. Done when the account saves without error and the connection test on the account screen reports success. If the test fails, check the sign-in method and mailbox permissions before you change server settings.
Enable background jobs with cron or a scheduled task
Fetching and sending mail depends on background jobs that run outside the browser session. The EspoCRM server configuration documentation states that cron or a scheduled task is required for these jobs. On a Linux server, add the EspoCRM cron entry for the web server user, using the command from the documentation for your install path. On a Windows server, create a scheduled task that runs the same command at the interval the documentation describes. Run the job once by hand to confirm it starts without a permission error. Done when the job log shows a completed run and a later run appears without manual input. Without this step, mail can sit in the queue even when the account is correct.
Send a test message outbound
Send a message from the new account to a mailbox you control outside both Microsoft 365 and EspoCRM. Use a subject line that names the test so it is easy to find later. Confirm that the message arrives with the mailbox address as the sender, that the reply-to address is the one you expect, and that a copy appears in the Sent folder of the mailbox. Then open the EspoCRM email list and check that the same message is stored there. Done when the external recipient receives the message with correct headers and EspoCRM shows the matching record. If the recipient does not receive it, check the SMTP settings and the sending permissions for that mailbox.
Send a test message inbound and check record links
From an external account, send a reply to the mailbox address, then wait for the next background job run. Confirm that the message appears in EspoCRM. A message from a contact or lead whose email address matches the sender should show on that record's activity or stream. If it links to nothing, confirm that the sender address is stored on a record and that the matching behavior you intend is in place. Then send a second message from an address that has no record, so you can see what EspoCRM does with unknown senders. Done when both inbound messages behave as you expect and you have written down the linking result for each.
Hand the mailbox over and record the setup
Give the mailbox to the team that will use it. Ask one user from that team to send and receive a message, check that they can see it on the correct record, and confirm that replies leave from the address the customer expects. Record the mailbox owner, the connection method, the location of the cron entry or scheduled task and the test results in your operations notes. A later administrator can then repeat the checks after a password change or a tenant policy change. Done when the team confirms the checks in writing and the notes name who renews credentials. Shared mailboxes need a named owner for that renewal.

How shared Microsoft 365 mailboxes work as EspoCRM group accounts

A shared mailbox such as sales@ or support@ is usually connected to EspoCRM as a group account rather than as one person's personal account. The reason is practical: a group account belongs to the team, so mail arriving there is not trapped in one user's view, and replies can go out under the shared address. With a personal account, the mailbox owner would see the mail, the owner would be the only one who could reply from it, and records created from those emails would be tied to that individual when they leave or change roles. In EspoCRM, the group account is configured by an administrator, and access to it is controlled through the teams and permissions of the users who need it, so the question to settle first is which teams should see the mailbox and what each role may do with the mail it receives.

Teams carry most of the access decisions. Assign the group account to the team that works the mailbox, then check that the roles given to those users allow reading and linking the related emails, creating and editing the records they touch, and sending from the group address. Users outside that team should not see the mailbox traffic unless there is a documented reason. Shared inbox folders, follower notifications and reply handling are covered in the sibling topic on EspoCRM shared inboxes with group email accounts, so this page does not repeat them. Use that topic when you need the operational detail for how a group address is worked day to day. Before you configure anything, confirm two things in your Microsoft 365 tenant. First, confirm how the shared mailbox is delegated: whether the account your EspoCRM connection uses has been granted access to the shared mailbox, and at what level, since the access that works for reading mail may not cover sending. Second, confirm the sending identity: whether mail should go out as the shared address itself, whether a send-as or send-on-behalf permission is in place, and whether your tenant policy allows that for the account used. Your Microsoft 365 administrator owns these settings, so agree them in writing before testing. Also confirm with your mail administrator which authentication method your tenant currently permits for this connection, because that decision shapes the setup covered in the other sections of this page.

Securing Microsoft mailbox credentials and access in EspoCRM

A mailbox connected to EspoCRM gives the CRM a route into customer correspondence, so its security depends on who signs in, how credentials are held and who can read the mail once it arrives. The cards below cover the EspoCRM settings and the operating habits that keep Microsoft 365 and Outlook connections contained, and they flag what to confirm with your own identity and Microsoft tenant administrators.

Keep mail work off admin accounts

Connect mailboxes using standard user accounts and reserve administrator accounts for configuration changes. EspoCRM's security guidance recommends avoiding admin accounts for daily work, because an administrator who fetches or sends mail exposes the highest-privilege login to phishing and session theft. Check which accounts currently hold EspoCRM admin rights and which Microsoft 365 roles they also carry, since overlapping roles widen the blast radius of a single compromise.

Enforce password and two-factor policy

Require two-factor authentication on every EspoCRM user who can reach a mailbox. EspoCRM's security guidance recommends a password policy and 2FA, but its own 2FA is not compatible with OIDC sign-in, so if you front EspoCRM with a Microsoft identity provider, confirm which second factor applies and where it is enforced. Document the policy in one place so the EspoCRM settings and the Microsoft Entra conditional access rules match.

Limit authentication token lifetime

Shorten how long EspoCRM sessions and authentication tokens remain valid, so a stolen browser session or token expires within a defined window. Mailbox access through an OAuth-based connection depends on refresh tokens, so set the EspoCRM session limits and the Microsoft token policies together and test that a revoked session stops fetching mail. Ask your identity team to confirm the exact lifetimes they will enforce, since the defaults depend on your tenant configuration.

Restrict access by IP address

Use EspoCRM's IP restriction settings to limit where administrative and mail-enabled logins can come from, such as office networks or a VPN egress range. This does not replace MFA, but it reduces the value of a password obtained elsewhere. Confirm with your network team which egress addresses are stable, and plan an exception path for remote staff before enforcing the rule, so mail fetching does not fail silently for people who travel.

Prefer OAuth over stored mailbox passwords

Where the Outlook integration supports OAuth, use it so EspoCRM receives a delegated token rather than holding a mailbox password. Where you must use IMAP and SMTP with a password, treat that password as a secret with an owner, a rotation schedule and restricted access to the EspoCRM administration pages. Confirm with Microsoft 365 administrators whether basic authentication for IMAP or SMTP is still permitted in your tenant, because that setting determines which option is open to you.

Review shared mailbox access and offboarding

Map every person and team who can open a group or shared mailbox in EspoCRM, and review that list on a schedule. When staff leave or change roles, revoke their EspoCRM user access, remove them from teams that see group mail and disconnect any personal mailbox they connected. Check that the Microsoft 365 account is disabled or its tokens revoked, because removing the CRM login alone does not stop a previously granted delegated connection.

What does it cost to connect Outlook and Microsoft 365 to EspoCRM?

What drives the cost of connecting Outlook and Microsoft 365 mailboxes to EspoCRM?

The cost depends mainly on how many mailboxes you connect, how many authentication paths you need, and how much tenant and identity work sits behind them. A single personal mailbox over IMAP and SMTP is a small task. Connecting several personal mailboxes, adding shared mailboxes as group accounts, and setting up OAuth through the Outlook integration each add configuration, testing and access decisions. Ask any partner to price these items separately in the written scope, so you can see which parts are one-time work and which parts recur.

How long does the Outlook mailbox setup take in our environment?

The duration depends on your Microsoft 365 tenant configuration, your EspoCRM hosting, and how many mailbox types you need. Teams with a clear mailbox list, an existing app registration policy and a tested EspoCRM instance usually move faster than teams that must first resolve identity or admin approval questions. Ask for a timeline in the quote that lists the dependencies: tenant access, admin consent, test mailboxes and sign-off on who owns each account.

What must we provide before a partner can start the work?

Plan to provide tenant access or a named administrator who can act during the build, a list of every mailbox to connect with its owner and purpose, and a decision on whether each account is personal or group. If OAuth through the Outlook integration is in scope, a Microsoft 365 administrator must be available to approve the required permissions, since tenant policy may require admin consent. You should also confirm which EspoCRM instance and version receives the connection, and who will hold the credentials after handover.

Can our internal administrator set up Outlook and Microsoft 365 mailboxes alone?

Often yes for a single IMAP and SMTP mailbox, provided the administrator has EspoCRM admin rights, access to the mail server settings and a test plan. The work becomes harder when OAuth consent, conditional access policies, shared mailbox permissions and mail delivery rules must be coordinated across Microsoft 365 and EspoCRM. Decide whether your team has the time and the Microsoft 365 administration skills to own that coordination, then ask any partner to state which parts they would do and which would need your administrator.

Does the Outlook integration require a paid extension or a specific plan?

The Outlook integration is one of the official EspoCRM extensions, so you should confirm its licensing and installation requirements before you commit. The EspoCRM pricing page lists the Advanced Pack as included in all EspoCRM Cloud plans, but that does not confirm the status of the Outlook extension for a self-hosted instance. Ask the vendor or your partner to confirm the extension's license terms, its compatibility with your EspoCRM version, and whether any Microsoft 365 licensing affects the setup.

What changes if we add shared mailboxes after the first setup?

Adding shared mailboxes later adds work in three areas: permissions on the Microsoft 365 side, group account configuration in EspoCRM, and decisions about who sees and replies to messages. Each new shared mailbox needs its own access review, folder and fetch settings, and notification rules. Ask for the cost of adding a mailbox as a separate change request in the quote, and confirm whether the original scope covers future additions or only the current list.

What recurring costs follow the initial connection?

After go-live, recurring costs include monitoring mail fetch and send failures, renewing or rotating credentials, reviewing mailbox access as staff change, and applying EspoCRM and extension updates that may affect mail handling. The first setup is usually a one-time cost, while these activities recur. Ask whether support is covered by a retainer or billed per request, and what response process applies when a mailbox stops syncing.

Limits to confirm in your Microsoft 365 environment

Microsoft 365 mailbox connections depend on settings controlled by your tenant administrators, your EspoCRM version and your hosting model. The items below are the points to confirm before you commit to a setup, and each one names who holds the answer.

Current support for the authentication method

Confirm with your Microsoft 365 tenant administrator that the authentication method you plan to use is still supported for mail access in your tenant. Microsoft has changed mail authentication requirements over time, so do not rely on older guides. Ask for a written answer that names the method, the tenant type and any conditional access policies that apply to mail clients.

Mailbox protocols enabled per account

IMAP and SMTP access can be turned off at the tenant level or per mailbox, and some accounts are blocked from legacy protocols entirely. Ask your Microsoft 365 administrator to confirm that IMAP and SMTP submission are enabled for each mailbox you plan to connect, including any shared mailboxes. A test login from the EspoCRM server should succeed before the mailbox is added to the CRM.

Mail volume and background job capacity

EspoCRM fetches email through background jobs, so the number of mailboxes and the volume of mail per mailbox determine how long each fetch takes and how much load the server carries. Ask your platform team how cron or the scheduled task runner is configured on your server and how many jobs can run in parallel. Agree on the fetch interval and the fetch-since date with the business owner of each mailbox.

Outlook integration and EspoCRM release match

The Outlook integration is an official extension, so its version has to match the EspoCRM release you run. Check the extension's compatibility with your current release before you install it, and plan the same check for every EspoCRM upgrade. Ask your EspoCRM administrator to record the installed release and extension versions in your change log.

Sending limits imposed by Microsoft

Microsoft 365 applies sending limits per account and per tenant, and these limits can block campaign or auto-reply traffic sent through a mailbox. Ask your Microsoft 365 administrator for the current limits that apply to your tenant and to the mailboxes you plan to use for outbound mail. Keep high-volume mass email on a separate sending service unless the limits confirm that the mailbox can carry it.

Fit with your hosting and TLS model

Your reverse proxy, certificate chain, outbound firewall rules and any egress allowlists decide whether EspoCRM can reach the Microsoft mail endpoints with the required encryption. Ask your network team to confirm outbound access on the IMAP and SMTP ports from the EspoCRM host, and ask your security team to confirm the certificate trust chain. Test the connection from the production network, not only from a development host.

How DeployOpen works on this

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Microsoft 365 mail connections in EspoCRM, we agree the mailbox inventory, authentication method and sharing model in writing before any configuration starts, so your team knows exactly what gets delivered and what it will need to provide.

How we scope

We inventory the personal and shared Microsoft 365 mailboxes that must reach EspoCRM, and who uses each one.
The written scope states the authentication path for each mailbox, including which Outlook integration or IMAP and SMTP settings apply.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.

How we build

We configure the mailboxes in your EspoCRM instance and set up group accounts for shared addresses such as sales or support.
We test sending and receiving from each account, confirming that messages link to the correct records and threads.
We confirm the mail settings and permissions against your Microsoft 365 tenant policies before go-live, with your administrators involved.

How we hand over

You receive a runbook covering each connected mailbox, its owner, its authentication method and its fetch and send settings.
The handover records credential storage, renewal steps and the admin accounts allowed to change mail configuration.
Your team is walked through the test results and the known limits, so day-one ownership is clear.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, covering mail connection changes after go-live.
We can review EspoCRM upgrades and Microsoft 365 policy changes that affect mailbox connections before they reach production.
Support requests are handled against the agreed scope, so changes to mailboxes or authentication are priced and planned in writing.

Connecting Outlook and Microsoft 365 mailboxes to EspoCRM