Updating DNS Records

Once your domain points at Traxio, its DNS records are managed in DirectAdmin. You can add and edit them yourself — verifying Google Search Console, connecting third-party email, or pointing a subdomain elsewhere are all self-service.

Opening the DNS editor

In DirectAdmin, go to Account Manager → DNS Management and select your domain. You will see the existing records, which were created automatically when the account was provisioned.

The record types you will actually use

• A — points a name at an IPv4 address. This is what sends your domain to your web server.
• CNAME — points one name at another name. Commonly used for www, and for verification records some services require.
• MX — where email for the domain should be delivered. Has a priority number; lower is tried first.
• TXT — arbitrary text. Used for domain verification and for SPF and DKIM.
• SRV — service location records, occasionally needed by chat and VoIP services.

Adding a record

1. Choose the record type.
2. Enter the name. Use @ for the domain itself, or just the subdomain part — enter blog, not blog.yourdomain.co.uk. Entering the full domain is the most common mistake here and produces blog.yourdomain.co.uk.yourdomain.co.uk.
3. Enter the value: an IP for A records, a hostname for CNAME, the text string for TXT.
4. Leave TTL at the default unless you have a reason to change it.
5. Save.

Two records worth adding for email

If you send any email from your domain — including forum notifications and WordPress password resets — these two records substantially improve whether it arrives.

SPF is a TXT record on @ declaring which servers may send as your domain. A basic one looks like v=spf1 a mx ~all. Only ever have one SPF record; multiple records invalidate each other, which is a very common misconfiguration.

DKIM cryptographically signs outgoing mail. DirectAdmin can generate the key pair for you and add the record automatically — look for the DKIM option under Email settings.

Propagation and TTL

Changes are not instant. The TTL value on a record tells other servers how long to cache it, so a record with a 14400 TTL can take up to four hours to update everywhere. If you know a change is coming, lower the TTL a day in advance and raise it again afterwards.

Before you change anything

Screenshot the existing records. DNS mistakes take your website or email offline, and the fastest recovery is putting back exactly what was there. This takes ten seconds and saves a bad afternoon.

Not sure whether a record is right? Post it in the community forum before saving — someone will spot the problem faster than you will find it after the fact.

Unsure what each record type actually does? DNS explained without the jargon covers A, CNAME, MX and TXT records through one honest analogy.

A worked example: verifying Google Search Console

Domain verification is the most common reason people first open the DNS editor, so here is the full round trip using Search Console as the example — other services (Microsoft, analytics tools, email providers) follow the identical pattern:

1. In Search Console, add your domain as a Domain property and copy the TXT value it gives you — a string beginning google-site-verification=.
2. In the DirectAdmin DNS editor, add a TXT record with name @ and the copied string as the value. Do not add quotes yourself; the editor handles formatting.
3. Save, wait a few minutes, then click Verify back in Search Console. If it fails, wait longer — verification checks are subject to the same caching as everything else in DNS — and confirm you pasted the whole string.

Verification TXT records are safe to leave in place permanently, and most services expect you to — some re-check periodically.

Understanding the records that are already there

The zone created at provisioning is a working default, and knowing what each part does tells you what is safe to touch:

• A records for @ and subdomains, pointing at your server IP — these make the website work. Leave them unless you are deliberately pointing something elsewhere.
• A CNAME or A record for www — makes the www version resolve. Leave it.
• An MX record pointing at the server — delivers your email to the mailboxes here. Change it only if your email lives with another provider.
• NS records — declare the authoritative nameservers. Do not edit these; wrong values here break the entire zone.
• TXT records for SPF (and DKIM once enabled) — email authentication. Edit the SPF record to add services; never add a second SPF record.

The general principle: adding records is low-risk; editing or deleting the defaults is where mistakes take sites offline — hence the screenshot advice above.

Frequently asked questions

How long until my change takes effect?

Up to the TTL of the record you changed — a 14400 TTL means up to four hours for cached answers to expire, though many resolvers pick it up sooner. New records (with nothing cached against the name) often work within minutes.

Can I safely delete a record I do not recognise?

Assume not, until identified. Unrecognised TXT records are usually verifications a service depends on; unrecognised CNAMEs often belong to a connected tool. Search the value, or post it in the community forum — deleting first and asking later is how email and integrations quietly break.

Why is my new subdomain showing an error?

An A or CNAME record makes the name resolve; the web server also needs to know what to serve for it. If you want the subdomain to host content on this account, create it as a subdomain in DirectAdmin (which adds both the DNS and the web configuration) rather than adding a bare DNS record alone.

I edited a record wrongly and my site went down — fastest fix?

Restore the previous value from your screenshot — recovery is exactly as fast as the caches that saw the bad value expire, which is another argument for modest TTLs. If you have no record of the old value, the defaults are recoverable: an A record for @ and www pointing at your server IP (shown in DirectAdmin) restores the website; the forum can help reconstruct the rest.