DMARC, short for Domain-based Message Authentication, Reporting and Conformance, is one of the most important technical concepts in email deliverability and domain protection. It is also one of the most misunderstood. In practice, DMARC is not “magic” and it is not just another random DNS detail. It is a policy published in DNS that tells receiving mail servers what to do with messages that claim to come from your domain but do not pass authentication checks in the right relationship to the visible From domain.

If you send newsletters, direct mail, automated campaigns, transactional messages or ordinary company email from your own domain, sooner or later DMARC becomes very hard to ignore. It helps receiving systems recognise whether an email really matches the domain identity it presents to the user. It also gives domain owners visibility through reports, which makes it easier to see who is really sending on behalf of the domain and where weak spots still exist in the sending setup.

What DMARC is and why people talk about it so much

Interest in DMARC has grown because SPF and DKIM alone are not always enough. You can have both configured and still leave room for confusion if the authenticated domain does not properly match the domain the user sees in the From field.

This is where DMARC brings order. It does not only ask whether a server was allowed to send a message or whether a message was signed. It also asks whether the authentication result actually makes sense in relation to the domain identity shown to the recipient.

That matters mainly because of spoofing, phishing and brand impersonation. If someone tries to send forged email in your domain’s name, DMARC is one of the main ways to tell receiving servers not to treat those messages as normal mail.

In practical terms, DMARC is especially important for:

• companies sending newsletters and marketing campaigns,
• e-commerce businesses using transactional and automated email,
• brands that want to reduce the risk of domain abuse,
• organisations working on deliverability and sender reputation,
• senders with larger mail volumes who need to meet stricter mailbox-provider expectations.

How DMARC works in principle

DMARC builds on the results of SPF and DKIM, but adds one more condition that is easy to underestimate – alignment. This is the key difference between a simplified explanation and how DMARC really works.

It does not merely check whether SPF or DKIM passed in some technical sense. It checks whether the domain validated by SPF or DKIM is aligned with the domain shown in the From header that the recipient actually sees.

In simplified form, the process looks like this:

1. the message arrives at the receiving mail server,
2. the server evaluates SPF and DKIM,
3. DMARC checks whether the SPF-authenticated or DKIM-authenticated domain aligns with the domain in the From field,
4. if at least one aligned result passes, the message can pass DMARC,
5. if not, the receiver looks at the DMARC record of the domain owner to decide how the message should be handled.

This is exactly why DMARC helps against domain impersonation. It is not enough for a message to be signed by some domain or sent from some technically allowed server. The authenticated identity also has to make sense in relation to the visible sender domain.

What DMARC depends on – SPF, DKIM and alignment

DMARC does not stand on its own. It is a layer built on top of SPF and DKIM. If you have not clearly defined which servers may send on behalf of your domain, or if your messages are not being signed correctly, DMARC has very little solid information to work with.

A useful way to think about the relationship is this:

• SPF says which servers are allowed to send email for your domain,
• DKIM proves that the message was signed by an authorised domain and was not materially altered in transit,
• DMARC checks whether the authenticated result from SPF or DKIM aligns with the domain in the visible From field and defines what should happen if it does not.

In practice, alignment is where many organisations get surprised. A message may “pass something” technically and still fail DMARC because the relationship between the authenticated domain and the visible sender domain does not line up properly.

That is one of the main reasons why DMARC deployments sometimes fail on the first attempt – not because DMARC is inherently mysterious, but because it reveals hidden inconsistencies in the sending infrastructure.

Where DMARC is published and what it looks like

DMARC is published in DNS as a TXT record, usually on the _dmarc subdomain of the main sending domain.

A simple example looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com;

It may look short, but this record is doing several important things at once:

• it declares that the record is a DMARC policy,
• it sets the policy level,
• it tells receiving systems where aggregate reports should be sent,
• it can control how subdomains are treated,
• it can define how strict alignment should be.

That is why copying a DMARC record from somewhere else without understanding it is risky. A badly designed DMARC record may not only fail to help. It can also start blocking legitimate messages from tools or services you forgot were sending on behalf of your domain.

What the policies p=none, p=quarantine and p=reject really mean

This is one of the most practical parts of the whole topic. The p= value defines what the receiver should do with messages that fail DMARC.

• p=none – monitor only. The receiver is asked not to change message handling because of DMARC failure. This is typically used at the start of deployment so you can collect reports and see what your domain is actually doing.
• p=quarantine – treat failing messages as suspicious. In practice, that often means sending them to spam or another lower-trust location rather than treating them as clean mail.
• p=reject – ask the receiving server to reject the message outright if it fails DMARC.

These policies are often best understood as stages of maturity rather than as one quick switch. Many teams begin with p=none, use reports to clean up forgotten senders and alignment problems, move to p=quarantine when the setup is more stable, and only later go to p=reject.

Why reporting is such an important part of DMARC

One of DMARC’s strongest benefits is not only enforcement, but visibility. The record can ask for reports, most often through the rua tag for aggregate reporting and, where supported, ruf for failure-oriented reporting.

That matters because many organisations do not actually know every service that sends email using their domain. Marketing platforms, CRM tools, old servers, ticketing tools, billing systems and third-party apps often accumulate over time.

DMARC reports help uncover that reality. They can show which senders are authenticating properly, which are failing, and which sources may be spoofing or using the domain without correct setup.

In practice, this makes DMARC much more than a blocking mechanism. It becomes a way to audit your real sending landscape and identify where email authentication still needs work.

What else can be configured in a DMARC record

Beyond the core policy, DMARC records can include additional tags that shape how the policy behaves.

• rua – where aggregate reports should be sent.
• ruf – where failure reports should be sent, if receivers support them.
• sp – a policy specifically for subdomains.
• pct – the percentage of failing mail the policy should apply to, useful for staged rollouts.
• adkim and aspf – whether DKIM and SPF alignment should be evaluated in relaxed or strict mode.

These details are part of what makes DMARC flexible. But they also make it possible to create a record that looks fine on the surface while behaving differently than intended. That is another reason why DMARC is best implemented with a clear understanding of what each tag is for.

