What is _globalsign-domain-verification and how to add the TXT record

Why did GlobalSign ask me to add _globalsign-domain-verification?

GlobalSign uses the TXT record for Domain Control Validation: publishing the requested value proves that you can change DNS for the domain or SAN being validated. The TXT record does not enable HTTPS and does not install a certificate on Apache, Nginx, IIS or a hosting panel.

A website can therefore open normally while a SAN still shows Pending, or it can still serve an old certificate after DNS validation has already succeeded. HTTP availability does not prove DNS control, and successful DCV does not prove that the new certificate is installed.

Open the Domain Verification Page for the current order and identify the exact domain or SAN that remains Pending. That is the name to troubleshoot. If one SAN is Approved and another is Pending, changing the DNS record for the already approved name does not solve the remaining validation.

Is _globalsign-domain-verification the TXT name or the TXT value?

_globalsign-domain-verification should not automatically be treated as the TXT Host/Name. The correct placement depends on what the current GlobalSign verification request provides. Current GlobalSign DVP workflows may ask for a TXT record at the common name with the supplied DVC in Value, while API-based or older workflows can present the validation data differently.

A valid TXT record at the wrong owner name is still useless to the GlobalSign check. Suppose the current verification request provides this complete DVC:

globalsign-domain-verification=AbCdEf1234567890

If that entire string belongs in TXT Value, changing it to:

Name: globalsign-domain-verification
Value: AbCdEf1234567890

creates a different DNS record. The DNS server may publish it without error, but GlobalSign will query the expected owner and will not find the expected value there.

Read the GlobalSign DVC literally

Work from the verification information attached to the current order. If GlobalSign provides Host and Value separately, copy each field separately. If the DVC is shown as one complete TXT value, keep it intact.

• Do not remove a leading underscore if it is part of the supplied value.
• Do not remove globalsign-domain-verification= when it is part of the DVC.
• Do not add spaces before or after the value.
• Preserve letter case in the verification token.
• Do not reuse a code from an older order only because the domain is the same.

What goes into Host or Name?

The Host field defines the owner name of the DNS record. Depending on the DNS panel, the root of example.com may be entered as @, as example.com, or with an empty field. Other panels expect a relative hostname or a complete FQDN.

A common failure is automatic zone-name expansion. If the panel already appends .example.com and the user enters example.com, the final record can become:

example.com.example.com

The record exists. It is simply at the wrong name.

What goes into Value or Content?

The TXT Value contains the validation data GlobalSign expects. If the current DVP shows one complete DVC, publish that value exactly. DNS tools often display TXT strings inside quotation marks; the presence of quotes in command output does not automatically mean that literal quote characters were added to the DVC.

Do not judge the record by how it looks in the control panel. Judge the final owner name and TXT data returned by DNS.

Where should I add the GlobalSign TXT record?

Add the GlobalSign TXT record at the DNS provider whose nameservers are authoritative for the domain. The registrar, web host and DNS provider can be separate services, so the presence of a DNS editor in a hosting panel does not mean that the zone there is live.

A typical failure is easy to reproduce: the domain is registered with one company, the website runs on a VPS, but nameservers point to another DNS service. A TXT record created in the VPS panel looks correct locally, yet no public resolver asks that DNS zone for the domain.

Find the active nameservers first:

dig NS example.com +short

On Windows, or on a system without dig:

nslookup -type=NS example.com

A response such as:

ns1.provider.example.
ns2.provider.example.

means that DNS changes must be made in the service responsible for those authoritative servers. A second zone for example.com in another hosting account has no effect on public DNS unless the domain is actually delegated to it.

For delegation problems or a recent nameserver migration, inspect the path from the root downward:

dig +trace example.com NS

This can expose a mismatch between the delegation stored at the parent zone and the DNS service you believe is active.

How do I add the GlobalSign TXT record in a DNS panel?

