Skip to main content

Email Processing Best Practices

These are the patterns we recommend when you build email automations. None of them are technical requirements. They are the choices that keep automations 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 Hosted Mailbox Per Integration​

We recommend giving each third-party system its own Hosted Mailbox. There is no technical requirement to separate them, but separate mailboxes usually make each automation easier to understand and troubleshoot.

If you have ten tools that send email, consider creating ten mailboxes and entering one address in each tool instead of separating all ten with expressions in a shared mailbox.

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, we recommend keeping 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, we recommend sending it straight to a Hosted Mailbox. Routing it through your mail host first also works.

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. Consider pointing 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​

We recommend configuring the Destination field on each 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 processing this message completely 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 automation.

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.

Start Simple, Then Add Edge Cases​

Build the smallest version that solves the main problem, test it with real messages, and then add handling for missing values, changed formats, and other edge cases. For many automations, the first useful version only needs to extract a value, look up a record, and create or update it.

Identify Automated Senders from the Email Content​

An automated sender often uses the same no-reply address for every customer. Read the customer or device identifier from the subject or body instead of trying to identify the customer from the sender address.

Match on a Field You Control​

We recommend matching third-party customer names to an Autotask account User-Defined Field (UDF) that you maintain. A dedicated UDF keeps the automation working when someone renames the account or the two systems use different names.

Decide What Repeat Alerts Should Do​

Choose whether a repeated alert should create another ticket, add a note to an open ticket, or close a ticket after recovery. All three designs can work. The monitoring alerts tutorial shows how to keep related alerts together and explains the choices.

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: consider creating 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, we recommend adding 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. You can give it a rule that creates a low-priority ticket so that mail does not vanish.

Next Steps​