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 Cloudflare 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 Cloudflare
Open Cloudflare, select the domain, then choose DNS → Records. Confirm the nameservers shown there match the domain’s authoritative nameservers.
Translate the host/name correctly
Cloudflare accepts @ for the zone apex. TXT and MX records are DNS records only; Cloudflare’s proxy toggle does not apply to MX.
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 Add record → MX. Enter @ as Name when routing the root domain, paste the MailerZ mail server into Mail server, and enter the exact priority.
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 Cloudflare
Save each record, use Cloudflare’s DNS record search to confirm it is visible, then run verification in MailerZ.
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
Do not create an A or CNAME record as a substitute for an MX record, and do not point MX at an orange-cloud proxied hostname.
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 Cloudflare DNS 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.