You create an email address for a project. A month later, the project ends, but the email keeps coming.
Having a separate address helped you organize the mail. Being able to switch that address off would make it much more useful.
That is the idea behind managed aliases in EpicMail. Instead of giving users another mailbox to maintain, we wanted to give them more control over the addresses feeding the mailbox they already have.
I'm Serge, the founder of EpicMail. We use Amazon SES for our built-in email service. Building aliases around it led to some useful product and engineering lessons, especially about forwarding, identity, and what a successful send actually means.
Decide what an alias promises
Consider these example addresses:
john+project [AT] epicmail.org
john+shopping [AT] epicmail.org
john+newsletters [AT] epicmail.org
They all belong to the same base mailbox, but each can represent a different relationship. A project has an end date. A shopping address might become noisy. Newsletters might be more useful in another account.
We chose aliases that users explicitly create and manage. Once created, an alias can receive mail, appear as the sending address, show activity, be blocked, or forward to another connected account the user owns.
An arbitrary suffix does not automatically become an active EpicMail address. That is a deliberate product choice: the aliases area should show the addresses the user has chosen to use.
There is also a privacy distinction worth making clear. Plus addresses expose the base address. They are useful for organization and control, but they are not anonymous email masks. Someone who sees john+shopping [AT] epicmail.org can also see john.
Know what SES provides
SES gives developers sending and receiving capabilities. The user experience around an alias is something the application still has to define.
For straightforward sending, a verified domain identity can cover addresses beneath that domain without individually verifying each address. AWS documents the details and exceptions in its identity verification guide.
Receiving is a separate setup. It requires a supported receiving region, the appropriate MX records, receipt rules, and permissions for the resources involved. The AWS receipt-rule walkthrough covers those pieces.
Those capabilities make a feature like this possible. They do not decide whether an alias should work automatically, which account should receive a forward, or what a user should see after blocking an address.
Writing down those behaviors before building the screens makes the implementation much easier to reason about.
Test the whole conversation
Receiving a message is only the start. A user also expects to reply without accidentally switching identities.
For an alias feature, a useful acceptance test is a complete conversation:
- Send a message to the alias from another mailbox.
- Open it and reply using the alias.
- Check the address the other person sees.
- Reply back and confirm the conversation returns to the intended mailbox.
Do the same with a message sent directly from the alias. It is easy to make the compose selector look correct while overlooking what happens at the other end.
BCC deserves a test too. The visible To and Cc headers do not describe every legitimate delivery. AWS distinguishes envelope recipients from message headers in its receiving-notification documentation.
These are useful tests even if you use a different email provider. The recipient experiences the entire exchange, not just your compose window.
Forwarding changes the inbox experience
Suppose someone forwards an alias to another account they have also connected to EpicMail. If both copies remain in their inboxes, a unified view can show the same message twice.
The forward worked, but the resulting experience is annoying.
We added an auto-archive option alongside alias forwarding. It lets the user keep the original stored in the EpicMail mailbox while clearing it from Inbox after the forward is accepted for sending. Archiving preserves the message without keeping it in the way.
It also makes the setting easier to explain. The user chooses where they want to read the message, while retaining a copy in the original mailbox.
A forwarding feature should answer that practical question, not leave the user to discover the duplicate-copy problem afterward.
Use honest status language
Email has more than one meaning of "sent."
Your sending service can accept a message before the destination server receives it. Even acceptance by a destination server does not guarantee that a person will find it in their inbox or read it.
SES provides separate delivery, bounce, and complaint notifications. Those events help describe different outcomes; they should not be collapsed into an unsupported promise that every accepted message reached a person's inbox.
This affects product language as much as infrastructure. A count of forwarded messages needs a clear meaning. An error needs to tell the user whether they should take action. A success message should describe the stage the application actually knows about.
For our auto-archive option, the boundary is acceptance for sending. It is not a guarantee of final delivery, and a later bounce does not automatically restore an already archived original. That is a useful limitation to state plainly.
Treat suppression as part of deliverability
SES suppression lists are another reason an address can look valid without a message being delivered as expected.
AWS distinguishes bounce and complaint reasons, and its account-level suppression list applies to an AWS account in a particular region. The suppression-list documentation explains the behavior and available controls.
For developers, the lesson is to understand the reason and scope before changing suppression settings. A complaint carries different meaning from a delivery failure. Removing an entry is not a universal fix for deliverability, and changing your own account's list does not control another sender's system.
This is part of the operational knowledge needed around email features, even when the interface itself is small.
Make control easy to find
A useful aliases screen should answer ordinary questions quickly:
- What did I create this address for?
- Is it still active?
- Where does its mail go?
- Has it been used?
- How do I stop receiving mail through it?
In EpicMail, aliases have an area for management and activity, with search and paging as the list grows. The sending identity is available from the compose window, where that choice belongs.
The aliases share the original mailbox's received-message allowance. Creating more addresses does not create additional mailboxes or additional allowances. Keeping that relationship clear avoids surprises later.
Why we added this to EpicMail
EpicMail brings existing accounts into one place: A unified inbox for Gmail, Outlook, Yahoo, iCloud, IMAP, and POP3.
Managed aliases add another way to organize incoming mail, specifically through the optional paid @epicmail.org inbox. They are included with that inbox without a separate fee per alias, and share its 5,000-message received allowance per usage period. This feature does not create aliases at a user's connected Gmail, Outlook, or other provider account.
There is a walkthrough on the EpicMail email aliases page.
The design question I would leave other developers with is this: when someone no longer wants to use an address, how easily can they take control of it? That answer can make an alias much more useful than a different spelling of the same inbox.