Category: DNS

An IP address, short for Internet Protocol address, is a unique number used to identify a device or network on the internet. Every time you open a website, send an email, use an app, or connect to an online service, your device uses an IP address to communicate.

Think of an IP address like a digital return address. It tells websites and online services where to send information back after you request it.

For example, when you visit a website, your browser sends a request from your network’s IP address. The website then sends the page data back to that address so it can load on your screen.

According to ICANN, IPv4 addresses are usually written as four numbers separated by dots, while IPv6 addresses use a longer format designed to support the continued growth of the internet.

What Is My IP Address?

When people search for “what is my IP address?”, they usually want to see their public IP address.

Your public IP address is the address visible to websites, apps, servers, and online tools when you connect to the internet. It is usually assigned by your internet service provider, mobile network, office network, or VPN provider.

The easiest way to check it is to use the HasheTools My IP Address Lookup Tool. It automatically detects your public IP address and can show details such as IPv4 or IPv6 address, ISP, location, and VPN or proxy detection where available.

How to Check Your IP Address

You can check your IP address in just a few seconds.

Open the HasheTools My IP Address Lookup Tool, and the tool will automatically show your current public IP address. You do not need to log in, install software, or manually enter anything.

A good IP checker may show:

Your public IPv4 address

Your public IPv6 address, if available

Internet service provider

Approximate location

Browser or device-related connection details

VPN or proxy status, if detected

This is useful when troubleshooting websites, checking VPN connections, verifying server access rules, or confirming which IP address is visible to the internet.

Public IP Address vs Private IP Address

There are two common types of IP addresses: public IP addresses and private IP addresses.

Public IP Address

A public IP address is the address visible on the internet. Websites, apps, and online services can usually see this address when you connect to them.

Your public IP may belong to:

Your home internet connection

Your mobile data provider

Your office network

A VPN server

A proxy service

A cloud server

This is the IP address most online tools display when you search “what is my IP?”

Private IP Address

A private IP address is used inside a local network, such as your home Wi-Fi or office network. Your phone, laptop, printer, smart TV, and router may all have private IP addresses.

Common private IP ranges include:

10.0.0.0 to 10.255.255.255

172.16.0.0 to 172.31.255.255

192.168.0.0 to 192.168.255.255

These private ranges are reserved for internal networks under RFC 1918.

In simple terms, your private IP identifies your device inside your local network, while your public IP identifies your network on the internet.

IPv4 vs IPv6: What Is the Difference?

There are two main versions of IP addresses: IPv4 and IPv6.

IPv4 Address

An IPv4 address uses four sets of numbers separated by dots.

Example:

192.0.2.53

IPv4 is still widely used, but it has a limited number of possible addresses.

IPv6 Address

An IPv6 address is longer and uses letters and numbers separated by colons.

Example:

2001:db8:85a3::8a2e:370:7334

IPv6 was created to support far more devices and networks than IPv4. ICANN describes IPv6 as the successor to IPv4, designed to support the next generation of internet growth.

Which One Should You Care About?

Most users do not need to choose between IPv4 and IPv6 manually. Your internet provider, router, operating system, and websites usually handle this automatically.

However, checking whether your connection shows IPv4, IPv6, or both can help with:

Website access issues

Server firewall rules

VPN testing

DNS troubleshooting

Hosting configuration

Network diagnostics

What Can Someone Learn From Your IP Address?

Your IP address can reveal some basic information about your internet connection, but it does not usually reveal your exact home address.

An IP lookup may show:

Approximate city or region

Country

Internet service provider

Network type

Time zone estimate

Whether the IP belongs to a data center, VPN, proxy, or residential ISP

However, IP location data is not always exact. It may show the location of your ISP, mobile carrier, VPN server, or nearby network hub instead of your real physical location.

Still, your IP address is important because it can be used for tracking, security filtering, fraud detection, analytics, access control, and troubleshooting.

Why Should You Check Your IP Address?

Checking your IP address can help in many everyday and technical situations.

1. To Confirm Your VPN Is Working

If you are using a VPN, your visible public IP should usually change. An IP checker helps confirm whether websites are seeing your real ISP IP or your VPN IP.

2. To Troubleshoot Website Access

Some websites, servers, firewalls, or hosting platforms block or allow traffic based on IP addresses. Knowing your current IP makes it easier to debug access problems.

3. To Set Up Server Whitelisting

Developers, website owners, and agencies often whitelist IP addresses for:

Admin dashboards

Hosting panels

Staging websites

Databases

APIs

Security plugins

SSH or SFTP access

Before whitelisting, you need to know your current public IP address.

4. To Check Your Internet Provider

An IP lookup can show which ISP or network your connection is using. This is useful if you are switching between home Wi-Fi, mobile data, office internet, or VPN.

5. To Improve Online Privacy

Checking your IP helps you understand what basic network information is visible when you browse online.

Is It Dangerous If Someone Knows My IP Address?

In most cases, simply knowing your IP address is not enough for someone to hack you. Websites, apps, email services, and servers see IP addresses all the time.

However, your IP address can still be misused in some situations.

Potential risks include:

Tracking your approximate location

Restricting or targeting access based on your network

Attempting port scans against exposed devices

Launching denial-of-service attacks against a network

Associating online activity with the same connection

Identifying your ISP or organization

The risk is higher if your router, server, camera, remote desktop, or other internet-facing service is poorly secured.

That is why IP privacy and network security both matter.

How to Protect Your IP Address

You cannot use the internet without some kind of IP address, but you can reduce unnecessary exposure and improve your privacy.

1. Use a Trusted VPN When Needed

A VPN can mask your real public IP address by routing your traffic through a VPN server. This means websites may see the VPN server’s IP instead of your ISP-assigned IP.

A VPN is especially useful when using public Wi-Fi, traveling, or accessing sensitive work systems. Washington Technology Solutions notes that a VPN encrypts data between your device and the network and acts as a protective tunnel on public Wi-Fi.

Choose a reputable VPN provider. Avoid unknown free VPNs that may log or sell browsing data.

2. Use HTTPS Websites

When visiting websites, look for secure HTTPS connections. The FTC recommends entering personal information only on secure sites that use encryption, especially when using public Wi-Fi.

HTTPS does not hide your IP address, but it helps protect the information sent between your browser and the website.

3. Secure Your Router

Your router is one of the most important devices in your network. To protect it:

Change the default admin password

Keep router firmware updated

Disable remote admin access unless required

Use WPA2 or WPA3 Wi-Fi encryption

Use a strong Wi-Fi password

Turn off WPS if you do not need it

Restart or replace outdated routers when necessary

A poorly secured router can expose your entire network.

4. Avoid Exposing Devices Directly to the Internet

Do not expose cameras, printers, NAS devices, smart home devices, or remote desktop services directly to the internet unless you fully understand the security risks.

If remote access is required, use:

VPN access

Strong authentication

Firewall rules

Updated firmware

Non-default passwords

Limited user permissions

5. Be Careful on Public Wi-Fi

Public Wi-Fi networks at airports, hotels, restaurants, and cafés can be convenient, but they should be used carefully.

When using public Wi-Fi:

Avoid entering sensitive information on non-HTTPS websites

Use a VPN when possible

Disable automatic Wi-Fi connections

Avoid file sharing

Log out of accounts after use

Keep your device updated

6. Keep Your System Updated

Operating system, browser, router, and app updates often include important security patches. Keeping devices updated reduces the chance that attackers can exploit known vulnerabilities.

7. Use a Firewall

A firewall helps block unwanted incoming traffic. Most operating systems include built-in firewall features. Make sure they are enabled, especially on laptops used outside your home or office network.

8. Check for IP Leaks

If you use a VPN, periodically check your IP address to confirm that your real IP is not exposed.

You should check:

Public IPv4 address

Public IPv6 address

DNS leak status

WebRTC leak behavior

VPN connection status

If your real IP still appears while connected to a VPN, your VPN or browser settings may need adjustment.

Static IP vs Dynamic IP

Your public IP address may be static or dynamic.

Static IP Address

A static IP usually stays the same over time. Businesses often use static IPs for servers, remote access, VPNs, email systems, and firewall rules.

Static IPs are useful for reliability, but they may also make tracking easier because the same IP remains associated with the same network.

Dynamic IP Address

A dynamic IP can change periodically. Many home internet connections use dynamic IP addresses assigned by the ISP.

Dynamic IPs are common and usually fine for everyday browsing, streaming, gaming, and general internet use.

Shared IP vs Dedicated IP

Some users have a shared IP, while others use a dedicated IP.

Shared IP

A shared IP is used by multiple users, websites, or customers. This is common with residential ISPs, mobile networks, shared hosting, and VPN services.

Dedicated IP

A dedicated IP is assigned to one user, server, or service. Businesses may use dedicated IPs for hosting, email reputation, secure access, or firewall control.

For most users, a shared IP is normal. For business systems, a dedicated or static IP may be useful.

Can You Change Your IP Address?

Yes, in many cases, you can change your visible IP address.

Common ways include:

Restarting your router

Switching from Wi-Fi to mobile data

Using a VPN

Connecting from a different network

Asking your ISP for a new IP

Using a proxy service

Upgrading to a static or dedicated IP plan

However, changing your IP does not automatically make you anonymous. Websites can still use cookies, browser fingerprints, account logins, device identifiers, and other tracking methods.

What Is an IP Address Used For?

IP addresses are used for many internet and security functions, including:

Routing internet traffic

Loading websites

Sending and receiving data

Email delivery

Server access control

Fraud detection

Website analytics

Network troubleshooting

Firewall rules

CDN routing

Geolocation-based content

VPN and proxy detection

For website owners, IP addresses also help with log analysis, spam prevention, rate limiting, and cybersecurity investigations.

Common IP Address Problems

“My IP Address Is Blocked”

Your IP may be blocked by a website, firewall, email server, or security system. This can happen because of suspicious activity, failed login attempts, spam history, shared VPN abuse, or incorrect firewall rules.

“My Location Is Wrong”

IP location is approximate. It may show your ISP’s location, VPN server location, mobile network gateway, or regional routing point instead of your real location.

“My IP Keeps Changing”

This usually means your ISP uses dynamic IP assignment. It is normal for many residential connections.

“My VPN Is Not Hiding My IP”

Your VPN may be disconnected, misconfigured, leaking IPv6, or affected by browser WebRTC leaks. Use an IP checker after connecting to confirm what IP is visible.

“I Need to Whitelist My IP”

Use an IP address checker to find your current public IP, then add that IP to your firewall, hosting panel, security plugin, or server access list.

Quick IP Address Safety Checklist

Use this checklist to protect your IP address and network:

Task	Why It Matters
Check your public IP regularly	Helps confirm what websites can see
Use a VPN on public Wi-Fi	Reduces exposure on untrusted networks
Keep your router updated	Protects your home or office network
Use strong Wi-Fi security	Prevents unauthorized network access
Avoid exposing devices online	Reduces attack surface
Use HTTPS websites	Protects data in transit
Enable firewall protection	Blocks unwanted incoming traffic
Check for VPN leaks	Confirms your real IP is hidden
Use strong passwords	Protects accounts and devices
Monitor suspicious activity	Helps detect security issues early

How HasheTools Helps You Check Your IP

HasheTools makes it simple to check your public IP address instantly. The My IP Address Lookup Tool can automatically detect your IP from your browser and show useful connection details such as IPv4, IPv6, ISP, location, and VPN or proxy status where available.

You can use it when:

Checking your current public IP

Testing a VPN

Troubleshooting website access

Setting up firewall rules

Verifying server whitelist access

Checking IPv4 or IPv6 connectivity

Reviewing basic network information

It is a fast, browser-based way to understand what your internet connection is showing to the outside world.

FAQs

How do I check my IP address?

The easiest way is to use an online IP address checker such as the HasheTools My IP Address Lookup Tool. It automatically detects your public IP address from your browser.

Can my IP address show my exact location?

Usually, no. Your IP address may reveal an approximate city, region, country, or ISP, but it normally does not reveal your exact home address.

Is my IP address private?

Your public IP address is visible to websites and online services you connect to. Your private IP address is used inside your local network and is not normally visible on the public internet.

Can someone hack me with my IP address?

Knowing your IP address alone is usually not enough to hack you. However, if your network or devices are poorly secured, attackers may try to scan or target exposed services.

How can I hide my IP address?

You can hide or mask your real public IP by using a trusted VPN, proxy, or privacy-focused network. A VPN is one of the most common options for everyday users.

Why does my IP address change?

Many internet service providers assign dynamic IP addresses, which can change when your router reconnects or after a certain period.

What is the difference between IPv4 and IPv6?

IPv4 is the older format that uses four numbers separated by dots. IPv6 is a newer, longer format designed to provide many more available addresses for modern internet growth.

Should I use a VPN to protect my IP address?

A VPN can help mask your real IP address and protect traffic on untrusted networks. It is especially useful on public Wi-Fi, while traveling, or when you want more privacy from websites and networks.

Why does my IP checker show a different city?

IP location databases are not always exact. They may show your ISP’s location, VPN server, mobile network gateway, or regional routing location instead of your actual location.

Can two devices have the same public IP address?

Yes. Devices on the same home or office network often share a single public IP address through Network Address Translation (NAT), while each device has its own private IP address.

Final Thoughts

Your IP address is a basic but important part of how the internet works. It helps websites, apps, and online services communicate with your device or network.

Knowing your IP address can help you troubleshoot connection issues, configure server access, check VPN protection, and better understand your online privacy.

The key is not to panic about your IP address being visible. Instead, use smart protections: secure your router, use HTTPS, avoid unsafe public Wi-Fi behavior, keep devices updated, and use a trusted VPN when privacy matters.

If you want to quickly check your current public IP address, use the HasheTools My IP Address Lookup Tool and review what your connection is showing online.

DNS is no longer just the invisible system that turns a domain name into an IP address. In 2026, DNS has become a core part of cybersecurity, brand protection, email authentication, and online trust.

That is exactly why NIST published SP 800-81 Revision 3, officially titled Secure Domain Name System (DNS) Deployment Guide, in March 2026. The updated guide explains how organizations should secure DNS infrastructure, protect DNS data, reduce misconfiguration, and use DNS as part of a broader zero trust and defense-in-depth security strategy.

For domain owners, this update matters because your DNS records control where your website loads, how your email is authenticated, how subdomains resolve, and how users reach your online services. A single weak DNS configuration can lead to phishing, domain hijacking, email spoofing, broken websites, or brand impersonation.

This guide explains what NIST SP 800-81r3 means in practical terms and what domain owners should focus on in 2026.

What Is NIST SP 800-81r3?

NIST SP 800-81r3 is the latest revision of NIST’s DNS security deployment guide. It provides recommendations for securing DNS protocols, DNS servers, authoritative DNS services, recursive DNS services, DNSSEC, encrypted DNS, and protective DNS. NIST describes DNS as an integral part of enterprise network architecture and warns that attacks against DNS infrastructure can threaten network operations.

The major shift in this revision is that DNS is treated as more than a background technical service. NIST now frames DNS as a foundational security control that can support zero trust, defense-in-depth, incident response, and policy enforcement.

In simple words: DNS is not only about “where does this domain point?” It is also about “Can this domain be trusted, monitored, protected, and verified?”

Why Domain Owners Should Care

Even if you are not running a large enterprise network, your domain depends on DNS for almost every important online function.

Your DNS controls:

• Website routing through A, AAAA, and CNAME records
• Email delivery through MX records
• Email authentication through SPF, DKIM, and DMARC records
• DNSSEC validation through DS, DNSKEY, and RRSIG records
• Subdomain behavior across hosting platforms, SaaS tools, landing pages, CDNs, and mail services
• Brand trust, because attackers often abuse DNS misconfigurations to impersonate legitimate organizations

NIST specifically warns that misconfigured or stale CNAME records and name server delegations can allow attackers to take control of external-facing domains. It also notes that attackers commonly register look-alike domains to trick users into believing they are interacting with a legitimate organization.

That means DNS security is not only an IT issue. It is also a business continuity, brand protection, email security, and customer trust issue.

The Biggest Change: DNS Is Now a Security Control

The most important message in NIST SP 800-81r3 is that DNS should be part of an organization’s active security strategy.

NIST explains that DNS can help prevent malicious communication before it starts because DNS queries usually happen before a browser, app, or device connects to a destination. This makes DNS useful for blocking dangerous domains, detecting suspicious activity, supporting digital forensics, and improving zero trust visibility.

For domain owners, this means your DNS setup should be reviewed with the same seriousness as SSL certificates, website security, email authentication, and hosting security.

A modern DNS security posture should answer these questions:

• Are our DNS records accurate and up to date?
• Is DNSSEC enabled and correctly configured?
• Are abandoned subdomains removed?
• Are old CNAME records still pointing to third-party services we no longer use?
• Are our authoritative name servers resilient?
• Are DNS changes monitored?
• Are SPF, DKIM, DMARC, and related TXT records valid?
• Are look-alike domains being monitored?
• Do we have a plan if DNS is hijacked or misconfigured?

1. Protective DNS: Blocking Threats Before Connections Begin

One of the strongest themes in NIST SP 800-81r3 is protective DNS.

Protective DNS is DNS with security capabilities added on top. It can analyze DNS queries and responses, block known malicious domains, prevent malware and phishing connections, enforce policy, and generate logs for security teams. NIST says protective DNS can be delivered by a vendor, deployed internally, or used in a hybrid model.

For domain owners, protective DNS is especially useful when managing company networks, employee devices, remote teams, or business systems. It can help stop users from reaching malicious domains before the actual web or app connection begins.

What should domain owners do?

Domain owners and website administrators should:

• Use a trusted DNS resolver with security filtering.
• Avoid allowing unmanaged devices to use random public DNS providers.
• Log malicious DNS blocks when possible.
• Review DNS queries for unusual patterns.
• Use protective DNS for office networks, remote endpoints, and sensitive systems.
• Combine DNS protection with email security, endpoint protection, and web security.

Protective DNS does not replace good website security, but it adds an early layer of defense.

2. DNSSEC: Protecting the Integrity of DNS Data

DNSSEC is one of the most important DNS security technologies discussed in NIST SP 800-81r3.

NIST explains that DNSSEC adds source authentication and integrity protection to DNS data. It helps DNS clients verify that DNS responses have not been tampered with. However, NIST also makes an important distinction: DNSSEC protects the integrity of DNS data, but it does not protect the confidentiality of DNS queries. For confidentiality, encrypted DNS protocols such as DoH, DoT, or DoQ are needed.

For domain owners, DNSSEC helps reduce the risk of DNS spoofing, cache poisoning, and unauthorized DNS response manipulation.

What should domain owners check?

A practical DNSSEC checklist includes:

• Confirm that your registrar supports DNSSEC.
• Confirm that your DNS hosting provider supports DNSSEC signing.
• Enable DNSSEC for your authoritative zone.
• Publish the correct DS record at the registrar.
• Verify DNSKEY, DS, and RRSIG records.
• Monitor DNSSEC validation after every DNS provider migration.
• Plan DNSSEC key rollovers carefully.
• Avoid misconfigured DNSSEC records because they can make a domain fail validation.

NIST also notes that DNSSEC signing and validation depend on accurate time. DNSSEC signers and validating recursive servers need reliable time sources to verify signatures correctly.

Before making DNSSEC changes, domain owners should test records carefully. HasheTools provides DNS lookup guidance for checking DNSKEY and RRSIG records, and its DS Lookup tool can help verify DS records used for DNSSEC validation.

3. Encrypted DNS: Improving DNS Privacy and Reducing Tampering

NIST SP 800-81r3 also highlights encrypted DNS protocols, including:

• DoH: DNS over HTTPS
• DoT: DNS over TLS
• DoQ: DNS over QUIC

