DNS

DNS (Domain Name System) is the service that translates human-readable domain names (like itiden.se) into IP addresses that computers use to communicate. Correct DNS configuration is essential for making websites accessible, sending and receiving email, and integrating external services.

DNS Records

DNS is built on different types of records. Each record type has a specific purpose, such as pointing a domain to a server, routing email, or verifying ownership with a third-party service. Understanding the most common record types is essential for managing domains.

A and AAAA Records

A records and AAAA records map a domain name to an IP address.

• An A record points to an IPv4 address.

• An AAAA record points to an IPv6 address.

Examples:

• example.com. – the domain name, fully qualified with a trailing dot.

• A / AAAA – the record type (IPv4 vs IPv6).

• 203.0.113.42 / 2001:db8::1234 – the IP address of the server hosting the site or service.

The trailing dot ensures the domain is treated as fully qualified. Without it, some DNS tools may treat the value as relative, which could lead to errors.

CNAME Record

A CNAME record (Canonical Name) makes one domain an alias of another. Instead of pointing directly to an IP, it points to another domain name, which in turn resolves to an IP.

This is common when connecting a custom domain to a cloud provider. For example, a site deployed on Vercel might get the URL:

Some DNS providers require the trailing dot (my-app.vercel.app.) to mark the domain as fully qualified, while others add it automatically. It is recommended to always include the trailing dot when writing records.

TXT Records

A TXT record stores arbitrary text data in DNS. Originally designed for simple human-readable notes, TXT records are now widely used by services to verify domain ownership and publish security-related information.

Domain verification example:

TXT records are often essential for enabling third-party services and improving security. Without them, services may not trust that you own the domain, and mail servers may not trust that your emails are genuine — often resulting in your messages going to spam.

TTL (Time to Live)

Every DNS record has a TTL value, which defines how long resolvers (like your ISP’s DNS or a browser cache) should store the record before checking again.

Here 3600 means one hour. If you change this record, it can take up to an hour before clients refresh and see the update.

• Low TTL (e.g. 60–300 seconds) is useful when making changes (such as moving a site to a new server).

• Higher TTL (e.g. 3600–86400 seconds) reduces DNS query traffic and improves performance but slows down how fast changes propagate.

Best practice is to use a longer TTL for stable records and temporarily lower it before planned migrations or updates.

Email Setup with DNS

To send and receive email reliably, several DNS records must be configured. The exact values depend on which email provider or service you use, but the record types are always the same: MX, SPF, DKIM, and DMARC.

The reason these records are required is to prevent abuse. Without them, any mail server could send messages pretending to come from your domain (a technique called spoofing). By publishing DNS records, you prove ownership of your domain and authorize specific servers or services to send mail on your behalf.

If these records are missing or misconfigured, receiving mail servers are much more likely to distrust your messages. This usually results in them being placed in the spam folder or, in some cases, rejected entirely. Configuring DNS correctly is therefore not only a security measure but also essential for email deliverability.

MX Records – Receiving Email

MX records tell other mail servers where to deliver messages for your domain.

Example: Google Workspace (Gmail):

This ensures email to @example.com is delivered to Google’s mail servers.

SPF Records – Authorizing Senders

SPF (Sender Policy Framework) is a TXT record that lists which servers are allowed to send mail for your domain. Receiving servers use this record to verify that the sender is legitimate. If an email comes from a server not listed in SPF, it will likely be flagged as spam or rejected.

Example: Google Workspace (Gmail only):

This allows Google’s mail servers to send email for @example.com. Any other server is treated as unauthorized.

Example: Google Workspace + Mailgun:

This authorizes both Google’s servers (for normal inbox mail) and Mailgun’s servers (often used for transactional emails like password resets or notifications) to send mail on behalf of example.com.

Using multiple include: statements is common when combining providers. It’s important to only add the services you actually use, adding too many weakens security.

DKIM Records – Verifying Integrity

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to your outgoing messages. Each email is signed with a private key, and the public key is published in DNS as a TXT record. Receiving mail servers use the public key to verify that the message was not altered and that it truly came from an authorized server.

Example: Google Workspace (Gmail DKIM):

Example: Mailgun DKIM:

The part before _domainkey (e.g. google, krs) is called the selector. Providers use different selectors, and you can have multiple DKIM records for the same domain if needed.

Without DKIM, receiving servers may still accept mail, but it is far more likely to be flagged as spam.

DMARC Records – Policy for Suspicious Mail

DMARC (Domain-based Message Authentication, Reporting & Conformance) builds on SPF and DKIM. It tells receiving servers what to do if an email fails both SPF and DKIM checks. It also enables reporting so you can monitor misuse of your domain.

Example (basic policy):

1. v=DMARC1 – version.

2. p=quarantine – policy (what to do with failing mail). Options are:

   • none – monitor only, take no action.

   • quarantine – mark as spam.

   • reject – block mail outright.

3. rua=mailto:reports@example.com – where to send aggregate reports.

Why This Matters

Together, SPF, DKIM, and DMARC ensure that:

• Only authorized servers can send mail for your domain (SPF).

• Emails can be verified as genuine and not tampered with (DKIM).

• Suspicious mail is handled according to your policy (DMARC).

If these records are missing or misconfigured, your emails will often land in spam folders or be rejected entirely. When configured correctly, they protect your brand from spoofing and improve the chance that legitimate mail reaches inboxes.