Treat DNS control as part of email trust
DNS hijacking is an unauthorized change to the information or resolution path that a client trusts. For an email team, the important question is not merely whether a domain's website moved. Determine which authority, account or resolver was affected, which mail-related names changed, and what receivers could have observed during the affected interval. A clean answer now does not establish that earlier delivery decisions used the same data.
Keep authoritative takeover separate from cache poisoning and local resolver redirection. They can produce similar symptoms but require different recovery owners. A registrar account can influence delegation; an authoritative hosting account can change zone content; a compromised endpoint can use an unexpected resolver. NIST's DNS deployment guide distinguishes threats to authoritative, recursive and stub services. That distinction is the starting point for a useful incident map.
Identify the trust boundary that moved
Compare the known registration and delegation baseline with the current authoritative service. Record who manages the registrar, DNS hosting, signing infrastructure and recovery contacts. Check whether a change was authorized before calling it malicious: planned migrations, delegated subdomains and split views can produce legitimate differences. Preserve uncertainty when records or account logs are unavailable.
The authoritative hierarchy matters because a trustworthy-looking zone export from the former provider may no longer describe the public delegation. RFC 1034 section 4.2 explains zone boundaries and delegation. Incident evidence should identify the server and path used for each observation, not just reproduce the answer text. A screenshot without its queried name, record type and timestamp is weak evidence of what changed.
Use established incident procedures to protect affected accounts, preserve relevant logs and coordinate restoration. Those actions require the organization's authorization; this article does not direct changes to a live service. Avoid destroying useful evidence by deleting accounts, replacing every record or clearing every cache before the incident owner has captured the affected state.
Trace different consequences for inbound and outbound mail
An unauthorized MX change can redirect attempts to deliver inbound mail. Whether a particular sender actually delivers depends on its selected route, transport protections and the resulting connection. Do not infer mailbox contents were read solely from an MX difference. Establish the affected interval and inspect delivery evidence before making an exposure claim.
Outbound identity checks have different dependencies. SPF evaluates whether the connecting address is authorized for the evaluated domain, using DNS policy under RFC 7208. If an adversary controls that policy, an SPF pass may reflect unauthorized policy rather than legitimate business authorization. Replacing a DKIM public key can affect verification, but publishing a key does not alter old message signatures or reveal the former private key. The key lookup and verification process is described in RFC 6376 sections 3.6 and 6.1.2.
DMARC relies on an authenticated identifier aligning with the Author Domain. It is not an independent registry of approved employees or vendors. A hijacked domain's authentication material can undermine the assumptions behind a passing result. Domain policy also informs receiver handling rather than guaranteeing a universal outcome, as explained in RFC 9989 sections 4.4 and 5.4.
Understand which protections address which risk
DNSSEC provides origin authentication and integrity for DNS data when validation has a usable chain of trust. It does not certify that a change made through an authorized signing system reflects the owner's intention. A malicious edit accepted and signed by a compromised authoritative administration path may still validate. RFC 4033 section 3 sets out the services DNSSEC provides; account protection and approval controls address a different layer.
Transport policies also need their own analysis. An existing MTA-STS policy can constrain permitted MX hosts and TLS validation for implementing senders, but initial discovery and policy caching have limits. DANE SMTP depends on DNSSEC-authenticated information and suitable TLSA records. Neither mechanism should be described as a universal antidote to administrative domain takeover. Consult RFC 8461 section 10 and RFC 7672 section 2 for their distinct trust models.
Fictional worked example of a disputed MX change
At the fictional organization Example Workshops, an alert reports that example.com now has a different MX target. The mail administrator's old DNS panel still displays the expected value. A proposed investigation would compare delegation, current authoritative answers and registrar change records before deciding whether the panel is simply no longer authoritative.
Suppose the incident record later establishes an unauthorized delegation change. The response owner would coordinate restoration of the approved authority and assess the time window against sender logs and transport-policy evidence. An authentication pass on an unrelated outbound message would not close the inbound exposure question. This scenario is invented and contains no observed incident, provider account access or tested restoration.
Define recovery beyond restoring one answer
Retain the approved record difference, dependency map and restore material, then verify the restored authoritative path and selected recursive views. Review any keys, credentials or policy endpoints implicated by the actual compromise without assuming every secret was exposed. Assign ownership for monitoring recurrence and unresolved exposure questions.
Close the incident only against explicit criteria: administration is controlled, intended records are served, dependent services are verified and the evidence interval is understood. Cached answers and queued mail can outlive the visible repair. Original approval and post-change lookup evidence remain missing here, so this educational explanation is not a completed hijacking assessment or a declaration that any domain is safe.