Add TXT records from Services, click your hosting, open DNS Zone Editor. Choose the domain, click Add Record, set the type to TXT, enter the name and the value the service gave you, save. Propagation can take a few hours.
TXT records are just text attached to a name in your zone. They don't route traffic or email by themselves. They exist so other systems can look up a string and confirm something about your domain: that you own it, that a server is allowed to send mail for it, or that outgoing mail is cryptographically signed. The three cases below cover almost everything you'll ever add one for.
Domain verification (Google, Microsoft, and similar)
Services like Google Search Console, Microsoft 365, or Google Workspace ask you to prove you control the domain before they'll activate anything on it. The usual method is a TXT record: they give you a string like google-site-verification=abc123..., you add it as a TXT record on the root name (@), and their system checks for it.
- Name:
@(root domain) unless the instructions say otherwise. - Type:
TXT - Value: the exact string they gave you, pasted with no extra quotes or spaces.
Some services re-check the record periodically, so removing it later can deactivate the integration.
SPF: authorizing who can send mail for your domain
SPF (Sender Policy Framework) is a TXT record on the root name that lists which mail servers are allowed to send email claiming to be from your domain. Receiving servers check it to catch spoofed mail. A typical record looks like:
For domains hosted with us, SPF is configured automatically. If you add a second mail service later, for example Google Workspace alongside our hosting, you don't create a second TXT record: you merge both into one, combining theinclude: mechanisms the providers give you. Two separate SPF records is a common misconfiguration and it makes SPF validation unpredictable.
For the full breakdown of what SPF, DKIM, and the record types around them actually do, see DNS record types explained.
DKIM: signing outgoing mail
DKIM (DomainKeys Identified Mail) adds a digital signature to outgoing email, published as a TXT record so receiving servers can verify the mail wasn't altered in transit and really came from a server authorized for your domain. DKIM records live on a selector subdomain, not the root, something like:
Name: default._domainkey Type: TXT Value: v=DKIM1; k=rsa; p=MIGfMA0GCSq...
The selector name (default in that example, sometimes something else) and the exact key value come from whatever's generating the signature. For domains hosted with us, DKIM is configured automatically. If you're routing mail through Google Workspace or Microsoft 365 instead, you'll add their DKIM TXT record the same way, using the selector and key they provide in their admin console.
DMARC, the policy layer that tells receiving servers what to do when SPF or DKIM checks fail, ships as a default _dmarc TXT record set to monitoring only (v=DMARC1; p=none;). To enforce a policy, edit that record rather than adding a second one.
Formatting rules that cause failures
- Quoting: paste the value exactly as given. Don't add your own surrounding quotes; the editor handles that if it's needed.
- Length: DNS caps a single text string at 255 characters. Long DKIM keys get split into multiple quoted strings automatically by most systems. If you're pasting a pre-split value, keep the segments and quotes intact rather than merging them into one long string.
- One record per purpose: multiple TXT records on the same name for different services is fine (verification + SPF can coexist on
@), but never create two SPF records or two conflicting DKIM records on the same selector. - Trailing dots and spaces: a stray space at the end of a pasted value is a common reason verification fails. Check for it if a check doesn't pass after enough time has passed for propagation.
For the general editor walkthrough, including TTL and how changes propagate, see DNS records and how to manage them.
When to contact support
If a verification check keeps failing after you've confirmed the value matches exactly and enough time has passed for propagation, open a ticket from Support in the portal. A real person can pull the current zone and check exactly what's published against what the third-party service expects, which is faster than guessing at formatting issues from your end alone.