How to mask email addresses safely

"Mask an email address" can mean three different jobs: hide a real inbox behind an alias, redact part of an address before displaying or logging it, or replace customer addresses in a test database. Mixing them together is how replies disappear, logs leak personal data, and test messages reach real people.

Choose the job first. Then use the smallest control that keeps the workflow useful.

Quick answer

A private destination inbox: use an email alias or proxy so receiving, forwarding, and managed replies still work.
An address shown in a UI or log: use partial redaction so an authorized user can recognize it without seeing the full value.
Customer data copied into development or QA: use synthetic replacement so validation and test delivery work without real recipients.

An alias is the right choice when messages still need to arrive. Redaction is for display. Synthetic addresses are for test data. Hashing can help with comparison or deduplication, but a hash is not a deliverable email address.

Hide a real inbox behind an email alias

An email alias gives senders a public address while keeping the destination private. Messages sent to the alias are forwarded to the verified destination, so you can rotate or disable the public address without publishing the real inbox.

This is useful for:

signup forms and account-specific contact addresses
support, billing, and partner mail
inbound workflows that should not expose a personal mailbox
addresses that may need to be disabled after misuse

MailSlurp aliases can be created from the dashboard or API. You provide the destination email address, choose whether replies should use a thread-aware address, and optionally attach a MailSlurp inbox or custom domain. Some destinations require verification before the alias becomes active.

/**
 * Example of using an email alias to mask an address and forward emails to hidden address
 */
const {
  AliasControllerApi,
  InboxControllerApi,
  Configuration,
  WaitForControllerApi,
} = require("mailslurp-client");

// setup mailslurp config
const config = new Configuration({ apiKey });

// create controllers
const inboxControllerApi = new InboxControllerApi(config);
const aliasControllerApi = new AliasControllerApi(config);
const waitForController = new WaitForControllerApi(config);

// create two different email addresses for testing
const inboxA = await inboxControllerApi.createInbox({ name: "inboxA" });
const inboxB = await inboxControllerApi.createInbox({ name: "inboxB" });
const emailAddressA = inboxA.emailAddress!!;
const emailAddressB = inboxB.emailAddress!!;

// create an alias
const alias = await aliasControllerApi.createAlias({
  createAliasOptions: {
    emailAddress: emailAddressA,
    useThreads: true,
  },
});
// emailAddressA has been masked by a new email address that was created by the alias
expect(alias.maskedEmailAddress).toEqual(emailAddressA);
expect(alias.emailAddress).not.toEqual(emailAddressA);

// alias isn't verified until you click the confirmation link sent to the aliased address
expect(alias.isVerified).toEqual(true);

For the complete routing model, verification flow, and reply behavior, use the alias email address proxy guide. The Email Alias API is the direct product path.

Redact an email address in a UI or log

Display masking turns alex@example.com into a recognizable but incomplete value such as a***@example.com. It is useful on account screens, support tools, and logs where showing the full address would create unnecessary exposure.

Keep the rules simple:

reveal only enough for the intended person to recognize the address
mask the local part before @; mask the domain too when it is sensitive
keep the full address out of client-side state, analytics events, and logs when it is not needed
apply authorization separately because visual masking is not access control

A small JavaScript formatter can handle display-only redaction:

function maskEmail(email) {
  const at = email.lastIndexOf("@");

  if (at <= 0 || at === email.length - 1) {
    return "***";
  }

  const local = email.slice(0, at);
  const domain = email.slice(at + 1);
  const visible = local.slice(0, 1);

  return `${visible}${"*".repeat(Math.max(3, local.length - 1))}@${domain}`;
}

maskEmail("alex@example.com"); // a***@example.com

Run this on the trusted side of your application when the unmasked value should never reach the browser. If a support operator needs a reveal action, make it permissioned and auditable instead of relying on CSS to hide the text.

Replace production email addresses in test data

A development or QA database should not send to customers by accident. Replace real addresses before the data reaches a test environment, and route any email-producing tests to inboxes the team controls.

A practical workflow is:

Copy only the records needed for the test.
Replace every recipient with a generated address under a controlled domain or a private MailSlurp inbox.
Preserve uniqueness so account constraints and joins still behave normally.
Keep any mapping back to source records outside the test dataset and restrict access to it.
Block or rewrite outbound mail that does not target an approved test domain.
Send a test message and confirm it reaches the expected controlled inbox.

MailSlurp can create a fresh inbox for each test run or scenario. That gives the test a real address and a receive API without reusing customer data or a shared team mailbox. Use Email Sandbox when you want isolated inboxes and deterministic message assertions in CI.

Hashing is not the same as masking

Hashing is useful when a system needs a stable comparison value without storing the original address in the same field. It is not a replacement address, and it does not make weak input impossible to guess.

If the application must send email, use an alias or a controlled synthetic address. If it only needs to compare records, use a keyed, documented pseudonymization method and keep the key or lookup data separate from the masked dataset.

Test the complete masked-email workflow

Do not stop after checking that the masked value looks right. Test the behavior that depends on it.

For an alias or proxy:

Send a message to the alias from an external test address.
Confirm it reaches the verified destination.
Check the sender, subject, body, attachments, and forwarding headers.
Reply through the supported thread flow when two-way masking is enabled.
Disable or rotate the alias and confirm the old route behaves as expected.

For a masked test dataset:

Trigger the real signup, reset, invite, or notification flow.
Wait for the message in the generated inbox rather than using a fixed sleep.
Assert the link, code, recipient, and environment.
Confirm no message was addressed to a production domain or customer inbox.

MailSlurp combines generated inboxes, aliases, wait-for-email APIs, webhooks, and message inspection so the privacy control can be tested as part of the workflow.

Common mistakes

Masking with CSS alone

Hidden text can still be present in the page source, accessibility tree, browser state, or network response. Remove or transform sensitive data before it reaches an unauthorized client.

Reusing one catch-all address in every test

Shared inbox state makes parallel tests harder to debug. Create an inbox per run or use strict message matching and cleanup rules.

Replacing the local part but keeping a real customer domain

An invented address at a real domain can still receive mail through a catch-all rule. Use a domain and inbox path that your team controls.

Treating an alias as a second mailbox

An alias is a routing layer. Retention, search, access control, and reply behavior belong to the destination or the alias platform and should be tested explicitly.

FAQ

What is email address masking?

Email address masking hides some or all of a real address. It may use an alias for live mail, partial redaction for display, or synthetic replacement for test data.

Can a masked email address still receive messages?

Yes, when the mask is an email alias or proxy connected to a verified destination. A redacted string such as a***@example.com is only a display value and cannot receive mail.

Should I mask or delete email addresses in logs?

If the address is not needed, omit it. If operators need limited recognition, store or display a redacted value and keep access to the original address in an authorized system.

How should I mask email addresses for testing?

Replace production addresses with unique, controlled test inboxes before the data enters QA. Then send through the real application flow and assert the received message with an API.

Final take

Use an alias when email must keep flowing, redaction when a person only needs a hint, and synthetic inboxes when tests need realistic delivery without customer data. MailSlurp gives each path a controllable address and a way to prove the message journey still works.

How to Mask Email Addresses Without Breaking Tests or Replies