Operations Playbook

A Mailbox Per Device: Email as a Machine Interface

By Alexey Bulygin
A rack of small machines each with its own labelled letter slot

A surprising amount of equipment speaks email and nothing else. Backup appliances, network monitors, building management systems, printers, industrial controllers, older instruments — all of them emit alerts by SMTP because that was the integration available when they were designed. A mailbox per device turns that from a nuisance into a manageable arrangement.

The alternative most sites live with is every machine sending to one shared address, which works until you need to know which of forty devices is complaining.

Why One Shared Address Fails

Pointing everything at alerts@ is the obvious approach and it degrades predictably.

The messages arrive with inconsistent subjects and sender names, because every vendor formats differently, so filtering them apart afterwards means writing rules against whatever text each device happens to emit. Those rules break when firmware changes the wording, which happens without announcement.

Volume compounds it. One chatty device — a monitor in a flapping state, an appliance retrying a failed job — can produce hundreds of messages and bury everything else. With a shared address there's no way to mute one source without muting the rule that catches all of them.

And you lose attribution. A mailbox per device means the address itself identifies the sender, before anyone reads a word of the message.

Routing That Stops Being Guesswork

The gain from a mailbox per device is mostly that routing becomes structural rather than interpretive.

Identification without parsing. Mail arriving at ups-basement@ is from the basement UPS. No rule, no subject matching, no ambiguity when a vendor changes their template.

Independent handling. One device can be silenced, rate-limited or ignored without affecting the others, because it has its own destination.

Retirement is clean. Decommissioning a machine means deleting one mailbox, rather than editing a filter and hoping nothing else depended on it.

Scripted processing per source. A script reading one device's mailbox knows exactly what format to expect, which makes parsing reliable in a way it never is against a mixed stream — the pattern in email ingest.

The Cost Question

A mailbox per device is only sensible where mailboxes aren't billed per seat, which is the whole reason it's rarely done.

At $7 a seat, forty devices is $3,360 a year to receive machine alerts, and no sensible person approves that. On plans capping counts by tier, forty device mailboxes cost nothing beyond the plan you already have — Pro allows 300 per domain, Agency 1,000.

What they do consume is the shared storage pool, and device mail accumulates relentlessly because machines never stop sending. A quota per device mailbox and a retention rule are both necessary rather than optional here, for reasons covered in mailbox storage quotas.

Aliases Instead, Usually

Being honest: for many sites the right answer isn't a mailbox per device at all, it's an alias per device.

If nothing reads each device's mail separately and you only want attribution, aliases give you the identifying address without a separate mailbox to administer or a separate store to fill. Everything lands in one place, and the receiving address still names the sender.

Choose real mailboxes when something processes each device's mail independently, when devices belong to different teams who shouldn't see each other's alerts, or when retention differs per device. Choose aliases when it's one human reading everything and the only requirement is knowing what sent what.

Alias allowances are 30 per mailbox on Starter, 50 on Pro and 100 on Agency, which covers most estates without any mailbox proliferation at all.

Configuring the Devices

The practical friction with a mailbox per device is at the equipment end, and it's worth knowing before committing.

Vendors vary enormously in how much of the modern submission stack they implement, and the age of the fleet decides how much work this is. A site with equipment bought in the last five years will find almost everything simply works; a site with a twenty-year-old building management system will not, and the relay described below is the standard answer rather than an unusual one.

Older devices frequently support only unauthenticated SMTP on port 25 rather than the authenticated submission defined in RFC 6409, or authentication schemes long since deprecated. Some can't do TLS at all. Those machines can't send to a modern mail service directly, and the usual answer is a local relay on the network that accepts their unauthenticated submissions and forwards them properly authenticated.

Where devices do support modern submission, give each one credentials of its own rather than sharing. A device on a network segment you don't fully trust holding a shared credential is a risk that per-device credentials remove, and rotating one machine's password then disturbs nothing else.

Test each device by triggering a real alert rather than using its built-in test button, because vendors' test messages frequently take a different code path from actual alerts and succeed where the real thing fails.

Naming a Mailbox Per Device So the Estate Stays Legible

The address is the only label you get, so it has to carry the location and the equipment type without anybody consulting a list.

Something like ups-basement@ or nas-office2@ reads correctly two years later; device7@ does not. Where the site already has an asset register, reusing its identifiers is better than inventing a parallel scheme that will drift out of step with it within a year.

Acting on What Arrives

A mailbox per device is only useful if something acts on what arrives, and the failure mode is a set of mailboxes nobody opens.

Decide per device whether alerts are read by a person, processed by a script, or simply archived for the day something goes wrong and you want history. All three are legitimate; what isn't is leaving it undecided, because unread device mail gives a false sense of monitoring.

For anything genuinely urgent, email is the wrong channel and always was. A machine that needs somebody woken up should reach a paging system, with the mailbox holding the record rather than carrying the alarm.

Share this article

We use necessary technologies to operate and secure TrekMail. Selecting Okay also allows limited analytics and advertising measurement described in our Cookie Policy.

Sign in to TrekMail

Access your dashboard, mailboxes and DNS.

or

12+ characters, and not one from a known data breach.

or

Reset email sent

If an account exists for this email, we've sent password reset instructions.

By continuing, you agree to TrekMail's Terms and Privacy Policy.