These protocols encrypt DNS communication between clients and recursive DNS servers. NIST explains that encrypted DNS can help protect sensitive DNS information from exposure or manipulation and reduce risks such as spoofing and machine-in-the-middle attacks.

However, encrypted DNS must be managed carefully. If browsers or devices bypass approved resolvers and use their own encrypted DNS providers, organizations may lose DNS visibility, logging, and policy enforcement. NIST recommends restricting endpoints to authorized DNS services wherever possible and blocking unauthorized DNS paths where appropriate.

What this means for domain owners

For website owners, encrypted DNS is mostly relevant in two areas:

First, it affects how users and employees resolve domains. If you run a business network, you should define approved DNS resolvers instead of allowing unmanaged DNS behavior.

Second, it reinforces the idea that DNS privacy and DNS integrity are separate issues. DNSSEC proves that DNS data has not been tampered with. Encrypted DNS protects the DNS transaction from being easily observed or modified in transit. A mature DNS security strategy may need both.

4. Authoritative DNS Must Be Hardened

Your authoritative DNS is the source of truth for your domain. If attackers compromise it, they can redirect your website, intercept traffic, break email, or abuse your domain reputation.

NIST recommends a resilient authoritative DNS architecture, including multiple authoritative name servers, network and geographic diversity, and secure primary-secondary configurations. It also recommends using a hidden primary server when an organization hosts its own zone information, with only secondary servers visible publicly.

NIST also warns that zone transfers should be restricted. Zone transfers can be useful for replication, but if they are exposed or misconfigured, they may leak DNS data or create denial-of-service risks. NIST recommends access controls, secure authentication methods such as TSIG, and confidentiality protections such as TLS where appropriate.

What should domain owners do?

Domain owners should:

• Use reputable, authoritative DNS providers.
• Keep at least two authoritative name servers.
• Avoid hosting DNS on a single fragile server.
• Disable public zone transfers unless specifically required.
• Restrict zone transfers to trusted secondary servers.
• Use TSIG or equivalent controls for DNS server-to-server updates.
• Separate authoritative DNS from recursive DNS where possible.
• Protect registrar and DNS provider accounts with MFA.
• Limit who can edit DNS records.
• Keep a record of every DNS change.

Most small businesses use managed DNS providers rather than self-hosted authoritative DNS. Even then, the same principles apply: choose reliable providers, restrict access, monitor changes, and remove stale records.

5. Dangling CNAMEs and Lame Delegations Are Serious Risks

One of the most practical parts of NIST SP 800-81r3 for domain owners is its warning about stale DNS records.

A dangling CNAME happens when a subdomain points to a third-party service that is no longer active or controlled by the domain owner. If the third-party resource can be claimed by someone else, an attacker may be able to take over that subdomain.

NIST warns that CNAME records can be exploited when the target domain or IP address is no longer controlled by the rightful organization. It recommends regularly monitoring domain configurations and deleting CNAME records when they are no longer needed.

A lame delegation can also create risk. NIST explains that if a subdomain is delegated to a DNS hosting provider and that service relationship lapses, attackers may be able to hijack resolution for that subdomain.

What domain owners should audit?

Review your DNS zone for:

• Old CNAMEs pointing to unused SaaS platforms
• Landing page tools are no longer in use
• Unused staging or development subdomains
• Old CDN records
• Expired hosting platforms
• Forgotten client portals
• Abandoned helpdesk or documentation subdomains
• NS records delegating subdomains to inactive providers
• TXT records from old verification processes
• SPF includes services you no longer use

A clean DNS zone is easier to secure, easier to troubleshoot, and less attractive to attackers.

6. TTL Values Should Be Practical, Not Random

TTL, or time to live, controls how long DNS records stay cached. Very low TTL values can increase DNS query load, while very high TTL values can delay important changes.

NIST recommends that TTL values should generally be in the range of 1800 seconds to 86400 seconds, or roughly 30 minutes to 1 day, for most DNS data. It also warns that TTL values of zero should not be used, and that very low TTL values can cause problems, especially with DNSSEC-validating caches.

Practical TTL guidance for domain owners

Use lower TTLs before:

• Website migrations
• DNS provider changes
• Email provider migrations
• CDN changes
• DNSSEC key changes
• Emergency incident response

Use stable TTLs for:

• Long-term website records
• MX records
• Verification records
• Records that rarely change

A good rule is to lower TTLs before a planned change, complete the change, verify everything, and then raise TTLs back to a stable value.

7. DNS Logging and Monitoring Are Now Essential

NIST emphasizes that DNS data can support incident response, security monitoring, and zero trust decision-making. Protective DNS logs can reveal blocked domains, suspicious queries, unusual traffic patterns, and possible malware activity. NIST also recommends integrating protective DNS with the broader security ecosystem through SIEM/SOAR tools, APIs, and threat intelligence workflows.

For domain owners, this means DNS should not be a “set it and forget it” system.

You should monitor:

• DNS record changes
• Registrar account logins
• Name server changes
• DS record changes
• MX record changes
• SPF, DKIM, and DMARC changes
• New subdomains
• Suspicious CNAME targets
• Unexpected TXT records
• Failed DNSSEC validation
• Unauthorized zone transfer exposure

DNS monitoring is especially important for agencies, SaaS businesses, ecommerce sites, financial services, healthcare organizations, and any brand that depends heavily on email trust.

2026 DNS Security Checklist for Domain Owners

Use this checklist to align your domain security with the spirit of NIST SP 800-81r3.

Area	What to Check	Why It Matters
DNSSEC	DS, DNSKEY, RRSIG, validation status	Helps protect DNS data integrity
Authoritative DNS	Name server redundancy and provider security	Reduces outage and hijacking risk
CNAME Records	Remove unused third-party targets	Prevents subdomain takeover
NS Delegations	Check delegated subdomains	Prevents lame delegation hijacking
TTLs	Use practical TTLs, avoid zero TTL	Improves stability and change control
Email DNS	SPF, DKIM, DMARC, MX records	Prevents spoofing and delivery issues
DNS Access	MFA, least privilege, change logs	Reduces unauthorized changes
Zone Transfers	Disable public AXFR	Prevents data leakage
Monitoring	Track DNS changes and suspicious records	Enables faster incident response
Look-Alike Domains	Monitor typosquats and homoglyphs	Protects brand reputation

How HasheTools Can Help

HasheTools.com can be part of a practical DNS review workflow. Domain owners can use DNS lookup and related checks to review DNS records, inspect DNSSEC signals, verify DS records, and identify issues in email authentication records such as SPF, DKIM, and DMARC. HasheTools’ own DNS guidance notes that users can check full DNS record stacks, security-related records, and DNS propagation behavior.

A simple monthly workflow could look like this:

1. Run a DNS lookup for your main domain.
2. Check A, AAAA, CNAME, MX, TXT, NS, and SOA records.
3. Verify SPF, DKIM, and DMARC records.
4. Check DNSSEC-related records such as DS, DNSKEY, and RRSIG.
5. Review old CNAMEs and subdomains.
6. Confirm your name servers match your intended DNS provider.
7. Document any changes made during the review.

This is not a replacement for a full security audit, but it is a strong starting point for reducing common DNS risks.

FAQs

What is NIST SP 800-81r3?

NIST SP 800-81r3 is the 2026 revision of NIST’s Secure Domain Name System Deployment Guide. It provides recommendations for securing DNS infrastructure, DNSSEC, encrypted DNS, protective DNS, authoritative DNS, and recursive DNS services.

Does NIST SP 800-81r3 apply to small domain owners?

Yes. While much of the document is written for enterprises and security teams, many recommendations are useful for any domain owner, including DNSSEC validation, removing stale DNS records, securing authoritative DNS, monitoring CNAMEs, and protecting email-related DNS records.

Is DNSSEC enough to secure a domain?

No. DNSSEC helps protect the integrity and authenticity of DNS data, but it does not encrypt DNS queries. NIST explains that DNSSEC and encrypted DNS solve different problems, so DNSSEC should be treated as one part of a broader DNS security strategy.

What is protective DNS?

Protective DNS is DNS enhanced with security features that analyze queries and responses, block malicious domains, enforce policy, and support security monitoring. NIST describes it as a way to block malware, phishing, ransomware, spyware, and other attacks at the DNS layer.

What DNS records should domain owners review in 2026?

Domain owners should regularly review A, AAAA, CNAME, MX, TXT, NS, SOA, DS, DNSKEY, and RRSIG records. They should also check SPF, DKIM, and DMARC records because these email security controls depend on DNS.

Final Thoughts

NIST SP 800-81r3 makes one thing clear: DNS security is no longer optional.

For domain owners, DNS is directly connected to website availability, email trust, brand protection, phishing prevention, and customer confidence. The new NIST guidance encourages a more mature approach: use DNSSEC for integrity, encrypted DNS for privacy, protective DNS for threat prevention, resilient authoritative DNS for availability, and regular DNS audits to prevent misconfiguration.

In 2026, the safest domains will not simply be the ones that resolve correctly. They will be the ones that are continuously verified, monitored, and protected.

AI has transformed phishing into a far more convincing and dangerous cyber threat. Instead of sending poorly written scam emails, attackers now use artificial intelligence to create personalized emails, clone trusted brands, generate fake websites, and even imitate voices and video calls to steal sensitive information.

As these attacks become more sophisticated, traditional warning signs like spelling mistakes and generic greetings are no longer enough to identify phishing attempts. Businesses and domain owners need stronger defenses, including email authentication and DNS security.

In this guide, you’ll learn how AI phishing works, how attackers clone legitimate brands, and the best ways to protect your organization with technologies such as SPF, DKIM, DMARC, BIMI, and DNSSEC. You’ll also discover how HasheTools’ free DNS and email security tools can help you check and strengthen your domain’s security.

What is AI phishing?

AI phishing is the use of artificial intelligence to create highly personalized phishing emails, voice calls, text messages, and fake websites that imitate trusted brands and individuals to steal credentials or financial information.

How Phishing Evolved into AI Phishing

Phishing has evolved dramatically over the past two decades. Early attacks relied on mass emails filled with spelling mistakes, generic greetings, and unrealistic offers that were relatively easy to identify. As attackers became more sophisticated, they began impersonating trusted brands, creating convincing login pages, and targeting specific individuals with personalized messages.

Today, artificial intelligence has transformed phishing into a highly automated and personalized threat. Large language models (LLMs), voice cloning, and deepfake technology allow attackers to generate professional emails, realistic phone calls, and even convincing video meetings that closely mimic legitimate people and organizations. Instead of sending millions of generic emails, cybercriminals can now launch tailored campaigns against employees, customers, or business partners within minutes.

The biggest change is not just the quality of phishing messages but the speed and scale at which they can be created. AI enables attackers to automate research, personalize content, clone trusted brands, and simultaneously adapt their tactics across email, SMS, voice, and video. This shift makes modern phishing far more difficult to detect and reinforces the need for strong email authentication, DNS security, and verification processes.

2026 by the Numbers

AI-powered phishing has grown rapidly, making attacks more convincing and easier to launch at scale. Recent industry reports highlight the accelerating threat:

• AI-generated phishing increased dramatically during 2025–2026, with AI now playing a major role in creating highly personalized phishing campaigns.
• Voice phishing (vishing) incidents surged as attackers began using AI voice cloning to impersonate executives, financial institutions, and trusted contacts.
• Deepfake fraud reached record levels, with organizations reporting a sharp rise in AI-generated video and voice impersonation attacks.
• Credential theft continues to be the primary objective, as AI enables attackers to create realistic emails, fake login pages, and multi-channel social engineering campaigns with minimal effort.

Key takeaway: AI has transformed phishing from mass, generic scams into highly targeted attacks that combine email, voice, SMS, and deepfake technology. Organizations should prioritize strong email authentication (SPF, DKIM, and DMARC), phishing-resistant MFA, and continuous security awareness training to reduce their risk.

The 6 Types of AI Phishing Attacks in 2026

AI has not just improved one type of phishing; it has turbocharged the entire attack surface simultaneously. Here are the six primary attack types security teams face in 2026:

AI-Generated Spear Phishing	LLMs scrape LinkedIn, company websites, social media, and data breaches to craft personalised emails referencing real names, job roles, reporting lines, ongoing projects, and communication styles. The resulting email is indistinguishable from genuine internal communication. 54% click-through rate vs 12% for traditional emails.
Vishing: AI Voice Cloning	Attackers clone an executive’s voice from as little as 3 seconds of publicly available audio (conference recordings, LinkedIn videos, earnings calls). They then call employees with a cloned voice requesting urgent wire transfers or credential resets. Human detection accuracy for high-quality voice clones drops to 24.5%. Vishing surged 442% in 2024.
Deepfake Video Meetings	Synthetic participants join video calls on Teams, Zoom, or Google Meet. In the $25 million Arup attack, an entire management team was deepfaked; the finance employee believed they were speaking with their actual CFO and colleagues in a live call. Real-time deepfake technology now runs on consumer hardware.
AI Smishing (SMS/WhatsApp)	AI generates personalised SMS and WhatsApp messages at scale, referencing real transaction details, delivery information, or account activity. SMS-based phishing accounts for 35% of all phishing attacks in 2026 and surged 40% year-over-year. SMS bypasses email security filters entirely.
Clone Phishing with AI Lookalike Sites	AI tools can clone a brand’s entire website, visual design, content, and login flow in minutes. Combined with typosquat domains that pass basic visual inspection, AI-cloned sites harvest credentials without triggering traditional URL reputation blocklists because the domains are freshly registered.
Autonomous AI Scam Agents	The cutting edge of 2026 attacks: fully autonomous AI agents that conduct entire social engineering campaigns end-to-end. The agent researches the target, crafts personalised messages, adapts dynamically to responses, conducts follow-up voice calls, and handles objections in real time, all without human attacker involvement.

Multi-Channel Attacks Are the Norm, Not the Exception

The most damaging attacks in 2026 combine multiple vectors in a coordinated sequence: a convincing AI-written email is followed by a voice-cloned phone call for ‘confirmation’, then a deepfake video call to ‘close the deal’. Each channel reinforces the others. A recipient who is slightly suspicious of an email becomes convinced when the voice call matches perfectly, because it is their actual CEO’s cloned voice.

Step-by-Step: How Attackers Clone Your Brand

Modern attackers can use AI to create convincing brand impersonation campaigns in just a few hours. The process typically follows these six stages:

Step	What Happens
1. Intelligence Gathering	AI collects publicly available information such as executive names, company branding, employee profiles, email formats, and recent announcements.
2. Infrastructure Setup	Attackers register a lookalike domain (e.g., yourbrand-secure.com), obtain an SSL certificate, and deploy a cloned version of your website.
3. Content Generation	Large language models generate realistic emails, landing pages, and messages that match your company’s tone, branding, and current business activities.
4. Voice & Video Cloning	Public audio and video recordings are used to create AI-generated voice clones or deepfake videos that impersonate executives or trusted employees.
5. Multi-Channel Attack	Victims receive coordinated phishing emails, SMS messages, phone calls, or video meeting invitations designed to build trust and create urgency.
6. Credential Theft or Fraud	Once the victim interacts with the fake website or approves a fraudulent request, attackers steal credentials, sensitive data, or financial assets.

The AI Brand Cloning Workflow

Public Information

│

▼

AI Collects Brand & Employee Data

│

▼

Lookalike Domain + Cloned Website

│

▼

AI Generates Personalized Emails & Messages

│

▼

Voice Clone / Deepfake Verification

│

▼

Victim Clicks or Approves Request

│

▼

Credentials or Funds Stolen

Why This Matters

Unlike traditional phishing, AI-powered brand cloning combines multiple attack methods into a single campaign. A convincing email may be followed by a voice-cloned phone call or a deepfake video meeting, making the scam appear legitimate. Because these attacks use real company information and polished communication, employees should always verify sensitive requests through an independent, trusted channel before taking action.

Tip: Protect your brand by enabling SPF, DKIM, DMARC, and BIMI, and regularly verify your DNS and email authentication records using HasheTools’ free lookup tools.

Real-World Case Studies: Attacks That Worked

1. Arup Deepfake Attack (2024)

A finance employee at global engineering firm Arup joined what appeared to be a legitimate video meeting with the company’s CFO and senior executives. In reality, every participant except the employee was an AI-generated deepfake. Trusting the meeting, the employee approved a $25 million transfer. The incident highlights why financial requests should always be verified through an independent communication channel.

2. ByBit Cryptocurrency Heist (2025)

The ByBit cryptocurrency exchange suffered a $1.5 billion theft after attackers reportedly compromised a third-party provider through a sophisticated spear phishing campaign. The attack demonstrated how AI-assisted social engineering can be used to target trusted suppliers instead of the primary organization. Strong vendor security and phishing-resistant authentication are essential to reduce supply chain risk.

3. AI Voice Fraud (2024)

Several organizations have reported fraud involving AI-generated voice cloning, where attackers impersonated executives to authorize urgent payments or sensitive actions. With only a few seconds of publicly available audio, criminals can create convincing voice replicas. The safest defense is to verify unexpected financial or credential requests by calling the person back using a trusted, known phone number.

How to Spot AI Phishing: The New Red Flags

Traditional phishing red flags are obsolete against AI-generated attacks. The absence of typos, generic greetings, or suspicious formatting no longer means an email is safe. Here are the detection signals that actually work in 2026:

Red Flag	Why AI Makes This Harder to Spot
Unexpected urgency with a financial or credential request	AI can generate urgency that sounds entirely natural. But the underlying pattern, urgent + financial/credential request, remains constant. Check the pattern, not the phrasing.
Request comes via an unexpected channel or new contact	AI enables attackers to approach via email, SMS, and voice simultaneously. If a contact reaches you through an unexpected channel claiming urgency, verify through a known channel.
The email domain is similar but not identical to the real brand	AI generates hundreds of convincing typosquat variants automatically. Check the exact sender domain character by character, not just visually.
Request bypasses normal process (‘just this once’)	AI social engineering specifically includes language that normalises process bypass. Any request to skip standard verification steps is a red flag regardless of how it’s phrased.
Slightly mismatched visual branding on linked pages	AI-cloned sites are close but not perfect; colour shades, font weights, or footer content may differ slightly. Check these against the real brand directly.
Executive contact is on holiday, travelling, or ‘unavailable’	Attackers schedule requests when the impersonated executive is genuinely unavailable (using public travel or OOO information). This makes callback verification harder.
Voice caller knows personal details, but something feels subtly ‘off’	AI voices are extremely convincing but may have slight response delays, unnatural phrasing at sentence boundaries, or limited ability to respond to very specific follow-up questions.
Video call participant’s mouth movements slightly lag behind the audio	Real-time deepfakes can exhibit minor sync issues, especially on lower-bandwidth connections or when the participant is responding to unexpected questions.

The One Detection Heuristic That Still Works

Regardless of how convincing a communication appears, perfect grammar, real names, authentic voice, and genuine context, ask yourself one question: Is this person asking me to take an action that bypasses a normal verification step? Wire transfers, credential resets, software installations, and data shares should always follow your standard verification process, no matter how authentic the requester appears. AI can clone everything except your organisation’s verification protocols.

The DNS Connection: How Email Authentication Stops Brand Cloning

One of the most effective and overlooked defences against AI brand cloning is proper email authentication via DNS. When attackers clone your brand, they almost always need to send emails that appear to come from your domain. DNS-based authentication protocols make this technically impossible, or at least detectable.

The Email Authentication Stack That Blocks Brand Cloning

