Exchange mail flow guides › Inbound: POP3 and IMAP retrieval into Exchange
Antispam and antivirus for POP3/IMAP-collected mail before it reaches Exchange: RBL checks, tagging, quarantine
Mail that a connector pulls from a provider mailbox never passes the filters that sit in front of your own MX record — an Edge Transport server, a filtering gateway, or Exchange’s connection filtering — because the connector submits it to Exchange over SMTP from its own address. Whatever the provider let into the mailbox arrives at Exchange as a message from a trusted internal host. The connector is therefore the last place where the original sender’s IP address can be checked against real-time blacklists, where spam can be tagged, diverted or dropped, and where attachments can be scanned before the message is submitted to Exchange.
Updated on 2026-10-08
What Exchange itself filters, and where, is taken from Microsoft Learn for Exchange Server 2016, 2019 and Subscription Edition. The connector side is taken from the POPcon PRO product and help pages and the knowledge base. If your MX record already points at a filtering provider or an Edge Transport server and the connector only picks up a few legacy mailboxes, most of this page does not apply — see the last section.
Where filtering can sit
| Stage | What it can see | What it can do | Who controls it |
|---|---|---|---|
| Provider, before the mailbox | The connecting server’s IP, envelope and content of every message addressed to the mailbox | Whatever the provider’s spam filter does — reject, sort into a spam folder, tag | The provider; you configure it in the provider’s web interface, if at all |
| Connector, after the download and before SMTP submission | The complete message including the Received headers with the IP addresses of the servers that handled it | Check the IPs against DNS blacklists, apply own white- and blacklists, tag the subject, divert to a review mailbox, delete; scan attachments for viruses; archive a copy | You, on the connector host |
| Exchange transport | The message as submitted by the connector; the connecting IP is the connector host | Malware agent: enabled by default on Mailbox servers. Antispam agents: enabled by default on Edge Transport servers, can be enabled on Mailbox servers. Connection filtering (RBL checks): Edge Transport only, and it judges the connector’s IP | You, with Microsoft’s cmdlets and scripts |
| Mailbox and mail client | The delivered message, including a [SPAM] tag the connector added | Junk filtering in the client; a rule that moves tagged mail into a review folder | The user, or a client rule you deploy |
Why Exchange’s own RBL check does not see the sender
Microsoft’s overview states that the antispam transport agents “are enabled by default on Edge Transport servers, and you can enable many of them on Exchange Mailbox servers”, and that the Malware agent “is available and enabled by default on Exchange Mailbox servers” (Antispam and antimalware protection in Exchange Server). The agent that does what a real-time blacklist check does is the Connection Filtering agent, and Microsoft documents two limits for it: it “is available only on Edge Transport servers”, and it “relies on the IP address of the connecting mail server to determine what action, if any, to take on an inbound message” (Connection filtering on Edge Transport servers). The same page explains that “IP blocklist providers are frequently referred to as real-time blocklists, or RBLs” and that the agent “compares the IP address of the connecting mail server to the list of IP addresses at the IP blocklist provider”.
For mail that a connector delivers, the connecting mail server is the machine the connector runs on. Its address is never on a blacklist, so an RBL check at Exchange answers “clean” for every message the connector submits, spam included. The addresses that would be worth checking — the server that handed the message to the provider — are only in the Received headers of the message, and a transport agent that judges the connection does not read them. That is the gap the connector fills: it has the whole message in hand before it opens the SMTP session and can look up the header addresses itself. The content-based agents are a different matter: if you enable the antispam agents on a Mailbox server, the Content Filter agent and its spam quarantine see connector-delivered mail like any other, and so does the Malware agent without any change.
How an RBL check works, and why it is not 100 %
A DNS blacklist lists IP addresses, not e-mail addresses, and the content of the message is irrelevant to the check. The knowledge base article on the antispam function describes the mechanism: the list operators run “spamtraps”, addresses that are never used for real mail; anything that arrives there is spam by definition, and the sending IP is listed in real time. The connector takes the addresses from the Received…from header lines of each fetched message, builds a DNS name from the reversed address and the list name, and resolves it. An answer means the address is listed; no answer means it is not.
Two things follow. False positives happen because the lists are about addresses, not senders: DSL and cable providers hand out addresses from shared pools, a pool that one abused machine has put on a list stays there for a while, and the next legitimate user on that address is treated as the spammer. False negatives happen because the lists react to past abuse; a freshly compromised server is not listed yet, and some spam leaves perfectly reputable servers through hijacked accounts. The method reduces spam substantially in practice, but “listed” is evidence, not proof — which is why the action you choose matters more than the number of lists.
POPcon PRO ships with a list of DNS blacklists and keeps it tidy: since version 4.9.9 (March 2026) the blacklist server list is cleaned automatically, removing defunct servers and updating names. The lists Servolutions runs in its own configuration are published on the antispam blacklist servers page, and before a list is used at all the connector checks that it does not list the private address 192.168.1.1; a list that answers for that address is broken and is skipped (diagnosing blacklist lookups).
Why the check can be slow: it is DNS
With eight or nine lists active the check normally takes less than two or three seconds per message. When it takes 30 seconds, or when every message is suddenly tagged as spam after months without trouble, the cause is almost always one of two things (spam checking takes 30 seconds per message, all e-mails are suddenly tagged as SPAM):
- A blacklist that no longer exists or answers slowly. Every lookup against it waits for a timeout. Remove the list, or let the automatic clean-up do it.
- A dead DNS server in the router’s or firewall’s list. Ordinary name resolution does not show the problem, because the first working server answers. A blacklist lookup for a legitimate sender, however, is supposed to fail — and a failed lookup is retried against every DNS server in the list, including the dead one, which times out. Since most lookups for clean mail must fail, the check crawls. Reduce the list to one working DNS server.
The knowledge base gives a test that needs nothing but a command prompt. Reverse the octets of an address and prepend them to a list name: ping 1.1.168.192.bl.spamcop.net must not resolve (a private address is never listed), while ping 2.0.0.127.bl.spamcop.net normally resolves to 127.0.0.2, the test entry most lists carry. If the first command returns an address, the DNS setup is wrong and every lookup looks like a hit — that is the “everything is spam” symptom.
Tag, divert or delete — and the whitelist
When a message is identified as spam, POPcon PRO applies one of three actions (antispam options): divert it to a mailbox you name, deliver it normally with [SPAM] prepended to the subject, or delete it. The blacklist page recommends starting with the tag whenever lists are added or changed, so that you can watch for a while which messages are marked without losing any. Servolutions runs its own mail that way: all listed servers active, [SPAM] in the subject, an Outlook rule that moves tagged mail into a folder, and a look through that folder once a week, which takes a couple of minutes and usually finds nothing. Deleting at the connector is final; diverting to a review mailbox is the middle way for sites that do not want the tag to reach users.
Besides the DNS lists there are two lists of your own. The user-defined whitelist always lets a message through, even if an IP is listed; the user-defined blacklist always marks a message as spam, whatever the lists say; and the whitelist has the higher priority of the two. Both match on the sender address, the recipient address, the subject, an attachment name, any header field, or text in the message body. Matching is a case-insensitive substring test, not a pattern: *@spammer.com does nothing useful, while @spammer.com blocks every sender at that domain without catching notspammer.com (wildcards in the blacklist). A trailing space from a copy-and-paste prevents a match, and collapsing pasted Name <address> entries into one @domain line shrinks a long list by an order of magnitude with no loss of coverage.
The virus path
POPcon PRO’s built-in antivirus engine scans every incoming message and its attachments before anything is relayed to Exchange; in the message flow the virus check comes first, then the spam check, then the rules, then SMTP submission (POPcon PRO features). For an infected message one of three actions applies (antivirus options): move it to the badmail folder for an administrator to look at, divert it to an address wrapped in a warning message, or delete it. The product page describes the default shape of the first two — infected mail is wrapped in a warning and routed to the postmaster — and the signatures update automatically; the check for new signatures runs daily or hourly, while the supplier typically publishes new signatures once a day. The version history records the engine side of this: a new antivirus update process for the ClamAV updater in October 2025, and additional libraries for it in March 2026. Signature updates need HTTP access from the connector host; a proxy can be entered on the connector’s connection page.
This does not replace Exchange’s own scan, and it does not have to. Microsoft’s Malware agent “scans messages as they travel through the Transport service on a Mailbox server”, checks for engine and definition updates every hour over TCP port 80, and deletes an infected message by default (Antimalware protection in Exchange Server). A message the connector submits is scanned there a second time. Two engines with different signature feeds catch more than one, and the connector’s scan has one advantage the transport scan lacks: it can hold the message back, wrapped, for a human, instead of deleting it.
One interaction to know about: a third-party on-access scanner on the connector host that deletes temporary .msg files out of the connector’s program folder, or stops the service process while it writes an infected file, interferes with the download. Since version 2.8 the connector reports a vanished file to the postmaster instead of retrying; if the scanner stops the process itself, exclude the POPcon program folder from on-access scanning (POPcon hangs when my virus scanner deletes .msg files). The built-in engine is meant to scan the mail; the host scanner should leave the connector’s working files alone.
Rules, archiving and the audit trail
Three more PRO functions sit at the same point in the flow. Rules act on the sender address, the recipient name, the subject or an attachment file name, and forward, copy, delete or reroute the message; they are evaluated in priority order after the spam check, so a rule can route [SPAM]-tagged mail to a review mailbox without any client involvement. Archiving writes a copy of every received message into daily or monthly folders as raw .eml files, independent of Exchange, so a message deleted as spam or virus by a later stage is still on disk. And the per-message log exports as CSV with the spam flag and the virus detection per message, which is how you find out, a month in, whether the lists are catching spam or legitimate senders.
When this page does not apply
If your MX record points at a filtering provider or at an Edge Transport server and mail reaches Exchange through that path, the spam decision has already been made before anything is in a mailbox, and the connector’s RBL check adds little. The same is true when the provider’s own filter sorts spam into a folder the connector does not fetch. The connector’s filtering earns its place where the provider mailbox is the only line of defence — the typical small-business setup in which the domain’s MX stays at the hosting provider and Exchange sees the world only through the connector. Which of the two setups you are in, and why one cannot be mixed casually with the other, is the subject of POP3 retrieval or MX record to Exchange.
Setting it up in POPcon PRO
- Antispam: enable the function, keep the shipped DNS blacklists or add the ones from the blacklist page, and set the action to
[SPAM]tagging to begin with (help). - Add the handful of senders you never want filtered to the user-defined whitelist as
@domainentries; add known-bad domains to the blacklist the same way. - Antivirus: enable the engine, choose the badmail folder or a diverted-with-warning address for infected mail, and check the signature date and subscription date on the same tab (help).
- Deploy a client rule or a connector rule for tagged mail; after a few weeks read the CSV log and decide whether to switch from tagging to diverting.
- Exclude the POPcon program folder from any on-access scanner on the host.
The Exchange side needs nothing extra for this: the receive connector that accepts the connector’s SMTP session is the one described in How to download POP3 and IMAP mailboxes into Exchange. Whether a catch-all mailbox or one mailbox per user is fetched makes no difference to the filtering — see Catch-all mailbox vs one POP3 mailbox per user.
Symptoms and what each one means
| Symptom | Cause | Fix |
|---|---|---|
| Spam check takes 30 seconds per message | A defunct blacklist, or a dead DNS server in the router’s list; failed lookups time out | Remove the list; one working DNS server in the router (knowledge base) |
Every message is tagged [SPAM] since yesterday | DNS answers for names that must not resolve; every lookup looks like a hit | Run the reversed-IP ping test; fix the DNS setup (knowledge base) |
| A blacklist is reported as failed and not used | The list answered for 192.168.1.1, or its DNS name does not resolve although its website does | Test with ping; replace the list (knowledge base) |
| A legitimate customer is tagged as spam | The sending server’s IP, or its provider’s pool, is on a list | Whitelist @customerdomain; the log shows which list fired |
*@spammer.com in the blacklist catches nothing | Entries are substrings, not patterns | Use @spammer.com (knowledge base) |
| Spam arrives although Exchange has connection filtering | Connection filtering judges the connector host’s IP, and exists only on Edge Transport | Check the header IPs at the connector; enable content-based agents on the Mailbox server if wanted |
| Download hangs; postmaster receives “file vanished” reports | A host antivirus scanner removes the connector’s temporary files | Exclude the program folder from on-access scanning (knowledge base) |
| Antivirus signatures stop updating | No HTTP access from the host, or a proxy not entered | Allow HTTP for the service; enter the proxy on the connection page |
Frequently asked questions
Does Exchange's own antispam filter mail that a POP3 connector delivers?
Only partly. Microsoft's Connection Filtering agent, the component that checks IP block list providers (RBLs), exists only on Edge Transport servers and decides on the IP address of the connecting mail server. For connector-delivered mail that address is the connector host, not the original sender, so an RBL check at Exchange cannot see the spam source. The agents that look at content can be enabled on Mailbox servers; the Malware agent is enabled there by default and scans connector-delivered mail like any other.
How does an RBL check work in a connector?
The connector reads the IP addresses in the Received headers of the fetched message and asks each configured DNS blacklist whether an address is listed. The lookup is a DNS query made from the reversed IP address and the list name; an answer means listed, no answer means not listed. The content of the message plays no part in this check. If an address is listed the message is tagged, diverted or deleted according to the configured action.
Why does the spam check suddenly take 30 seconds or tag everything as spam?
Both symptoms point at DNS, not at the mail. A blacklist that no longer exists, or a DNS server in the router's list that is dead, turns every lookup that is supposed to fail into a timeout; because most lookups for legitimate mail must fail, the check becomes slow. The knowledge base gives a ping test with a reversed IP against bl.spamcop.net that shows within seconds whether lookups behave. The fix is to remove defunct lists and reduce the router's DNS list to one working server.
Tag, divert or delete: which spam action should I start with?
Tag. POPcon PRO's own blacklist page recommends letting it mark suspected spam with [SPAM] in the subject first, deliver it normally, and move it with a mail client rule into a folder that is reviewed from time to time. Deleting at the connector is final, and real-time blacklists do produce false positives, for example when a provider's shared IP pool has been abused. Diverting to a review mailbox is the middle way.
What happens to a message with a virus?
POPcon PRO scans every message and its attachments before it submits anything to Exchange. For an infected message the configured action applies: move it to the badmail folder, divert it to an address wrapped in a warning message, or delete it. The signatures are updated automatically; the check for new signatures runs daily or hourly. Exchange's own Malware agent scans the message again in transport, which costs nothing and catches what one engine misses.
More in the Exchange mail flow guides, on the POPcon PRO product page, the POPcon PRO download page or in the knowledge base. Auf Deutsch: Spam- und Virenfilter für per POP3/IMAP abgeholte Mail.