Why DMARC does not solve everything by itself

DMARC is powerful, but it is not a universal email fix.

It does not guarantee inbox placement. It does not fix poor sender reputation. It does not repair broken list hygiene. It does not automatically make recipients trust your emails. And it does not remove every edge case in complex mail flows such as forwarding, mailing lists or older third-party systems that break alignment.

It is better to think of DMARC as a domain identity and anti-spoofing layer. That is already extremely valuable, but it is still only one part of the wider email setup.

Where DMARC matters most in practice

DMARC becomes especially important when a domain is used for:

• marketing and newsletter sending,
• transactional email from e-commerce or SaaS systems,
• company mailboxes and day-to-day business communication,
• brand protection against spoofing and phishing,
• compliance with stricter expectations from large mailbox providers.

That is why DMARC is not only a technical concern for mail administrators. It also matters to marketers, founders, e-commerce operators and anyone responsible for a domain’s public credibility.

Why this term is worth understanding even outside technical roles

DMARC is one of the clearest examples of the fact that email is not only about writing a message and pressing send. Behind the scenes, there is also identity, trust and policy.

If you understand what DMARC does, it becomes much easier to see why an email may be blocked even though it “looked fine”, why a brand can be impersonated through email if authentication is weak, and why one forgotten sending tool can cause trouble across an entire domain.

That is why DMARC is worth understanding even outside technical professions. It sits exactly at the point where email deliverability, domain protection, sender reputation and brand trust all meet.

Related terms

• DNS – DMARC is published as a DNS TXT record, so its role only makes full sense in the wider context of how DNS works.
• SPF – one of the two core authentication methods DMARC builds on.
• DKIM – the other core authentication method DMARC evaluates together with alignment.
• Alignment – the rule that checks whether the SPF-authenticated or DKIM-authenticated domain matches the visible From domain closely enough to count as a DMARC pass.
• From domain – especially important in DMARC because this is the sender identity the human recipient actually sees.
• TXT record – the DNS record type used to publish DMARC.
• rua / ruf – DMARC reporting tags used to request aggregate and failure-oriented reports.
• p=none, p=quarantine, p=reject – the three main DMARC policy levels that define how failing mail should be handled.
• MX records – not part of DMARC itself, but closely related to the wider email infrastructure of a domain.
• Nameservers – the authoritative servers that publish the DMARC record and the rest of the domain’s DNS data.

A TXT record is a DNS record used to store text-based information for a domain or subdomain. At first sight, that can sound vague, but in practice TXT records are extremely important. They are commonly used for domain ownership verification, email authentication, service validation and other technical instructions that need to be published through DNS without pointing directly to a server or IP address.

Unlike an A record, which points to an IPv4 address, or an MX record, which tells the internet where incoming email should be delivered, a TXT record does not route traffic in the usual sense. Its role is different. It publishes text data that other systems can read and interpret.

That is exactly why TXT records appear in so many practical situations. You may see them when connecting a domain to Google Workspace or Microsoft 365, when setting up SPF or DMARC, when verifying domain ownership for an external service, or when publishing security-related information connected to email and domain control.

What a TXT record actually does in practice

A TXT record allows a domain owner to place text-based information into DNS in a way that other services can query and interpret. The value itself may look like plain text, but in many real-world cases it is not meant for humans to read casually. It is meant for systems and services that expect a specific format.

For example, an email service may look for a TXT record that defines which servers are allowed to send mail for your domain. A cloud service may ask you to place a verification code in a TXT record to prove that you control the domain. A security setup may use TXT records to publish policy information that receiving systems should check before trusting a message.

This is why TXT records are often described as very flexible. They can hold simple text, but in practice they are often used to carry structured technical information.

Why TXT records matter so much

TXT records matter because many modern internet services rely on them as a simple and standard way to publish small pieces of control or verification data.

They are useful because:

• they are widely supported – nearly every DNS provider supports TXT records,
• they are flexible – the value can hold many different types of information depending on the use case,
• they are easy to query – external systems can look them up through DNS without needing direct access to your hosting or email server,
• they work well for verification – adding a TXT record is one of the most common ways to prove control over a domain.

This is also why TXT records show up again and again when connecting domains to third-party tools. They are one of the simplest ways to confirm ownership and publish technical instructions without changing how the website itself loads.

What TXT records are used for most often

The most common use cases are much more practical than the name “text record” may suggest.

• Domain verification – many services ask you to add a TXT record with a specific verification string to prove that you control the domain.
• SPF – SPF is published as a TXT record and lists which servers are allowed to send email for the domain.
• DMARC – DMARC is also published as a TXT record and defines how receiving mail servers should treat messages that fail email authentication.
• Other service integrations – various SaaS tools, security platforms and cloud services use TXT records for domain linking and validation.

That is why TXT records are so common in email administration, but not limited to it. They sit at the point where DNS meets identity, trust and service configuration.

What a TXT record looks like

A TXT record usually contains a hostname or DNS name, the record type TXT, and a value written as one or more text strings.

A simple example could look like this:

example.com TXT "verification=abc123xyz"

Or in the case of SPF:

example.com TXT "v=spf1 include:_spf.google.com -all"

And for DMARC:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

To a non-technical user, these may just look like random strings. In practice, each one follows a specific format expected by the service that reads it.

TXT records do not point to a server

This is one of the most important distinctions. A TXT record does not normally point traffic anywhere. It does not say “go to this IP address” the way an A record does, and it does not say “deliver email to this mail server” the way an MX record does.

Instead, it publishes information. That is why TXT records are often misunderstood by people who expect every DNS record to route a service somewhere. TXT records are more about declaration than about routing.

Put simply, a TXT record says: here is a piece of information about this domain. Other systems can now read it and act accordingly.

Can a domain have more than one TXT record?

Yes. A domain can have multiple TXT records. In fact, this is very common.

For example, one domain may simultaneously publish:

