customer@example.com writes to support@yourdomain.com
Email Routing Lab
Configure a sample identity, then watch the receiving or sending path one boundary at a time. Nothing is sent and no address is stored.
Domain, recipient, limits and routing policy are checked
support@yourdomain.com maps to your.inbox@gmail.com
your.inbox@gmail.com returns an SMTP success response
The forwarding outcome becomes available in delivery history
Adjust the sample values and run the flow. This demonstration does not test DNS or deliver a message.
Simulation boundary: This lab teaches the sequence. Use the live DNS diagnostic for a real domain, then send external test messages before production use.
Build this route in MailerZSee the path before changing your DNS.
The lab separates the public address, MailerZ routing policy and destination inbox. That distinction matters: an alias is not a mailbox, forwarding acceptance is not inbox placement, and successful SMTP authentication is not the same as final recipient acceptance.
Receiving path
External mail servers follow your MX records. MailerZ checks the recipient, stores the required message data, applies the alias route and attempts delivery to the destination.
Sending path
Your client authenticates to MailerZ SMTP with an approved identity. MailerZ attempts delivery and records the remote response without becoming an unrestricted relay.
What simulation cannot prove
It does not inspect your DNS, credentials, reputation, mailbox rules or recipient filtering. Real readiness requires published records and external tests.
SimulateUnderstand the intended route and responsibility boundaries.
DiagnoseRun the live public DNS checker against the real domain.
VerifySend inbound and outbound messages from unrelated providers.
ObserveKeep message IDs and SMTP outcomes for the launch window.
MailerZ makes the delivery path visible; it cannot control a third-party provider’s spam folder, mailbox rules or temporary outage.