Protocol	How It Stops Brand Cloning
SPF	Publishes which mail servers are authorised to send email as your domain. An attacker sending from a lookalike domain or their own server fails SPF; the receiving mail server can reject or flag the message.
DKIM	Cryptographically signs every outgoing email. Even if an attacker intercepts and modifies a legitimate email, the DKIM signature breaks. Cloned emails sent from attacker infrastructure cannot produce a valid DKIM signature for your domain.
DMARC	Ties SPF and DKIM together and enforces a policy. At p=reject, any email claiming to be from your domain that fails authentication is rejected at SMTP level before it reaches the recipient’s inbox. This is the core protection against domain spoofing.
BIMI	Displays your verified brand logo in Gmail, Yahoo, and Apple Mail. Recipients see your authenticated logo next to legitimate emails and notice its absence on spoofed ones. Makes AI-cloned emails visually distinguishable.
DNSSEC	Cryptographically authenticates your DNS records. Prevents attackers from poisoning resolver caches to forge your SPF, DKIM, or DMARC records against invalidating resolvers.

Verify Your Email Authentication Records

Strong email authentication is one of the most effective ways to reduce the risk of domain spoofing and brand impersonation. Instead of manually reviewing DNS records, use HasheTools’ free lookup tools to verify that your email authentication is configured correctly.

• SPF Lookup: Confirm which mail servers are authorized to send email on behalf of your domain.
• DKIM Lookup: Verify that your DKIM public keys are published and correctly configured.
• DMARC Lookup: Check whether your domain has a DMARC policy and whether it is enforcing protection against spoofed emails.
• BIMI Lookup: Validate your BIMI record and ensure your verified brand logo is configured correctly for supported email providers.

You can also use the DNS Lookup tool to review all published DNS records in one place and identify potential configuration issues.

Quick Security Check: Run your domain through the SPF Lookup, DKIM Lookup, DMARC Lookup, and DNS Lookup tools on HasheTools to identify misconfigurations before attackers can exploit them.

Technical Defences: What to Deploy

Defending against AI phishing requires a layered technical stack. No single control is sufficient; AI attacks probe for gaps in each layer and route around individual defences. Deploy all of the following:

Email Security Layer

• DMARC at p=reject: The most critical single control. Prevents your domain from being used in phishing emails sent to anyone. Verify current status with HasheTools DMARC Lookup.
• DKIM on all sending services: Configure DKIM signing on every platform that sends email as your domain (your mail server, CRM, marketing platform, support desk). Verify with HasheTools DKIM Lookup.
• SPF with -all qualifier: List all authorised sending IPs and use -all to reject unauthorised senders. Avoid ~all (softfail) in production; it doesn’t protect you.
• BIMI with Verified Mark Certificate: Display your authenticated logo in Gmail, Yahoo, and Apple Mail. Helps recipients visually identify real emails from your domain.
• Anti-phishing email gateway: Deploy an advanced email security solution (Microsoft Defender for Office 365, Proofpoint, Abnormal Security) that uses AI-based detection of AI-generated phishing, fighting fire with fire.
• Lookalike domain monitoring: Subscribe to a service that monitors newly registered domains similar to yours. Attackers register typosquat domains weeks before campaigns launch; early detection enables proactive takedown.

Authentication & Access Control

• Phishing-resistant MFA (FIDO2/WebAuthn): Hardware security keys (YubiKey, Google Titan) and passkeys are immune to credential phishing because they cryptographically bind authentication to the legitimate domain. Even if an employee enters credentials on a cloned site, the authentication won’t succeed.
• Zero Trust Network Access: Authenticate every access request regardless of network location. Compromised credentials stolen via phishing cannot be used to access internal systems without additional device and context verification.
• Privileged Access Management (PAM): High-value accounts (finance, HR, IT admin) require additional authentication steps for sensitive operations. Makes it harder for AI-cloned social engineering to result in unauthorised access even if credentials are obtained.

DNS and Domain Security

• DNSSEC on your domain: Cryptographically authenticates your DNS records. Prevents attackers from forging your SPF, DKIM, or DMARC records via cache poisoning. Verify with HasheTools DNS Lookup.
• Registrar lock on all domains: Prevents DNS hijacking at the registrar level even if your account is compromised. Critical for ensuring your authentication records remain genuine.
• Certificate Transparency monitoring: Receive alerts when new SSL certificates are issued for domains similar to yours. AI-cloned phishing sites obtain legitimate SSL certificates; CT logs give you early warning.
• DNS-based content filtering (RPZ): Configure your resolvers to block known phishing and malware domains using Response Policy Zones. Prevents employees from reaching AI-cloned phishing sites even if they click a link.

Human Defences: Training for the AI Era

Technical controls reduce exposure but cannot eliminate it; humans remain the final decision point in most attacks. AI phishing specifically targets the gap between technical defences and human judgment. Training programs must be completely rebuilt for the AI threat landscape.

What Old Training Taught vs. What You Need Now

Traditional Phishing Advice	What Works Against AI Phishing in 2026
Look for spelling mistakes and poor grammar.	AI-generated messages are usually error-free. Focus on what is being requested, not how well it is written.
Hover over links before clicking.	Verify the exact sender domain and confirm requests through a trusted communication channel.
Be cautious of urgent emails.	Treat any request for money, credentials, or sensitive data as suspicious, even if it appears genuine.
Report suspicious emails to IT.	Report suspicious emails, SMS messages, voice calls, and video meetings, as AI attacks now use multiple channels.

The Verification Protocol That Stops AI Attacks

The most effective human control is a clear, consistently enforced verification protocol for any sensitive request:

1. PAUSE: resist the urgency. AI specifically generates time pressure to prevent verification.
2. VERIFY OUT-OF-BAND: call the requestor back on a number from your company directory, not a number they provided. Send an email to their standard address, not a reply to the suspicious one.
3. CONFIRM THE REQUEST TYPE: Any request for wire transfer, credential reset, access grant, or sensitive data requires a second approver regardless of how credible the source appears.
4. CHECK THE DOMAIN: Use HasheTools DNS Lookup to verify the sender’s domain resolves to your expected nameservers and has valid DMARC records.
5. REPORT REGARDLESS: report all suspicious contacts to security even if you didn’t fall for it. AI campaigns test many targets simultaneously; your report protects colleagues.

Simulated AI Phishing Training Dramatically Reduces Risk

KnowBe4’s 2025 benchmark data shows that security awareness training reduces the global phish-prone percentage by 40% within three months and by 86% after 12 months. However, these results are based on simulations that include AI-generated lures. Training programs using only template-based email simulations no longer capture the risk. Organisations need simulated vishing calls and deepfake video scenarios alongside email simulations to build the right response instincts.

If You’re Targeted: Incident Response Checklist

If you suspect an AI phishing attack or discover that your brand is being impersonated, take these steps immediately:

• Preserve Evidence: Save suspicious emails, SMS messages, call recordings, screenshots, URLs, and timestamps. Avoid deleting anything until the investigation is complete.
• Secure Accounts: Reset any compromised passwords, revoke active sessions, and enable phishing-resistant MFA (passkeys or security keys) wherever possible.
• Verify Your Domain Security: Check your SPF, DKIM, DMARC, DNS, and MX records using HasheTools to ensure your email authentication and DNS settings haven’t been altered.
• Report and Contain the Threat: Report the phishing campaign to your IT/security team, email provider, hosting company, and domain registrar. If a lookalike domain is involved, request an immediate takedown.
• Notify Affected Parties: Inform employees, customers, or business partners if they may have received fraudulent messages or shared sensitive information.
• Review and Strengthen Security: After the incident, enforce DMARC (p=reject), enable DNSSEC, monitor lookalike domains, and update employee training to include AI-generated phishing, voice cloning, and deepfake attacks.

Is version mein original section ki key actions cover ho jati hain, lekin length kaafi kam ho jati hai aur HasheTools ke DNS/email security tools ka CTA bhi naturally include rehta hai.

How HasheTools Helps You Monitor Your Brand’s DNS Exposure

HasheTools provides free, real-time DNS and email security tools that let you instantly assess whether your domain is properly protected against AI brand-clone phishing. No account required.

HasheTools Tool	How It Protects Against AI Brand Cloning
DMARC Lookup	Check your DMARC record policy instantly. If it shows p=none or is missing entirely, attackers can send an email claiming to be you. Escalate to p=reject to prevent this. Your first check after reading this guide.
DKIM Lookup	Verify your DKIM public keys are correctly published for every domain selector. Missing or incorrect DKIM means email forgery can bypass authentication.
DNS Lookup TXT	View your full SPF record and verify all authorised sending sources are listed. Unauthorised senders not in your SPF record and not caught by DMARC can impersonate you.
BIMI Lookup	Check whether your BIMI logo record is correctly configured. BIMI gives recipients visual confirmation that emails are authenticated and reveals to you if not set up.
CNAME Lookup	Check for dangling CNAME records pointing to deprovisioned services. Dangling CNAMEs are a subdomain takeover vector that attackers use to send authenticated-looking emails from your subdomains.
Blacklist Check	If your domain has been used in phishing campaigns, it may appear on spam blocklists. Check immediately after any suspected brand abuse incident.
DNS Servers Lookup	Verify your authoritative nameservers haven’t been changed by a registrar hijacking attack. If NS records point to unknown nameservers, your entire DNS is under attacker control.
Reverse DNS Lookup	Verify your mail server IPs have correct PTR records. Missing or mismatched PTR records reduce email deliverability and can cause legitimate emails to be treated as spam while phishing emails from dedicated IPs sail through.
SMTP Test	End-to-end email delivery test confirms SPF pass, DKIM signing, PTR match, and DMARC alignment in a single check. Run this after any authentication configuration change.

11. Frequently Asked Questions

Can I detect AI-generated phishing emails?

Not reliably from content alone. AI-generated emails are grammatically perfect and contextually accurate. The most reliable detection is not based on email quality but on: (1) the type of action being requested; any financial, credential, or access request should trigger verification; (2) the sender domain check character by character for typosquatting; (3) DMARC authentication status check if the email passed authentication.

Does DMARC at p=reject completely stop phishing attacks against my organisation?

DMARC p=reject prevents attackers from sending emails that appear to come FROM your domain. It does not prevent phishing emails sent from lookalike domains (hashetools-secure.com instead of hashetools.com), vishing calls, deepfake video, or SMS attacks. DMARC is essential for protecting your outbound reputation and blocking exact-domain spoofing, but it must be combined with the full technical stack and human training described in this guide.

How can I tell if a voice call is AI-cloned?

Reliably detecting a high-quality voice clone in real time is extremely difficult; human detection accuracy drops to 24.5% for high-quality clones. Rather than trying to detect the fake, use out-of-band verification: end the call and call the person back on a known, verified number. Ask a personalised question whose answer the attacker would not know. Establish a safe word or code phrase with executives in advance for use in urgent situations.

What should I do if my company’s brand is being cloned in a phishing campaign?

Act immediately: (1) document and report the phishing infrastructure to hosting providers and domain registrars; (2) submit abuse reports to Google Safe Browsing and Microsoft SmartScreen to get the site flagged in browsers; (3) escalate your DMARC to p=reject if not already there; (4) alert your customers through official channels that a phishing campaign is active; (5) file a report with FBI IC3; (6) consider engaging a brand protection service for rapid domain takedown.

Is SMS phishing (smishing) as dangerous as email phishing in 2026?

Increasingly, yes. SMS-based phishing accounts for 35% of all phishing attacks in 2026. SMS bypasses email security gateways entirely, and recipients tend to trust SMS messages more than email. AI generates personalised SMS messages that reference real transaction details, delivery information, or account activity. Deploy mobile threat defence solutions and train employees to treat SMS requests for credentials or financial action with the same scepticism as email requests.

How do attackers get the voice samples they need to clone a CEO’s voice?

They rarely need to obtain samples covertly; the samples are publicly available. LinkedIn video posts, conference presentation recordings, podcast appearances, earnings call recordings, YouTube interviews, and company promotional videos all provide the audio attackers need. Just 3 seconds of audio is sufficient for commercial voice cloning tools. Executives should be aware that every public audio or video recording they produce is a potential voice cloning resource.

Do I need a VMC (Verified Mark Certificate) for BIMI to stop phishing?

DMARC at p=reject stops phishing from your exact domain regardless of BIMI. BIMI adds a visible trust signal, your authenticated logo, that helps recipients distinguish genuine emails visually. A VMC is required for Gmail and Apple Mail BIMI logo display. Yahoo Mail and Fastmail support BIMI without a VMC. Even without a VMC, DMARC enforcement is the critical protection. BIMI is the visible trust layer that rewards you for doing it.

Your AI Phishing Defence Checklist

• Secure Your Email Authentication: Configure SPF, DKIM, and DMARC (p=reject) to prevent email spoofing, and implement BIMI to display your verified brand logo.
• Protect Your Domain & DNS: Enable DNSSEC, registrar lock, and monitor lookalike domains to reduce the risk of domain hijacking and brand impersonation.
• Strengthen Account Security: Use phishing-resistant MFA (FIDO2/passkeys) for all users, especially administrators, finance teams, and executives.
• Monitor Your Domain Regularly: Verify your domain’s DMARC, DKIM, SPF, DNS, SMTP, and blacklist status using HasheTools to identify security gaps before attackers do.
• Train Employees for AI-Era Phishing: Teach staff to verify sensitive requests through a trusted secondary channel instead of relying on grammar, branding, or familiar voices.
• Prepare an Incident Response Plan: Create a documented process for reporting phishing attempts, preserving evidence, resetting compromised accounts, notifying affected parties, and responding quickly to security incidents.

Check Your Domain’s Phishing Protection Right Now

Is your DMARC enforced? Are your DKIM keys published? Is your domain on a blacklist? Find out in seconds with HasheTools, completely free, no login required.

Have you ever wondered how many websites are hosted on the same server as your domain? Whether you are managing a website, auditing hosting performance, checking security risks, or researching competitors, finding every domain hosted on the same server can reveal valuable technical insights.

Many websites, especially those using shared hosting, run on the same IP address as dozens, hundreds, or even thousands of other domains. By identifying these domains, you can better understand your hosting environment, detect suspicious neighbors, troubleshoot server-related issues, and make smarter decisions about website security and performance.

With HasheTools, you can run fast DNS, IP, email, network, and web checks from one platform. HasheTools provides free online utilities for DNS, IP, email, network, and web analysis, helping developers, IT teams, domain owners, and website administrators diagnose technical issues quickly.

What Does “Domains Hosted on the Same Server” Mean?

Every website is connected to an IP address that directs visitors to the server where the site’s files are stored.

When multiple domains share the same IP address, they are often hosted on the same server or hosting environment.

For example:

example1.com → 192.0.2.10

example2.com → 192.0.2.10

example3.com → 192.0.2.10

In this example, all three domains use the same IP address. However, this does not necessarily mean they have the same owner. They may simply be using the same shared hosting provider, cloud platform, CDN, proxy service, or server infrastructure.

Why Would You Want to Find Domains on the Same Server?

Finding domains hosted on the same server can help with security audits, SEO analysis, competitor research, and hosting troubleshooting. By identifying websites that share an IP address, you can gain valuable insights into your hosting environment and server infrastructure.

1. Website Security Audits

If your website shares a server with spammy, compromised, or poorly maintained websites, there may be indirect risks to server reputation, performance, and security.

This is especially important for:

• WordPress websites
• Shared hosting accounts
• Small business websites
• Agency-managed client sites
• E-commerce stores
• SaaS websites

A same-server domain check can help determine whether your website is hosted in a trustworthy environment.

2. SEO and Server Reputation

Although search engines evaluate websites individually, poor hosting quality can negatively affect SEO through slow page speeds, downtime, malware warnings, or a poor IP reputation.

If many suspicious or low-quality websites share the same IP address, it may be worth reviewing your hosting setup.

3. Competitor and Market Research

A reverse IP lookup can reveal websites using the same infrastructure, helping you identify:

• Sister websites
• Regional domain variations
• Campaign landing pages
• White-label platforms
• Staging or test environments
• Related business websites

This information can support competitor analysis, digital marketing research, and domain intelligence.

4. Troubleshooting Hosting Issues

If multiple domains on the same IP address are experiencing downtime or performance problems, the issue may be server-wide rather than limited to a single website.

Common causes include:

• DNS configuration issues
• Hosting server outages
• Shared IP misconfigurations
• SSL certificate problems
• Firewall restrictions
• CDN or proxy issues
• Server overload

5. Detecting Unauthorized Domains

For VPS and dedicated server owners, checking domains hosted on the same IP can help identify unknown or unauthorized websites connected to your infrastructure.

This can help system administrators maintain better visibility, security, and server control.

How Domains Are Connected to a Server

To understand how to find domains on the same server, you need to understand a few basic DNS concepts.

A Record

An A record connects a domain name to an IPv4 address.

Example:

example.com → 192.0.2.10

AAAA Record

An AAAA record connects a domain name to an IPv6 address.

Example:

example.com → 2001:db8::1

CNAME Record

A CNAME record points one domain or subdomain to another hostname.

Example:

www.example.com → example.com

PTR Record

A PTR record is used for reverse DNS. It maps an IP address back to a hostname.

HasheTools’ All DNS Records Lookup can retrieve multiple DNS records, including A, AAAA, CNAME, MX, TXT, NS, SOA, and PTR records, which helps users review a domain’s full DNS configuration in one place.

The Best Ways to Find Every Domain Hosted on the Same Server

There are several ways to identify domains hosted on the same server. The most common methods include IP lookup, DNS record lookup, reverse IP lookup, and hosting analysis.

Method 1: Find the Domain’s IP Address

The first step is to find the IP address of the domain you want to investigate.

You can do this using a DNS lookup tool.

Steps:

1. Go to HasheTools.
2. Open a DNS lookup or all DNS records tool.
3. Enter the domain name.
4. Check the A record or AAAA record.
5. Copy the IP address shown in the result.

Example:

yourdomain.com → 203.0.113.25

Once you have the IP address, you can use it to search for other domains connected to the same server.

Method 2: Use a Reverse IP Lookup

A reverse IP lookup checks which domains are associated with a specific IP address.

Instead of asking:

What IP does this domain use?

Reverse IP asks:

What domains use this IP?

This is the most direct method to find websites hosted on the same server.

Example:

IP Address: 203.0.113.25

Possible hosted domains:

– example.com

– example.net

– samplebusiness.com

– clientsite.org

Reverse IP lookup is especially useful for checking shared hosting environments.

Method 3: Check All DNS Records

Sometimes, a domain may not directly point to a simple hosting IP. It may use:

• CDN services
• Cloud hosting
• Load balancers
• Proxy services
• Multiple A records
• IPv6 records
• CNAME chains

That is why checking all DNS records is important.

Using HasheTools’ All DNS Records Lookup, you can retrieve a complete overview of a domain’s DNS records instead of checking A, MX, TXT, CNAME, or NS records separately. The tool is designed for domain administrators, network engineers, and security specialists who need to audit or troubleshoot DNS configurations. (HasheTools)

Look for:

• A records
• AAAA records
• CNAME records
• NS records
• PTR records
• MX records
• TXT records

This gives you a better understanding of how the domain is configured and where it may be hosted.

Method 4: Use Command Line Tools

If you are comfortable using a terminal, you can also find the IP address of a domain manually.

Using nslookup

nslookup example.com

Using dig

dig example.com A

Using host

host example.com

These commands help you identify the IP address behind a domain. After that, you can use a reverse IP lookup tool to discover other domains connected to the same IP.

Method 5: Check the Hosting Provider

Once you have the IP address, you can also check which hosting provider owns it.

This can help you understand whether the domain is hosted on:

• Shared hosting
• VPS hosting
• Dedicated server
• Cloud infrastructure
• CDN network
• Managed WordPress hosting
• Enterprise hosting

For example, if the IP belongs to a common shared hosting provider, you may find many unrelated websites on the same server. If it belongs to a private server or dedicated infrastructure, there may be fewer domains.

Method 6: Analyze Nameservers

Nameservers can also reveal hosting or DNS provider information.

Example:

ns1.hostingprovider.com