• a verification TXT record for Microsoft 365,
• an SPF record for email sending,
• a DMARC record on the _dmarc subdomain,
• another verification token for an external marketing or analytics service.

This is one reason why TXT records need to be managed carefully. They are flexible, but they can also become messy if old values remain in DNS long after a service has been removed.

How TXT records relate to email

TXT records are especially important in email configuration. This is where many domain owners first meet them.

For example, SPF is published as a TXT record. DMARC is also published as a TXT record. And depending on the provider, some DKIM-related setups also involve TXT publication of the public key, although some providers instead use CNAME-based DKIM delegation.

This matters because email reliability is not only about where mail is delivered. It is also about who is allowed to send it, how the sender is authenticated and whether the domain publishes the expected trust signals for receiving systems.

That is why TXT records are so often involved in deliverability issues. A website can work perfectly while email authentication still fails because a TXT-based SPF or DMARC configuration is wrong or incomplete.

What can go wrong with TXT records

TXT records are simple in concept, but there are still several common mistakes:

• the value is pasted incorrectly,
• quotation marks or formatting are changed by mistake,
• an old TXT record remains in place and conflicts with the new setup,
• the record is published on the wrong hostname or subdomain,
• the administrator assumes the change is live immediately, even though DNS cache is still serving older data.

Another practical issue is size and structure. Some TXT values are long, especially in email-related use cases. DNS systems may split long TXT content into multiple quoted strings behind the scenes. That is normal, but it is one of the reasons why copying and editing TXT records manually should be done carefully.

Why TXT record changes do not show up immediately

Like other DNS records, TXT records are affected by caching and TTL. That means even after the authoritative record is changed correctly, part of the internet may still see the older value for some time.

This becomes very visible when verifying a domain with a service that keeps saying “record not found” even though the TXT record has already been added. In many cases, the problem is not that the record is wrong. It is simply that the new value has not yet become visible through the relevant DNS resolvers.

That is why TXT record changes should be checked with DNS lookup tools, not only inside the DNS provider’s control panel.

What are the limits of TXT records?

TXT records are very useful, but they are not meant for everything. They are good for relatively small pieces of text-based data, verification strings and technical policy information. They are not designed to replace proper routing records such as A, AAAA or MX, and they are not a place for large amounts of structured application data.

They are also highly context-dependent. A TXT value only makes sense if the system reading it knows how to interpret it. Without that context, it is just text sitting in DNS.

Why this term is worth understanding even outside technical roles

TXT records are one of the clearest examples of how DNS is used for much more than pointing a website to a server. They show that modern domains also carry proof, trust signals, service validation and policy information in the background.

If you understand what a TXT record does, it becomes much easier to understand why one service asks you to “add this DNS value”, why a domain verification process may fail for a few hours even after the record is added, or why email authentication depends so heavily on correctly published text-based DNS data.

That is why TXT records matter not only to DNS specialists, but also to website owners, marketers, founders and anyone connecting a domain to external services. They are quiet DNS records, but often some of the most operationally important ones.

Related terms

• DNS – TXT is one type of DNS record, and its role makes full sense only in the wider context of how DNS works.
• Nameservers – TXT records are stored on authoritative nameservers and served from there to the rest of the internet.
• Hostname – important because TXT records may be published on the root domain or on specific subdomains, depending on the use case.
• A record – useful for contrast, because A points directly to an IPv4 address, while TXT stores text-based data.
• AAAA record – similar to an A record, but for IPv6 rather than IPv4.
• MX record – another DNS record type, but with a very different function, since MX controls incoming email routing.
• SPF – one of the best-known examples of a policy published through a TXT record.
• DMARC – another major email policy record published through TXT.
• Domain verification – one of the most common reasons third-party tools ask domain owners to add a TXT record.

An A record is a DNS record that translates a domain or hostname into a specific IPv4 address. This is what allows the internet to determine which server it should connect to when someone opens a website, an app or another service available under a specific name. So if a domain leads to a server over IPv4, the A record is what tells DNS which IP address belongs to it.

At first glance, an A record can seem like a basic technical detail that only comes up when hosting is being configured.

In reality, it is one of the most important DNS records of all. As soon as a domain or subdomain points to a specific server, the A record is very often the reason why.

What an A record actually does in practice

When a user enters a domain into the browser, the device does not automatically know which IP address it should connect to.

First, the name has to be translated into a specific numeric network destination. That is exactly the role of the A record. If the domain or hostname is available over IPv4, the A record returns the matching IPv4 address, for example 203.0.113.10.

This means the A record is not the website itself and not the server itself. It is DNS information that says which IPv4 address belongs to that name.

Why it is called an A record

The letter “A” stands for Address.

It is one of the oldest and most fundamental DNS record types. That is exactly why it appears so often – it solves one of the most basic DNS tasks possible: translating a name into the address of a server.

In practice, the important thing is that an A record does not deal with aliases, email routing or other special DNS functions. Its role is very direct – to say which IPv4 address belongs to a given name.

What an A record looks like

An A record contains two main pieces of information:

• the domain or hostname,
• the IPv4 address that name should point to.

In practice, this means that a hostname such as www.example.com may have an A record with the value 203.0.113.10. When someone opens that name, DNS returns that IP address and the browser connects to the correct server.

What is the difference between an A record and an AAAA record?

An A record and an AAAA record solve a very similar problem, but for different address families.

• A record maps a name to an IPv4 address.
• AAAA record maps a name to an IPv6 address.

So both records do similar work, but each one is used for a different version of the Internet Protocol. In practice, one domain can have both at the same time. That is common when a service should be reachable over both IPv4 and IPv6.

Where A records are used most often

An A record is used anywhere a domain or subdomain should point directly to a specific IPv4 address of a server.

Typical examples include:

• the main website,
• subdomains such as www, blog or app,
• application servers,
• internal or dedicated services accessible through a specific hostname.

That is why A records are so common when setting up hosting, moving a website or pointing subdomains to particular services.

Why a domain can have more than one A record

