DNS is massively underestimated

DNS as the control centre

To understand why so much depends on DNS, it is worth looking at what it actually does. The internet is decentralised, and so that systems can still work together reliably, DNS translates technical IP addresses into meaningful names. Most people still know the “www” in front of an address, but understanding often stops there, although the interesting and security-relevant records lie right behind it.

Because DNS does not only determine at which address a website can be reached. It also decides where emails go, which servers are considered trustworthy and which services respond under a domain at all. That makes it the control centre where the reachability and trust of your own product come together, and that is exactly why it is a rewarding target.

The record your email depends on

A good example is the question of how emails actually find their way to the recipient. For this, DNS has the so-called MX records, short for mail exchange. When a mail server wants to deliver a message to hero@foo.de, it first asks DNS who is responsible for email for foo.de, and exactly this MX record provides the answer.

The MX record is therefore the switch that decides where incoming mail ends up. That it can be queried publicly is part of normal operation and not a problem in itself. It only becomes a risk because it can be changed as soon as someone has control over the zone, and it is exactly this changeability that most people underestimate.

A takeover scenario, step by step

To make the danger tangible, it is worth playing through an attack the way it actually happens in practice. It rarely starts with a spectacular hack, but with a stolen login to the DNS provider, for instance because the login there was only protected by a password, or because a credential stealer landed on the computer of someone with production access.

With this access, the attacker points the domain’s MX record at their own server, so that from this moment on all incoming emails reach them first. They do not have to touch the real mail server at all, because the switch in DNS is enough to put themselves between sender and recipient.

Now they exploit the fact that almost every account on the internet can be reset by email via “Forgot password”. They trigger a reset at the company’s SaaS services and cloud platforms, intercept the confirmation email and take over one account after another, without ever having guessed a single password.

What makes it particularly insidious is that the attacker can transparently forward the remaining emails to the real server. They keep the reset emails, everything else is delivered as normal, so at first nothing stands out in everyday work and the takeover continues unnoticed. This pattern is no longer theory but is being observed: in 2025, security researchers described cases in which attackers verified hijacked domains with SaaS providers and abused the password reset function of privileged accounts via redirected emails.

Why MFA does not save you here

At this point the objection often comes that multi-factor authentication has been enabled. That is good and important, but it only helps to a limited extent in this scenario, because many password reset flows reset or bypass the second factor too as soon as someone controls the mailbox.

Protection therefore does not lie with the individual login alone, but one level deeper, in control over DNS and the accounts that depend on it. Whoever can redirect the MX record undermines part of the login security before MFA even comes into play.

Why the risk is growing right now

Anyone who considers all this a fringe topic underestimates how much the threat landscape has shifted recently. Attacks via the software supply chain and compromised open source libraries have increased massively, and several independent analyses for 2025 show growth in malicious packages in the triple-digit percentage range, driven by automatically stolen credentials and tokens.

The reason behind it is uncomfortably simple: a stolen token or a harvested password is often easier to obtain today than attacking a system directly. How quickly a harmless-looking dependency becomes a gateway is described in more detail in the article Why “we scan after the git commit” is not enough. For DNS this means: access to the zone is just as rewarding a target as the code itself.

The forgotten record: dangling MX

One special case deserves attention of its own, because it is so easily overlooked. If a domain is no longer actively used for email, but its MX record still points to a service that is no longer operated or was never set up properly, a so-called dangling MX record arises. Such a dangling record can, under certain circumstances, be taken over by third parties, so that a domain that was actually retired suddenly becomes usable again for credible attacks.

Especially those who have accumulated several domains over the years often carry a handful of such legacy issues around without knowing it. That is why not only the actively used zone belongs under scrutiny, but also every domain that was once registered and then lost from view.

What to do in concrete terms

The first step is an inventory that honestly answers which domains exist at all, where they are hosted and who has access to them. In practice there are almost always considerably more domains and DNS zones than expected, and this tidying up alone brings clarity.

On this basis it is worth checking the DNS records regularly, especially the MX records, so that an unwanted change does not go unnoticed for months. In parallel, permissions should be minimised, because nobody needs full admin in production by default, and the environments for development, staging and production belong cleanly separated, even if smaller teams in particular like to save in the wrong place here until it gets expensive.

In the end, the biggest difference is made by monitoring that alerts automatically as soon as a critical DNS record changes. A manipulated switch rarely stands out by itself, whereas a notification at the right moment makes the difference between an attack fended off and a successful one.

Where the impact comes from

DNS looks inconspicuous, but whoever takes control of it often controls the rest along with it, right up to access to SaaS services, cloud platforms and externally purchased systems, all of which can be reset via email accounts. That is exactly why DNS is not a purely technical topic, but a question of how resilient the operation of your own product really is.

The recurring core is the gap between the documented and the actual state, and that gap is exactly where our product Driftguard comes in: it makes visible when the real state of a cloud deviates from what is on paper. A redirected MX record is exactly such a deviation, one that must not drift away without anyone noticing.

If you want to take an honest look at your current security situation, we will look at it together, pragmatically and without buzzword bingo. Such gaps can usually be closed in a lightweight way, by adjusting an internal process or making a small technical change, rather than turning it into a big project.