A domain verification TXT record is how a provider checks that you can publish DNS for a name before it will accept that name’s mail. You copy a token, put it at the host the dashboard names, look it up in public, then click verify. It is not MX. It is not SPF. Mixing those three records is how teams “verify” in the wrong panel and still cannot receive.
Quick answer for domain verification txt record
Mail systems need proof you control the domain before they will let you publish MX toward their hosts or send as that domain. The usual proof is a TXT string the provider generated. IETF RFC 5321 — Simple Mail Transfer Protocol will later deliver to whatever MX you publish. Verification is the gate so a stranger cannot add yourbrand.com to their account.
Publish at the DNS that NS points to. If Cloudflare is authoritative and you paste the token at the registrar, the public lookup will not show it. The dashboard will keep saying pending. That is not a MailerZ outage. Look up NS, then TXT, from a resolver that is not your laptop cache. See troubleshooting and tools.
After verify, you still publish one MX set, create named aliases, hold unknown, and prove inbound. Verification alone does not move mail. Docs and migration planner cover the cut that follows. Do not skip TXT because you already “connected” a website.
Keep the verification TXT unless the provider says to remove it. Some products re-check. Deleting it after a green check can break later features. Do not merge the token into the SPF string. Two TXT jobs, two records or two clearly separate strings as the dashboard specifies.
User problem and decision criteria
The usual failure is the wrong panel. NS is at the CDN. The founder edits the registrar because that is the login they remember. They wait 48 hours. Nothing verifies. They open a ticket. The public TXT lookup was always empty.
The second failure is stuffing the token into SPF. SPF is also TXT. Receivers parse v=spf1. A verification token inside that string can break SPF and still fail verify if the provider looks for a dedicated name like _mailerz.example.com or a specific prefix.
The third failure is publishing MX first. Mail starts arriving at a provider that has not accepted the domain, or at leftover hosts. Verify first, aliases second, exclusive MX third, inbound proof fourth.
Decision criteria: exact host and value from the live dashboard; authoritative NS known; public TXT match; no SPF merge; no website CNAME treated as verify; a person who can edit DNS the same day.
Criteria that do not belong: waiting two days without a public lookup, buying a mailbox so verify “works,” or changing Gmail MX. Gmail is not the domain you are proving.
Agencies should screenshot the dashboard token and the public TXT in the same ticket. Clients will delete the TXT during a “DNS cleanup.” Re-verify after any bulk record delete.
Internationalized domains and www are not the mail name. Verify the name that will appear after the at-sign. Verifying www does not verify the apex.
Technical mail flow
The provider’s verifier queries public DNS for the TXT at the host it told you. If the string matches, the domain is bound to the account. Then you may publish MX toward that provider. Sending servers still follow IETF RFC 5321 — Simple Mail Transfer Protocol MX, not the verification TXT.
SPF, DKIM, and DMARC are later if you send. MailerZ Free has no send-as. Paid send-as copies dashboard SMTP. Open relay is 550. Verification does not grant an open relay.
Envelope SRS applies on inbound forward after MX works. Header fields stay intact. None of that starts at verify click. Verify only unlocks the next controls.
TTL on the TXT should be short while you iterate, then you can leave it. A 24-hour TTL on a typo means a day of pending. Fix the value, wait the TTL, look up again.
Step-by-step setup / decision path
- Add the domain in MailerZ. Copy host and token exactly. Watch for quotes and trailing dots the panel may add.
- Look up NS. Open that DNS panel only.
- Create the TXT at the host the dashboard named. Do not put it on
wwwunless asked. - Look up TXT from a public resolver. The token must appear. If not, you edited the wrong panel or TTL has not passed.
- Click verify in the app. If it fails while public DNS matches, wait a few minutes and retry. Do not republish MX in panic.
- Create named aliases. Hold unknown.
- Publish exclusive MX. Delete leftovers. Prove inbound from a third mailbox.
- Leave the verification TXT in place unless the dashboard says remove it.
If the dashboard names a subdomain host, a TXT at the apex will not count. Read the host column twice.
Multiple verification TXT records from Google, Microsoft, and MailerZ can coexist if they are different strings. Do not overwrite an existing Google verify record with the MailerZ token unless you are leaving Google. Add a new TXT.
Failure modes and proof
Wrong panel: public TXT empty. Proof: NS versus where you clicked save.
Token in SPF: SPF breaks, verify still pending if host mismatches. Proof: one v=spf1 plus a random token inside it.
Quotes stored as part of the value: lookup shows extra characters. Proof: copy the raw TXT.
Apex versus named host: you published at the wrong name. Proof: lookup on the exact host.
MX first: mail already flowing to leftovers. Proof: public MX before verify completed.
Deleted after success: later re-check fails. Proof: TXT gone.
Website CNAME only: no TXT. Proof: lookup type TXT empty.
Laptop cache: you see the record, the verifier does not. Proof: public resolver.
Two people publishing different tokens: last write wins. Proof: the live string versus the dashboard.
MailerZ workflow and product boundary
MailerZ is custom-domain aliasing and forwarding with optional paid send-as. Secuno LLC operates mailerz.net. The app is mail.mailerz.net. It is not Workspace, not IMAP, and not an open relay.
Verification is the first DNS step the dashboard asks for. Then aliases, exclusive MX, inbound proof. Envelope SRS on forward. Headers intact. Free: hold unknown, no send-as. Solo forty dollars a year with fifteen aliases and five send-as per hour. Starter eight or eighty. Business nineteen or one hundred ninety. Agency thirty-nine or three hundred ninety. Quote pricing.
Copy SMTP from the dashboard only after paid send-as. Do not invent ports. This page does not invent SOC 2, ISO, HIPAA, SLAs, or inboxing rates.
Cost, alternatives, and trade-offs
TXT verify is free in DNS. The cost is time in the wrong panel. A Workspace seat does not replace ownership proof on a forwarder.
Some registrars offer “one click connect.” If that click writes the wrong host, you still need a public lookup. Convenience that skips the lookup is not cheaper.
Doing nothing and publishing MX without verify leaves you unable to use the provider and still at risk of leftover hosts. Spend the ten minutes.
Agencies should not bill verify as a mystery. Show the two screenshots. Clients understand a matching string.
If you cannot edit DNS, you cannot verify. Get the NS owner before you promise a cut date.
Keeping old Google verify TXT while adding MailerZ is fine. Keeping old Google MX is not. Do not confuse those leftovers.
CAA records and SSL issuance are a different proof of control. A successful Let’s Encrypt run does not verify MailerZ. Do not skip TXT because the site has HTTPS. Mail and certificates share a domain name, not a record type.
DNSSEC can make a bad TXT look “stuck” if you published a signature over the old set. If public lookups disagree in a signed zone, wait for the DNSSEC chain or ask whoever signed the zone. This is rare for small domains and still not a reason to merge the token into SPF.
Shared family domains need a written owner. If a sibling can delete TXT, they can unbind the mail product. Treat the verification record as production, not as leftover clutter in a spring-clean.
Verification is ownership, not MX
How to verify a domain with a TXT record is a copy-paste of the exact token and host from the MailerZ dashboard onto the authoritative DNS panel — the panel that matches public NS. Look the name up in public until the string matches. Then click verify. Do not publish MX first and call that verification. Do not paste the token into an SPF record. Do not add quotes the dashboard did not ask for, and do not strip quotes if the panel requires them for a string with spaces. The public lookup is the judge, not the registrar preview.
Print NS first. A GoDaddy tab while Cloudflare answers is a silent publish. The token never appears on 8.8.8.8. MailerZ verify stays red. Operators then “fix” by publishing MX on the wrong zone. Customers never arrive. History stays empty. Edit the panel that matches NS. If you must move NS to use a panel you like, wait TTL, then publish the TXT, then verify, then MX.
Host name mistakes are the second class. Some dashboards want the token at the apex. Some want a prefixed name. Copy the host the dashboard printed. A leftover Google site verification TXT can sit beside the MailerZ token. That is fine. Two MailerZ tokens from two abandoned signups are how people verify the wrong workspace. Delete the stale token if the dashboard issued a new one.
TXT quoting varies by panel. If public lookup shows extra quotes or a truncated string, the panel wrapped wrong. Fix quoting. Wait TTL. Lookup again. Then verify. A green verify button without a public match is a cache lie or the wrong panel. Do not proceed to exclusive MX until verify is honest.
What verification does not do
It does not cut inbound. It does not delete leftover MX. It does not approve send-as. It does not encrypt the body. SPF, DKIM, and DMARC are sending records you publish later if you send. Free cannot finish send-as. Confirm /pricing. MailerZ is not IMAP. Destinations stay Gmail or Outlook after you later publish exclusive MX and named aliases.
Self-send is still a bad gate after verify. Probe from another mailbox once MX and aliases exist. Envelope SRS only. Header From stays. Unauthorized send is 550. Not an open relay. Not SOC 2. Not HIPAA.
A TXT that looked published and was not
An operator pasted the token into SPF as an include. Public TXT showed a broken v=spf1. Verify failed. They added a second v=spf1. Permerror. The fix was restore one SPF for sending later, publish the ownership token as its own TXT at the host the dashboard named, wait two resolvers, then verify. Then exclusive MX. Then a foreign probe.
A second operator verified on a parked zone that was not the website zone. The site stayed on a host with old Google MX. Customers used the site domain. History empty. Print the name customers type after the @. Verify that name. Cut that name.
Related: docs, troubleshooting, tools, features. RFC 1035 for TXT presentation. Google and Microsoft verification docs if you also keep their tokens — cite them, do not mix tokens into one string. Commercial helpers stay nofollow.
Verify, then cut, then probe
Order: NS match, TXT public match, dashboard verify, exclusive MX, leftover delete, two views, named aliases, foreign probe. Skip any step and you will debug the wrong layer. Do not enable catch-all on verify day. Hold unknowns. Do not wire SMTP until inbound proves the zone.
Agencies: one token per client zone, one login story. Do not paste client A’s TXT onto client B. Offboard means delete tokens and MX you own. Start free on a domain you can break. Sign in if the zone already lives here. The next action is a public TXT lookup, not another tab.
If verify flips green and then red after a wizard, a helper rewrote the zone. Recheck the token. Republish. That is how to verify a domain with a TXT record without treating a button as DNS.
Token hygiene after verify
After the dashboard is green, leave the TXT in place unless the product tells you to rotate. Deleting a working token to “clean the zone” is how verify flips red during a later audit. Google and Microsoft site tokens can stay as siblings. Do not concatenate them with the MailerZ string. Do not put the ownership token inside v=spf1. One SPF later, when you send, as its own record.
If you transfer registrars, NS may change. The new panel may not copy TXT. Public lookup goes empty. Verify goes red. Republish the same token at the new answering NS. Do not issue a second signup token unless the dashboard rotated. Two tokens and one verify click is a coin flip.
Hostname apex versus www is a different name. Customers type the bare domain after @. Verify the bare domain. A www TXT does not prove example.com. Same for a host named mail. Verify the name you will put on MX.
Quoting: if the panel added extra quotes and public lookup shows them as part of the string, strip or re-enter until the token matches exactly. If the panel stripped required quotes and the string split on spaces, restore the quoted form the dashboard gave you. Two resolvers. Then click verify again. Then MX. Then leftover delete. Then named aliases. Then a foreign probe. That order is how to verify a domain with a TXT record without mixing layers. Confirm /pricing when send-as is next. Free cannot finish send-as. Related: docs, troubleshooting, tools, features.
Verify is not a send-as green light
A green ownership TXT does not publish SPF, does not sign DKIM, and does not set DMARC. It does not copy the SMTP pair. It does not delete leftover MX. Teams that stop at verify and print hello@ on the homepage still have empty history. Finish MX exclusivity and a foreign probe. Then, if From must travel, pay a card that includes send-as and copy the pair. Free cannot finish send-as. Confirm /pricing.
If verify is green and MX is exclusive and history is still empty, the alias is unnamed or unknowns are held. Name it. Do not paste a new TXT. Related: docs, troubleshooting, features.
Worked quoting ticket
A panel stored the token with wrapping quotes. Public lookup included the quote characters. The dashboard compared raw and failed. They re-entered the token as an unquoted string. Lookup matched. Verify went green. A second panel split a token on spaces because quotes were stripped. They restored the quoted form from the dashboard. Lookup matched. Same rule: public string equals dashboard string. Then MX. Then leftovers gone. Then a foreign probe. Do not skip to send-as. Free has no send-as. Confirm /pricing. Related: docs, troubleshooting, tools.
NS transfer day
On nameserver transfer day, treat verify as dirty until public TXT matches again. Do not cut MX on the old panel after NS has moved. Do not issue a new token unless the dashboard rotated. Lookup, match, verify, then exclusive MX. Two resolvers. Foreign probe. Confirm /pricing only when send-as is the next hop. That is how to verify a domain with a TXT record after a transfer, not only at signup.
If the transfer also cloned leftover Google MX, verify can look green while hop one is still split. Public TXT match is not public MX exclusivity. Finish both before you print hello@.
FAQ
- What is the safest way to handle domain verification txt record?
- Copy the exact token and host from the dashboard. Publish TXT at the authoritative DNS panel—the one that matches NS. Look the name up in public until the string matches. Then click verify. Do not publish MX first and call that verification. Do not paste the token into SPF.
- Does this require a new mailbox?
- No. A verification TXT proves you control the DNS name. MailerZ is not IMAP. Destinations stay Gmail or Outlook after you later publish MX and named aliases.
- Will it work with Gmail or Outlook?
- Verification does not touch those products. After MX and aliases exist, inbound can land in Gmail or Outlook. TXT ownership is a prior step so the provider will not accept a domain you do not control.
- What DNS records are involved?
- The verification TXT at the host the dashboard names, plus NS that decide which panel is real. MX comes after verify. SPF, DKIM, and DMARC are sending records, not the ownership token. Leftover MX is a later cut problem.
- What should I test before production?
- Public TXT lookup matching the dashboard token. Then verify in the app. Only then publish exclusive MX and prove inbound from a third mailbox. A green verify button without a public TXT match is a cache lie or the wrong panel.
Key takeaways
- A domain verification TXT record proves DNS control. It is not MX and not SPF.
- Publish at the panel that matches authoritative NS.
- Confirm the token with a public TXT lookup before you trust the verify button.
- Do not merge the token into the SPF string.
- Verify, then aliases, then exclusive MX, then inbound proof.
- Leave the TXT unless the dashboard says to remove it.
- Add a new TXT next to Google or Microsoft verify records. Do not overwrite them blindly.
- MailerZ will not accept a domain you cannot prove.
Conclusion
Copy the token, publish it where NS is real, look it up in public, then verify. After that you may cut MX. Before that you are guessing.
Add the domain on MailerZ, publish the TXT the dashboard shows, and only then point mail at the service.