Exchange mail flow guides › Inbound: POP3 and IMAP retrieval into Exchange

POP3 retrieval or MX record to Exchange: when a connector is the right choice and when it is not

Pointing the MX record at your Exchange Server gives you direct SMTP delivery and is the better design when the server can be reached from the internet on port 25 under a name your public DNS can point to, and when you filter spam on arrival yourself; a POP3/IMAP connector is the right choice when one of those is missing or unwanted, during a migration, or when the provider mailboxes have to stay where they are. This guide sets the two designs side by side, says plainly when you do not need a connector, and describes the order in which shops usually move from one to the other.

Updated on 2026-09-29

The two designs

MX record to Exchange. Other mail servers look up the MX record of your domain and deliver to the host it names. Microsoft puts the requirement in one sentence in its post-installation guide (Configure mail flow and client access on Exchange servers): “To receive email from the internet for a domain, you need an MX resource record in your public DNS for that domain. Each MX record should resolve to the internet-facing server that receives email for your organization.” The example there pairs the MX record with an A record that carries the server’s public IP address. On the server, the default receive connector named “Default Frontend” listens for anonymous inbound SMTP mail on port 25, and Microsoft lists port 25/TCP from the internet (any) to the Mailbox server as the port required for inbound mail (Network ports for clients and mail flow in Exchange).

POP3/IMAP retrieval. The MX record stays with the provider. The provider’s mail server accepts the mail and stores it in mailboxes; a connector service in your network logs in to each mailbox on a schedule, downloads what is new and submits it to Exchange over SMTP. POPcon is such a connector: a Windows service that downloads email from external POP3 and IMAP mailboxes into Microsoft Exchange Server and distributes it to the correct Exchange mailboxes. Exchange has no such function of its own; see Does Exchange Server have a built-in POP3 connector?

Side by side

	MX record points at Exchange	POP3/IMAP connector
Public DNS	MX record for the domain that resolves to your internet-facing server; in Microsoft’s example an A record with the public IP address behind it	Unchanged; the MX record stays with the provider
Firewall, inbound	Port 25/TCP from the internet (any) to the Mailbox server, or to an Edge Transport server in the perimeter network	Nothing inbound from the internet
Connections the design makes	Sending servers connect to you	The connector connects out to the provider (POP3 110/995, IMAP 143/993) and to Exchange on port 25 inside your network
Spam filtering on arrival	Yours to provide: Edge Transport server, antispam agents enabled on the Mailbox server, or a filtering service in front	Whatever the provider applies to its mailboxes; POPcon PRO adds checks against real-time blacklists and antivirus scanning at the connector
When Exchange is down	Mail waits on the sending servers, for as long as each of them keeps retrying	Mail waits in the provider mailbox; already downloaded messages wait in the connector and are retried every cycle
Delay until the message is in the mailbox	None beyond SMTP delivery	Up to one retrieval interval; the minimum interval is 1 minute, 0 means continuous retrieval
Finding the recipient	The SMTP envelope names the recipient	Exact with one provider mailbox per user; with a catch-all mailbox the connector reads the recipient from the message headers
Accepted domain in Exchange	Required	Required

When the MX record is the better design

If your server can take mail from the internet on port 25 and you have an answer for spam, direct delivery is simpler: one hop fewer, no retrieval interval, and the recipient is always the one the sender’s server named. A connector then adds nothing for that domain, and this guide does not suggest otherwise.

The spam question deserves a closer look before the switch, because it is the part that the provider handled until now. Microsoft describes three places for it (Antispam protection in Exchange Server):

• An Edge Transport server in the perimeter network. All antispam agents are installed and enabled there by default, and the Connection Filtering agent — the one that works with IP block lists and block list providers — is available only on Edge Transport servers. Microsoft describes the role as a way to minimise the exposure of the internal Exchange organization to threats on the internet.
• Antispam agents on the Mailbox server. They have to be enabled first; Microsoft’s procedure does that with the script Install-AntiSpamAgents.ps1 (Enable antispam functionality on Mailbox servers). Microsoft’s own wording: you typically enable them if the organization has no Edge Transport server or does no other antispam filtering on incoming messages. The Malware agent, by contrast, is installed and enabled by default on Mailbox servers.
• Filtering before the mail reaches Exchange — a mail gateway or a hosted filtering service that the MX record points at and that relays to Exchange. For Exchange this is SMTP delivery like any other, and no connector is involved.

