Decide whether the stale answer is local
Flushing a local DNS cache can remove a stale answer from one computer's resolver cache. It does not publish a DNS change, clear an external recursive server or force an email receiver to repeat authentication. Start by identifying which component supplied the surprising answer. Otherwise a successful flush message can create false confidence while the actual cause remains elsewhere.
The concrete command examples here are scoped to the Microsoft documentation for Windows 11 and Windows Server 2025, reviewed on 8 November 2026. They are proposed steps, not executed transcripts. The cache model also helps on other systems, but this guide does not prescribe macOS or Linux commands, whose resolver implementations and service arrangements differ. No DNS or operating-system settings have been changed here.
Separate the places that can remember an answer
A workstation may use a local resolver cache, while its configured DNS server maintains a separate recursive cache. Applications can add another layer or use a different resolution path. The authoritative server publishes zone data; it is not simply another copy of the workstation cache. Compare those layers before selecting an intervention. DNS resolvers and name servers have different roles in the architecture. RFC 1034
Positive data can remain cached for its remaining TTL. Negative answers can also be cached: a previous absence may survive after an operator creates a record. Consequently, an empty-looking result is not sufficient evidence that publication failed. The response type, exact name, queried server and observation time matter. RFC 2308
Do not use the TTL currently shown in a control panel as a universal countdown for old copies. The earlier response may have carried another TTL, and different resolvers may have obtained it at different times. Some resolvers can also serve stale data under defined failure conditions. That is a separate behavior to investigate, not something a workstation flush disables. RFC 8767
Collect a small baseline before discarding it
On the scoped Windows systems, the proposed read-only command ipconfig /displaydns displays the DNS client cache, including information derived from the Hosts file and dynamically obtained records. The proposed read-only command ipconfig /all helps record the adapter and DNS configuration. Review output locally and redact unrelated network details before sharing it. Microsoft ipconfig
For the affected name, note what application reported the problem and whether it was looking up TXT, CNAME, A or another type. A browser reaching a website does not test the same dependency as a mail verifier querying a DKIM selector. Record the network context, including an active corporate VPN if relevant, without assuming it is the cause. Keep the baseline intact so a later improvement has something concrete to compare against.
Request a separate, authorized comparison of the same name and type from the configured recursive server and from a verified authoritative server. A lookup utility contacting a named server is not proof of what the application's own cache contained. Treat each result as a different observation. This article supplies no real resolver comparison, so its catalogue evidence requirement remains open.
Use a flush as a controlled local change
The proposed modifying command is ipconfig /flushdns. Microsoft describes it as resetting the DNS client resolver cache, including dynamically added entries and negative cache entries. Run it only on the intended Windows host, under the organization's permission and elevation requirements. Capture the baseline first; the operation deliberately discards information that could help diagnose the issue. Microsoft ipconfig
This is not a request to run that command here. It is also not a reason to add other commands from a troubleshooting checklist. In particular, DHCP release and renewal are different operations, and DNS registration is not cache clearing. A local-cache investigation should not silently expand into changing network connectivity or publishing host registration data.
Repeat the original application action after an authorized flush and retain a second observation. Keep the name, record type and network path consistent. If the workstation immediately receives the same stale answer from its recursive server, repeated local flushing is unlikely to isolate anything new. Escalate the resolver comparison instead of turning a small diagnostic step into a ritual.
Interpret the result without inventing causation
Imagine a fictional case where the authoritative service has the new DKIM selector, a corporate resolver still returns a negative answer, and a workstation has cached that negative answer too. Clearing the workstation cache does not remove the corporate resolver's copy. The next request can refill the workstation with the same result. A new authoritative query and a workstation retry therefore answer different questions.
Now imagine that the named-server comparison is current but the application still behaves differently. Investigate the application's resolver path, its own caching behavior and the exact identity it is querying. Do not immediately declare Windows broken or change public DNS. If the result changes after a flush, record the sequence as an observation rather than proof that every authentication failure had the same cause.
An error such as SERVFAIL also needs a separate branch. It is not equivalent to a confirmed missing TXT record, and empty output without response details is weak evidence. Preserve the failure, server identity and time before deciding whether to involve DNS, network or application owners. RFC 1035
Define what resolution would actually mean
Close a local-cache incident when the affected application and the relevant DNS observations agree with the intended state, or when the remaining difference is assigned to a specific owner. Record what was and was not changed. A customer-facing note should say that a local cache was reset, not that DNS was globally refreshed.
For email authentication, keep the receiving service outside this claim. A flush on an administrator's laptop does not alter a remote receiver's cached SPF, DKIM or DMARC dependencies and does not re-evaluate a message already processed. Successful end-to-end authentication needs suitable received-message evidence. A clean local result is one useful observation, not the final proof of mail delivery.