Verify domain ownership through DNS by obtaining the exact record from the service requesting proof, adding it in the authoritative DNS zone and checking the service’s verification result. Keep the record type, name and value distinct. Preserve unrelated records and existing verification tokens, and retain the evidence needed to maintain ownership access afterwards.
Begin with the service and property being verified. Identify the intended organisation, account owner and domain scope before preparing a change. Website hosting, domain registration and authoritative DNS may be managed through different arrangements, so confirm where the actual zone is maintained rather than choosing the most familiar dashboard.
What authority does the verification grant?
Google’s ownership-verification guide describes one concrete service. A verified Search Console owner has the highest permission level. DNS-provider verification is the documented route for a Domain property. Review the intended access decision with the responsible domain owner before adding another verification route.
Search Console can have multiple verified owners. Existing owners’ verification tokens should not be overwritten. Inspect the current records and ownership arrangement so the proposed addition does not silently disrupt someone else’s legitimate access.
Search Console periodically checks the verification token’s presence and validity. Keep the verification record in the domain-maintenance inventory with its purpose and owner. A successful initial check should lead to an understood maintenance decision, especially when DNS management later moves to another provider.
Treat removal as a separate access decision. Ask the responsible owner to identify which service or account depends on a record before changing it. A token that looks unfamiliar may still be supporting an intended verification relationship.
Which DNS record should be added?
Manual DNS verification uses a name/value pair supplied by Search Console. Use the current instructions from the service and property you are actually verifying. Record the type, name and value exactly as provided, then follow the DNS provider’s documented way of entering them.
Cloudflare’s record-type reference helps distinguish common records. A and AAAA records map names to IP addresses. CNAME records map a domain name to another canonical name. Do not infer the intended verification record from the fact that the domain already has another kind of record at a familiar name.
NS records identify the server used for authoritative DNS. Confirm the zone in which the requested addition belongs and who controls it. A record saved in an inactive or unrelated zone will not answer the same question as one served by the intended authoritative arrangement.
TTL controls how long resolvers cache a response before revalidation. Retain the relevant record and lookup context when investigating visibility, while using the service’s own instructions for any verification timing. This guide invents no universal waiting period for every provider and configuration.
| Verification item | What to retain | Check to perform |
|---|---|---|
| Requested service and property | Intended domain scope and account owner | Access decision matches the actual request |
| Authoritative zone | Confirmed DNS management route | Addition is made in the zone that serves the name |
| Record specification | Exact type, name and value | Saved entry matches the service’s instruction |
| Existing records | Relevant baseline before the addition | Unrelated records and owners’ tokens remain intact |
| Verification outcome | Service result and observation context | Service recognises the intended proof |
This original worksheet gives the administrator and domain owner a shared record of the change. Use placeholders in public examples and keep account access details in the approved private operational material.
How should the change be checked?
Review the saved record against the request before attempting verification. DNS interfaces may present names differently, so use the provider’s documented interpretation of the name field. Inspect the resulting fully qualified record where the arrangement provides that view.
Then check the relevant DNS answer through an appropriate lookup and record the queried name, type and returned value. Keep that observation separate from the service’s verification result. A visible record is useful evidence, while the service still needs to accept the proof for its particular property and account context.
Complete the service’s verification step through the authorised account route and retain the observed result. If it fails, compare the request, saved entry and lookup evidence before changing unrelated records. Identify which part of the chain differs from expectation and assign that question to the responsible owner.
Avoid replacing an entire record set to add a verification entry. Choose the provider’s scoped supported operation and review its effect. Where a tool replaces a full zone, preserve and review the complete intended set before considering that different action.
What should be reviewed during a DNS move?
Include verification records in the migration inventory alongside the other records the domain needs. Identify their purpose, service and owner, then decide which must remain present in the new authoritative arrangement. Keep an unexplained record as a review question rather than discarding it through guesswork.
Check access after the approved migration using the relevant service route. Record the new DNS evidence and any change to verification status. Assign responsibility for resolving a discrepancy so the domain owner does not discover a lost verification relationship only when they next need the service.
Keep the ownership review proportionate to the organisation’s actual account structure. The technical record should make it clear who can explain each verification entry and who authorises changes, without copying credentials into a shared DNS spreadsheet.
Original token-addition and verification exercise
Prepare a fictional domain and an approved test property in a suitable non-production arrangement. Use the service-issued test record and retain its exact specification privately. The exercise follows the addition, lookup and service result while preserving the baseline records.
First, identify the authoritative zone and intended account owner. Review the existing relevant records and write the proposed addition. Have another reviewer compare the planned type, name and value with the service’s current instruction.
Next, make only the authorised test addition and inspect the saved result. Query the intended record and retain the observation, then carry out the service’s verification step through the approved account. Record any difference between DNS visibility and the service’s outcome.
Finally, review the purpose and maintenance owner of the new record. Ask how it would be carried into a later DNS move and how removal would be authorised. Retain the worksheet so the successful test becomes an understandable access arrangement rather than an unexplained token.
Ask another authorised colleague to compare the final record with the original request. Have them identify the service and purpose from the retained worksheet. This provides a useful handover check before the administrator closes the task.
For related work, see domains and hosting. Get started with the requested verification record and your authoritative DNS arrangement.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.