Create a TXT record in the authoritative zone, use the owner name required by the current GlobalSign verification request, and paste the DVC into Value without modifying it. The names of the fields vary between panels, but the DNS data behind them is the same.

Behind the control panel, a TXT record is conceptually similar to this zone-file entry:

example.com. 300 IN TXT "globalsign-domain-verification=AbCdEf1234567890"

This is an example of DNS structure, not a universal GlobalSign record that should be copied. In that line, example.com. is the owner, 300 is the TTL, TXT is the record type, and the quoted string is the TXT data. The actual owner and DVC must come from your verification request.

Panels where the root domain is entered as @

Many DNS editors use @ for the apex of the current zone. In the zone for example.com, @ normally represents example.com. Another panel may require the field to be blank or may display the full domain automatically.

Use @ only if that is how your DNS manager represents the required owner. Do not convert a GlobalSign instruction to @ just because another guide uses it.

Panels that append the zone automatically

If a panel expects a relative label and you enter:

app.example.com

it may create:

app.example.com.example.com

If the editor previews the complete hostname, inspect it before saving. Otherwise query both the intended name and the accidental name with dig.

Panels that accept a complete FQDN

Other DNS systems accept app.example.com exactly as entered. There is no universal syntax for the Name field across DNS panels. The final DNS response settles the question.

If the intended validation owner already has a CNAME, do not replace it blindly just to make room for TXT. Review how a CNAME record points to another domain and confirm which authorization location the current GlobalSign workflow allows.

How can I check the GlobalSign TXT record before clicking Verify?

Query the TXT record outside the DNS control panel before clicking Verify. A saved row in the editor proves only that the interface accepted the change. It does not prove that authoritative DNS returns the expected owner and DVC.

For the root domain:

dig TXT example.com

For compact output:

dig +short TXT example.com

For a subdomain:

dig TXT app.example.com

On Windows:

nslookup -type=TXT example.com

PowerShell can perform the same lookup:

Resolve-DnsName example.com -Type TXT

The expected answer contains the DVC from the current GlobalSign request, for example:

"globalsign-domain-verification=AbCdEf1234567890"

The sample value above is only illustrative. Compare the real response with the DVC from your order.

How to read the dig response

A short query is convenient when you only need the TXT strings:

$ dig +short TXT example.com
"v=spf1 include:_spf.example.net -all"
"globalsign-domain-verification=AbCdEf1234567890"

That output confirms that the queried owner currently returns the GlobalSign value. If the full DVC matches the active verification request, there is no reason to keep editing the TXT content.

For more context, use a normal query. The answer section may contain:

;; ANSWER SECTION:
example.com. 300 IN TXT "globalsign-domain-verification=AbCdEf1234567890"

Read the line from left to right: example.com. is the owner, 300 is the TTL, TXT is the record type, and the quoted part is the returned TXT data. A matching value at the wrong owner does not validate the intended name.

An empty answer is different from a successful TXT response. For example, status: NOERROR with no TXT in the Answer section means DNS could resolve the queried name or zone context but did not return the requested TXT record. NXDOMAIN means the queried DNS name does not exist according to that response. Both are different from a correct GlobalSign TXT answer.

Query the authoritative server directly

Ask the nameserver itself instead of relying only on a recursive cache:

dig @ns1.provider.example TXT example.com +norecurse

In a full dig response from a server authoritative for that name, the flags normally include aa, meaning Authoritative Answer. The important part is still the Answer section: it should contain the expected TXT owner and DVC.

If the authoritative server does not return the record, a stale public resolver is not the problem. Check the DNS zone, Host field and provider.

Check every authoritative nameserver

Do not stop after querying only ns1. If the domain has two authoritative servers, ask both:

dig @ns1.provider.example TXT example.com +short
dig @ns2.provider.example TXT example.com +short

If ns1 returns the DVC and ns2 does not, DNS is not consistent yet. An external validator can receive an answer from either authoritative server, so validation may remain Pending or behave inconsistently.