When a connector is the right choice

• The server cannot, or should not, be reached from the internet on port 25. A connector needs no inbound opening at all: it makes outbound connections to the provider and delivers to Exchange inside the network.
• The mailboxes have to stay at the provider. An address at the internet provider, a Gmail or Microsoft 365 mailbox, or a domain that remains hosted because webmail or other clients keep using it: there is no MX record of yours to change, or changing it would break the other users. The connector can leave the messages at the provider for a number of days so that those clients still see them.
• Only part of a domain lives on your Exchange server. In a branch office that handles a subset of the company’s addresses the MX record belongs to the main office; the knowledge-base article Configuring POPcon for a branch office that handles only part of a domain describes that setup.
• You are migrating. The connector brings the mail into the new Exchange server while DNS, firewall and filtering are still being prepared, and the switch of the MX record can follow later or never.
• You want the provider to be the buffer. While Exchange is offline for maintenance, mail simply accumulates in the provider mailboxes and is collected afterwards (see the first question below).

The price of the connector design is the one in the table: a retrieval interval instead of immediate delivery, provider mailboxes to maintain, and with a catch-all mailbox a dependency on the recipient headers the provider writes. Catch-all (multidrop) mailbox vs one POP3 mailbox per user explains that last point; the setup itself is in How to download POP3 and IMAP mailboxes into Exchange Server 2016, 2019 and SE.

What happens while Exchange is down

With a connector nothing is lost. POPcon delivers over SMTP, which requires an explicit acknowledgement for every message; until Exchange confirms receipt, POPcon keeps the message in a temporary .msg file and retries the delivery automatically on every following retrieval cycle (Will I lose emails if Exchange is down when POPcon tries to deliver?). Mail that has not been downloaded yet is still in the provider mailbox.

With the MX record at Exchange, the message stays with the sending server, which tries again later. How long it keeps trying is decided by the sender, not by you. As an illustration of such a setting: Exchange Server, when it is the sending side, tries for a message expiration timeout of 2 days by default and then returns a non-delivery report to the sender (Message retry, resubmit, and expiration intervals in Exchange Server). Other mail systems have their own values. For a planned maintenance window this is rarely a problem; for a server that may be unreachable for days it is a reason to keep a buffer in front — a second Edge Transport server, a filtering service, or the provider mailbox.

Moving from retrieval to the MX record

Shops that start with a connector and later move the MX record usually do it in this order:

1. Run the connector first. Exchange receives the mail through the connector; set the accounts to leave messages on the server for a few days while the old clients are still in use.
2. Prepare Exchange for direct delivery. The domain must be an accepted domain (Accepted domains in Exchange Server); it already is if the connector delivers to addresses in that domain. Open port 25 from the internet to the server that is to receive the mail, and decide where spam is filtered.
3. Change the MX record in the public DNS of the domain so that it resolves to that server, and verify it with nslookup and set type=mx, as Microsoft’s guide describes.
4. Keep the connector running for a while. Anything that is still delivered to the provider mailboxes after the change is collected as before. When the provider mailboxes stay empty, remove the accounts from the connector.

The outbound direction is not part of this change. Exchange sends through a send connector that either uses the MX records of the recipient domains (Create a Send connector to send mail to the internet) or routes everything through a smart host (Create a Send connector to route outbound mail through a smart host). If you send through provider smart hosts, the guide Multiple smart hosts in Exchange covers that side.

Frequently asked questions

More in the Exchange mail flow guides, on the POPcon product page, the download page or in the knowledge base. Auf Deutsch: POP3-Abholung oder MX-Eintrag auf Exchange: wann ein Connector richtig ist – und wann nicht.