ns2.hostingprovider.com

If many domains use the same nameservers and IP address, they may be connected through the same hosting environment.

However, nameservers alone do not always prove that websites are hosted on the same server. They only show where DNS is managed.

Method 7: Check SSL Certificate Data

Some domains hosted together may appear in SSL certificate records, especially when multiple domains are included in the same certificate.

This can reveal:

• Alternative domain names
• Subdomains
• Related websites
• Brand-owned domains
• Development or staging domains

However, SSL certificate data should be used carefully. It may not show every domain on the server, and many modern websites use separate certificates.

Step-by-Step: How to Find Domains Hosted on the Same Server

Here is a simple workflow you can follow.

Step 1: Enter the Domain

Start with the domain you want to investigate.

Example:

example.com

Step 2: Find Its IP Address

Use HasheTools to check DNS records and identify the domain’s A record or AAAA record.

Step 3: Copy the IP Address

Copy the IP address returned in the DNS result.

Example:

203.0.113.25

Step 4: Run a Reverse IP Lookup

Use a reverse IP lookup method to find other domains connected to the same IP address.

Step 5: Review the Domain List

Check the returned domains carefully. Look for:

• Suspicious websites
• Unrelated websites
• Competitor domains
• Client websites
• Staging domains
• Old or abandoned websites

Step 6: Verify the Results

Not every result will always be current. DNS changes over time, and some reverse IP databases may contain outdated records.

Verify important domains by checking their current DNS records.

Step 7: Take Action

Depending on your findings, you may decide to:

• Move to better hosting
• Upgrade to VPS or dedicated hosting
• Improve website security
• Review DNS configuration
• Remove unknown domain mappings
• Contact your hosting provider
• Audit neighboring domains

What to Look for in Same-Server Domain Results

When you find domains hosted on the same IP, do not just count them. Review their quality and relevance.

Check for Spammy Domains

If the server hosts many spam, adult, phishing, gambling, or malware-related websites, it may be a warning sign.

Check for Too Many Websites

A very high number of domains may indicate overcrowded shared hosting, which can affect performance.

Check for Similar Ownership

If several domains appear to belong to the same company, it may indicate a network of related websites.

Check for Old or Abandoned Sites

Outdated sites on the same server may create security risks if they are not maintained.

Check for Blacklist Issues

If the shared IP address is blacklisted, email deliverability and server reputation may suffer.

Shared Hosting vs Dedicated Hosting

Shared Hosting vs VPS vs Dedicated vs Cloud Hosting

Understanding your hosting type is important when evaluating domains hosted on the same server. Different hosting environments affect performance, security, resource allocation, and the number of websites sharing an IP address.

Hosting Type	Description	Advantages	Disadvantages
Shared Hosting	Multiple websites share the same server and IP address.	Low cost, easy setup, provider-managed maintenance.	Shared resources, less control, potential performance issues.
VPS Hosting	Virtualized server resources provide greater isolation than shared hosting.	Better performance, more control, improved security.	Higher cost and more technical management.
Dedicated Hosting	A single organization uses an entire server.	Maximum control, strong performance, better isolation.	Expensive and requires server administration expertise.
Cloud Hosting	Resources are distributed across scalable cloud infrastructure.	Scalable, reliable, flexible, and highly available.	Can be more complex, and pricing may vary based on usage.

Which Hosting Type Is Best?

• Shared Hosting is suitable for personal websites, blogs, and small businesses.
• VPS Hosting is ideal for growing websites that need more control and resources.
• Dedicated Hosting is best for high-traffic websites, e-commerce stores, and business-critical applications.
• Cloud Hosting is a popular choice for modern applications that require scalability and reliability.

When analyzing domains hosted on the same server, remember that shared hosting environments often contain many unrelated websites, while dedicated and VPS hosting typically provide greater isolation and control.

Does Sharing a Server Affect SEO?

Sharing a server does not automatically hurt SEO. Many websites use shared hosting without any problem.

However, SEO can be affected indirectly if the shared server causes:

• Slow loading speed
• Frequent downtime
• Poor uptime
• Malware infections
• Bad IP reputation
• Email deliverability issues
• Security warnings
• Crawl errors

Search engines care about user experience, reliability, and website quality. If your hosting environment creates technical problems, your SEO performance may suffer.

Common Misconceptions About Domains Hosted on the Same Server

When analyzing domains that share the same IP address, it’s important to avoid some common misconceptions.

Same IP Address Means the Same Owner

Not necessarily. Many hosting providers place hundreds or even thousands of unrelated websites on the same IP address through shared hosting services.

Domains on the Same IP Are Part of the Same Website Network

Sharing an IP address does not automatically mean websites are connected. They may simply use the same hosting provider, cloud platform, CDN, or server infrastructure.

Reverse IP Lookup Results Are Always Complete

Reverse IP lookup tools rely on publicly available DNS data and third-party databases. As a result, some domains may be missing, outdated, or hidden behind CDN and proxy services.

Shared Hosting Is Always a Bad Choice

Shared hosting is a cost-effective option for blogs, personal websites, and small businesses. Problems typically arise only when servers are overcrowded, poorly maintained, or hosting suspicious websites.

Key Takeaway

Finding domains hosted on the same server can provide valuable insights, but the results should always be interpreted carefully. Shared IP addresses do not prove common ownership, and reverse IP data may not always reflect the complete hosting environment.

Limitations of Finding Domains on the Same Server

Reverse IP lookup is a useful way to identify domains that share an IP address, but the results are not always complete or perfectly accurate. Several factors can limit visibility into a website’s actual hosting environment.

CDN and Proxy Services Can Hide the Origin Server

Websites that use Cloudflare, Akamai, or other CDN and proxy services often display the CDN’s IP address rather than the origin server’s real IP. As a result, reverse IP lookups may show domains sharing the CDN infrastructure instead of the actual hosting server.

Load Balancers and Multiple IP Addresses

Large websites frequently use load balancers and multiple IP addresses to distribute traffic. This can make it difficult to determine all domains associated with a specific server.

DNS Records Change Over Time

Domains can move between hosting providers or servers. Some reverse IP databases may contain outdated information, resulting in domains that are no longer hosted on the same infrastructure.

Shared IP Pools

Many hosting providers assign websites to shared IP pools. In these environments, a single IP address may represent hundreds or even thousands of websites rather than a single physical server.

Private and Internal Domains May Not Be Visible

Staging sites, development environments, internal systems, and private domains are often not publicly indexed, which means they may not appear in reverse IP lookup results.

Best Practices Before Making Decisions

Reverse IP lookup results should not be the only factor when evaluating a hosting environment. Before making any hosting, SEO, or security decisions, follow these best practices:

• Verify DNS Records: Check the current A and AAAA records for important domains.
• Test Server Performance: Review page speed, uptime, and server response times.
• Review Website Security: Scan for malware, outdated software, and security vulnerabilities.
• Check IP Reputation: Verify whether the shared IP address appears on spam or blacklist databases.
• Consult Your Hosting Provider: Ask about server isolation, resource allocation, and security measures.
• Evaluate Hosting Needs: Consider upgrading to VPS, cloud, or dedicated hosting if your website requires greater performance, security, or control.

How HasheTools Helps with Domain and Server Analysis

Investigating domains hosted on the same server often requires checking DNS records, IP addresses, and other network-related data. HasheTools simplifies this process by providing a collection of free online tools for DNS, IP, email, network, and website analysis.

With HasheTools, you can:

• Check DNS records for any domain
• Find A and AAAA records
• Review complete DNS configurations
• Validate domain settings
• Investigate IP and network information
• Troubleshoot DNS-related issues
• Support hosting, migration, and security audits

For this use case, the All DNS Records Lookup tool is particularly useful because it retrieves multiple DNS record types in a single search, including A, AAAA, CNAME, MX, TXT, NS, SOA, and PTR records. This provides a comprehensive view of a domain’s DNS configuration, helping website owners, developers, and IT teams diagnose hosting and connectivity issues more efficiently.

Practical Use Cases

Domain hosting on the same server analysis can be valuable for different professionals and organizations:

• Website Owners: Evaluate hosting quality and identify whether a crowded shared server may be affecting performance.
• SEO Professionals: Investigate IP reputation, hosting-related SEO issues, and server reliability.
• Developers: Troubleshoot DNS, hosting, staging, and deployment problems.
• Agencies: Audit client websites and assess hosting performance and security risks.
• Security Teams: Identify suspicious neighboring domains and potential infrastructure exposure.
• Domain Investors: Research related websites, domain networks, and parked domains.

When Should You Move Away from Shared Hosting?

Shared hosting is suitable for many websites, but there are situations where upgrading may be beneficial.

Consider moving to VPS, cloud, or dedicated hosting if:

• Your website experiences slow loading times.
• Server downtime is affecting reliability.
• Your IP address is associated with suspicious or spammy domains.
• You run an e-commerce or business-critical website.
• You handle sensitive customer or business data.
• Your traffic and resource requirements are growing.
• You need greater control over security and server configuration.
• Email deliverability issues are linked to a shared IP reputation.

For personal websites and low-traffic blogs, shared hosting is often sufficient. However, growing businesses, SaaS platforms, and online stores may benefit from more isolated and scalable hosting environments.

FAQs

1. What is a reverse IP lookup?

A reverse IP lookup identifies domains associated with a specific IP address. It is commonly used to discover websites that may share the same server or hosting infrastructure.

2. Can I find every domain hosted on the same server?

Not always. Reverse IP lookup can identify many domains sharing an IP address, but CDN services, private networks, load balancers, and outdated DNS records can limit visibility.

3. How do I find a website’s IP address?

You can use a DNS lookup tool to view a domain’s A record (IPv4) or AAAA record (IPv6), which reveals the IP address associated with the website.

4. Why do multiple domains share the same IP address?

Multiple domains often share the same IP because they use shared hosting, cloud infrastructure, CDN services, or the same hosting provider.

5. Can domains on the same server affect SEO?

Sharing a server does not directly affect SEO. However, poor server performance, downtime, malware issues, or a bad IP reputation can indirectly impact search rankings and user experience.

6. Can Cloudflare hide a website’s real server IP?

Yes. Cloudflare and other CDN providers can mask the origin server’s IP address by displaying their own network IPs instead.

Conclusion

Finding domains hosted on the same server can provide valuable insights for website audits, SEO analysis, security assessments, and hosting evaluations. By identifying a domain’s IP address and using reverse IP lookup techniques, you can discover other websites sharing the same infrastructure and gain a better understanding of your hosting environment.

However, it’s important to interpret the results carefully. Shared IP addresses do not necessarily indicate common ownership, and factors such as CDN services, proxy networks, load balancers, and outdated DNS data can affect the accuracy of reverse IP results. For the most reliable analysis, combine reverse IP lookups with DNS records, hosting research, security checks, and performance testing.

With HasheTools, you can quickly analyze DNS records, IP addresses, and domain configurations from a single platform. Whether you’re a website owner, developer, SEO professional, or IT administrator, these tools can help you make more informed decisions about your hosting, security, and online infrastructure.

Search is changing. People are no longer relying only on Google to find information, products, and services. AI tools like ChatGPT, Claude, Perplexity, and Gemini are increasingly being used to answer questions and recommend resources.

As AI-powered search grows, many website owners are asking a new question: How do AI systems understand and prioritize website content?

One proposed solution is LLMS.TXT, a file designed to help large language models identify a website’s most important pages, resources, and documentation.

But does your website actually need LLMS.TXT in 2026? Does it improve SEO? Does Google use it? And how is it different from robots.txt?

In this guide, we’ll explain what LLMS.TXT is, how it works, its potential benefits and limitations, and whether it’s worth implementing on your website.

What Is LLMS.TXT?

LLMS.TXT is a plain text or Markdown file placed at the root of a website, typically:

https://yourdomain.com/llms.txt

Its purpose is to provide AI systems with a clear overview of a website’s most important content, resources, and pages.

According to the original LLMS.TXT proposal, the file helps large language models quickly identify relevant information when processing website content.

In simple terms, LLMS.TXT tells AI systems:

“This is what our website is about, and these are the key resources you should focus on.”

A typical LLMS.TXT file may include:

• A brief website description
• Important pages and resources
• Product or service information
• Documentation and help center links
• Blog categories or cornerstone content
• API documentation
• Notes about priority content

Unlike a sitemap, which focuses on URL discovery, LLMS.TXT is designed to provide context and highlight the most valuable content on a website.

Why Is LLMS.TXT Being Discussed in 2026?

LLMS.TXT has gained attention because AI-powered search is changing how people discover information online. Instead of browsing multiple search results, users increasingly ask tools like ChatGPT, Claude, Perplexity, and Gemini for direct answers.

For example, rather than searching for “best CRM tools for small businesses,” a user might ask:

“What are the best CRM tools for a small real estate agency with a limited budget?”

AI systems can then summarize options, compare features, and recommend resources.

This shift has created a new challenge for website owners. Traditional SEO focuses on search engine rankings, while AI visibility focuses on making content easy for AI systems to understand, summarize, and reference.

However, Google has stated that websites do not need LLMS.TXT or other special AI-specific files to appear in its AI-powered search experiences. As a result, LLMS.TXT should be viewed as an optional AI-readability layer rather than a replacement for SEO.

How Does LLMS.TXT Work?

LLMS.TXT provides AI systems with a structured overview of a website’s most important content.

When an AI crawler, assistant, or retrieval system accesses your website, it may check for an LLMS.TXT file to quickly identify key pages, documentation, services, and resources. Rather than analyzing hundreds of URLs, the file highlights the content you consider most important.

A simplified example might look like this:

# Website Name

Short description of the website.

## Important Pages

– Home

– Services

– Blog

– Contact

## Key Resources

– SEO Guide

– Documentation

– Help Center

This structure helps AI systems understand your website’s purpose and prioritize important content. The proposed LLMS.TXT specification uses Markdown formatting and organized links to make information easier to interpret.

LLMS.TXT vs Robots.txt: What Is the Difference?

Many people confuse LLMS.TXT with robots.txt, but they serve different purposes.

Robots.txt

Robots.txt tells crawlers which parts of a website they can or cannot access.

Example:

User-agent: GPTBot

Disallow: /private/

LLMS.TXT

LLMS.TXT does not control crawler access. Instead, it provides AI systems with a structured overview of a website’s most important content.

Example:

## Best Resources

– Pricing Guide

– Product Documentation

– Case Studies

Key Difference

Robots.txt	LLMS.TXT
Controls crawler access	Provides content context
Helps manage crawling	Helps AI understand content
Can restrict bots	Cannot block bots

If you want to limit AI crawler access, use robots.txt or other crawler-control tools. If you want to help AI systems understand your website’s key resources, LLMS.TXT may be useful.

LLMS.TXT vs Sitemap.xml

A sitemap.xml file helps search engines discover URLs on your website.

An LLMS.TXT file helps AI systems understand which pages are most important and what your website is about.

Sitemap.xml is for discovery

It tells search engines:

“Here are the URLs on my website.”

LLMS.TXT is for understanding

It tells AI systems:

“Here are the most meaningful resources on my website.”

For SEO, sitemap.xml is still more important. LLMS.TXT is an additional layer, not a substitute.

Does Google Use LLMS.TXT?

As of Google’s 2026 documentation, website owners do not need an LLMS.TXT file to appear in Google’s AI-powered search experiences. Google has stated that special AI-specific files like LLMS.TXT are not required for visibility in Google Search. (Google for Developers)

This is important because LLMS.TXT is sometimes presented as a new SEO ranking factor. It is not.

Google continues to emphasize the same fundamentals that have long supported search visibility:

• High-quality, helpful content
• Fast website performance
• Crawlable pages
• Strong internal linking
• Mobile-friendly design
• Schema markup where appropriate
• Clear author and brand signals

If your primary goal is improving Google SEO, focus on these foundations first. LLMS.TXT should be viewed as an optional AI-readability enhancement rather than a replacement for traditional SEO.

Do AI Companies Use LLMS.TXT?

Adoption of LLMS.TXT is still evolving. Some organizations and documentation-heavy platforms have started implementing LLMS.TXT or similar files. For example, Cloudflare provides LLMS.TXT-style documentation resources, and Yoast SEO offers a feature that can automatically generate and update an LLMS.TXT file for WordPress websites.

However, support across major AI platforms is not yet universal. As a result, LLMS.TXT should be viewed as a future-focused optimization that may improve AI readability, rather than a proven method for increasing traffic or search visibility.

Does LLMS.TXT Improve SEO Rankings?

No direct evidence shows that LLMS.TXT improves traditional Google rankings.

Google has stated that LLMS.TXT is not required for appearing in its AI-powered search experiences and is not a confirmed ranking factor.

However, LLMS.TXT may support a broader AI visibility strategy by helping AI systems identify and understand your most important content more efficiently.

Think of it as an organizational layer rather than an SEO ranking signal. While it is unlikely to improve rankings directly, it can make your website’s key resources easier for AI systems to discover, interpret, and reference.

Does Your Website Need LLMS.TXT in 2026?

Not every website needs LLMS.TXT in 2026, but it can be useful for websites that want to improve how AI systems understand and interpret their content. It works best as an additional layer for AI visibility rather than a core SEO requirement.

 

LLMS.TXT is most useful for websites that have structured or content-heavy platforms such as SaaS products, blogs, documentation sites, or service-based businesses.

Should Blogs Use LLMS.TXT?

Yes, blogs can benefit from LLMS.TXT, especially if they have a large number of articles. It helps highlight cornerstone and evergreen content so AI systems can better identify the most important guides instead of scanning every post equally.

For blogs, focus on including:

• Pillar or cornerstone posts
• In-depth guides
• Category pages
• High-performing evergreen content

Avoid listing every blog post, as it reduces clarity and effectiveness.

Should Small Business Websites Use LLMS.TXT?

Small business websites can use LLMS.TXT, but it should not be a priority over core SEO practices.

For small businesses, it is better to first focus on:

• Service pages
• Local SEO
• Google Business Profile
• Reviews and trust signals
• Fast and mobile-friendly design

Once these foundations are strong, LLMS.TXT can be added as a simple enhancement to improve AI readability by including key pages like services, contact, and core information.

The Main Benefits of LLMS.TXT

1. Helps AI Systems Understand Your Website

AI systems do not always need every page on your website. LLMS.TXT provides a curated overview of your most important content, making it easier to identify key resources and understand your site’s structure.

2. Improves Content Prioritization and AI Visibility

Websites often contain service pages, blog posts, documentation, case studies, and support resources. LLMS.TXT helps highlight the content that matters most, making it easier for AI systems to identify, understand, and reference valuable information. While it is not a ranking factor, it can support broader AI visibility and GEO efforts when combined with strong content and website structure.

3. Easy to Implement

Creating an LLMS.TXT file is relatively simple. Most websites can create a Markdown file, add links to important resources, and place it in the website root directory. Some WordPress tools are also beginning to support automated generation.

4. Future-Proofs Your Website

LLMS.TXT is still an emerging standard, but adopting it now can help prepare your website for future AI search and content discovery developments.

The Limitations of LLMS.TXT

LLMS.TXT can be useful, but it is not a complete solution.

1. It Does Not Control AI Crawlers

LLMS.TXT does not block or restrict bots. If you want to manage crawler access, use robots.txt, server-side controls, or AI crawler management tools.

2. It Does Not Replace SEO

LLMS.TXT cannot fix poor content, slow pages, weak technical SEO, or a poor user experience. Strong SEO fundamentals remain essential.

3. Adoption Is Still Limited

LLMS.TXT is a proposed standard, and support across AI platforms is not yet universal. Its long-term role is still evolving.

4. It Requires Maintenance

An outdated LLMS.TXT file can point AI systems to old or less relevant content. Review and update it whenever you publish major content or change your site structure.

