Custom-domain email alias: branded receiving without another mailbox
Create addresses such as support@yourdomain.com, forward them to existing inboxes and send through authenticated SMTP while retaining domain ownership.
This is MailerZ's core job. It is useful when several stable domain identities should reach existing inboxes without provisioning a full mailbox for every address.
This page is educational, not a promise that one configuration fits every organization. Use the working DNS diagnostic, an external receive-and-reply test and current plan limits before moving a production domain.
What this term means in the MailerZ model.
A custom-domain email alias is an address under a domain you control that routes to another mailbox. The domain's MX records select the inbound receiver; routing rules select destinations; outbound SMTP and authentication records handle sending. The alias itself does not require a separate mailbox.
Email vocabulary is overloaded. “Alias,” “forward,” “mask,” “mailbox” and “send as” may describe different layers depending on the provider. The safest approach is to draw the address, inbound receiver, route, destination storage and outbound sender separately. If a vendor cannot explain each layer, a single feature checkmark is not enough evidence.
Use the page to qualify the problem before choosing software.
SaaS founders with multiple brands
Agencies managing client domains
Freelancers with public role addresses
Teams consolidating mail into Gmail or Outlook
Organizations requiring a separate mailbox per user
Domains without DNS access
Bulk campaign infrastructure
Users who want a provider-issued disposable address
The details that change cost, risk and daily usability.
MX decides where incoming mail starts
Publish only the intended receiver's MX set. Mixed unrelated providers are not a safe load-balancing technique because priority describes failover order. Use the authoritative DNS zone, remove obsolete records only after staging, and allow for cached answers.
- Confirm authoritative nameservers
- Copy hostnames and priorities exactly
- Avoid a Null MX
- Compare two public resolvers
SPF, DKIM and DMARC serve outbound trust
SPF authorizes senders, DKIM signs a message and DMARC evaluates alignment plus policy. These records matter for send-as, but they do not replace MX or guarantee inbox placement. Publish one SPF policy per hostname and one DMARC record at _dmarc.
- One SPF policy
- Selector-specific DKIM
- One DMARC policy
- Real-message verification
Catch-all is an operating decision
Catch-all lets any local part receive, which reduces setup friction but increases typo and spam exposure. MailerZ plan behavior can hold or forward unknown recipients. Decide who reviews held mail and whether an unknown address should ever become permanent.
- Explicit aliases for critical roles
- Policy for unknown recipients
- Dictionary-spam monitoring
- Documented route owner
Prove one address before moving the domain.
- 01
Add the root domain
Enter the domain without protocol, path or mailbox prefix.
- 02
Verify ownership
Publish the exact verification value shown by MailerZ in the active DNS zone.
- 03
Publish MX
Replace conflicting inbound providers during the planned cutover.
- 04
Create aliases and destinations
Build every critical route before traffic moves.
- 05
Configure outbound
Publish authentication, add SMTP to the client and test a recipient-visible From address.
Keep a rollback record. Save the previous MX, SPF, DKIM and DMARC values before editing. Create routes before changing MX and retain the old provider account until DNS caches settle and important aliases have been tested.
Eight foundations for evaluating any email alias product.
An alias is an identity, not necessarily a mailbox
An address can receive without owning a separate inbox. MailerZ accepts mail for the domain, resolves the local part to a configured route and forwards the message to an existing mailbox. This lowers mailbox cost and keeps users in familiar clients, but storage, search, folders and final spam placement remain the destination provider's responsibility.
Incoming and outgoing email are separate systems
MX tells other servers where to deliver incoming mail. SMTP credentials let a client submit outgoing mail. SPF, DKIM and DMARC help receivers authenticate the sending identity. Completing one path does not configure the other. A useful launch test proves both directions with an unrelated external provider.
The visible sender and the envelope sender are different
Mail clients emphasize the From header, while transport also uses an envelope sender and return path for bounces. Forwarders may preserve or rewrite fields to maintain replies and authentication. Diagnose with complete headers and the downstream SMTP response, not only the name shown in the inbox list.
A forwarded result is not the same as inbox placement
A destination server can accept a message and later place it in spam, quarantine or a category tab. MailerZ can show evidence about its processing and the next handoff, but it cannot guarantee a user's final view. This boundary should be explicit in sales, documentation and support.
Catch-all exchanges setup speed for exposure
A catch-all accepts unknown local parts, which is useful when creating addresses on the fly. It can also attract typo traffic and dictionary spam. Define whether unknown mail should be held, forwarded or rejected; name the administrator who reviews it; and create explicit aliases for high-consequence roles.
Plan limits are product architecture
Count domains, aliases, seats, retention days, monthly outgoing mail and peak hourly send-as. A plan that clears only the average month is fragile. Keep headroom for launches and incidents, and use a dedicated bulk sender when traffic needs campaign-scale consent, reputation, complaint and unsubscribe handling.
Custom domains are portability insurance
When the domain belongs to you, the visible address can survive a provider change. Recreate the route at the next provider and repoint DNS. Provider-owned addresses normally cannot move, so every service or correspondent must learn a replacement. This exit cost deserves more weight than a small subscription difference.
Every route needs a human owner
Document who controls the registrar, DNS, MailerZ workspace, destination mailbox and billing. Use strong unique credentials and multi-factor authentication wherever available. Offboard former staff, rotate SMTP secrets and review high-value routes before renewal rather than waiting for a missed recovery email.
The address senders remember on your domain.
Alias, policy, and store-before-acceptance.
Where the durable copy lives; placement is not guaranteed.
The diagram is conceptual. Delivery history and message headers provide evidence for a real message.
A resilient alias system is managed after launch, not merely configured once.
Design the route before publishing the addressDecide the destination, backup owner, reply identity, catch-all relationship and expected traffic before placing an address on a website or invoice. Public addresses develop dependencies quickly. A route created after the first customer message arrives is already late. Use a temporary internal test address to validate the pattern, then create the production local part explicitly and record its owner.
Use destinations as responsibilitiesForward support, billing and security to people responsible for those functions rather than to one founder's permanent inbox. Where several recipients are necessary, decide whether every person should receive a copy and who is accountable for replying. Forwarding fan-out can expose customer content more widely and create duplicate responses. A shared destination workflow may be better than adding copies indefinitely.
Monitor changes, not only outagesRecord who changed an alias, destination, catch-all policy, SMTP credential or DNS record and when. Many email incidents begin with a legitimate configuration change whose side effect appears hours later as caches expire. A simple change note dramatically shortens diagnosis. Pair it with an external test message after every consequential change and keep the message identifier with the record.
Separate reputation by sending purposeOperational replies, password messages, receipts and marketing campaigns have different complaint and volume patterns. Even when the visible brand is the same, use appropriate sending systems and authentication for each purpose. MailerZ is intentionally limited for human-scale operational sending. A dedicated transactional or marketing provider should handle automated volume so a campaign spike cannot disrupt replies from critical role addresses.
Create an incident checklist before an incidentStart with authoritative DNS, then public MX, provider acceptance, routing decision, destination response, final placement and outbound reply. Preserve UTC time, sender, recipient, message ID and full remote response. Avoid changing several records simultaneously. Escalate with evidence and never share SMTP passwords. A consistent checklist lets a non-specialist eliminate common failures without guessing.
Review the system before renewalOnce a year, verify domain ownership, renewal payment, nameservers, DNS records, active aliases, destinations, administrators, SMTP credentials, traffic headroom and recovery methods. Remove obsolete routes and former staff. Run a receive-and-reply test from an unrelated provider. Compare actual usage with the selected plan and save the updated decision record. Quiet infrastructure remains reliable because someone owns this routine.
Protect the full chain, not only the forwarding account.
The registrar and authoritative DNS account can redirect an entire domain, so their security is at least as important as the forwarding dashboard. Use unique credentials, strong multi-factor authentication, protected recovery methods and reliable domain renewal. Maintain more than one trusted administrator for business-critical domains, but grant only the access each person needs.
Email forwarding necessarily processes envelope information and message content long enough to route and transmit it. Transport encryption protects a connection when both servers cooperate; encryption at rest protects stored data under the provider's key-management model. Neither statement automatically means ordinary Internet mail is end-to-end encrypted. Review the privacy policy, security page, data-processing terms and destination provider together.
Keep SMTP credentials separate per identity or user when supported, rotate exposed credentials and remove them when a team member leaves. Never paste secrets into a public diagnostic. MailerZ's DNS checker uses public DNS answers; it does not need mailbox or SMTP passwords.
Read the MailerZ security boundaryA green DNS check is readiness evidence, not a delivery guarantee.
Start diagnosis at authoritative nameservers, then inspect MX routing, public resolver agreement, ownership verification and outbound authentication. Next send a real message from a provider unrelated to the destination. When delivery fails, preserve the complete SMTP response, UTC timestamp, message ID, sender, recipient and recent changes. A 4xx response is generally temporary; a 5xx response generally needs a configuration, address or policy change before retrying.
Forwarding can complicate authentication because the forwarding server is not the original sender. DKIM preservation, SRS and ARC can help communicate context, but the destination provider still evaluates reputation, content and local policy. Do not promise inbox placement. Tell users exactly which hop accepted the message and what remains outside MailerZ control.
Six numbers make every plan comparable.
MailerZ currently offers Free; annual-only Solo; and monthly or yearly Starter, Business and Agency tiers. Paid plans use a ninety-day store and increase domains, aliases, seats and sending allowances. Compare the first plan that clears every requirement, not the cheapest headline price. Include destination mailbox cost, migration time, support burden and exit effort.
Do not choose a plan that exactly matches today's peak. New domains, staff changes, launches and incidents consume headroom quickly. If the expected workload includes campaigns or large automated streams, use a specialized sender instead of trying to stretch operational SMTP beyond its intended purpose.
Compare exact MailerZ limitsUse the refund window to test risk, not colors.
The new-user refund policy provides a seven-day full-refund window subject to its published terms. A serious evaluation produces reusable evidence: route inventory, DNS values, test-message identifiers, headers, downstream responses, capacity worksheet and rollback notes.
Direct answers without hiding the boundaries.
Does a custom-domain email alias create another inbox?+
Not in the MailerZ model. MailerZ receives mail for addresses on a domain you control and forwards it to a verified destination such as Gmail or Outlook. The destination remains the mailbox and long-term system of record.
Can I reply from the alias?+
Yes, when the selected MailerZ plan includes send-as capacity and the mail client is configured with MailerZ SMTP. Test with an external recipient and verify the visible From address; inbound forwarding and outbound SMTP are separate paths.
Is an address on my own domain portable?+
Usually. Because you control DNS, you can move the domain to another compatible provider and recreate the same local parts. Provider-owned shared-domain aliases are normally not portable.
Does forwarding guarantee inbox placement?+
No. MailerZ can report routing and downstream handoff evidence, but the destination provider controls final inbox, spam, quarantine and policy decisions.
Can I use MailerZ for newsletters or bulk campaigns?+
No. The SMTP allowances are designed for human-scale replies and operational sending. Bulk and large transactional streams need a dedicated sending platform with consent, bounce, complaint and unsubscribe controls.
How should I test a new domain?+
Start with a low-risk domain or address. Verify public MX, SPF, DKIM and DMARC; send from an unrelated provider; inspect delivery history; configure one SMTP identity; reply externally; then expand.
Technical claims should be inspectable.
This guide uses MailerZ's current product scope and pricing plus the first-party or standards sources below. The referenced emailalias.io page was reviewed for search intent and topic coverage, not copied. Vendor features and terms can change; follow the source and verify current checkout or documentation before relying on a consequential claim.
MailerZ is a product of Secuno LLC. Educational content is not legal, compliance or deliverability advice.Start free, verify the domain, and test both directions.
Upgrade only after the delivery evidence, workflow and plan limits match the job.