A domain or hostname does not have to have only one A record.

In some situations, it can have multiple IPv4 addresses at the same time. This is used, for example, for traffic distribution, higher availability or redundancy. DNS can then return multiple answers and the client connects to one of them depending on its own behaviour and network conditions.

So multiple A records are not necessarily a mistake. On the contrary, they may be part of a fully intentional and technically correct setup.

An A record is not the same thing as a CNAME

This distinction is important.

An A record points directly to an IPv4 address. CNAME, by contrast, does not point directly to an IP address at all. It creates an alias from one name to another name. So if you need a name to point directly to a specific IPv4 address, the correct choice is an A record. If you want one name to inherit its destination from another hostname, the correct choice is CNAME.

That is why these two record types should never be treated as interchangeable. They are both important, but they solve technically different tasks.

How an A record relates to a hostname

An A record is always tied to a specific name – in other words, to a domain or hostname.

That means it does not belong to “the server in general”, but to the specific name under which that server or service should be reachable. One hostname can have one A record, while another hostname can have a different one. This is exactly how DNS distinguishes which service leads to which technical destination.

How an A record relates to hosting

When hosting changes, the A record is very often one of the main things that changes with it.

If you move a website to a new server, you usually receive a new IPv4 address that the domain should point to. That is the address that needs to be written into the A record. If the domain still points to the old IP address, it will continue leading users to the previous server even after the migration.

That is why the A record is one of the first things checked when a website is moved, hosting is changed or old content is still showing after a migration.

Why an A record change does not show up immediately

Like other DNS changes, an A record change does not become visible across the whole internet immediately.

The reason is caching and the TTL value. DNS resolvers keep older answers in memory for some time before they fetch the new version. That means some users may still see the old server for a while even though the A record has already been updated.

That is why A record changes normally come with some propagation time.

What happens if the A record is missing or wrong?

If a domain or hostname needs to be reachable over IPv4 and the A record is missing, DNS will not be able to return the correct IPv4 address. The result may be an unavailable website or another unavailable service.

If the A record is configured incorrectly, the domain may point to the wrong server. This often happens during hosting migrations, manual DNS edits or simple IP-address typing mistakes.

So the practical rule is straightforward: if the domain should lead to a specific server over IPv4, the A record must be correct and current.

Why this term is worth understanding even outside technical roles

The A record is one of those terms that looks technical at first, but in reality it sits behind many everyday situations that people outside IT still have to deal with.

As soon as a website is moved to new hosting, a new subdomain is created or a domain starts pointing somewhere it should not, the A record is often part of the explanation. Once you understand what this record does, it becomes much easier to see why the domain name alone is not enough and why the internet still needs a specific IP address to reach the right server.

That is why the A record matters even outside technical professions. It is one of the simplest but most important examples of how DNS turns a human-readable name into a real network destination.

Related terms

• DNS – the A record is one of the most basic DNS record types, and its role only makes full sense in the wider context of DNS.
• IP address – the A record translates the name into a specific IPv4 address.
• Hostname – the A record is tied to a specific hostname or domain and defines which IPv4 address belongs to it.
• AAAA record – the direct counterpart of the A record for IPv6 and the clearest comparison for understanding the difference between the two address families.
• Nameservers – authoritative nameservers are where A records are stored and from where the internet looks them up.
• CNAME – an important related concept, because unlike an A record, CNAME does not point directly to an IP address, but to another hostname.

An alias is an alternative or substitute name that does not point to its own separate destination, but instead refers to an already existing name, address or object. In technical practice, people most often encounter this idea where there is no need to create a brand-new destination, because it is enough to give another name to something that already exists. That is why the term alias often comes up in DNS, email systems and user account administration.

At first glance, an alias can seem like a small detail or simply another way of naming the same thing.

In reality, it is a very practical principle. Instead of configuring everything again from scratch, you create an alternative name that leads to an existing target. This makes systems easier to manage, reduces duplication and simplifies future changes.

What an alias is in the simplest possible way

The easiest way to think about an alias is as a nickname or a second name.

One person may have an official name, but other people may also call them by something else. It is still the same person, just under a different label. An alias works in a similar way in technology. It does not create a new target, a new server or a new service. It simply adds another name to an existing one.

That is its main purpose. An alias does not create a new technical reality. It makes the existing one available under another name.

Why aliases are used

An alias is mainly used when the same target should be available under more than one name, or when administrators do not want to manage the same thing separately in multiple places.

This is useful, for example, when:

• a service should work under more than one name,
• configuration should be easier to manage,
• an older name should continue to work even after the technical target changes,
• the same setup should not have to be duplicated manually.

That is why an alias is not just a cosmetic naming trick. In many cases, it is a practical tool for keeping a system cleaner and easier to maintain.

Alias in everyday technical practice

Aliases are not used only in DNS.

They also appear commonly:

• in email, where one mailbox receives messages sent to more than one address,
• in user accounts or system naming, where one object is known under multiple labels,
• in commands or scripts, where one shorter name points to another longer command,
• in web and platform configuration, where several names lead to the same technical service.

In all of these cases, the principle stays the same. An alias does not create a new entity. It only creates another name for the one that already exists.

What alias means in DNS

In DNS, the idea of an alias is used when one name should not have its own independent address, but should instead refer to another hostname.

This is where the CNAME record comes in. A CNAME works as a DNS alias from one hostname to another hostname. That means, for example, that one subdomain does not need its own separate A or AAAA record if it can simply act as an alias of another hostname that already points to the real server.

In this context, the concept of alias is especially important. It shows that not every DNS name needs its own direct routing. Some names simply inherit the destination of another name.

Alias is not the same thing as a redirect

This is an important distinction.

An alias and a redirect are not the same thing, even though the two are often confused in ordinary conversation. An alias means that one name refers to another target at the level of naming or DNS logic. A redirect, by contrast, usually means the user or system first arrives at one place and is then actively sent somewhere else.

So with an alias, there is usually no “forwarding during the journey”. The alternative name leads to the same target from the beginning.