What Should Be Included in an LLMS.TXT File?

A good LLMS.TXT file should be simple, focused, and easy to understand. Rather than listing every page on your website, include only the resources that best represent your business, products, services, and expertise.

Recommended Structure

# Website Name

Short description of your website and its purpose.

## Core Pages

– Home

– About

– Services

– Contact

## Key Resources

– Important service pages

– Product pages

– Documentation

– Help center articles

## Best Guides

– Cornerstone blog posts

– Tutorials

– Research-based content

## Optional

– Case studies

– Pricing page

– FAQs

Best Practices

When creating an LLMS.TXT file:

• Include only important pages
• Keep the file concise and organized
• Use clear Markdown formatting
• Link to evergreen resources when possible
• Avoid keyword stuffing
• Review and update the file regularly

How to Create an LLMS.TXT File

Creating an LLMS.TXT file is straightforward and only requires a few steps:

1. Identify Your Most Important Pages

Start by selecting the pages that best represent your website and expertise. These may include your homepage, service or product pages, documentation, key blog guides, FAQs, case studies, and contact page. Focus on the content you want AI systems to understand and prioritize.

2. Organize and Describe Your Resources

Group related pages under clear headings such as Services, Products, Documentation, Resources, or Blog Guides. Where helpful, add short descriptions to explain the purpose of important pages and resources. Keep the structure simple, organized, and easy to understand.

3. Publish and Maintain the File

Save the file as llms.txt and upload it to your website’s root directory so it is accessible at yourdomain.com/llms.txt. Review and update the file regularly whenever you publish important content, launch new services, update documentation, or make significant changes to your website structure.

LLMS.TXT and AI Crawlers: What Website Owners Should Know

As AI-powered search continues to grow, many website owners want more control over how AI systems interact with their content. It is important to understand that LLMS.TXT is not a crawler control tool.

If you want to allow, block, or manage AI crawlers such as GPTBot, you should use robots.txt or other bot management solutions. Robots.txt controls crawler access, while LLMS.TXT provides context by highlighting your website’s most important pages and resources.

In simple terms:

• robots.txt = Controls crawler access
• sitemap.xml = Helps discover URLs
• LLMS.TXT = Helps AI understand your content

For most websites, these tools work best together. Robots.txt manages access, sitemap.xml supports content discovery, and LLMS.TXT provides additional context about your website’s key information.

Common LLMS.TXT Mistakes to Avoid

Treating It as a Ranking Hack: LLMS.TXT is not a shortcut to better Google rankings. It should not be expected to deliver direct SEO gains.

Adding Too Many Links: A bloated file reduces clarity and usefulness. Keep only the most important and relevant pages.

Keyword Stuffing: Avoid turning LLMS.TXT into a keyword-heavy or spammy file. It should be simple and natural.

Not Updating It Regularly: An outdated LLMS.TXT can mislead AI systems by pointing to old or irrelevant content.

Replacing Sitemap.xml: LLMS.TXT is not a replacement for sitemap.xml. Both serve different purposes and should be used together.

Using It for Bot Blocking: LLMS.TXT does not control or block crawlers. Use robots.txt or server-side tools for access control.

Is LLMS.TXT Part of GEO?

LLMS.TXT can be considered a small part of Generative Engine Optimization (GEO), but it is not the core of it.

GEO focuses on making content easier for AI systems to understand, trust, summarize, and cite. It is about improving overall content quality and structure, so AI models can use it effectively.

A strong GEO strategy includes:

• Expert, experience-driven content
• Clear and direct answers to user questions
• Entity optimization (brands, topics, and relationships)
• Schema markup for structured data
• Original insights and data
• Strong author credibility
• Regularly updated information
• Internal linking and topical clusters
• Consistent brand signals
• Crawlable and well-structured pages

LLMS.TXT fits into this ecosystem as a supporting layer, helping AI systems quickly identify important pages, but it does not replace high-quality content, SEO fundamentals, or structured data.

FAQs About LLMS.TXT

1. Is LLMS.TXT the same as robots.txt?

No. Robots.txt controls crawler access. LLMS.TXT provides context and guidance for AI systems.

2. Does LLMS.TXT improve Google rankings?

No direct evidence shows that LLMS.TXT improves Google rankings. Google says LLMS.TXT is not needed for appearing in its generative AI search features.

3. Should every website have LLMS.TXT?

Not every website needs it. It is most useful for websites with important content, documentation, guides, product information, or service pages.

4. Can LLMS.TXT block AI crawlers?

No. LLMS.TXT does not block crawlers. Use robots.txt, server controls, or AI crawler management tools for that.

5. What should I include in LLMS.TXT?

Include your most important pages, service pages, documentation, guides, resources, and short descriptions of your website’s key content.

Conclusion

LLMS.TXT is not essential for every website in 2026, but it can help AI systems better understand your most important content and resources. While it supports AI visibility and GEO efforts, it should be used alongside—not instead of—strong SEO fundamentals such as high-quality content, technical optimization, and structured data.

If you’re planning to implement LLMS.TXT, use the HasheTools LLMS.TXT Checker to quickly analyze your file, identify issues, and ensure it follows current best practices. As AI-powered search continues to grow, small optimizations like LLMS.TXT can help keep your website future-ready.

A website can look completely legitimate and still be dangerous. In 2026, phishing sites use valid HTTPS certificates, AI-generated designs, cloned login pages, and lookalike domains that are often impossible to spot at first glance.

That’s why checking whether a domain is safe before visiting is more important than ever. A quick safety check can help you avoid phishing attacks, malware downloads, fake online stores, and credential theft.

In this guide, you’ll learn how to verify a domain using practical checks like:

• URL and domain inspection
• WHOIS and domain age lookup
• SSL certificate verification
• DNS and DMARC analysis
• Blacklist and reputation checks

You’ll also discover how to use free tools from HasheTools.com to investigate suspicious domains, detect phishing websites, and verify website legitimacy before clicking any link.

Why Checking a Domain’s Safety Matters in 2026

Every link you click, every URL you type, and every domain you visit involves a trust decision. In 2026, that trust decision is more consequential than ever. Cybercriminals have access to AI-powered phishing tools that generate convincing lookalike websites at scale, buy aged domains with established reputations, and obtain valid SSL certificates for malicious sites within minutes of registering them.

The old indicators of safety no longer work in isolation. A website can have a padlock (HTTPS), look exactly like your bank, use a domain name that’s only one character different from the real one, and still be a sophisticated phishing site designed to steal your credentials, install malware, or hijack your session.

The solution: a systematic, multi-layer domain safety check that goes beyond the padlock icon and looks at DNS records, registration details, blacklist status, certificate details, and behavioural signals together. This guide walks you through every layer.

How Attackers Use Malicious Domains in 2026

Understanding the attack types helps you know what to look for during a safety check:

Typosquatting

Registering domains with common misspellings of legitimate brands: paypa1.com, arnazon.com, micros0ft.com. Victims type or click slightly wrong and land on a fake site that looks identical to the real one.

Lookalike Domains

Domains that use different TLDs or subdomains to appear legitimate: paypal.com.verify-account.net (the real domain here is verify-account.net, not paypal.com), or support.apple.com.phish.xyz.

Homoglyph Attacks

Using characters that look visually identical to legitimate letters, Cyrillic ‘a’ instead of Latin ‘a’, or Unicode lookalikes. The domain appears correct even on close inspection, but it is a completely different domain.

Aged Domain Abuse

Buying domains with years of legitimate history, then repurposing them for malware or phishing. These domains pass age-based reputation checks because they were genuinely used for something benign previously.

HTTPS Abuse

Obtaining a valid SSL certificate for a phishing domain. The padlock is real, the site is encrypted, but the certificate only proves identity to that domain name, not that the site is legitimate.

AI-Generated Phishing Sites

In 2026, AI tools can clone a website’s appearance in seconds. Attackers scrape a legitimate site’s HTML, CSS, and images, then serve a perfect copy from a malicious domain to harvest credentials.

Step 1: Check the URL Carefully

The domain name itself is the first and most important thing to inspect. This sounds obvious, but it is surprisingly easy to get wrong, especially on mobile devices where the full URL is often hidden or truncated.

Anatomy of a URL

URL structure: know what each part means

https://secure.paypal.com/signin/confirm?token=abc123   ^       ^      ^         ^   |       |      |         | Protocol  |    Domain    Path/Query      Subdomain   |               TLD (.com) # The REAL domain is always the part immediately before the first single / # after the protocol in this case: paypal.com # # DANGER EXAMPLES: # paypal.com.login.verify-now.net   <- real domain is verify-now.net # http://192.168.1.1/paypal/login   <- IP address, not a domain # paypa1.com                        <- digit 1 replacing letter l # pаypal.com                        <- Cyrillic ‘a’ (looks identical)

What to Check in the URL

• Identify the real domain: Find the part just before the first lone slash (/) that is the actual domain you’re visiting. Everything before it (subdomains) does not change who owns the domain.
• Check the TLD: Legitimate businesses use .com, .org, .net, .gov, .edu, and country TLDs. Be wary of unusual TLDs (.xyz, .click, .loan, .top, .gq) on sites claiming to be major brands, though note many legitimate sites also use modern TLDs.
• Look for character substitution: Check for 0 (zero) instead of O, 1 (one) instead of l or I, rn instead of m, vv instead of w.
• Copy to a text editor: Paste the URL into Notepad or a similar text editor to see it in a plain font where homoglyphs are easier to spot.
• Check for extra subdomains: apple.com.account.verify.ru is NOT apple.com. The domain is verify.ru.
• Hover before clicking: On desktop, hover over a link to see the real URL in the browser status bar before clicking.

Step 2: Check HTTPS and the SSL Certificate

HTTPS and a padlock icon are necessary but not sufficient for safety. A padlock only means the connection between your browser and the server is encrypted; it says nothing about whether the server belongs to a legitimate organisation or is run by an attacker.

Let’s Encrypt and other free SSL providers issue certificates automatically to any domain, including phishing sites. In 2026, over 80% of phishing sites have valid HTTPS certificates. The padlock is not a safety badge.

What to Check in the SSL Certificate

1. Click the padlock icon (or the information icon on Chrome) in your browser’s address bar.
2. View the certificate details (look for ‘Certificate’ or ‘More information’)
3. Check the ‘Issued to’ or ‘Common Name’ field; it should match the exact domain you’re visiting.
4. Check the Certificate Authority (CA): recognised CAs: DigiCert, Sectigo, GlobalSign, Let’s Encrypt, Amazon, Microsoft. Unknown or self-signed CAs are red flags.
5. Check the certificate type: DV (Domain Validated) only proves domain control. OV (Organisation Validated) and EV (Extended Validation) verify the organisation’s legal identity and provide higher trust for banking and financial sites.

Certificate Type	What It Proves	When to Expect It
DV: Domain Validated	Domain owner controls the domain	Free; any site, including phishing sites, can get this
OV: Organisation Validated	Legal organisation identity verified	Small to mid-size businesses, SaaS companies
EV: Extended Validation	Rigorous legal entity verification	Banks, financial institutions, e-commerce leaders
Self-Signed	Nothing anyone can create these	Internal tools only, never on a public website; you should trust it

Step 3: Look Up the Domain Age and WHOIS Data

Domain registration data is publicly available through WHOIS, a database that records when a domain was registered, who registered it, through which registrar, and when it expires. This information is one of the most reliable indicators of domain legitimacy.

How to Run a WHOIS Lookup

Use HasheTools WHOIS Lookup at hashetools.com, enter the domain, and instantly see registration details, registrar, creation date, expiry date, and nameservers.

WHOIS lookup via command line

# macOS / Linux whois yourdomain.com # Look for these key fields: # Creation Date: 2024-03-15T08:00:00Z   <- when domain was registered # Expiry Date:   2025-03-15T08:00:00Z   <- when domain expires # Registrar:     NameCheap, Inc.        <- who it was registered through # Registrant:    [REDACTED]             <- owner (often privacy-protected) # Name Server:   ns1.example.com        <- where DNS is hosted

What to Look for in WHOIS Data

• Registration date: A domain registered within the last 30 days claiming to be a major brand or financial institution is an immediate red flag. Legitimate brands register domains years or decades before you encounter them.
• Expiry date: A domain set to expire very soon (days or weeks away) may be a throwaway attack domain. Legitimate businesses renew for years in advance.
• Registrar: Phishing domains frequently use budget registrars (Namecheap, GoDaddy, Porkbun, all legitimate registrars but also popular with attackers due to low cost and easy registration). Note: Using these registrars doesn’t make a domain malicious, but combined with other signals, it contributes to a risk profile.
• Registrant details: Most legitimate businesses have organisation details in WHOIS (or use registrar privacy protection). Be wary of domains with obviously fake registrant information (gibberish names, fake addresses).
• Nameservers: Check if the nameservers are consistent with what you’d expect from the claimed organisation’s hosting infrastructure.

WHOIS Signal	Suspicious	Legitimate
Domain age	Registered < 30 days ago	Registered years ago, matching brand history
Expiry date	Expiring soon or < 1 year registration	Renewed for multiple years
Registrant name	Privacy-protected + brand claim	Organisation name matches brand
Registrar	Offshore/unknown registrar	Well-known registrar
Name servers	Free DNS provider or unknown NS	NS matching claimed organisation’s infrastructure

Step 4: Run a Blacklist Check

DNS-based blacklists (DNSBLs) and web reputation databases maintain constantly updated lists of domains and IP addresses known to be involved in spam, malware distribution, phishing, and other malicious activity. Checking a domain against these lists is one of the fastest safety signals you can get.

How Blacklists Work

Security researchers, ISPs, and automated honeypot systems continuously report malicious domains and IPs to blacklist operators. When a domain is reported for phishing, it is added to the blacklist, and email servers, DNS resolvers, and security tools worldwide query these lists to block or flag traffic from blacklisted sources.

How to Check a Blacklist with HasheTools

1. Go to hashetools.com and open the Blacklist Check tool
2. Enter the domain name or IP address you want to check
3. HasheTools queries dozens of major blacklists simultaneously and shows which ones flag the domain
4. A domain listed on any spam/malware blacklist should be treated as dangerous until investigated further

Blacklist Type	What It Flags	Examples
Email spam blacklists	IPs/domains that send spam	Spamhaus SBL, SURBL, Barracuda
Malware/phishing	Sites distributing malware or harvesting credentials	Google Safe Browsing, PhishTank, OpenPhish
DNS-based blocklists	Domains/IPs flagged by DNS resolvers	Quad9, Cloudflare RADAR, Comodo
Botnet/C2 lists	Command-and-control infrastructure for malware	Feodo Tracker, Abuse.ch URLHaus
Reputation scores	Composite trust score across multiple signals	Cisco Talos, Fortinet FortiGuard

Step 5: Inspect DNS Records

DNS records reveal a significant amount of information about a domain’s infrastructure, purpose, and configuration. Inspecting them is a layer of safety analysis that most users skip, but it’s one of the most revealing steps for technical users.

What DNS Records to Check

• A record: The IP address the domain resolves to. Check it against known cloud/hosting providers. A domain claiming to be a UK bank but resolving to an IP in a country with no connection to that bank is suspicious.
• MX records: Mail server records. Legitimate organisations have MX records matching their email provider (Google, Microsoft, etc.). A domain with no MX records but claiming to be a business that would send email is odd.
• TXT records: Check for SPF, DKIM, and DMARC records. Legitimate organisations sending emails have these configured. A domain with no SPF or DMARC claiming to be a major brand is likely a spoofing domain.
• NS records: Nameservers. Check whether the nameservers match what you’d expect from the organisation’s hosting. A ‘bank’ using free DNS hosting is a red flag.
• WHOIS nameservers vs. DNS NS records: These should match. A mismatch can indicate a hijacking attempt or misconfiguration.

Inspect DNS records using dig key safety checks

# Check what IP the domain resolves to dig suspicious-domain.com A +short # Then search the IP: is it in a country consistent with the claimed org? # Check MX records: Does a ‘business’ have professional mail setup? dig suspicious-domain.com MX +short # Check TXT records legitimate senders have SPF/DMARC dig suspicious-domain.com TXT +short # Red flag: no SPF record for a domain claiming to be a major brand # Red flag: no DMARC for a domain that sends email to customers # Check nameservers dig suspicious-domain.com NS +short # Red flag: free DNS provider (freedns.afraid.org, etc.) for a ‘bank’

Step 6: Check Website Reputation

Multiple free tools and databases aggregate reputation signals for domains, combining blacklist data, user reports, scan results, and historical behaviour into a reputation score. Use these as an additional layer of verification:

Tool / Service	What It Checks	How to Use
Google Safe Browsing	Malware and phishing detection (Google’s database)	transparencyreport.google.com/safe-browsing/search
VirusTotal	70+ antivirus and URL scanners simultaneously	virustotal.com paste URL, instant multi-scanner result
URLScan.io	Full page screenshot, DNS, network, and behaviour scan	urlscan.io scans any URL without visiting it
Cisco Talos	Email and web reputation based on threat intelligence	talosintelligence.com/reputation_center
Sucuri SiteCheck	Malware, blacklist status, and security config	sitecheck.sucuri.net
MXToolbox	Blacklist check, DNS health, and MX analysis	mxtoolbox.com/blacklists.aspx
Whois.domaintools.com	Domain age, registrant, and reputation scoring	whois.domaintools.com
HasheTools	DNS Lookup, WHOIS, Blacklist Check, DMARC, CNAME	hashetools.com all DNS-based checks in one place

URLScan.io is particularly useful because it visits the suspicious URL in a sandboxed environment and returns a screenshot, letting you see what the site looks like without exposing your own browser or device. If you’re unsure about a link, scan it with URLScan.io before clicking it yourself.

Step 7: Analyse the Page Content and Behaviour

If you’ve decided to visit the domain (ideally in a sandboxed browser or after completing all prior checks), the page itself provides additional safety signals:

Content Red Flags

• Immediate login prompt: A page that shows nothing but a login form before providing any context is a common phishing pattern, especially if it pre-populates your email address (scraped from the link)
• Urgency language: “Your account has been suspended”, “Verify within 24 hours or lose access”, “Unusual activity detected,” high-pressure language designed to bypass critical thinking
• Broken links and images: Cloned phishing sites often have broken internal links, missing images, or non-functional navigation. The attacker only built the login page.
• Mismatched branding: Slightly wrong fonts, colours, logos, or layout compared to the real brand’s website
• Unusual form fields: Asking for information a legitimate site would never request at login, Social Security Number, full credit card details on a non-payment page, mother’s maiden name
• Immediate download prompts: Being asked to download a file immediately upon visiting is a major malware distribution signal

Browser Behaviour Red Flags

• Browser warning: If Chrome, Firefox, Safari, or Edge displays a red ‘Dangerous Site’ or ‘Deceptive Site Ahead’ warning, leave immediately. These warnings are based on Google Safe Browsing and are accurate the vast majority of the time
• Redirect chains: Being redirected through multiple domains before landing on a page can indicate a malicious redirect chain designed to obscure the final malicious destination
• Pop-ups demanding action: Fake virus warnings, fake browser update prompts, fake captchas that ask you to download something
• Console errors: Opening browser dev tools (F12) and seeing JavaScript errors or requests to suspicious third-party domains can reveal malicious infrastructure

Red Flags: Signs a Domain Is Almost Certainly Dangerous

If you observe any combination of the following signals, treat the domain as malicious until proven otherwise:

