DirectAdmin DNS Management: Records, Nameservers and Pointing Your Domain

ProWebHosting does not sell domains, so every customer arrives with a domain registered somewhere else and the same first question: how do I connect it to my hosting? The answer is DNS. This guide explains the two ways to point a domain at your account, what each record type on the DNS Management page does, how to set up email authentication, and why changes take a while to show up.

Two ways to point a domain registered elsewhere

Your registrar (the company you bought the domain from) holds a setting called nameservers. Nameservers are the servers the internet asks when it wants to know where yourdomain.com lives. You can either hand that job to our nameservers, or keep it at the registrar and add records there manually. Both work. They differ in who is in control.

For most business sites, changing the nameservers is the simpler path. You do it once at the registrar, and from then on everything you set up in DirectAdmin, including the mail hostname, subdomains and the DKIM record, just works. We send you the nameserver names and your server IP address on WhatsApp when your account is created. If you are still deciding what a domain is versus what hosting is, start with domain vs hosting.

Choose the A record route when your DNS must stay where it is: for example, the domain is on a company-wide DNS service, or your email is with Google Workspace or Microsoft 365 and someone else manages those records. In that case add an A record for the bare domain and one for www, both pointing to the server IP we gave you. Leave the existing MX records alone.

The DNS Management page in DirectAdmin

Under Account Manager, click DNS Management. The page shows the zone for the selected domain as a table of records: the name, the type, the value and the time to live (TTL). When you add a domain to your account, DirectAdmin creates a working zone for you. Expect to see A records for the domain itself and for www, mail and ftp, NS records naming the nameservers, an MX record pointing email at mail.yourdomain.com, and a TXT record with the default SPF policy.

Remember the control rule from the previous section. Edits on this page only take effect if your domain is using our nameservers. If DNS is at the registrar, the page still shows records, but nobody on the internet is asking our server for them.

Record types you will actually use

The Add Record list is long, but a business website needs only a handful of types. Here is what each one does and when you would touch it.

One CNAME rule catches people out: a name that has a CNAME cannot have any other record. That is why the bare domain uses an A record rather than a CNAME, since it also needs MX and TXT records. Use CNAMEs on subdomains only.

Email authentication: SPF, DKIM and DMARC

If you send email from your domain, three TXT records decide whether Gmail and Outlook trust it or drop it into spam. All three live on the DNS Management page. When you use our nameservers, DirectAdmin creates SPF for you and adds DKIM when you enable it; when DNS is elsewhere, you copy each record across by hand.

SPF lists which servers are allowed to send mail for your domain. DirectAdmin creates a TXT record on the bare domain that looks like v=spf1 a mx ip4:your-server-ip ~all, which authorises the hosting server. If you also send through a newsletter service or Google Workspace, add their include: entry to the same record rather than creating a second SPF record. A domain must have exactly one.

DKIM signs every outgoing message with a private key on the server and publishes the matching public key in DNS so receivers can check the signature. In DirectAdmin, open E-mail Manager, then E-mail Accounts, and click Enable DKIM below the accounts table. DirectAdmin generates the key and adds a TXT record named x._domainkey to your zone. If your DNS is at the registrar, copy that TXT record there, otherwise mail goes out signed with a key nobody can verify, which is worse than no signature at all.

DMARC tells receivers what to do when SPF or DKIM fails and where to send reports. In the Evolution skin, click Add Record, choose TXT, and pick the DMARC preset; it creates a record named _dmarc. A safe starting policy is v=DMARC1; p=none; rua=mailto:you@yourdomain.com, which only reports. Tighten SPF to -all and move the policy to quarantine once the reports show that all your legitimate senders pass. For creating the mailboxes themselves, see DirectAdmin email accounts.

Propagation: why changes take time

Every DNS record carries a TTL, the number of seconds a resolver may keep the answer before asking again. DirectAdmin uses a default TTL of 3600, one hour. Your internet provider, Google Public DNS, your office router and your own laptop all cache answers up to that limit, so after you change a record some people see the new value at once and others see the old one for up to an hour. Nameserver changes at the registrar sit higher up the chain and commonly take several hours, occasionally up to a day or two, to reach everyone.

• Lower the TTL a day before a planned change. DNS Management has an Override TTL value setting at the bottom of the page that applies one TTL to the whole domain. Set it to 300, wait a day, make the change, then restore the default.
• Do not judge propagation from one computer. A public DNS checker that queries resolvers in several countries shows the real picture.
• Flush your own cache when testing. On Windows run ipconfig /flushdns; on macOS the resolver clears on a network reconnect. Or simply test from your phone on mobile data.
• Keep the old host live until propagation completes, so visitors who still get the old answer see a working site.

If you are moving a site to us, the safe order is: upload and test on our server first, then lower the TTL, then switch DNS, then issue the SSL certificate once the domain resolves here. Our migration guide walks through that timeline, and the Let's Encrypt SSL guide covers the certificate step.

Mistakes we fix most often

• Editing records in DirectAdmin while the nameservers still point to the registrar. The edits look saved but change nothing. Check the nameservers first.
• Pointing the bare domain but forgetting www, so yourdomain.com works and www.yourdomain.com does not, or the other way round.
• Leaving MX records pointing at the old host after moving, so the website is here but email is still delivered to a server you no longer pay for.
• Putting the domain behind a third-party proxy service before SSL is issued, which can stop the HTTP validation Let's Encrypt needs. Issue the certificate first, then enable the proxy.
• Adding a second SPF record instead of editing the existing one. Two SPF records cause every check to fail.

Frequently asked questions