Alias is not a new independent target

This is another key point.

When you create an alias, you do not create a new server, a new mailbox or a new standalone service. You create another name for something that already exists. That is why aliases simplify administration – the technical destination only needs to be maintained in one place, while the other names follow it.

This is especially useful when the real target may change over time. Once the main destination changes, the alias can continue working without the same update having to be repeated in several different places.

Where alias makes the most sense

Alias is most useful where more than one name should refer to the same thing and where you do not want to manage everything manually in several places.

Typical examples include:

• subdomains that should lead to one main service,
• email addresses that should all end up in the same mailbox,
• internal system names and shortcuts,
• situations where an older name needs to remain valid for compatibility even though the technical setup has moved elsewhere.

That is where aliases save work and reduce the risk that a change is applied in one place but forgotten in another.

What are the limits of an alias?

An alias is very useful, but it is not the right answer for every situation.

If a name needs to have its own fully independent logic, its own direct addressing or its own separate records and settings, then an alias may not be the right solution. In DNS, for example, aliases through CNAME work well in some places, but not everywhere. They are best used where the name is meant to follow another hostname rather than behave as a fully independent endpoint.

That is why an alias should be understood as a naming shortcut, not as a replacement for all other technical configuration.

An alias works best when one name only needs to lead to an already existing destination without having its own separate technical setup.

For example, if eshop.example.com should behave exactly like shop.example.com, it can be used as an alias. Both names lead to the same place, and there is no need to manage two separate destinations.

The same logic applies to email. If sales@example.com should deliver messages to the same mailbox as info@example.com, an alias makes sense because no new mailbox has to be created. It is simply another name for the same destination.

An alias is less suitable when the name needs to behave as its own independent technical object. For example, if api.example.com must point to a different server, have its own DNS records, its own SSL certificate setup or its own routing logic, then it should not just be an alias of another name. In that case, it needs its own direct configuration.

Why this term is worth understanding even outside technical roles

Alias is one of those terms that sounds more technical than the logic behind it really is.

In reality, it expresses a fairly simple principle: one thing can be available under more than one name without becoming a new independent service. That matters not only to developers, but also to website owners, marketers, content managers and business operators who work with domains, email or external services and need to understand why one name may simply inherit the behaviour of another.

Once the concept of alias is clear, it becomes easier to understand why some changes only need to be made in one place, why several addresses may lead to the same target, and why some names inside a system are not independent at all, but simply point elsewhere.

That is why alias is worth understanding outside purely technical professions too. It is a simple naming principle, but one that explains a great deal about how domains, services and systems are organised in practice.

Related terms

• DNS – aliases are especially important in DNS because some names do not need their own separate address, but can refer to another name.
• CNAME – the most typical example of an alias in DNS, because this record makes one hostname an alias of another hostname.
• Hostname – in DNS, an alias usually does not point directly to an IP address, but to another hostname.
• IP address – an alias usually does not point directly to an IP address, but instead to a name that is later resolved into one.
• A record – useful as a contrast, because an A record points directly to an IPv4 address instead of to another name.
• AAAA record – similar to an A record, but for IPv6, and helpful for understanding the difference between a direct address record and an alias.
• Nameservers – in DNS, alias records are stored on authoritative nameservers and served from there to the rest of the internet.

Why DNS updates usually take hours rather than minutes?

A DNS change does not work in a way that becomes visible across the whole internet immediately after you save it. In practice, the new setting has to become visible gradually through authoritative nameservers and through the caches of individual DNS resolvers, which is why the discussion is usually about hours rather than minutes. In most cases, a DNS change becomes visible within a few hours, but sometimes it can take up to 24 hours and occasionally even longer.

This is exactly what confuses many people.

The DNS records may already be changed correctly, but the website, email or another service still behaves according to the previous setup.

That does not automatically mean something is broken. Quite often, it is simply the result of how DNS infrastructure works and how long different systems keep older records in memory before asking for a fresh version.

Why a DNS change does not take only a few minutes

DNS servers store domain information in cache.

That is useful in normal operation because they do not need to look up the same domain from scratch every time. It speeds things up and reduces load. The downside is that when you change a DNS record, part of the internet may continue using the older version for a while.

In practical terms, the new IP address or the new DNS record may already be set correctly, but some servers, internet providers or local devices may still be holding the older data in memory. That is why the change does not become visible everywhere at the same time.

What TTL is and why it decides how fast a DNS change becomes visible

How long a DNS server may keep an older record in cache is determined by the TTL value, short for Time to Live. It is the time in seconds for which the record is considered valid before it should be requested again from the authoritative source.

A common TTL value is 3,600 seconds, which equals one hour. In some cases, it may be set to 86,400 seconds, which equals 24 hours. That is one of the main reasons why DNS changes sometimes seem fast and at other times feel surprisingly slow. The higher the TTL, the longer the wait can be.

Put simply: if the record has a TTL of one hour, some resolvers may continue serving the previous version for around one hour. If the TTL is set to 24 hours, the older version may stay visible much longer. That is why DNS changes are often planned in advance and preferably outside peak traffic hours.

You should also expect a short interruption

When DNS records are changed, it is sensible to allow for the possibility of a short interruption lasting a few minutes.

This matters especially when the routing of a website, email or another service is being changed. If such a change is made at the busiest time of day, the impact can be more noticeable.

That is why DNS changes are usually recommended outside peak hours – typically in the evening or at the weekend, when traffic is lower and a short interruption affects fewer people.

How to check whether the DNS change is already visible

The simplest option is to verify the DNS records through a public DNS checker.

Such a tool shows what records different servers in different parts of the world currently see for your domain. That helps you quickly tell whether the problem is really an unfinished DNS change or simply the fact that some resolvers are still working with older cached data.

In practice, it is often useful to check the domain without “www” first and see whether the new state is already visible.

If a checker shows the correct records but the website still loads incorrectly for you, the issue is often no longer in the authoritative DNS setup itself, but in local cache or your provider’s resolver cache.