Registered < 30 days ago	Claiming to be an established brand or financial institution. Legitimate companies don’t appear overnight.
The domain appears on any blacklist.	Security researchers have specifically flagged this domain for phishing, malware, or spam. Treat as confirmed dangerous.
The browser shows a security warning.	Google Safe Browsing or equivalent has already flagged the site. Leave immediately; the warning is rarely wrong.
URL contains brand name as subdomain	paypal.com.verify.net ‘paypal.com’ is the subdomain, ‘verify.net’ is the real domain. Classic phishing structure.
No DMARC / no email auth records.	A domain claiming to be a major brand but with no SPF, DKIM, or DMARC configured is likely a spoofing domain, not the real brand.
SSL certificate issued the same day as registration	A domain registered today with a same-day SSL certificate is almost certainly a phishing site. Attackers automate this process.
Homoglyph characters in a domain name	Any Unicode or non-ASCII characters in a domain claiming to be a well-known brand, such as paypał.com, for example, is an impersonation attack.
Domain resolves to an IP in an unexpected country.	Your bank’s domain resolving to an IP in Eastern Europe or Southeast Asia, with no established presence there, is a hijacking indicator.
Asks for credentials not appropriate to the context	Requesting your bank password on a page reached via a text message link, or asking for full card details to ‘verify identity’.

Green Flags: Signs a Domain Is Likely Safe

No single signal guarantees safety, but the following signals in combination provide strong evidence of legitimacy:

Domain registered years ago	A domain with 5+ years of registration history matching the claimed brand’s founding date is a strong legitimacy signal.
Consistent WHOIS organisation details	Registrant organisation name matches the claimed brand, with a business address consistent with their known headquarters.
OV or EV SSL certificate	An organisation-validated or Extended Validation certificate confirms that the Certificate Authority verified a legal entity.
DMARC at p=reject	A strict DMARC policy indicates that the organisation actively manages its email authentication in a manner consistent with legitimate business operations.
Clean blacklist status	No appearance on any major spam, malware, or phishing blacklist across dozens of databases.
MX records matching the claimed email provider	A business using Google Workspace, Microsoft 365, or a professional email provider and MX records to match.
Nameservers from the enterprise DNS provider	DNS hosted on Cloudflare, AWS Route 53, Google Cloud DNS, or an enterprise provider, consistent with a properly managed organisation.
Domain matches official brand communications.	URL matches exactly what appears in the company’s official printed materials, social media profiles, and app store listings.
No security warnings from the browser	Google Safe Browsing, Mozilla, and Microsoft SmartScreen all have clean records for this domain.

How to Check Specific Domain Types

Email Links

1 Check sender domain Does From: match the brand?

2 DMARC Lookup Is email auth enforced?

3 Hover link Does URL match claim?

4 Blacklist Check Any malicious history?

5 VirusTotal Scan the link before clicking

Email is the primary delivery mechanism for malicious domains. Before clicking any link in an email: verify the sender’s domain matches the claimed brand exactly, run a DMARC lookup to confirm the brand has email authentication enforced (and therefore this email was authenticated), hover the link to inspect the URL, and scan it with VirusTotal if you’re still unsure.

Social Media Links

• URL shorteners: Links shared on Twitter/X, Instagram, and other platforms are often shortened (bit.ly, t.co, etc.). Use a URL expander to reveal the final destination before visiting.
• Verify official accounts: Check the blue verification badge and account age before trusting links shared by accounts claiming to be official brands.
• Cryptocurrency and giveaway scams: Any post promising cryptocurrency rewards, giveaways, or investment returns from a link is almost always a scam, regardless of how legitimate the account appears.

E-Commerce Domains

• Check for secure checkout: Payment pages must be on the same domain you browsed to, not redirected to a different domain.
• Verify with company registration: For unknown online stores, search the company name + ‘scam’ or check Companies House (UK), BBB (US), or ASIC (Australia)
• Unrealistic pricing: Products priced 80-90% below retail are almost always either counterfeit, non-existent, or a payment credential harvesting operation

File Download Links

• Domain must match the software vendor: Software downloads must come from the official vendor’s domain, not a ‘mirror’ site you’ve never heard of
• Scan with VirusTotal: For any downloadable file, scan the URL with VirusTotal before downloading, and scan the file itself after
• Check the file extension: A file named ‘document.pdf.exe’ or ‘invoice.zip’ contains an executable disguised as a document.

Frequently Asked Questions

Does HTTPS mean a website is safe?

No. HTTPS only encrypts the connection between your browser and the website. It does not guarantee the website itself is legitimate. Many phishing sites use valid HTTPS certificates, so always verify the domain name, WHOIS age, and blacklist status before trusting a site.

How can I check a link without clicking it?

On desktop, hover over the link to preview the real URL in your browser’s status bar. On mobile, press and hold the link to view the full destination. You can also paste the URL into tools like VirusTotal or URLScan.io to analyse it safely without visiting the site.

What should I do if I accidentally click a suspicious link?

Do not enter any information or download files. Close the tab immediately and run a malware scan on your device. If you entered credentials, change your password immediately from the official website and enable two-factor authentication where possible.

Can a domain that is 10 years old still be dangerous?

Yes. Attackers often purchase aged domains because they already have a reputation history and may bypass basic trust checks. Always combine domain age with blacklist checks, DNS analysis, and website behaviour before trusting a site.

How do I check if a shortened URL is safe?

Avoid clicking shortened URLs directly. Use a URL expander tool to reveal the final destination first, then check the full URL using blacklist, WHOIS, and reputation tools before visiting.

Is it safe to visit a site that fails one safety check?

Not always. A blacklist warning is a major red flag, even if other checks appear normal. If multiple checks raise concerns, such as a new domain, suspicious DNS setup, or a phishing-style URL, avoid visiting the site until verified.

How do I report a phishing or malicious domain?

You can report suspicious domains to Google Safe Browsing, Microsoft Defender SmartScreen, PhishTank, ICANN, or your national cybersecurity authority. Reporting helps security providers block malicious websites faster.

Is it safe to visit a website without HTTPS?

Generally, no. Websites without HTTPS do not encrypt data between your browser and the server. Never enter passwords, payment details, or sensitive information on a non-HTTPS website.

Can scammers create fake websites that look real?

Yes. Modern phishing websites can closely imitate legitimate brands using copied layouts, logos, and even valid SSL certificates. This is why checking the domain name, WHOIS data, and blacklist status is critical before trusting a site.

Conclusion

Checking whether a domain is safe before visiting is no longer optional in 2026. Modern phishing websites can look almost identical to legitimate brands, use valid HTTPS certificates, and even operate from aged domains with existing reputations. A glance at the padlock icon is not enough to determine whether a website can be trusted.

The safest approach is to combine multiple checks, inspect the URL carefully, verify WHOIS and domain age data, review SSL certificate details, check blacklist and reputation databases, and analyse DNS records such as SPF, DKIM, and DMARC. Even a few seconds of verification can help prevent credential theft, malware infections, financial fraud, and phishing attacks.

Whether you are checking an email link, verifying an online store, analysing a vendor website, or investigating a suspicious domain, following a structured safety-check process dramatically reduces your risk.

With free tools from HasheTools.com, you can quickly perform DNS lookups, blacklist checks, WHOIS analysis, DMARC verification, and other essential domain security checks, all from one place, without creating an account.

Before clicking any unfamiliar link, remember: if a domain feels suspicious, investigate first and trust later.

If your business uses more than two email platforms, say, Google Workspace for internal mail and Mailchimp for campaigns, there is a strong chance your SPF record is silently failing authentication. The culprit is almost always the SPF 10-lookup limit: a hard ceiling built into the SPF specification that causes authentication errors the moment your record requires more than ten DNS queries to resolve.

This guide, written by the HasheTools team, explains exactly what SPF flattening is, why the lookup limit exists, how exceeding it breaks your email delivery, and most importantly, how to fix it permanently. We also cover the risks of naïve flattening and how dynamic flattening tools solve the maintenance problem that catches most teams off guard.

What is SPF, and why does it matter?

SPF (Sender Policy Framework) is an email authentication standard defined in RFC 7208. It allows a domain owner to publish a list of IP addresses and mail servers that are authorised to send email on behalf of that domain. When a receiving mail server gets a message claiming to be from your domain, it checks your SPF record in DNS to verify whether the sending IP is on your approved list.

Without a valid SPF record, your domain is an open target for email spoofing and phishing attacks. Worse, major email providers like Gmail and Outlook use SPF results as one of the primary signals for spam filtering; a failing SPF record sends your legitimate marketing emails straight to the junk folder.

A basic SPF record looks like this:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all

The v=spf1 tag identifies this as an SPF record. The include: mechanisms tell receiving servers to also check the SPF records of the listed domains. The -all at the end means: reject any mail that doesn’t match the above.

The SPF 10-lookup limit: what it is and why it exists

The SPF specification imposes a hard limit of ten DNS lookups during SPF record evaluation. This limit exists for a practical reason: every DNS query adds latency to the email authentication process. If a single SPF check could trigger dozens of recursive lookups, it would slow down mail servers and open a potential vector for denial-of-service attacks against DNS infrastructure.

The following SPF mechanisms each count as one lookup toward the limit:

• include: fetches another domain’s SPF record
• a: resolves a domain’s A/AAAA records
• mx: resolves a domain’s MX records
• exists: checks whether a domain exists in DNS
• redirect= redirects evaluation to another SPF record (counts as one lookup)

Crucially, lookups are recursive: when you include _ spf.google.com, that record itself may include further domains, each adding to your count. There is also a void lookup limit of two DNS queries that return no results (NXDOMAIN or empty responses), which are capped at just two before authentication fails with a PermError.

Why modern SPF records exceed the lookup limit

A decade ago, most organisations sent all their email through a single provider. Today, the average mid-sized business uses five or more email platforms simultaneously. Each platform requires its own include statement, and most of those platforms have complex SPF records of their own with multiple nested lookups.

Consider a common setup:

v=spf1 include:_spf.google.com; Google Workspace up to 4 lookups include:spf.protection.outlook.com; Microsoft 365 1-2 lookups include:sendgrid.net; SendGrid 2 lookups include:servers.mcsv.net; Mailchimp 2 lookups include:_spf.salesforce.com; Salesforce 2 lookups -all ; Total: ~11-13 lookups exceeds the limit

None of the above services is an unusual choice. Yet together they breach the limit before you’ve added your transactional email provider, your CRM, or your customer support tool. The problem isn’t any one platform; it’s the compounding effect of a modern multi-vendor email stack.

What is SPF flattening?

SPF flattening is the process of resolving all include: mechanisms and nested SPF records down to their underlying IP addresses, then replacing the include: chains with direct ip4: and ip6: entries. Because IP address references require zero DNS lookups to validate, a fully flattened SPF record can stay well within the 10-lookup limit regardless of how many email providers you use.

Before flattening

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all ; Lookup count: ~8  (and growing as providers update their records)

After flattening

v=spf1 ip4:35.190.247.0/24   ip4:64.233.160.0/19 ip4:66.102.0.0/20     ip4:74.125.0.0/16 ip4:40.92.0.0/15      ip4:40.107.0.0/16 ip4:167.89.0.0/17     ip4:192.254.112.0/20 ip4:198.37.144.0/20   ip4:198.153.192.0/19 -all ; Lookup count: 1  (only the initial TXT lookup for your own record)

The result is functionally identical; the same IP ranges are authorised, but the authentication process now completes in a single DNS query instead of eight or more.

How SPF flattening works step by step

Whether you use a tool or do it manually, the flattening process follows the same logic:

1. Retrieve your current SPF record from your DNS zone (query your domain’s TXT records).
2. Recursively resolve each include: mechanism. For example, resolving _ spf.google.com reveals further includes, which resolve to CIDR IP ranges.
3. Collect all resulting IP addresses across every include chain, both IPv4 (ip4:) and IPv6 (ip6:) ranges.
4. Deduplicate and consolidate overlapping or adjacent CIDR ranges where possible to reduce record length.
5. Write the new TXT record using only ip4:/ip6: entries plus your termination qualifier (-all, ~all, etc.).
6. Publish and test the new record using an SPF validator tool before removing the old one.

The risks of static SPF flattening and how to avoid them

Flattening sounds simple, but there is a critical problem with the naive approach: the IP addresses belonging to providers like Google, SendGrid, and Microsoft change regularly. When SendGrid adds a new sending range, your static flattened record won’t include it, and legitimate emails sent through that new IP will fail SPF authentication.

Static flattening risks

• IP drift: Providers rotate or expand their sending IP ranges without notifying customers.
• Record length: A fully flattened enterprise record can exceed 255 characters (the DNS TXT record string limit) or 512 bytes (the UDP DNS response limit). This requires careful CIDR aggregation or record splitting.
• Maintenance burden: Manual re-flattening every time a provider changes IPs is tedious and error-prone.

Dynamic SPF flattening: the better solution

Dynamic SPF flattening tools solve the maintenance problem by automating the entire process. Instead of publishing IP addresses directly in your TXT record, they give you a managed include statement that points to their DNS infrastructure. Their system continuously monitors your providers for IP changes and updates the underlying resolution automatically.

Your SPF record becomes something like:

v=spf1 include:spf.hashetools.com -all ; One lookup. Their infrastructure handles all the IP resolution. When Google adds a new range, its system updates automatically.

This gives you the deliverability benefits of flattening with none of the maintenance risk.

SPF flattening tools: a practical comparison

Choosing the right tool depends on whether you need a simple one-time fix or ongoing automated management. Here is how the leading options compare:

Tool	Pricing	SPF flattening	Notable features
EasyDMARC	Free + paid	Dynamic auto-update	Full DMARC dashboard, alerting
dmarcian	Paid tiers	Manual + guided	Visualization, team features
Mimecast	Enterprise	Automatic	Integrated email security suite
HasheTools SPF Checker	Free	Manual only	Instant lookup count, syntax validation, error highlighting
PowerDMARC	Free + paid	Dynamic auto-update	AI-powered threat analysis

For most organisations sending more than 10,000 emails per month, a dynamic flattening tool is worth the investment. The cost of a single deliverability incident, lost revenue, and damaged sender reputation typically exceeds a year of tool subscription fees.

Common SPF errors explained

SPF PermError: too many DNS lookups

The most common error. Exceeding ten lookups during SPF evaluation causes a permanent failure. It cannot be retried; the message is treated as definitively unauthenticated. Fix: flatten your record or reduce the number of include mechanisms.

SPF SoftFail (~all)

The sending IP is not listed as authorised, but the domain owner has not issued a hard rejection. Receiving servers may accept the message but mark it as suspicious. If your record ends in ~all instead of -all, a softfail will not block delivery but will hurt your sender’s reputation over time.

SPF HardFail (-all)

The sending IP is explicitly not authorised. Combined with a strict DMARC policy (p=reject), this causes outright rejection of the message. This is the correct configuration once your SPF record is fully validated.

SPF None

No SPF record was found for the domain. This is treated as authentication, not a missed opportunity, but rather a failure, which means the domain does not protect against spoofing.

Multiple SPF records

A domain must have exactly one SPF TXT record. If you have two (a common mistake when migrating providers), SPF validation returns PermError. Delete the old record when publishing a new one.

How to fix SPF failures: a step-by-step process

1. Check your current record. Use the HasheTools SPF Checker (hashetools.com) or Google’s Admin Toolbox to retrieve your current record and count the actual number of DNS lookups it triggers.
2. Identify which includes are driving the count. Most tools will show a recursive tree of lookups. Find the deepest chains; these are your main targets for flattening.
3. Remove redundant or outdated includes. Do you still use every service in your SPF record? Old CRMs, discontinued email tools, and deprecated IP ranges are common culprits. Audit each include against your current email stack.
4. Consolidate where possible. If you’re using both Outlook and Microsoft 365, you may only need one include. Check for overlapping ranges.
5. Choose a flattening approach. Manual one-time flattening for simple setups; a dynamic flattening tool for any organisation with three or more active email providers.
6. Publish the new record and test. Use an SPF validator to confirm the lookup count is below 10 and that all expected IPs are covered. Send test emails through each of your email platforms.
7. Monitor. Set a reminder to re-audit your SPF record quarterly, or use a dynamic tool with automated alerting.

SPF vs DKIM vs DMARC: how they work together

SPF alone is not sufficient for complete email security. It is one layer of a three-part authentication stack. Understanding how each protocol contributes helps you configure them correctly and interpret failures accurately.

Feature	SPF	DKIM	DMARC
Purpose	Authorizes sending IPs	Verifies message integrity	Enforces auth policy
DNS record type	TXT	TXT (DKIM key)	TXT
Protects against	IP spoofing	Content tampering	Both (policy layer)
Lookup limit	10 lookups max	None	Depends on SPF/DKIM
Required for DMARC	Yes	Yes	N/A is the policy

DMARC is the enforcement layer that ties SPF and DKIM together. Even if your SPF record is perfectly flattened, a p=none DMARC policy means failures have no consequence. Work toward quarantine and eventually reject once you are confident your SPF and DKIM configurations are solid.

SPF record best practices

• One record per domain. Never publish two SPF TXT records. Merge everything into a single record.
• End with -all, not ~all. SoftFail provides false security. Once your configuration is verified, use a hard fail qualifier.
• Monitor for provider IP changes. At a minimum, check your main providers’ SPF records every quarter. Better yet, use a dynamic flattening tool.
• Test after every DNS change. Any DNS update, even unrelated to SPF, warrants a re-check of your SPF lookup count.
• Document your email stack. Keep a record of every service authorised to send email on your domain, with the corresponding include: mechanism and the person responsible for it.
• Don’t include providers you no longer use. Every legacy includes a security risk and a wasted lookup.
• Align SPF with DMARC. Ensure the domain in your SPF record’s envelope sender aligns with your From: header domain, or DMARC will still fail even if SPF passes.

How SPF flattening improves email deliverability

Email deliverability is ultimately about sender reputation. Gmail, Outlook, Yahoo Mail, and other major providers evaluate every inbound message against a set of signals, and authentication results sit near the top of that list.

A correctly configured, flattened SPF record contributes to deliverability in several concrete ways:

• Eliminates authentication errors that trigger spam filters regardless of content quality.
• Strengthens your DMARC pass rate, which feeds directly into sender reputation scoring at major inbox providers.
• Reduces soft bounces caused by SPF failures on messages that should have been delivered.
• Protects your domain reputation by preventing spoofed emails (which would fail your strict SPF) from damaging how providers perceive your domain.

 

For transactional emails, especially password resets, order confirmations, and account notifications, a deliverability failure is not just a metric problem. It has a direct impact on user experience and business continuity.

Frequently asked questions

What is SPF flattening?

SPF flattening is the process of converting SPF include: mechanisms into direct IP address entries (ip4:/ip6:). This eliminates recursive DNS lookups and keeps the SPF record within the 10-lookup limit required by the SPF specification (RFC 7208).

What exactly counts toward the 10-lookup limit?

The following mechanisms each count as one lookup: include:, a:, mx:, exists:, and redirect=. The ptr: mechanism also triggers lookups, but is deprecated and should never be used. IP4: and IP6: entries do not trigger any DNS lookups and therefore do not count.

Can SPF flattening break my email delivery?

Yes, if done incorrectly. Static flattening that is not kept up to date will break delivery when email providers change their sending IPs. The solution is either to use a dynamic flattening tool that automatically updates or to schedule regular audits (at least quarterly) if managing the record manually.

My SPF record has only 8 includes. Am I safe?

Not necessarily. The count is on DNS lookups, not including statements. A single include can trigger three or four additional lookups through its own nested includes. Use the HasheTools SPF Checker (hashetools.com), which counts actual recursive lookups, not just surface-level mechanisms.

Do I need both SPF and DKIM?

Yes. DMARC requires at least one of SPF or DKIM to pass, but best practice is to have both configured correctly. DKIM is particularly important because it survives email forwarding (where SPF often fails), and it verifies message content integrity in a way SPF cannot.

How often should I audit my SPF record?

At a minimum, every quarter, or immediately after adding or removing any email service from your stack. Major providers (Google, Microsoft, Twilio/SendGrid) update their sending infrastructure periodically. If you use a dynamic flattening tool, it handles this automatically.

