Skip to main content

Email Processing Best Practices

These are the patterns we recommend when you build email workflows. None of them are technical requirements. They are the choices that keep workflows simple to reason about, easy to troubleshoot, and safe to change six months from now.

If you have not read it yet, start with Hosted and Remote Mailboxes. It explains the two mailbox types, the three Hosted Mailbox address types, and how MSPintegrations decides which mailbox handles an inbound message.

Build One Mailbox Per Integration​

The single most useful habit is to give each third-party system its own Hosted Mailbox.

If you have ten tools that send email, create ten mailboxes and hard-code one address into each tool. Do not point all ten at a shared mailbox and separate them with expressions.

This matters because:

  • Expressions stay simple. A rule in the 3CX mailbox never has to prove the message came from 3CX. It already did.
  • History is pre-filtered. When you need to see what UniFi sent last Tuesday, open the UniFi mailbox history.
  • Changes stay contained. Rewriting the parsing for one vendor cannot break another vendor's tickets.
  • Failures stay contained. A vendor that changes its email format breaks one mailbox, not all of them.

For a system that sends paired alerts, such as device up and device down, put both rules in that system's mailbox. A 3CX mailbox with a "3CX Down" rule and a "3CX Up" rule is clearer than a shared alerts mailbox with twenty rules in it.

The same logic applies to Remote Mailboxes, though you are usually constrained by which real mailboxes exist.

Route Automated Mail Directly​

When a system sends the mail rather than a person, send it straight to a Hosted Mailbox.

The address is hard-coded into the sending system once and no human ever reads it or types it, so it does not need to be memorable. In exchange you get immediate processing with no polling delay, and a delivery path with nothing in the middle that can drop the message.

This matters most for tools that monitor your mail infrastructure. If your Microsoft 365 monitoring alerts route through Microsoft 365, an outage suppresses the alert about the outage. Point that tool at a Hosted Mailbox instead.

Routing automated alerts through your mail host first works fine, and plenty of customers do it. We just do not recommend it as the default.

Poll Rather Than Forward​

Some mail has to reach your mail server first. A published address such as [email protected] has MX records pointing at your mail host, and you are not going to move them.

You have two options: forward those messages to a Hosted Mailbox, or let MSPintegrations poll the mailbox with a Remote Mailbox. Both work. We recommend polling.

Forwarding is a blind handoff. Your mail host sends the message and gets no confirmation that MSPintegrations received it. When someone reports that an email never became a ticket, a forward gives you almost nothing to trace. Polling leaves the original message sitting in a folder you can open and read.

If you do forward, forward the message rather than sending it as an attachment, so the original sender and subject survive the hop.

Set a Destination Folder on Remote Mailboxes​

Configure the Destination field on every Remote Mailbox so processed messages move out of the watched folder.

This turns the source mailbox into a status board. Anything still in the inbox has not been processed. Anything in the destination folder has. When someone asks whether a message reached MSPintegrations, you have the answer in one click, before you open the console.

Leave Destination blank and processed messages stay in the inbox, unread, indistinguishable from messages that never got picked up.

Order Rules Deliberately​

Rules attached to a mailbox evaluate top to bottom, and every matching rule fires unless an action stops processing. Order is part of your logic, not a cosmetic detail.

A reliable layout:

  1. Suppression first. One rule at the top that matches out-of-office replies, known spam senders, and vendor noise, with a Stop All Processing action. Create it even if you have nothing to suppress yet, leave the expression empty, and disable it until you need it.
  2. Specific rules next. Narrow, well-tested rules that handle known message formats.
  3. General rules after. Broader fallbacks.
  4. A catch-all rule last. A rule with no expression that creates a low-priority ticket or sends a notification, so a message that matched nothing still surfaces somewhere.

Inside a rule, action steps run in order and each step can stop processing. The Update-then-Create ticket pattern depends entirely on this: the Update step runs first and stops when it finds a ticket, so the Create step only runs for genuinely new requests. See Create Your First Mailbox for the full build.

Test Before You Go Live​

You never have to point production traffic at an untested workflow.

For a Hosted Mailbox, send email to the address directly from any mail client. Your live support address is not involved. Send a few real-looking messages before you write any rules at all, so History captures how the sender actually formats its mail. Build the rules against what you see, not what you expect.

For a Remote Mailbox, point it at a subfolder rather than the inbox to start. Drag a handful of real messages into that folder by hand, confirm they process correctly, then switch the mailbox to the inbox.

Once messages are in History, use Replay to re-run the same message through your current rules. Iterate against a real message instead of sending a new test each time you change something.

Only after the rules behave correctly should you configure the sending system, or your mail flow rules, to point at the new address.

Look at the Data First​

Before writing an expression or a parsing step, send a real message through and read the parsed result in History.

Email rarely looks the way you assume. Subjects carry invisible prefixes, bodies arrive as HTML with different whitespace than the plain-text part, and vendors change formats without telling anyone. History shows you the parsed values your rules will actually see.

When a body does not look right, see Understanding Multi-Part Emails and Viewing Raw Email Files.

Name Things for the People Who Come Later​

  • Mailboxes: name the prefix after the system, such as unifi-alerts or 3cx, not alerts2.
  • Rules: describe the outcome, such as Create Ticket for Device Offline, not Rule 1.
  • Action steps: describe what the step produces, such as Extract Device Name.
  • Autotask source: create a dedicated source named after each mailbox address. Ticket volume per integration then comes straight out of PSA reporting with no extra work.

Add a Domain Catch-all as a Safety Net​

Once you have a domain with several Standard mailboxes on it, add one Domain Catch-all mailbox to that domain.

Standard mailboxes always win over the catch-all, so existing addresses are unaffected. What the catch-all gives you is visibility into mail sent to a typo, a retired address, or an address a vendor was configured with before you built the matching mailbox. Give it a rule that creates a low-priority ticket so that mail does not vanish.

Next Steps​