What to do if the change still has not appeared after 24 hours

If a DNS change still does not seem visible after one day, that does not automatically prove that something is configured incorrectly. In some cases, the TTL may be higher than the usual 24-hour assumption, which extends how long older data remains in cache.

A more common real-world situation is different: public DNS checkers already show the correct records, but when you open the site you still see the old version or perhaps an error page. In that case, the problem is often that the older DNS data is still stored in the cache of the operating system, the browser or the DNS resolver used by your internet provider.

Can flushing DNS cache help?

Yes – in exactly that kind of situation, clearing the local DNS cache can make sense.

On Windows, this is commonly done with the command ipconfig /flushdns in Command Prompt. On macOS, the exact command depends on the system version, but the principle is the same: remove older locally stored DNS information and force the system to fetch a fresh version.

If public DNS tools already show the correct values and the issue persists only for you or only for a subset of users, flushing DNS cache is one of the quickest steps worth trying.

A typical real-life scenario looks like this: the DNS records are already updated correctly, public tools show the new state, but your computer or your connection still works with the older version. In that case, the issue is not a failed DNS change. It is just delay caused by cache.

What to think about before changing DNS

If you already know that DNS records will need to be changed, it is worth planning the change in advance. It helps to know the current TTL, to assume that the change will not be immediate, and to avoid making critical changes in the busiest part of the day.

For important services, it also makes sense to check what records are currently in place and to be very clear about what exactly is going to change. DNS often looks simple only until something goes wrong. And when a change does happen, the biggest practical issue is often not writing the new record itself, but waiting until the new version is actually visible across the wider internet.

Why this matters even outside technical roles

DNS changes are one of those things that many people only notice when a website stops loading correctly, email starts behaving strangely or a migration to new hosting does not seem finished. Yet this is exactly where the underlying logic of internet infrastructure becomes visible.

If you understand why a DNS change takes time, it becomes much easier to understand why a website may still point to the previous server after a migration, why email may still be delivered according to the older setup for a while, or why one person sees the new version while another still sees the old one.

That is why this topic matters not only to developers or DNS administrators, but also to website owners, marketers, founders and anyone responsible for a live domain. DNS changes rarely fail because of one dramatic mistake. More often, they simply need time because the rest of the internet is still catching up through cache expiry.

Related terms

• DNS – the wider system that translates domain names into IP addresses and other technical records. Without understanding DNS itself, it is hard to understand why changes do not appear instantly.
• Nameservers – one of the key layers through which new DNS settings become visible. If you do not know what role nameservers play, it is easy to assume a DNS change failed even when it is simply still propagating.
• TTL (Time to Live) – one of the most important concepts for understanding DNS propagation speed, because it defines how long cached records may stay in use before being refreshed.
• DNS resolver – the resolver decides which DNS answer a user or device actually receives at a given moment. It is often the place where the visible delay happens between a completed DNS change and what the user still sees.
• DNS cache – the most common reason why a new DNS record does not become visible immediately, even though the authoritative change has already been made.
• SPF records – a practical example of a DNS record used for email, showing that DNS does not affect only websites but also other important services.
• DKIM records – another example of a DNS-based record where changes can directly affect email verification and deliverability.
• DMARC – expands the context by showing that DNS also plays a role in domain protection and email trust, not only in traffic routing.

An MX record, short for Mail Exchange record, is a DNS record that tells the internet which mail server should receive email for a specific domain. That is how a sending mail server knows where to deliver a message when someone writes to an address such as name@yourdomain.com. Without a properly configured MX record, a website can still work normally, but email delivery will sooner or later start to fail.

At first glance, an MX record may look like a small technical detail hidden somewhere in DNS administration. In reality, it is one of the most important records connected to any domain that uses email. As soon as you rely on business email, hosted mail, Google Workspace, Microsoft 365 or another mail platform, the MX record becomes one of the key settings that decides whether incoming email reaches the right place at all.

What an MX record actually does in practice

When someone sends an email to an address on your domain, the sending server has to work out where that message should physically go. It does not deliver the email to “the domain” in a vague sense. It has to deliver it to a real mail server. That is exactly what the MX record is for.

In practical terms, an MX record acts like a routing instruction for incoming mail. If it is configured correctly, the message goes to the right mail server. If it is configured incorrectly, delivery may fail or the message may be sent to a different mail server than the administrator intended.

This is one of the important differences between web traffic and email traffic. A website usually points to an IP address through an A or AAAA record. Email delivery, however, normally works through MX records, which define which mail servers should be tried for the domain and in what order.

What an MX record looks like

An MX record usually contains two key pieces of information:

• the hostname of the mail server that should receive the email,
• the priority value that tells sending systems which server should be tried first.

The priority value is often the part that confuses people at the beginning. With MX records, a lower number means a higher priority. So if a domain has two MX records with values 10 and 20, the sending server will first try the server with priority 10. Only if that does not work will it move on to the server with priority 20.

In other words, an MX record does not only define where mail goes. It also defines the order in which mail servers should be attempted. That makes it possible to have a primary mail server and one or more backup servers.

Why a domain can have more than one MX record

A domain does not have to use only one MX record. In fact, it is common to use more than one. The reason is simple – reliability and delivery logic.

Sometimes multiple MX records are used as backup. If the main mail server is not available, the sending system can try the next one in the list. In other cases, some servers may be configured with the same priority so that delivery can be spread across multiple mail servers.

That is why checking MX records is not only about whether “some MX record exists”. It is also about whether the priorities make sense and whether the full set of MX records matches how the domain’s email infrastructure is actually supposed to work.

An MX record does not store email – it only tells other servers where to send it

This distinction matters. The MX record itself does not receive, store or manage email.

It is only a DNS instruction that tells other systems which mail server should receive the message. The actual mail handling is done by the mail server the MX record points to.

Put simply, the MX record is routing data, not the mailbox and not the mail application. If it is configured incorrectly, the problem is not that the email account itself is broken. The problem is that incoming mail may never reach the correct server in the first place.