What is the difference between SPF SoftFail and HardFail?

SoftFail (~all) means the domain owner believes the sending IP is not authorised, but has not issued a hard rejection; receiving servers may still accept the message. HardFail (-all) is a firm declaration that the IP is not authorised, and combined with DMARC p=reject, it causes outright message rejection.

Conclusion

SPF flattening is an essential solution for fixing the 10 DNS lookup limit and preventing SPF authentication failures in modern email systems. As businesses use multiple email platforms like Google Workspace, Microsoft 365, Mailchimp, and SendGrid, SPF records often become complex and exceed the allowed lookup limit, leading to delivery issues and PermError failures.

By flattening your SPF record, you reduce DNS lookups, improve email deliverability, and ensure your messages consistently reach inboxes instead of spam folders. It also strengthens your overall email authentication setup when combined with DKIM and DMARC.

For long-term reliability, especially in dynamic email environments, using an SPF flattening tool or automated solution like HasheTools helps keep your records optimized and up to date.

In short, SPF flattening is not just a fix; it’s a best practice for maintaining secure, stable, and high-performing email delivery.

DNS is one of the most critical systems on the internet, yet it remains one of the least protected. Every time someone visits your website, sends you an email, or connects to your services, they rely on DNS to get the correct destination. The problem? Traditional DNS offers no built-in way to verify whether the response it returns is legitimate or forged.

This is exactly the gap DNSSEC (Domain Name System Security Extensions) was designed to fill. By adding cryptographic signatures to DNS records, DNSSEC allows resolvers to verify that the data they receive is authentic and hasn’t been tampered with. It transforms DNS from a trust-based system into a verifiable one.

And yet, despite being available for over 20 years, most domains in 2026 are still vulnerable. In this guide, we’ll break down how DNSSEC works, why adoption remains low, and what risks you face if your domain isn’t protected.

What is DNSSEC?

DNSSEC stands for Domain Name System Security Extensions. It is an additive security layer for DNS that uses public-key cryptography to sign DNS records, allowing resolvers to verify that the records they receive are authentic and unaltered.

The core problem DNSSEC solves: DNS was designed to be fast and lightweight, not secure. A standard DNS response carries no proof of authenticity; a resolver receiving an answer has no built-in way to tell whether it came from the legitimate authoritative nameserver or from an attacker who injected a forged response. DNSSEC fixes this by turning DNS records into signed, verifiable data.

DNSSEC does NOT encrypt DNS traffic (that’s DNS-over-HTTPS or DNS-over-TLS). What it does instead is provide data integrity and origin authentication; you can verify what the answer says and who it came from, even though the data travels in plaintext.

The Analogy: DNSSEC as a Wax Seal: Imagine sending a letter through the postal system in medieval times. Anyone handling the letter could open it and replace its contents. Adding a wax seal doesn’t stop anyone from reading the letter, but it does let the recipient verify that the seal is unbroken, confirming the letter hasn’t been tampered with and truly came from the claimed sender. DNSSEC’s cryptographic signatures work on the same principle: they don’t hide the DNS data, but they make tampering detectable.

The DNS Vulnerability DNSSEC Solves

To understand why DNSSEC matters, you first need to understand how DNS can be attacked without it.

The Kaminsky Attack: DNS’s Worst Nightmare

In 2008, security researcher Dan Kaminsky revealed a fundamental vulnerability in DNS that sent shockwaves through the industry. His technique, now called the Kaminsky Attack, could poison a recursive resolver’s cache in seconds using a simple but devastating exploit.

How the Kaminsky Attack Works

1. Attacker targets: Picks the victim’s resolver and a target domain
2. Floods with queries: Queries for random.target.com subdomains
3. Sends fake replies: Races to answer with forged DNS response
4. Guesses txn ID: 16-bit space = 65,536 possibilities
5. Poisons the cache: Fake record cached for full TTL duration

Why was it so dangerous? DNS transaction IDs are only 16 bits, meaning there are only 65,536 possible values. By querying for non-existent subdomains (which the resolver had to look up fresh each time) and flooding with forged responses, an attacker could statistically expect to guess the right transaction ID within seconds. Once poisoned, the forged record would be served to every user of that resolver for the duration of its TTL, potentially for hours or days.

The emergency patch, randomising source ports to add another ~16 bits of randomness, bought time but didn’t fundamentally solve the problem. DNSSEC is the definitive fix.

What an Unprotected DNS Response Looks Like

Standard DNS response, no authentication, no verification

$ dig hashetools.com A ;; ANSWER SECTION: hashetools.com.   300  IN  A  104.21.45.67 # This response contains: #   ✓  The IP address (104.21.45.67) #   ✗  No signature, could be from a legitimate server OR an attacker #   ✗  No proof that the data hasn’t been modified in transit #   ✗  No chain of trust back to any verified root # A forged response looks identical. The resolver cannot tell the difference.

Who Is Actively Exploiting Unprotected DNS in 2026? Nation-state actors (documented campaigns from Iran, Russia, China, and North Korea targeting government and critical infrastructure domains), ransomware operators using DNS hijacking for initial access and C2 communication, phishing campaigns using lookalike domains that exploit unprotected resolvers, and malware using DNS cache poisoning to redirect software update servers to deliver malicious payloads. If your domain lacks DNSSEC, any of these actors can forge records for your domain against unvalidating resolvers.

How DNSSEC Works: Cryptographic Signatures Explained

DNSSEC adds digital signatures to DNS records using asymmetric public-key cryptography, the same mathematical foundation used in HTTPS certificates and code signing.

The Basic Mechanism

1. The zone owner (your DNS provider or authoritative server) generates a key pair: a private signing key and a public verification key
2. Every DNS record set (all A records for your domain, all MX records, etc.) is signed using the private key, producing a digital signature stored in an RRSIG record
3. The public key is published in the DNS zone itself, in a DNSKEY record, so anyone can retrieve and use it to verify signatures
4. When a resolver receives a DNS response, it retrieves the DNSKEY and verifies the RRSIG signature. If the signature is valid, the data is authentic; if the signature is invalid or missing, the response is rejected
5. The public key itself is verified by a digital signature from the parent zone, creating a chain of trust all the way back to the signed DNS root

What a DNSSEC-Protected Response Looks Like

DNSSEC-enabled DNS response, with cryptographic proof

$ dig hashetools.com A +dnssec ;; ANSWER SECTION: hashetools.com.   300  IN  A      104.21.45.67 hashetools.com.   300  IN  RRSIG  A 13 2 300 20261231000000 ( 20261201000000 12345 hashetools.com. Xy9zABCDEFGH1234… )   # Digital signature ;; ADDITIONAL SECTION: hashetools.com.   3600 IN  DNSKEY 257 3 13 ( mdsswUyr3DPW132mOi8V9xESWE8jTo0d… )   # Zone’s public key # This response contains: #   ✓  The IP address (104.21.45.67) #   ✓  RRSIG: cryptographic signature over the A record #   ✓  DNSKEY: public key to verify the signature #   ✓  Chain of trust verified back to the DNS root #   ✓  Any tampering invalidates the signature, immediately detectable

The Two Key Types in DNSSEC

DNSSEC uses two types of keys in a two-layer signing architecture:

Key Type	Abbreviation	What It Signs / Purpose
Key Signing Key	KSK	Signs the ZSK DNSKEY record. Longer-lived. Its hash (DS record) is stored in the parent zone to create the chain of trust.
Zone Signing Key	ZSK	Signs all the actual DNS records in the zone (A, MX, TXT, CNAME, etc.). Rotated more frequently than the KSK.

Why two keys? Separating the roles allows the ZSK (which signs many records and must be used frequently) to be rotated often without changing the KSK (which is anchored in the parent zone via a DS record and is more complex to rotate). This is analogous to having a master key and working keys; the working key can be changed without replacing the master.

The DNSSEC Record Types You Need to Know

DNSSEC introduces four new DNS record types that work together to provide authentication. Understanding them is essential for troubleshooting and configuration.

Record Type	Full Name	What It Contains / Does
DNSKEY	DNS Public Key	Stores the zone’s public keys (ZSK and KSK). Published in the DNS zone itself. Resolvers use this to verify RRSIG signatures.
RRSIG	Resource Record Signature	The digital signature over a set of DNS records (called an RRset). One RRSIG per record type per zone. Signed with the ZSK.
DS	Delegation Signer	A hash of the child zone’s KSK DNSKEY. Published in the PARENT zone. Creates the link between parent and child in the chain of trust.
NSEC / NSEC3	Next Secure / Next Secure v3	Proves that a domain or record type does NOT exist. Prevents attackers from returning forged NXDomain responses. NSEC3 hashes the names for privacy.

DNSKEY Record Anatomy

DNSKEY record: your zone’s public key

Flags:      257    # 257 = KSK (Zone Signing Key + SEP flag), 256 = ZSK

Protocol:   3    # Always 3 for DNSSEC

Algorithm:  13    # 13 = ECDSA P-256 with SHA-256 (recommended in 2026)

PublicKey:  mdsswUyr3…    # Base64-encoded public key, used to verify RRSIG signatures

RRSIG Record Anatomy

RRSIG records the digital signature over your DNS records

TypeCovered: A    # Record type this signature covers

Algorithm:  13    # Must match the DNSKEY algorithm

Labels:     2    # Number of domain labels in the name

TTL:        300    # Original TTL of the signed records

Expiration: 20261231000000    # Signature validity end (YYYYMMDDHHMMSS)

Inception:  20261201000000    # Signature validity start

KeyTag:     12345    # Identifies which DNSKEY was used to sign

Signature:  Xy9zABCD…    # The base64-encoded digital signature

DS Record Anatomy

DS record: published in the PARENT zone (your registrar / TLD)

KeyTag:     12345    # Matches the KeyTag in the child’s KSK DNSKEY

Algorithm:  13    # Hash algorithm (13 = ECDSA)

DigestType: 2    # 2 = SHA-256 (recommended)

Digest:     AB12CD34…    # SHA-256 hash of the child zone’s KSK DNSKEY

The Chain of Trust: From Root to Your Domain

DNSSEC’s power comes from a hierarchical chain of trust that extends from a single globally trusted root, the DNS Root Zone, all the way down to your individual domain records. Every link in this chain is cryptographically verified.

DNS Root Zone  ( . ) Trust Anchor, maintained by ICANN, signed by the Root KSK (rotated by ICANN, last major rotation 2018, upgraded 2026)

│  Root KSK signs Root ZSK  │  Root ZSK signs .com DS record

TLD Zone  ( .com / .org / .net / etc. ) Operated by Verisign (.com), PIR (.org), etc. Contains DS records for registered domains.

│  TLD nameserver publishes DS record  →  links to your domain’s KSK

Your Domain  ( yourdomain.com ) Your DNS zone contains DNSKEY records (KSK + ZSK) and RRSIG signatures over every record set.

│  ZSK signs every DNS record in your zone (A, MX, TXT, CNAME, NS, SOA…)

Individual DNS Records (A, MX, TXT, CNAME…) Each record set has a corresponding RRSIG. Resolver validates RRSIG → DNSKEY → DS → TLD → Root. Chain complete.

Breaking the chain: If any link in this chain is missing or invalid, if your registrar didn’t submit your DS record to the TLD, if your RRSIG has expired, if the algorithm in your DNSKEY doesn’t match your RRSIG, the entire DNSSEC validation fails. DNSSEC-validating resolvers will refuse to serve the response, resulting in SERVFAIL errors for your users.

Why Most Domains Still Don’t Have DNSSEC in 2026

DNSSEC was standardised in RFC 4033–4035 in 2005. In 2026, two decades later, fewer than 25% of registered domains have it enabled. This is one of the most persistent adoption failures in cybersecurity. Here’s why:

Operational Complexity

DNSSEC requires managing key pairs, signing zones, submitting DS records to registrars, coordinating key rollovers, and monitoring signature expiry. For organisations without dedicated DNS expertise, this is daunting.

Signature Expiry Risk

RRSIG records have an expiration date, typically 30 days. If signatures aren’t refreshed before expiry (automatically by the DNS provider or manually), the domain goes into SERVFAIL for all validating resolvers. This ‘break everything’ failure mode makes operations teams reluctant to enable it.

Key Rollover Complexity

Rotating DNSSEC keys safely requires a precise multi-step dance between the child zone and the parent (registrar). A mistimed rollover breaks the chain of trust. Automated key management has improved but remains error-prone in many environments.

Registrar / Provider Support Gaps

Not all DNS providers and registrars support DNSSEC, or support it well. Many budget hosting providers, legacy DNS platforms, and smaller registrars offer no DNSSEC support at all, leaving their customers unable to enable it regardless of intent.

Invisible Protection

DNSSEC protects against attacks that most domain owners have never personally experienced. The risk is real but invisible; unlike an SSL error (which shows a red browser warning), a DNS cache poisoning attack is completely invisible to the victim. Low perceived urgency → low adoption.

No Direct Business Incentive

SSL certificates have a visible browser padlock that drives adoption through customer-facing consequences. DNSSEC has no equivalent visible signal. There is no ranking boost, no browser warning for its absence, and no direct customer-facing benefit that organisations can point to when justifying the operational cost.

Global Coordination Required

DNSSEC requires both the domain owner, the registrar, and the TLD operator to support and correctly configure it. A failure at any party breaks the chain. Coordinating across these three separate entities, especially for legacy domains, creates inertia.

2026 Adoption Trends: A Reason for Optimism: While overall adoption remains low, the trajectory is improving. Cloud-managed DNS providers (Cloudflare, AWS Route 53, Google Cloud DNS) now enable DNSSEC with a single click and handle all key management automatically. The ccTLD adoption rate is much higher than that of commercial domains. .gov domains in the US are mandated to use DNSSEC. ICANN’s 2026 root zone upgrades are prompting renewed attention to DNSSEC at all levels of the hierarchy.

DNSSEC Advantages and Limitations

Advantages of DNSSEC	Challenges & Limitations
Eliminates DNS cache poisoning attacks against your domain	Does NOT encrypt DNS traffic (use DoH/DoT for that)
Provides cryptographic proof of DNS record authenticity	Does NOT prevent DNS hijacking at the registrar level
Protects against Kaminsky-style forged response injection	Misconfiguration causes a complete domain outage (SERVFAIL)
Enables DANE, binding TLS certificates to DNS records	RRSIG signatures expire and require active maintenance
Enables SSHFP, verifying SSH host keys via DNS	Key rollovers require careful coordination with the registrar
Provides authenticated denial of existence (NSEC/NSEC3)	Increases DNS response size (adds RRSIG + DNSKEY records)
Required for some government and compliance frameworks	Not all DNS providers/registrars support it
Free to enable, no ongoing certificate cost	NSEC records can enable zone enumeration (use NSEC3)
Increasingly automated by major DNS providers	Amplification: larger responses can be abused in DDoS
Protects users even when they can’t see it working	Low validator adoption limits end-to-end protection

How to Check if Your Domain Has DNSSEC

Before configuring DNSSEC, verify your current status. There are multiple ways to check:

Method 1: HasheTools DNS Lookup

The quickest method for most users: go to hashetools.com, open the DNS Lookup tool, enter your domain, and look for DNSKEY and RRSIG records in the results. If they appear, DNSSEC is enabled. If they don’t, it is not.

Method 2: Command Line (dig)

Check for DNSSEC records using dig

# Check for DNSKEY record (your zone’s public key) dig yourdomain.com DNSKEY +short # If DNSSEC is enabled, you’ll see output like: # 257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0d…   (KSK) # 256 3 13 oJMRESz5E4gYzS/q6XDrvU1/6STjwd1D…   (ZSK) # Check for RRSIG records (signatures over your A record) dig yourdomain.com A +dnssec +short # DNSSEC enabled: returns A record AND RRSIG record # DNSSEC not enabled: returns only A record, no RRSIG # Check DS record (published at your registrar / TLD) dig yourdomain.com DS +short # If no DS record: chain of trust is broken, DNSSEC not propagated

Method 3: DNSSEC Analyser Tools

Full DNSSEC chain validation: online tools

# ICANN DNSSEC Analyser: # https://dnssec-analyzer.verisignlabs.com/yourdomain.com # DNSViz, detailed visual chain of trust analysis: # https://dnsviz.net/d/yourdomain.com/dnssec/ # Cloudflare DNSSEC Debugger: # https://dnssec-debugger.verisignlabs.com/ # Look for: #   Green checkmarks = valid chain of trust #   Red X = broken link in chain #   Yellow warning = configuration issue (often expiring signatures)

Interpreting Your Results

What You See	What It Means
DNSKEY + RRSIG records present, DS record in TLD	DNSSEC is fully enabled, and the chain of trust is intact.
DNSKEY + RRSIG records present, no DS record	DNSSEC is configured in the zone, but the DS record is not submitted to the registrar. Chain of trust broken, not validated.
No DNSKEY, no RRSIG records	DNSSEC is not enabled on your domain. All DNS responses are unauthenticated.
RRSIG records present but expired	Signatures have passed their validity date. Validating resolvers return SERVFAIL. The domain is effectively unreachable.
SERVFAIL when querying your domain	DNSSEC is configured but broken, expired signatures, missing DS record, algorithm mismatch, or failed key rollover. Urgent fix required.

How to Enable DNSSEC: Step-by-Step Guide

The exact steps vary by DNS provider and registrar, but the fundamental process is the same for everyone. Here is the complete workflow:

Before You Start: Confirm that both your DNS provider (who hosts your DNS zone) and your domain registrar (where you registered the domain) support DNSSEC. They may be the same company (e.g., if you use Cloudflare for both) or different companies (e.g., GoDaddy as registrar, AWS Route 53 as DNS provider). If your DNS provider doesn’t support DNSSEC, you’ll need to migrate your DNS before enabling it.

Step 1: Enable DNSSEC Signing in Your DNS Provider

1. Log in to your DNS provider’s dashboard
2. Navigate to the DNS settings for your domain
3. Find the DNSSEC option (usually labelled ‘DNSSEC’, ‘DNS Security’, or ‘DNSSEC Signing’)
4. Enable DNSSEC signing, the provider will generate a KSK and ZSK, and begin signing your zone.
5. The provider will display a DS record (containing the KeyTag, Algorithm, DigestType, and Digest). Copy this exactly; you’ll need it in Step 2

Step 2: Submit the DS Record to Your Registrar

1. Log in to your domain registrar (where you purchased the domain)
2. Navigate to the DNS or DNSSEC settings for your domain
3. Find the ‘Add DS Record’ or ‘DNSSEC’ section
4. Enter the DS record values provided by your DNS provider: Key Tag, Algorithm, Digest Type, Digest.
5. Save the DS record; the registrar will publish it in the TLD zone
6. Wait for propagation, DS records typically propagate within 1–48 hours

Step 3: Verify the Chain of Trust

Verify your complete DNSSEC chain after configuration

# Step 1: Confirm DNSKEY is published dig yourdomain.com DNSKEY +short # Should return 2 records: one KSK (flags=257), one ZSK (flags=256) # Step 2: Confirm DS record is in the TLD zone dig yourdomain.com DS +short # Should return your DS record, matches the KSK hash # Step 3: Confirm RRSIG is present on your A record dig yourdomain.com A +dnssec # Should return: A record + RRSIG record # Step 4: Full chain validation dig yourdomain.com A +sigchase +trusted-key=/etc/trusted-key.key # Or use DNSViz online for a visual chain check

Step 4: Set Up Monitoring