This can happen during an update, after a problem with zone synchronization, or when authoritative servers are not serving the same version of the zone. Do not resave a record that is already correct on one server. First find out why the authoritative answers disagree.

Compare recursive resolvers only when needed

Once all authoritative servers return the same correct DVC, compare public resolvers if necessary:

dig @1.1.1.1 TXT example.com
dig @8.8.8.8 TXT example.com

If authoritative DNS is correct but a recursive resolver still returns an older answer, caching is now a reasonable explanation. At this point, waiting makes sense. Before the authoritative checks, it was only a guess.

Why does GlobalSign still say the TXT record cannot be found?

If GlobalSign cannot find the TXT record, isolate the failure instead of repeatedly recreating the same value. Check the active DNS provider, record owner, exact DVC, authoritative consistency, DNS response status and the current GlobalSign validation request.

The TXT record was added to the wrong DNS provider

Run:

dig NS example.com +short

Compare the returned nameservers with the control panel where the TXT was created. If they belong to another DNS service, the edited zone is not authoritative.

The record exists at the wrong hostname

A DNS panel may append the zone automatically, or the pending validation may target a subdomain instead of the apex. Query the names separately:

dig TXT example.com
dig TXT app.example.com

If a duplicated FQDN is possible, test it:

dig TXT example.com.example.com

If the DVC appears there but not at example.com, the Name field was interpreted incorrectly. Waiting will not move the TXT record to the correct owner.

The TXT value was changed

Compare the DNS response with the current DVC character by character. Look for:

• a missing character;
• an extra space;
• a removed validation prefix;
• changed letter case;
• characters copied from surrounding documentation;
• a value from an older verification request.

Some GlobalSign DNS verification workflows treat the verification value as case-sensitive, so a token that merely looks similar may still fail validation.

Authoritative nameservers return different TXT values

A record can be correct on one authoritative server and absent on another:

$ dig @ns1.provider.example TXT example.com +short
"globalsign-domain-verification=AbCdEf1234567890"

$ dig @ns2.provider.example TXT example.com +short

In this state the zone is not ready for a reliable external check. GlobalSign may query either server. Check the DNS provider for an incomplete update, secondary-zone synchronization issue or other reason why the authoritative servers disagree.

Wait or retry verification only after the authoritative servers return the same expected DVC.

The authoritative servers are correct but a resolver is stale

Compare a direct authoritative query with a recursive one:

dig @ns1.provider.example TXT example.com
dig @1.1.1.1 TXT example.com

If every authoritative NS already returns the correct DVC but the recursive answer is old, stop editing DNS. Recreating the TXT record does not clear somebody else's cache and can make troubleshooting harder.

The DNS query returns SERVFAIL

SERVFAIL is not the same as “the TXT record does not exist.” It means the resolver could not successfully complete the DNS lookup. A broken authoritative server, delegation problem or DNSSEC validation failure can produce this result.

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12345

In that state, editing the GlobalSign DVC may not help because the DNS resolution path itself is failing. Check whether normal records for the domain resolve, compare responses from authoritative servers and, where DNSSEC is enabled, investigate the DNSSEC chain. Fix DNS resolution first. Then return to the GlobalSign check.

The DVC belongs to an expired or different validation request

GlobalSign verification codes are tied to a validation request rather than permanently to a domain. Current GlobalSign guidance limits the DVC/DNS validation tag to 30 days. If an old order is being retried, confirm that the TXT value still belongs to the active request before spending time on DNS caching.

GlobalSign TXT verification: 5-minute diagnostic

1. Find authoritative nameservers with dig NS example.com +short.
2. Query the exact TXT owner required by the validation request.
3. Query every authoritative NS directly.
4. Make sure all authoritative servers return the same DVC.
5. Compare the DVC with the current GlobalSign request character by character.
6. Check the exact domain or SAN that remains Pending.
7. Look for a duplicated FQDN such as example.com.example.com.
8. If DNS returns SERVFAIL, fix DNS resolution before retrying DCV.
9. Confirm that the verification request is still current.
10. Only then click Verify again.