What to watch out for when configuring MX records

One common mistake is assuming that any MX record will do as long as one exists. In reality, what matters is whether it points to the correct mail server, whether it matches the requirements of the mail provider you are using, and whether the priority values are set properly.

Another important technical point is that an MX record should not point to a CNAME. In practice, the MX target should be a hostname that resolves through its own A or AAAA record. This may sound like a small detail, but it matters a great deal in email operations. If the MX target is configured incorrectly, delivery and compatibility problems can follow.

A further common issue appears during migration. An administrator changes the MX records while moving to a new email service, but the new mail environment is not fully ready yet. The domain then starts routing mail to the new destination before the rest of the mail setup is in place.

What if a domain is not supposed to receive email at all?

Not every domain has to accept incoming email. Some domains exist only for a website, for technical purposes or for redirection, and there is no reason for anyone to send mail to them.

For these cases, there is also the concept of a null MX. This is an explicit DNS statement that the domain does not accept email. It is a more advanced configuration detail, but a useful one. If a domain truly does not receive mail, it is cleaner to say so explicitly than to leave sending servers guessing or attempting delivery unnecessarily.

In practical terms, null MX is about making the domain’s intent clear. It does not make mail work better – it tells the internet that the domain is not meant to receive mail in the first place.

What happens if an MX record is missing?

If a domain has no MX record, that does not automatically mean email can never be delivered. Under SMTP rules, a sending system may in some cases fall back to the A or AAAA record of the domain itself. But that is not a state a normal mail setup should rely on.

In practical terms, the rule is simple: if a domain is supposed to receive email, it should have correct MX records. Depending on fallback behaviour is unnecessary risk and often leads to confusion when something breaks in real operation.

One especially important point is this: a website can still work even if MX records are missing or wrong. Your email cannot. That is why MX records are one of the first things checked when mail on a domain is not arriving properly.

How MX records relate to other email DNS records

An MX record handles the routing of incoming mail, but that is not the whole DNS layer of email. In practice, it is closely connected to other records, especially SPF, DKIM and DMARC.

This matters because healthy email operation is not only about where a message should be delivered. It is also about how the sender is authenticated, how domain abuse is limited and how the domain’s trustworthiness is communicated to receiving systems. The MX record solves one critical part of the mail setup, but not the whole thing.

Why MX record changes do not take effect immediately

Like other DNS changes, MX record updates do not become visible across the whole internet instantly. The reason is caching and the TTL value, which stands for Time to Live. DNS resolvers keep previous answers in memory for a limited period and only fetch the new version when that period ends.

This means that after changing mail provider or moving to a new mail server, some parts of the world may still deliver mail based on the old settings for a while. That is why these changes should be handled carefully, ideally only when the new mail servers and the rest of the supporting mail setup are already fully prepared.

Where MX records most often come up in real life

MX records are most often dealt with when setting up business email, moving to Google Workspace or Microsoft 365, changing hosting provider or troubleshooting delivery problems. These are exactly the moments when it becomes clear that a website and email are two different services and that each relies on a different part of the DNS setup.

For a website owner, company administrator or business founder, the practical lesson is simple: if the domain uses email, MX records are among the most critical settings to keep under control.

Why this term is worth understanding even outside technical roles

MX records are one of those DNS terms that most people only run into when mail stops working. Yet they are one of the clearest examples of the fact that a domain is not only about the website. It is also about other services that need to be pointed correctly and kept in sync.

If you understand what an MX record does, it becomes much easier to understand why the website can work normally while email does not. And in everyday business reality, that is often more important than people expect – especially on company domains, where reliable email delivery may matter even more than the website itself.

That is why MX records are worth understanding even outside technical professions. They are a quiet part of DNS, but one of the most important ones whenever a domain is expected to receive email reliably.

Related terms

• DNS – an MX record is one type of DNS record, and its role only makes full sense within the wider logic of DNS.
• Nameservers – MX records are stored on the authoritative nameservers for a domain, and sending systems look them up there through DNS resolution.
• TTL (Time to Live) – defines how long systems may keep MX records in cache before they fetch an updated version.
• Hostname – the specific server name the MX record points to. In practical terms, this is the mail server hostname that should receive email for the domain.
• CNAME – a DNS record type that points one name to another name. For MX, this matters because the MX target should not be a CNAME alias, but a hostname with its own A or AAAA record.
• SMTP – the protocol used for email transport, which relies on MX records to decide where incoming mail should be delivered.
• SPF, DKIM, DMARC – related email authentication records that show email setup is not only about routing, but also about verification, trust and domain protection.

A hostname is a specific name used to identify a host, server, device or service in a network. In the internet and DNS context, it usually means a domain name or subdomain name that points to a particular technical destination – for example www.example.com, mail.example.com or api.example.com. In simple terms, a hostname is the human-readable name a system uses instead of making people work directly with an IP address.

At first glance, the word hostname can seem obvious. People often use it casually and assume it simply means “the domain”. In practice, however, the meaning is narrower and more useful than that. A hostname is usually the specific network name that identifies one particular endpoint, service or machine within the wider naming structure.

That is why the term appears so often in DNS, hosting, server administration, email infrastructure and API configuration. As soon as someone needs to point a service to a real technical target, the hostname becomes part of the conversation.

What a hostname actually does in practice

When someone opens a website, connects to an API, sends email or uses another internet service, they usually do not work directly with a numeric IP address. Instead, they use a hostname.

That hostname is then resolved through DNS to the appropriate technical information – often an IP address through an A or AAAA record, or another name through a CNAME record.

This means the hostname itself is not the server, not the application and not the network path. It is the usable name that identifies where the system should go next.

In real life, that makes hostnames one of the most practical layers of internet infrastructure. They separate the human-facing identity from the lower-level technical addressing.

How a hostname is different from a domain

This is where many people get confused.

A domain is the broader namespace, such as example.com. A hostname is usually a specific name inside that structure that identifies a host or service, such as www.example.com or mail.example.com.

