Arcunox

No noise. No tracking. Just tools.

Building a Quiet Inbox

Updated: Sep 27, 2026 Email Privacy

Email is cooked

I decided to remove myself from the circus of constant spam, phishing attempts, and unwanted marketing. The goal was simple: open my inbox and find nothing but emails I authorised.

If you're happy with your current Gmail or Outlook setup, this article probably isn't for you. My approach requires paid email services, a custom domain, and some deliberate configuration.

This isn't a claim to have built the ultimate anti-spam system, nor does it promise perfect privacy or security. It's simply one practical approach that works well for my personal, day-to-day use. It won't necessarily suit everyone.

At a minimum, you'll need at least one custom domain and dedicated email hosting. A password manager is also highly recommended.

Domain Registration

The first step is acquiring a domain name.

A standard .com domain remains the path of least resistance. It's widely recognised, familiar to users, and generally accepted by third-party services without much friction.

You can certainly use an alternative top-level domain (TLD), but some services are more suspicious of unfamiliar or less common extensions and may block or flag them during registration.

Finding a good, available .com isn't always easy. Take your time with this step. Your domain becomes the foundation of the entire email system, so it's worth choosing something you'll be comfortable using for years.

Email Hosting: Your Own Server vs. a Provider

Once you have a domain, you need somewhere to host your mail and handle delivery.

There are two broad approaches.

Running Your Own Server

You can run your own mail server on a VPS or local hardware. This gives you considerable control over the environment, but it also means you're responsible for maintaining it.

Email delivery is particularly unforgiving. IP reputation, spam filtering, reverse DNS, backups, server maintenance, security updates, and delivery problems can quickly turn into a significant amount of work.

For a personal mailbox, I decided that wasn't worth the trade-off.

Using a Hosted Provider

Instead, I use a dedicated email service provider.

I retain ownership of my domain and control the relevant DNS records, while the provider handles the underlying mail infrastructure, server availability, security updates, and much of the delivery complexity.

For my use case, this provides a reasonable balance between control, privacy, and convenience.

Choosing a Hosted Email Provider

The requirements will vary from person to person, but I looked for a provider that supported the following:

I deliberately avoided providers that bundle email with calendars, cloud storage, office applications, or other services I don't need.

Pricing, features, and privacy policies vary considerably between providers, so it's worth comparing them before committing. The provider you choose becomes a significant part of your email infrastructure.

Account Setup

The primary account required a little more thought than simply choosing an address such as:

admin@mydomain.com

I specifically chose an email host that doesn't require a phone number for account creation or verification. I prefer keeping authentication and account recovery independent of my mobile carrier.

My primary administrative login is completely detached from the public-facing domains I own.

In other words, I don't use an address such as admin@mydomain.com to log into the service in case that address is publicly exposed. I use a completely different domain. Keeping the administrative identity separate means there is less publicly discoverable information associated with the account responsible for managing my mail.

Email Username

Instead of using a recognisable address as the authentication username, I use a randomly generated address, for example:

4hd67csdskbw3e@mydomain.com

A password manager is useful here because it can generate a high-entropy random address and store it alongside the corresponding password.

The authentication username is used later for the email client setup.

DNS and MX Setup

Now comes the plumbing.

To make the domain work with your email provider, you need to update its DNS records through your domain registrar or DNS provider.

The most important records are your MX (Mail Exchange) records. These tell other mail servers where to deliver messages addressed to your domain.

Your email provider will give you the specific MX records you need to configure.

You'll also want to configure the major email authentication mechanisms:

These records help prevent other people from successfully impersonating your domain and can improve the trustworthiness of legitimate mail you send.

Most reputable email providers provide step-by-step instructions for configuring these records. Follow their documentation carefully, as the exact values vary between providers.

Email Client Setup

When configuring an email client, I take another small precaution.

I do not use:

4hd67csdskbw3e@mydomain.com

I use instead, an alias that can be publicly exposed.

This address is never used for sending or receiving normal mail. I don't publish it, give it to third parties, or intentionally expose it in my email identity. It does not appear in email headers.

It exists solely as the account's authentication identity.

The idea is simple: if automated scanners discover my public aliases, they don't automatically discover the username associated with my mail client credentials.

This isn't a substitute for strong passwords or other security controls, but it removes another predictable piece of information from the equation.

Alias Setup

This is the part of the system that makes the whole approach worthwhile.

I use a unique email alias for every third-party service I register with.

For example, when signing up for an online shopping service, I might generate something like:

frco-z62n-shopping@mydomain.com

I generate these addresses using the:

Arcunox generator tool

The exact format isn't particularly important; the important part is that each service receives its own unique address.

The alias then routes directly to my primary inbox through my email provider.

Because these are actual aliases rather than disposable forwarding addresses, I can generally send and receive mail using the alias just as I would with a normal mailbox.

Why Unique Aliases Matter

The biggest advantage is traceability.

Suppose I create:

abc12-shopping@mydomain.com

for an online retailer. If that exact address starts receiving unsolicited marketing messages or appears in a leaked database.

I immediately know which service originally received the address.

There's no need to guess where the leak came from.

If an alias becomes compromised or starts attracting unwanted mail, I can disable, delete, or quarantine that specific address without affecting the rest of my email system.

This creates a useful isolation layer between my identity and the services I interact with.

Instead of giving hundreds of companies the same address, I give every service its own identifier.

The Result

The practical result is a much quieter inbox.

I don't need to rely entirely on a spam filter to decide what belongs in my inbox. The system is designed so that every address has a known purpose.

If I receive something at an address I never gave to a particular sender, that's immediately interesting.

If one of my aliases starts receiving obvious spam, I can investigate the source and shut down that individual address.

It's not perfect, but it changes the relationship I have with email. My inbox becomes something I deliberately populate rather than something I constantly clean up.

Limitations

This setup isn't without trade-offs.

The first is complexity. Setting everything up takes time, particularly if you're unfamiliar with DNS, email authentication, and domain management.

There are also recurring costs. You need to pay for the domain and email hosting, and potentially additional services depending on how you build the system.

A custom domain also has a visibility downside.

If a service suffers a data breach, your custom domain may appear in the leaked data alongside your alias. A unique alias tells you which service received the address, but it doesn't make the address anonymous.

There's also an ongoing maintenance burden. Domains need to remain registered, DNS records need to remain correct, and your email provider needs to remain operational.

Finally, you need to protect the domain itself.

I recommend enabling WHOIS privacy where available, keeping domain-transfer locks enabled, protecting the registrar account with strong authentication, and storing recovery information securely.

The system reduces certain types of exposure; it doesn't eliminate the need for good security practices.

Conclusion

This approach might seem excessive for someone who receives a few emails a day.

For me, the appeal is control.

Every service gets its own address. My primary mailbox remains hidden behind those aliases. My administrative account isn't publicly exposed. And when an address starts receiving mail it shouldn't, I can identify and isolate it.

It also reduces my dependence on a single traditional mailbox identity.

I'm not claiming this is the ultimate solution to spam, phishing, privacy, or email security. It isn't.

It's simply a practical system for people who want more control over their personal email and are willing to trade some convenience for it.

If you're tired of constantly cleaning up your inbox, concerned about your addresses appearing in data breaches, or simply want to stop handing the same email address to every service you use, a custom domain with provider-managed hosting and unique aliases is worth considering.