If these checks pass, there is no reason to keep recreating the TXT record.

How does GlobalSign TXT verification work for subdomains, SANs and wildcards?

For certificates containing several names, troubleshoot the specific SAN and authorization domain that GlobalSign currently asks you to validate. A TXT record that successfully validates one name does not automatically prove that every SAN in the order has passed DCV.

Check the SAN that is actually Pending

Consider an order with three names:

example.com      Approved
www.example.com  Approved
api.example.com  Pending

Do not modify the already working DNS validation for example.com just because the certificate order itself is not finished. Open the validation details for api.example.com and check the method, required owner and authorization location for that SAN.

This is a common diagnostic state: the certificate is still waiting, but only one name is waiting.

Higher-level authorization domains can exist in some workflows

Some GlobalSign API workflows support Authorization Domain Names at permitted parent levels. For a hostname such as a.b.c.example.com, a supported workflow may allow validation at one of the parent authorization domains instead of requiring a TXT record at every individual label.

That does not mean “always put the TXT at the root domain.” Use the authorization location accepted by the DVP or API workflow for the current request.

Multiple SANs need status checks, not guesswork

Do not confuse GlobalSign DCV with ACME DNS-01

A GlobalSign verification token and the ACME _acme-challenge TXT record used by services such as Let's Encrypt belong to different validation mechanisms. An existing _acme-challenge record does not mean that the GlobalSign DVC is present.

Query the owner GlobalSign expects and look for the current GlobalSign value specifically.

Can existing TXT records such as SPF or Google verification stay in DNS?

Yes. A DNS owner can have multiple TXT records, so a GlobalSign verification value can coexist with SPF, Google site verification, Microsoft verification and other TXT data.

Do not append the GlobalSign token to an SPF string. SPF syntax and certificate validation perform unrelated jobs, and the GlobalSign value should remain a separate TXT record.

A valid lookup can return several records:

"v=spf1 include:_spf.example.net -all"
"google-site-verification=abc123"
"globalsign-domain-verification=AbCdEf1234567890"

There is no conflict in that response. The records share the same owner but contain separate TXT values.

Deleting a working SPF or service-verification record to “make room” for GlobalSign can create a completely different problem. Add another TXT record and confirm the complete set with:

dig TXT example.com

A DNS server may also render one long TXT value as several quoted character strings. Formatting in command output can differ from the control panel, so compare the effective TXT data rather than assuming that every pair of quotes represents a separate configuration error.

What should I do after GlobalSign approves the domain?

When the required GlobalSign domain or SAN changes to Approved, DCV is finished for that validation. Do not keep troubleshooting the TXT record because the browser still shows an old certificate. Certificate issuance and TLS deployment are separate steps.

1. Confirm that every required domain or SAN has the expected validation status.
2. Complete any remaining certificate or organization validation required by the product.
3. Receive or retrieve the issued certificate.
4. Install it on the web server, load balancer, CDN or hosting panel that terminates TLS.
5. Check the certificate actually presented on port 443.

From Linux or macOS, inspect the TLS endpoint with:

openssl s_client -connect example.com:443 -servername example.com

Check the certificate subject or SANs, issuer and validity data returned by the endpoint. A browser certificate viewer or an external SSL checker can provide the same basic confirmation visually.

If GlobalSign says Approved while the browser still displays an old certificate, stop touching DNS. Look at certificate installation, virtual-host selection, SNI, CDN termination, load balancers and whether the service actually reloaded its TLS configuration.

Do not automatically delete the GlobalSign TXT record immediately after approval. Whether it can be removed depends on the certificate workflow, renewal process and any automation that may use DNS validation again. Finish the active issuance process and check the requirements of the system responsible for future renewals.

Once DVP says Approved, the DNS validation phase has done its job. The next useful test is the certificate actually served on port 443.