All postsGUIDE · 8 MIN READ

DNS records explained: A, CNAME, MX and TXT for your .az or .com domain.

R
Rivervo · Rivervo
·
November 13, 2026
A · MX
CNAME · TXT

Every time someone opens your website or sends you a letter, their computer first asks DNS a question: where does this name live? The answers come from a small set of records you control. Get them right and the website opens, mail arrives and nobody notices DNS at all. Get one wrong and the site shows someone else's page or letters bounce.

The good news: a business domain usually needs only a handful of records, and they work the same way for .az, .com and any other zone. This guide explains them in plain words and shows where to edit them.

How DNS works in one paragraph

A domain name like yourcompany.az is turned into addresses by a chain of servers. Your domain's nameservers are the authoritative source: they hold your records. Everyone else — the internet providers' resolvers, the big public resolvers — asks the nameservers and then caches the answer for a while. That is all you need to understand most DNS behaviour: you edit records on the nameservers, and the rest of the world sees the change when its cached copy expires.

Nameservers: who holds your records

The registry for each zone (.az, .com and so on) only stores one thing about your domain that matters here: which nameservers are authoritative for it. Those nameservers can belong to:

  • your hosting — at Rivervo, ns1.rivervo.com and ns2.rivervo.com;
  • your registrar's DNS service;
  • a separate DNS provider, such as Cloudflare.

You can only edit records where the nameservers point. A record added at the registrar does nothing if the domain uses your host's nameservers, and the other way round. At Rivervo, check Domains → your domain → Where it points.

The records you will actually use

A — the website's address

Maps a name to an IPv4 address. The record that makes yourcompany.az open your website.

Name: @     Type: A    Value: 203.0.113.10
Name: www   Type: A    Value: 203.0.113.10

@ means the domain itself. www is a separate name and needs its own record (or a CNAME, below). AAAA is the same for IPv6.

CNAME — an alias for another name

Points one name to another name instead of an address. Useful when the target's address can change and the service gives you a host name to point at.

Name: shop   Type: CNAME   Value: yourstore.example-shop.com

A CNAME cannot be used on the root (@) of the domain, and a name with a CNAME cannot have other records. Use A or AAAA on the root.

MX — where your mail goes

Tells other mail servers where to deliver letters for your domain. Each MX has a priority: the lowest number is tried first.

Name: @   Type: MX   Priority: 10   Value: mx.your-mail-service.example

Only the mail service you actually use should be in MX. If old MX records from a previous provider remain, some letters will go there.

TXT — text for verification and email security

Free text attached to a name. TXT records hold SPF, DKIM and DMARC for email and the verification codes that services such as search consoles ask you to publish.

Name: @        Type: TXT   Value: "v=spf1 +a +mx ~all"
Name: _dmarc   Type: TXT   Value: "v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.az"

What SPF, DKIM and DMARC do is explained in our guide SPF, DKIM and DMARC.

Less common, but good to know

  • SRV — locates a service on a given port (some chat and calling systems use it).
  • CAA — lists which certificate authorities may issue SSL certificates for your domain.
  • NS — delegates a subdomain to other nameservers.

Subdomains

A subdomain is any name in front of your domain: shop.yourcompany.az, crm.yourcompany.az, mail.yourcompany.az. It needs no registration and costs nothing — it is just another record in the same zone:

  • an A record with the subdomain's name when it should open a server you know the address of;
  • a CNAME when a service gives you a host name to point at (a shop builder, a help desk, a landing page tool);
  • an NS record only when you want to hand the whole subdomain to other nameservers.

Subdomains are independent: changing shop does not touch the main website or the mail. That makes them a safe way to try a new service under your company's name.

A typical business domain

NameTypeWhat it does
@AWebsite
wwwA or CNAMEWebsite with www
@MXIncoming mail
@TXT (SPF)Who may send mail as you
selector._domainkeyTXT (DKIM)Signature key for your mail
_dmarcTXT (DMARC)Policy for failed mail

That is all most companies ever need. Everything else is added when a specific service asks for it.

TTL: why changes are not instant

Every record has a TTL (time to live): how long others may keep a cached copy, in seconds. With a TTL of 3600, a resolver that looked up your record may keep showing the old value for up to an hour after you change it.

Plan changes with that in mind:

  1. A day before an important change (moving the website, switching mail), lower the TTL of the records you will change to 300 seconds (5 minutes).
  2. Wait at least the old TTL so the caches pick up the short one.
  3. Make the change. The old value disappears from caches within minutes.
  4. When everything works, raise the TTL back to an hour or more.

More on this in why DNS takes time.

Where to edit records at Rivervo

It depends on where your domain's nameservers point:

  • Rivervo nameservers and a Rivervo website — the records live on your hosting: Websites → your site → DNS zone. Add a record, choose the type (A, AAAA, CNAME, MX, TXT, SRV, CAA), the name and the value; edit or delete existing ones. Records marked Managed by us (for mail and SSL) are kept up to date for you. Changes are live on our nameservers right away.
  • Domain registered at Rivervo, using the registrar's DNS — Domains → your domain → DNS records → Add record. Supported types: A, AAAA, CNAME, MX, TXT, NS, SRV. TTL from 5 minutes to 1 day, 1 hour by default. Records can be edited only while the domain is active.
  • Another DNS provider — edit the records there. Rivervo gives you the values to copy.

The full reference is in the help article Managing DNS records.

Pointing a domain at a website and email without downtime

The safe order when you move to a new host:

  1. Set up the website on the new host and check it before anyone sees it.
  2. Lower the TTL a day before.
  3. Change the website's A record (or switch the nameservers) — see pointing a domain to hosting.
  4. If the mail moves too, copy the old mail first and change MX last.
  5. Keep the old hosting running for a few days until you're sure every visitor and every letter arrives at the new place.

If you would rather not do it yourself, free migration moves the site for you: our engineer copies the DNS records too, so mail and subdomains keep working after the switch.

Common mistakes

  • Editing records where the nameservers don't point. Check where the domain points first.
  • A trailing dot or a missing one. Some DNS editors want full names with a final dot (mail.example.com.), others add the domain themselves. Follow the hint next to the field.
  • Two SPF records. Merge them into one.
  • A CNAME on the root. Use an A record.
  • Old MX records left behind. Remove the previous provider's MX after switching mail.
  • Changing everything at once with a long TTL. Lower the TTL first.

Common questions

Does DNS work differently for .az domains? No. Records, nameservers and TTL work the same way for .az, .com and every other zone. Only the registration rules differ from zone to zone.

How long does a DNS change take? On our nameservers it is live at once. Others see it when their cached copy expires — minutes with a short TTL, up to a day with a long one.

Can I keep my domain at another registrar and host the website at Rivervo? Yes. Point the domain at Rivervo with nameservers or an A record; the registration can stay where it is. You can also transfer the domain later.

What does "Managed by us" mean in the DNS zone? Those records are created and updated by the panel for your mail and SSL certificates. Leave them as they are.

How do I check what the world sees? From a terminal: dig +short yourcompany.az @1.1.1.1 asks a public resolver directly. Compare with @8.8.8.8 to see whether caches have updated.