DNS Records Explained: A, AAAA, CNAME, MX, and TXT

DNS maps names to services and publishes verification or email policy. Similar-looking records serve different purposes, and changes can affect websites, mail, APIs, and certificates.

Quick answer

Use A for IPv4 addresses, AAAA for IPv6, CNAME for an alias to another hostname where allowed, MX for inbound mail routing, and TXT for verification or policies such as SPF, DKIM, and DMARC.

Why this matters

DNS is distributed and cached. Removing an old record too early or creating conflicting records can produce intermittent failures that vary by resolver.

Step-by-step

1. Inventory current records

Export or record names, types, values, TTLs, and the service owner before changing anything.

2. Choose the correct record type

Follow the destination service documentation and understand whether it expects an IP, hostname, mail exchanger, or TXT value.

3. Prepare the transition

Lower TTL ahead of planned cutovers when useful, but remember already cached answers remain until their original TTL expires.

4. Apply a minimal change

Avoid deleting unrelated verification or mail records. Preserve exact DKIM names and quoted values as instructed.

5. Verify from multiple resolvers

Check authoritative responses, public recursive DNS, application behavior, mail routing, and TLS issuance.

What to verify before you finish

• IPv4 and IPv6 both reach valid services if published.
• Mail MX targets resolve and accept intended traffic.
• Only one SPF policy exists per hostname.
• Old records are removed after the rollback window.

Common mistakes to avoid

• Using CNAME at a name where other records are required.
• Publishing AAAA without working IPv6 service.
• Replacing all TXT records during verification.
• Expecting propagation to be instantaneous.

Where Seedarc fits

Seedarc Web Hosting is the managed path for websites that need a simpler publishing workflow, while Seedarc VPS Hosting is available when the application needs operating-system control. The useful decision is not whether a feature sounds impressive, but whether it reduces the work and risk involved in the exact workload you are running.

Frequently asked questions

Is this safe to change on a live service?

Yes, but change one record set at a time, preserve a rollback value, and understand existing TTLs before cutover.

What should I do if the change fails?

Return to the last known-good configuration, read the earliest relevant error in the logs, and change one variable at a time. If the issue is specific to the hosting layer, collect timestamps and the affected service ID before contacting Seedarc support.

Next step

Maintain a DNS inventory that explains which Seedarc or third-party service owns every record. Review Seedarc Web Hosting when you are ready to apply the workflow on Seedarc.