In practice, people sometimes use the terms loosely and say “domain” when they really mean “hostname”. That is understandable in ordinary conversation, but technically the distinction can matter.

For example:

• example.com may be the main domain,
• www.example.com may be the hostname for the public website,
• mail.example.com may be the hostname for mail-related infrastructure,
• api.example.com may be the hostname for an application endpoint.

So a hostname is usually a concrete DNS name used for a particular system role, while the domain is the broader naming space it belongs to.

How a hostname is different from a URL

This is another common mix-up. A hostname is not the same thing as a full URL.

A URL may contain several parts:

• the protocol, such as https://,
• the hostname, such as www.example.com,
• the path, such as /products,
• and sometimes query parameters or fragments.

So in the address https://www.example.com/products, the hostname is only www.example.com.

This matters because many technical settings apply specifically to the hostname, not to the full URL. DNS, SSL certificates, server configuration and routing rules often begin with the hostname.

How a hostname is different from an IP address

A hostname is a name. An IP address is a numeric network address.

The hostname is what people and systems usually use at the interface level. The IP address is what the network ultimately uses to route traffic to the correct destination.

That is exactly where DNS comes in. DNS translates the hostname into the technical data needed to continue the connection.

Without this separation, people would need to remember and manage raw numeric addresses much more often. Hostnames make networks and internet services much more practical to use.

What a hostname usually looks like

A hostname is typically written as one or more labels separated by dots, for example:

• www.example.com
• mail.example.com
• app.eu.example.com

Each label is one part of the name. In DNS terms, names are built from labels joined together with dots.

In normal usage, people usually write the hostname without a trailing dot. In strict DNS notation, a fully qualified domain name can be written with a final dot, but in everyday practice that is rarely shown.

Can a hostname include the main domain only?

In some contexts, yes. The main domain itself can act as the name used for a service, especially for a website running directly on the apex domain.

But in practical internet and hosting discussions, the word hostname often refers more specifically to a service name under the domain, such as www, mail, api or another subdomain-like label.

That is why the term can feel slightly blurry in ordinary speech. In real operations, however, what matters most is whether the name clearly identifies the intended host or service and resolves correctly in DNS.

What rules apply to hostnames?

At the DNS level, names are built from labels, and those labels have length limits. In internet host naming practice, host software is expected to handle labels up to 63 characters and full names up to 255 characters.

It is also worth knowing that older naming assumptions were relaxed long ago, and hostnames may begin with a digit as well as a letter. That surprises some people because outdated explanations still repeat older, stricter rules.

For everyday use, the most important takeaway is not memorising every syntax detail. It is understanding that hostnames follow technical naming rules and are not just arbitrary text.

Where hostnames appear most often

Hostnames are used in many everyday technical situations, even when users do not notice them explicitly.

Typical examples include:

• website hostnames such as www.example.com,
• mail-related hostnames such as mail.example.com,
• API hostnames such as api.example.com,
• application endpoints such as app.example.com,
• verification or service-specific names used by cloud tools and SaaS platforms.

In all of these cases, the hostname acts as the network-facing identity of that endpoint. DNS and the surrounding infrastructure then take care of the technical mapping.

How a hostname relates to DNS records

A hostname usually becomes operationally meaningful only because it has relevant DNS records attached to it.

For example:

• an A record can map the hostname to an IPv4 address,
• an AAAA record can map it to an IPv6 address,
• a CNAME record can make it an alias of another hostname,
• a TXT record can publish verification or policy information for that hostname.

This is why hostnames are not just naming labels in the abstract. They are also the anchor points where actual DNS logic is applied.

How a hostname relates to nameservers

The DNS records of a hostname are stored on the authoritative nameservers for the domain or zone.

That is where resolvers look when they need to find the records tied to that hostname. So when someone changes the DNS configuration of a hostname, the change does not appear magically by itself. It becomes visible through the nameserver and resolver process, just like any other DNS change.

What happens if a hostname is wrong or missing?

If the hostname is wrong, does not resolve in DNS or points to the wrong destination, the service may fail even if the rest of the infrastructure is healthy.

A website may not load. An API may not connect. A verification process may fail. Email-related services may break. The hostname itself is not the entire service, but it is often the first naming layer the whole connection depends on.

This is why hostname issues can look surprisingly serious in practice, even though the term itself sounds simple.

What are the limits of the term hostname?

The word hostname is widely used, but it is not always used with perfect precision. In some conversations it means any DNS name. In others it means specifically the name of one host or one service endpoint. In still other cases, people loosely use it where they really mean a full domain or even a full URL.

That does not make the term useless. It simply means the context matters. In technical work, it is usually best to treat a hostname as the specific DNS name that identifies the host or service being discussed.

Why this term is worth understanding even outside technical roles

Hostname is a useful concept because it sits exactly between human-friendly naming and real technical infrastructure. It is one of the clearest examples of how internet services are identified in practice.

If you understand what a hostname is, it becomes much easier to understand why a service can have one visible web address, another API address and another mail-related address, all under the same wider domain. It also becomes easier to understand why DNS settings, SSL certificates and hosting changes often refer to one hostname rather than to “the whole website” in a vague sense.

That is why the term matters outside purely technical professions too. Website owners, marketers, founders and content managers often work with hostnames even when they do not call them that. Once the concept is clear, many DNS and hosting discussions become much easier to follow.

Related terms

• DNS – hostname resolution only makes full sense in the wider context of DNS.
• Domain – the wider naming space a hostname belongs to.
• Subdomain – often the practical form a hostname takes when identifying a specific service under a main domain.
• FQDN – a fully qualified domain name, which is the complete DNS name of a host or endpoint.
• IP address – the network address a hostname is often resolved to through DNS.
• A record – maps a hostname to an IPv4 address.
• AAAA record – maps a hostname to an IPv6 address.
• CNAME – makes one hostname an alias of another hostname.
• TXT record – may publish verification or policy data on a hostname or on the root domain, depending on the use case.
• Nameservers – the authoritative servers that publish the DNS records connected to the hostname.