Your MailerZ dashboard is the source of truth for record names, targets and priorities. The examples below describe the fields—not production values.
A verified domain whose inbound routing and sending-authentication records match the unique values in your MailerZ dashboard.
Before you begin
Open the domain in MailerZ and keep its DNS checklist visible.
Confirm that Amazon Route 53 is the authoritative DNS host for the domain, not only the registrar.
Inventory existing MX and TXT records before editing anything.
Step-by-step
Open the authoritative DNS zone in Amazon Route 53
Open AWS Route 53 → Hosted zones, choose the exact public hosted zone, then choose Create record. Avoid editing a private hosted zone used only inside a VPC.
Translate the host/name correctly
For the zone apex, leave Record name blank. Route 53 displays the full domain automatically. Use a standard record, not an alias record, for MX and TXT.
After saving, compare the fully qualified record name—not only what you typed.Add the verification TXT record
Create a TXT record using the exact host/name and complete token shown in MailerZ. Keep quotation handling at the provider default unless the interface explicitly requires otherwise.
Add every MailerZ MX record
Choose MX and enter each value in the format priority, a space, then the MailerZ mail server—for example: 10 [dashboard MX host].
Add sending-authentication records
If MailerZ shows SPF, DKIM or other TXT/CNAME records, copy each host and value verbatim. Combine SPF authorization carefully—publishing two separate SPF records at one name can fail evaluation.
Review conflicting mail routes
Old MX records can continue sending some mail to the former provider. Remove them only when you are ready to cut over and have confirmed no other mailbox service depends on them.
Save and verify from Amazon Route 53
Choose Create records, reopen the record set, and query the public zone. A 300-second TTL is practical during setup; raise it later if desired.
Run a two-direction delivery test
Send from an unrelated mailbox to a named alias, confirm delivery history, then reply through MailerZ SMTP and inspect the visible From address at the recipient.
Match every DNS field before saving
This diagram demonstrates field placement and sequence. Use the unique values in your MailerZ dashboard; never copy credentials or verification tokens from a public tutorial.
@mailerz-verification=••••••Verify@10 · [dashboard MX host]Route[DKIM selector]v=DKIM1; k=rsa; p=••••SignField-by-field reference
Treat this as a translation layer between MailerZ and the provider interface.
TXT, MX or CNAME from dashboardTells DNS what kind of information you are publishing.Exact name shown in MailerZPlaces the record at the root domain or required selector.Exact destination or tokenRoutes mail or proves domain control; one missing character breaks validation.Exact MX priorityControls the order receiving servers try mail exchangers.Auto or 300 seconds during setupControls resolver caching; it is not a guaranteed propagation timer.Verify the setup
MailerZ reports the domain as verified.
A public DNS lookup shows the intended MX records and priorities.
An external message reaches the configured destination.
A reply sent through SMTP preserves the expected From address.
Avoid these issues
A private hosted zone or a second public hosted zone with the same name may look correct in AWS while having no effect on internet mail.
Do not copy MX hosts, verification tokens or DKIM values from screenshots or another domain.
A registrar can differ from the authoritative DNS provider; edit the zone used by the active nameservers.
Propagation is not a single timer. Previously cached records can remain until their TTL expires.
Competing MX records can split or misdirect inbound delivery.
Common problems and exact next actions
MailerZ still says unverified
Likely cause: The record is in the wrong authoritative zone, the host was duplicated, or an old answer is cached.
Next action: Check active nameservers, query the exact record publicly, compare every character, then retry after the TTL window.
Some messages arrive at the old provider
Likely cause: Old and new MX records are both published or different resolvers still hold the previous answer.
Next action: Inspect the public MX set from multiple resolvers. Remove obsolete MX records only after confirming the intended cutover.
Receiving works but sending fails
Likely cause: MX controls receiving; SMTP authentication and SPF/DKIM records control sending.
Next action: Open the sending section in MailerZ, complete every authentication record, then retest with a generated SMTP credential.
Provider interface details can change. Check Amazon Route 53 docs
Configure one address, then prove the full loop.
Receive a message, reply through SMTP, and confirm the expected From address before moving your whole domain.