DNS A, AAAA, CNAME, MX and TXT records: examples of when to use each one
Published on 2026-10-26 by frfrand
Types of DNS records and common errors when connecting web and email
They give you a domain and someone says "put the IP in the DNS". That's enough for some sites, but email, service validation, and subdomains need different records. Understanding five types saves you many unnecessary changes.
Let's turn it into a procedure you can use on a real VPS. The goal is to understand why it works, how to test it, and what problem appears if one part is misconfigured.
What A, AAAA, CNAME, MX, and TXT mean and when you need them
A points a name to IPv4; AAAA to IPv6; CNAME creates a DNS alias for another name under compatible conditions; MX indicates mail receiving servers; TXT carries textual information such as verifications, SPF, DKIM, or DMARC according to its format.
Before changing anything in production, note the current state: IP, domain, port, affected service, and time of the last deploy. An isolated change is easy to verify; five simultaneous changes make it harder to reconstruct what happened.
Configuration or example commands
dig ejemplo.com A +short
dig ejemplo.com AAAA +short
dig www.ejemplo.com CNAME +short
dig ejemplo.com MX +short
dig ejemplo.com TXT +short
# DMARC suele consultarse como TXT
dig _dmarc.ejemplo.com TXT +shortDomains, IPs, paths, and names are illustrative. Do not copy an entire configuration over the current one without comparing first. In examples that include ports or firewall, make sure to keep administrative access.
How I would do it step by step
- Preparation. To publish a website on a VPS, configure A or AAAA records to addresses that actually serve the site.
- Step 2. If you create
wwwas a CNAME, check restrictions and how your DNS provider supports it. - Step 3. For email, configure MX records to appropriate hosts and verify reputation, SPF, DKIM, and DMARC.
- Step 4. Do not create two incompatible records for the same name just because a tutorial did it.
- Verification. Verify the DNS response and then test the actual service: resolution does not guarantee that HTTP or SMTP works.
When finished, verify actual operation from another connection. For example, for an API it is not enough to open the browser: run a read request, a write to a test database, and check the process logs.
Example of a real project
An agency connects api.cliente.com to FastAPI on ArduMaker and keeps Google Workspace email. It only needs to change the API record; touching MX without reason can cut off the client's email.
The lesson is simple: an infrastructure configuration does not live isolated from the application. The frontend, the server, the database, and the workers connect, so measuring where the failure starts is more useful than restarting everything.
The error I would avoid
A CNAME at the domain apex has standard DNS restrictions, although some providers offer flattening or their own aliases. Do not assume that every DNS interface implements the same thing.
When working with client servers, keep a backup or rollback procedure before changes that affect data, network, or certificates. And if you don't know what permissions an operation requires, avoid running it as root just to stop errors from showing.
How does it relate to ArduMaker?
When managing domains and VPS from ArduMaker, differentiate web records from email records. Publishing an API should not imply altering MX configurations of existing services.
In a typical case you can create a VPS for the application, deploy from Git, associate an HTTPS domain, and manage the backend and necessary databases. The tools help centralize operations, but you need to understand which port and process fulfills each function.
Questions that arise when you try it
How do I know if the failure is DNS or the service? Check resolution first, then connection to the port, and finally the application response. That order avoids confusing different problems.
Can I expose a database to make it easier to maintain? Better design private access or authenticated tunnels when possible. Exposing a port does not replace engine permissions or the firewall.
What should I document? The expected configuration, how it is verified, and how to return to the previous state. That document helps you more than a list of commands without context.
References
In summary: a good network or server configuration is one that you can explain, verify, and recover when something fails.