---
title: "Access Management in E-Mail Systems"
description: "Access management controls which users and systems are permitted to access email resources like mailboxes and servers, often via ACLs and authentication."
url: "https://mailmum.io/glossary/access-management-in-email-systems/"
---

# Access Management in E-Mail Systems

Access management in email systems is the practice of controlling who may
connect to a mail server, who may send through it, and who may read which
mailbox. It covers three separate questions that are often treated as one:

1. **Who may deliver mail to us?** Inbound access, controlled at the SMTP
   connection by [ACLs](https://mailmum.io/glossary/access-control-list-acl/) and blocklists.
2. **Who may send mail through us?** Outbound access, controlled by SMTP
   authentication on the submission service.
3. **Who may read this mailbox?** Mailbox access, controlled by IMAP/POP
   authentication and per-folder permissions.

Getting the second one wrong is what turns a mail server into a source of
[abuse](https://mailmum.io/glossary/abuse/). Getting the third one wrong exposes mail; getting the
first wrong mostly means more spam in the inbox.

## Who may send mail through the server?

The dividing line is the port. Port 25 is for server-to-server transfer and
accepts mail for local recipients from anyone; ports 587 and 465 are the
submission service, and there authentication is mandatory.

Conflating them is the classic open relay: a server that accepts mail for
arbitrary destinations on port 25 without authentication. The relevant controls
are:

* **SMTP AUTH over TLS only.** Credentials must never cross the network in
  plaintext, which means `smtpd_tls_auth_only = yes` in Postfix or the
  equivalent elsewhere.
* **A closed relay policy.** `reject_unauth_destination`, or its equivalent, as
  the terminating rule of the recipient restrictions.
* **Sender ownership enforcement.** An authenticated user should only be able to
  use envelope senders they are entitled to, otherwise one compromised account
  can forge every address in your domain.
* **Rate limits per account.** A mailbox that suddenly sends 10,000 messages an
  hour is compromised, and a limit converts that from an outage into a ticket.

## How is inbound access controlled?

Inbound access management is decided during the SMTP conversation, before the
message body is accepted:

* **Connection stage** — the client IP address is checked against local
  allow and deny maps and against DNS blocklists. See
  [IP blacklisting](https://mailmum.io/glossary/ip-blacklisting/) for how those lists work.
* **HELO/EHLO stage** — the [hostname](https://mailmum.io/glossary/hostname/) the client
  presents is checked for syntactic validity and consistency with its
  [reverse DNS](https://mailmum.io/glossary/reverse-dns-rdns/).
* **Envelope stage** — sender and recipient are validated. Rejecting
  unknown recipients here rather than accepting and bouncing later is what
  prevents [backscatter](https://mailmum.io/glossary/backscatter/).
* **Content stage** — only after all of the above does it make sense to
  spend CPU on scanning the message.

## Allow lists and deny lists: when to use which

A deny list is the default posture for a public mail server: accept from
everyone, reject known-bad. It scales to the open internet, and it is what
DNSBLs are built for.

An allow list inverts the default and only makes sense where the set of
legitimate senders is closed and known:

* Traffic from an application server or monitoring host to an internal relay.
* A partner or supplier feed that must never be blocked, protected by an
  explicit entry above the blocklist checks.
* Administrative access to a management interface.

The failure modes differ. A stale deny list lets spam through, which is
annoying. A stale allow list silently bypasses every check beneath it, which is
how an entry added years ago for a since-decommissioned partner becomes a hole.
Allow list entries should therefore be as narrow as possible, dated, and
reviewed.

## What about mailbox access?

Mailbox access is a different system with different failure modes. It is
governed by IMAP or POP authentication and, for shared and delegated mailboxes,
by per-folder ACLs.

Two practices matter more than the rest. First, shared mailboxes such as
`info@`, `sales@` or `abuse@` should have their access grants reviewed when
people change roles, since delegation is added far more often than it is
removed. Second, legacy IMAP and SMTP clients that cannot do modern
authentication force the use of app passwords — those are full-strength
credentials with no second factor, and they are what credential-stuffing
attacks target.

## What should be monitored?

Access management is not a configuration you finish. The things worth alerting
on are:

* Authentication failures per account and per source IP, to catch credential
  stuffing before it succeeds.
* Successful authentication from unexpected geographies or at unusual hours.
* Outbound volume per authenticated account against its normal baseline.
* Rejected relay attempts, which indicate someone is probing the server.
* Changes to allow lists and to mailbox delegations, which should be rare enough
  that each one is worth reading.