1. Monitor RRSIG expiry: RRSIG records have an expiration date. Your DNS provider should auto-renew them, but set up an alert in case auto-renewal fails.
2. Monitor DS record consistency: Periodically verify that the DS record at your registrar matches your current KSK.
3. Set up DNSSEC failure alerts: Tools like Zabbix, Nagios, or cloud monitoring services can alert you if your domain starts returning SERVFAIL.
4. Use HasheTools DNS Lookup regularly: Quick periodic checks confirm DNSKEY and RRSIG records remain present and valid.

Key Rollover: The Critical Ongoing Operation: ZSK rotation should happen every 30–90 days. KSK rotation is less frequent (annually or as needed) but more complex; it requires updating the DS record at your registrar. Most managed DNS providers handle ZSK rotation automatically. KSK rotation typically requires manual action: generate new KSK → publish both old and new DNSKEY simultaneously (pre-publication) → update DS record at registrar → remove old DNSKEY after DS has propagated. Never remove the old DNSKEY before the new DS record has propagated globally.

DNSSEC by DNS Provider: Quick Reference

DNSSEC support and ease of configuration vary significantly by provider. This table covers the most commonly used DNS providers and registrars as of 2026:

Provider	DNSSEC Support	Auto Key Mgmt	How to Enable
Cloudflare	Full	Automatic	DNS → DNSSEC tab → Enable DNSSEC. The DS record is displayed automatically.
AWS Route 53	Full	Automatic	Hosted Zone → Enable DNSSEC Signing → Register DS with registrar.
Google Cloud DNS	Full	Automatic	Cloud DNS → Zone → DNSSEC → Enable. DS record provided.
Cloudflare Registrar	Full	Automatic	One-click if DNS is also on Cloudflare, DS is submitted automatically.
GoDaddy DNS	Partial	Manual keys	Domain Settings → DNS → DNSSEC. Must manage key rotation manually.
Namecheap	Partial	Limited	Advanced DNS → DNSSEC. Key management support varies by plan.
Name.com	Supported	Manual	Manage Domain → DNS Records → DNSSEC Records.
Porkbun	Supported	Auto if Porkbun DNS	Domain → Edit → DNSSEC. Auto if using Porkbun DNS.
cPanel / WHM	Depends	Provider-dependent	Depends on the hosting provider’s DNS server configuration.
Generic BIND	Full (manual)	Manual only	Use dnssec-keygen + dnssec-signzone. Requires significant expertise.
PowerDNS	Full	Auto-signing	pdnsutil secure-zone yourdomain.com, then submit the DS record.

Recommendation: Use a Provider That Automates DNSSEC: The biggest cause of DNSSEC-related outages is expired RRSIG signatures that weren’t refreshed in time. Choosing a DNS provider that handles key generation, zone signing, and signature renewal automatically (Cloudflare, AWS Route 53, Google Cloud DNS) eliminates the most dangerous operational risks. If your current provider doesn’t support automatic DNSSEC management, consider migrating your DNS before enabling DNSSEC.

DNSSEC and Email Security: The Connection

DNSSEC has a direct and important relationship with email security, specifically through DANE (DNS-based Authentication of Named Entities), an extension that allows you to publish your mail server’s TLS certificate fingerprint in DNS and have it validated via DNSSEC.

What is DANE?

DANE (RFC 7671) allows you to publish a TLSA record in DNS that specifies which TLS certificate or Certificate Authority your mail server uses. Receiving mail servers that support DANE can verify this record, and reject connections if the certificate doesn’t match, even if the presented certificate is ‘valid’ according to traditional CA verification.

This closes a significant gap in email security: traditional STARTTLS encryption for email is opportunistic and can be stripped by a man-in-the-middle attacker. DANE makes TLS enforcement mandatory and verifiable.

DANE TLSA record for email: published in DNSSEC-signed zone

# TLSA record for your mail server (MX record host) # Format: _port._protocol.hostname TLSA usage selector matchingtype hash _25._tcp.mail.yourdomain.com.  IN  TLSA  3 1 1  ( AB12CD34EF56…  ) # Usage 3 1 1 = DANE-EE: Domain-issued cert, SubjectPublicKeyInfo, SHA-256 # Requires: DNSSEC enabled on yourdomain.com + STARTTLS on your mail server

DNSSEC + Email Authentication Stack

Protocol	Role in Email Security
SPF	Authorises sending IPs for your domain (DNS TXT record, benefits from DNSSEC authentication)
DKIM	Cryptographically signs email messages (DNS TXT record, DNSSEC prevents forging of public key)
DMARC	Enforces SPF/DKIM policy and alignment (DNS TXT record, DNSSEC prevents policy tampering)
BIMI	Displays brand logo in inbox (DNS TXT record, DNSSEC prevents logo URL hijacking)
DANE / TLSA	Pins TLS certificate for SMTP, requires DNSSEC. Makes opportunistic TLS into verified TLS.
MTA-STS	Alternative to DANE for enforcing SMTP TLS, does not require DNSSEC, but is complementary

The key insight: SPF, DKIM, DMARC, and BIMI records are all DNS TXT records. Without DNSSEC, an attacker with access to a poisoned resolver could forge any of these records, serving a modified SPF record that authorises their own servers, or a modified DKIM public key that lets them forge signed messages. DNSSEC protects the integrity of your entire email authentication infrastructure.

DNSSEC vs. DNS-over-HTTPS: Understanding the Difference

These two technologies are frequently confused because they both improve DNS security. They are complementary, not competing; they solve different problems at different layers.

Attribute	DNSSEC	DNS-over-HTTPS (DoH)
What it protects	DNS data integrity and origin authenticity	DNS query privacy in transit
What it prevents	Cache poisoning, forged responses	Eavesdropping, on-path query manipulation
Encryption	No, data travels in plaintext	Yes, full encryption of DNS query and response
Authentication	Yes, cryptographic proof of record origin	No, doesn’t verify record authenticity
Where configured	DNS zone (server-side) + registrar	Client device or resolver
Failure mode	SERVFAIL (breaks resolution)	Falls back to standard DNS if DoH is unavailable
Protects against the ISP	No, ISP can still see (not forge) records	Yes, ISP cannot see or modify queries
Required by	DANE, SSHFP, some compliance frameworks	Privacy regulations, some enterprise policies
2026 adoption	< 25% of domains	~35% of DNS queries globally (Mozilla/Cloudflare)

Use both: DNSSEC validates that the DNS records themselves are authentic. DoH ensures that nobody on the network path can observe or tamper with your DNS queries. Together, they provide comprehensive DNS security: authenticated data delivered over an encrypted channel.

The Complete DNS Security Stack for 2026: Enable DNSSEC on your domain (protects your DNS records from forgery) + Enable DoH/DoT on your resolver and endpoints (protects query privacy and on-path manipulation) + Enable DANE/TLSA for your mail servers (cryptographically binds your TLS certificates to DNSSEC) + Monitor continuously with HasheTools (catches misconfigurations and attacks early). This four-layer approach closes the major DNS attack surfaces described in this guide.

Frequently Asked Questions

What happens if DNSSEC is misconfigured?

Validating resolvers like Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 will return SERVFAIL, making your website, email, and all DNS-dependent services completely unreachable. This is why monitoring RRSIG expiry and DS record consistency is critical after enabling DNSSEC.

Will DNSSEC slow down my DNS resolution?

Marginally. It adds a few milliseconds of cryptographic validation and slightly larger responses, but in practice, the impact is negligible. Responses are still cached normally, and the security benefit far outweighs the cost.

Do I need DNSSEC if I already use Cloudflare or a CDN?

Yes. CDNs protect at the application layer, but they can’t stop DNS cache poisoning at the resolver level. An attacker who poisons a resolver redirects users before they ever reach your CDN. DNSSEC stops the attack before that happens.

What algorithm should I use?

ECDSA P-256 with SHA-256 (Algorithm 13) is the 2026 recommendation, strong security, small keys, and fast validation. Ed25519 (Algorithm 15) is a great alternative. Avoid RSA-SHA1; SHA-1 is cryptographically deprecated.

How do I fix a broken DNSSEC chain?

Use DNSViz (dnsviz.net) to identify the broken link. Expired RRSIG, re-sign the zone. Missing DS record, resubmit it to your registrar. Missing DNSKEY, re-enable signing in your DNS provider. Then verify with HasheTools DNS Lookup and allow up to 48 hours for propagation.

Is DNSSEC required by regulations?

Yes, in several frameworks. US OMB mandates it for all .gov domains. The EU’s NIS2 Directive requires it for critical infrastructure operators. PCI-DSS v4.0 includes relevant DNS security controls. Many government procurement contracts now extend this requirement to vendor domains.

Conclusion

DNSSEC fixes a fundamental flaw in the Internet’s infrastructure, one that no amount of application-layer security can patch. Without it, your DNS records, including SPF, DKIM, and DMARC, can be silently forged against vulnerable resolvers.

The operational barrier is lower than ever. Major providers like Cloudflare, AWS Route 53, and Google Cloud DNS automate key management and signature renewal entirely. Enabling DNSSEC can take under five minutes.

In 2026, it shouldn’t be optional. Pair it with DoH/DoT for transport privacy, DANE for mail server certificate pinning, and continuous monitoring, because when DNS is compromised, everything built on top of it is at risk.

DNS hijacking, spoofing, and tunneling are cyberattack techniques that exploit the Domain Name System, the internet’s directory service, to redirect users to malicious sites, intercept traffic, or secretly exfiltrate data. Because virtually all network traffic relies on DNS, attackers who can manipulate DNS responses gain powerful control over what a user or system actually connects to.

Why DNS Is a Prime Target

DNS was designed in the 1980s for a small academic network. Security was never a priority. Most DNS traffic travels unencrypted over UDP port 53, making it observable, interceptable, and manipulable by anyone on the network path between your device and the DNS server.

What makes it especially dangerous:

• Unencrypted by default: DNS queries are transmitted in plaintext, visible to any observer
• Trust-based and stateless: resolvers accept the first matching response; they don’t verify the sender’s identity
• Cached responses: a poisoned cache entry persists for its full TTL, affecting every user on that resolver
• Rarely monitored: most organisations actively watch HTTP/HTTPS traffic but treat DNS as invisible infrastructure

DNS is exploited at every stage of a modern attack: reconnaissance, phishing, command-and-control, and data exfiltration, all hiding inside a protocol that firewalls seldom block.

DNS Hijacking: The Redirect Attack

DNS hijacking alters DNS resolution so that a domain resolves to an IP address controlled by an attacker. Unlike spoofing, hijacking involves persistent modifications to DNS infrastructure, making it harder to detect and longer-lasting.

Types of DNS Hijacking

Type	How It Works
Router hijacking	An attacker compromises your router and changes its DNS server settings to a rogue resolver
Local hijacking	Malware modifies the local hosts file or DNS client settings on your device
Registrar hijacking	An attacker gains access to your registrar account and changes your authoritative nameservers
Authoritative NS hijack	Attacker compromises the nameserver itself; changes affect every resolver worldwide

Real-World Example: DNSpionage

The DNSpionage campaign (2018–2019, attributed to Iranian threat actors) compromised domain registrar accounts for government and commercial targets across the Middle East, redirecting traffic through attacker-controlled servers and capturing credentials for months before detection. Nation-state actors continue to use registrar-level hijacking as a primary espionage technique in 2026.

Signs Your Domain May Be Hijacked

• DNS propagation checkers show different IPs across global resolvers
• Your registrar sends unexpected NS record change notifications
• SSL/TLS certificate monitoring fires unexpectedly for your domain
• Users report being redirected to login pages that look like yours
• Unexpected DMARC reports show unfamiliar sending sources

DNS Spoofing & Cache Poisoning

DNS cache poisoning injects a fraudulent DNS record into a recursive resolver’s cache. Once poisoned, the resolver serves the attacker’s forged answer to every client that queries for that domain, until the cache entry expires.

How It Works

DNS resolvers accept UDP responses that match the query’s transaction ID (a 16-bit number). If an attacker can guess or brute-force that ID and send a forged response before the legitimate nameserver replies, the resolver accepts and caches the fake answer.

In 2008, researcher Dan Kaminsky demonstrated a devastating variant that could poison a resolver in seconds, forcing emergency patching of nearly all DNS software worldwide. In 2026, modern variants combine Kaminsky-style flooding with IP fragmentation exploitation and side-channel timing attacks.

Hijacking vs. Spoofing: Key Differences

Attribute	DNS Spoofing / Cache Poisoning	DNS Hijacking
Target	Recursive resolver cache	DNS infrastructure (registrar, NS, router)
Persistence	Temporary (until TTL expires)	Persistent until discovered
Requires system access?	No, network-level attack	Yes, account/system compromise
Affected users	All users of the poisoned resolver	All users of the domain globally
Primary defence	DNSSEC, DNS-over-HTTPS	Registrar lock, MFA, NS monitoring

DNSSEC: The Technical Defence

DNSSEC cryptographically signs DNS records. A resolver that validates DNSSEC signatures can detect a forged response, even one with the correct transaction ID, because the signature won’t match. Despite being standardised in 2005, DNSSEC adoption remains below 30% globally, leaving the majority of DNS traffic vulnerable.

Check if your domain has DNSSEC enabled:

dig yourdomain.com DNSKEY +dnssec

# A valid response includes RRSIG records.

# If no RRSIG records appear, DNSSEC is not enabled.

DNS Tunneling: Hiding Data in Plain Sight

DNS tunneling encodes arbitrary data, commands, stolen files, malware payloads, inside DNS queries and responses. It exploits the fact that DNS traffic is almost universally permitted through firewalls, even in highly locked-down environments.

Firewalls block unusual outbound ports. But DNS on UDP port 53 is rarely blocked; doing so would break internet access entirely. Attackers build covert channels over a protocol that security teams rarely inspect.

What Gets Tunneled

• Command & control (C2): Malware receives attacker instructions via DNS TXT records, bypassing corporate firewalls entirely
• Data exfiltration: Sensitive files are base64-encoded and split across hundreds of DNS queries; the attacker’s nameserver reassembles them
• VPN bypass: Tools like iodine and dns2tcp create functional IP tunnels over DNS, enabling full internet access through captive portals
• Malware staging: Payloads are downloaded through DNS, bypassing HTTP/HTTPS filtering

What Tunneled Traffic Looks Like

# LEGITIMATE: Short subdomain, common record type

dig hashetools.com A

# hashetools.com. 300 IN A 104.21.45.67

# TUNNELED: Long encoded subdomain, TXT record

dig aGVsbG8gd29ybGQgdGhpcyBpcyBzdG9sZW4gZGF0YQ.evil.com TXT

# Red flags: long base64 subdomain + TXT query + unknown domain

DNS Tunneling Red Flags

Indicator	Why It’s Suspicious
Subdomain length > 50 characters	Legitimate subdomains are short; long base64 labels indicate data encoding
High query rate to a single domain	Tunneling tools make rapid-fire queries abnormal for legitimate use
Unusual record types (TXT, NULL)	Tunneling tools favour TXT records to carry payload data
Unknown or newly registered domains	Attacker infrastructure is often freshly registered
Large DNS response sizes	TXT records carrying C2 commands are far larger than typical responses

DNS Rebinding Attacks

DNS rebinding tricks a victim’s browser into treating an attacker-controlled server as if it were on the victim’s local network, bypassing the same-origin policy and exposing internal services.

How it works:

1. Victim visits attacker’s domain (via phishing or malicious ad)
2. Domain resolves to the attacker’s real server with a very short TTL (1 second)
3. TTL expires; next DNS lookup returns a private IP (192.168.x.x or 10.x.x.x)
4. The browser now treats the attacker’s domain as a local network address
5. JavaScript can now read responses from routers, NAS devices, internal panels, and IoT devices, with no authentication required.

Most home routers rely on “protected by not being on the internet” as their only security. DNS rebinding destroys that assumption.

DNS Amplification: DDoS via DNS

DNS amplification exploits open DNS resolvers to amplify attack traffic by 50–100x. The attacker sends a small query spoofing the victim’s IP, and the resolver sends a much larger response to that victim, overwhelming their bandwidth without requiring significant botnet resources.

A single DNS ANY query (~40 bytes) can generate a 3,000+ byte response. Multiplied across thousands of open resolvers, the result is a massive volumetric DDoS.

Defences:

• Never run an open DNS resolver
• Implement BCP38 source address validation at the network edge
• Enable DNS Response Rate Limiting (RRL)
• Disable or minimise responses to ANY queries (RFC 8482)

AI-Driven DNS Attacks in 2026

The most significant shift in 2026 is the convergence of AI with DNS exploitation.

• AI-generated phishing infrastructure: ML models generate hundreds of near-identical lookalike domains that pass traditional brand-similarity checks
• Staged pre-positioning: Attackers register domain infrastructure weeks or months before activation. Spikes in newly observed domains precede phishing campaigns by 2-6 weeks.
• ML-evasive DGAs: Deep learning domain generation algorithms produce names statistically indistinguishable from legitimate traffic, defeating entropy-based detection
• Automated reconnaissance: AI scans DNS records at scale to identify misconfigured zones, forgotten subdomains, and exposed internal services faster than any human analyst

The defender’s response requires ML-powered DNS monitoring that evaluates domains in full context, query frequency, registration age, certificate transparency logs, and geographic patterns, rather than simple blocklists.

How to Detect DNS Attacks

Command-Line Checks

# Check your authoritative nameservers for unexpected changes

dig yourdomain.com NS +short

# Compare responses across global resolvers — inconsistency signals poisoning

dig @8.8.8.8 yourdomain.com A +short

dig @1.1.1.1 yourdomain.com A +short

dig @208.67.222.222 yourdomain.com A +short

# Detect tunneling — look for anomalously long subdomain queries in logs

grep -E ‘query: [a-zA-Z0-9+/]{50,}\.’ /var/log/named/query.log

Anomaly Reference Table

Anomaly	Likely Attack
Sudden NS record change	Registrar/domain hijacking
Domain resolves to different IPs across resolvers	Cache poisoning
Spike in NXDomain responses	DGA malware C2 search
Base64-encoded subdomain queries	DNS tunneling/data exfiltration
Very short TTL (1–5 seconds) on your records	DNS rebinding preparation
High-volume TXT queries to an unknown domain	DNS tunneling C2 channel
Internal hosts querying external resolvers directly	Malware bypassing internal DNS

DNS Security Checklist

Domain & Registrar

• Enable registrar lock (transfer lock) on all domains
• Enable MFA on your registrar account, use an authenticator app, not SMS
• Set up registrar alerts for any NS, A, or MX record changes
• Monitor NS records continuously and verify they match expected values

DNSSEC & Encrypted DNS

• Enable DNSSEC on all domains
• Verify DNSSEC validation: dig yourdomain.com A +dnssec
• Enable DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) on endpoints
• Use a validating resolver: Cloudflare 1.1.1.1, Google 8.8.8.8, or Quad9 9.9.9.9

Email Authentication

• Publish SPF record for all sending domains
• Configure DKIM signing on outgoing mail
• Enforce DMARC at p=reject
• Implement BIMI for verified logo display in Gmail and Yahoo

Network & Resolver Hardening

• Never run an open DNS resolver
• Implement DNS Response Rate Limiting (RRL)
• Enable BCP38 source address validation at the network edge
• Block outbound DNS from endpoints to anything except your authorised resolvers
• Subscribe to certificate transparency monitoring for your domain

Conclusion

DNS remains one of the most critical and most overlooked components of internet security. In 2026, attackers exploit it through hijacking, spoofing, tunneling, rebinding, amplification, and, increasingly, AI-enhanced techniques that evade traditional detection.

The good news is that most of these attacks are detectable and preventable with the right foundations. Enable DNSSEC. Use DNS-over-HTTPS. Lock your registrar. Monitor your records. Enforce email authentication. And treat DNS logs as a frontline security signal, not background noise.

DNS security is not a set-and-forget task. It requires continuous vigilance, layered defences, and awareness of how the threat landscape evolves, starting with understanding the attacks described here.