Analyze your domain's overall security, DNSSEC, and DNS configuration with specialized tools.
This check runs the DMARC, SPF, DKIM, BIMI, MTA-STS/TLS-RPT and DNSSEC checks for a domain at the same time and shows each one's status in a single report.
Overall Security
Six domain security checks, each with its status.
Frequently Asked Questions about DNSSEC
DNSSEC (Domain Name System Security Extensions) is a set of extensions to the DNS protocol that allow cryptographically validating responses sent by DNS servers. It was designed to add features such as authenticity and integrity to the name resolution service. It works as an authenticity seal for websites, ensuring that when typing a web address, you are redirected to the correct website instead of a fraudulent one. Unlike the original DNS which had no security, DNSSEC addresses vulnerabilities such as cache poisoning and identity spoofing. It does not define a new protocol, but creates new records and flags within the framework of existing DNS messages.
Solves: DNSSEC helps protect DNS traffic from spoofing, forgery, and tampering, detecting and rejecting manipulated data. It protects DNS data, authenticates DNS responses, improves IoT device security, and fosters user trust. It can also be the foundation for new security technologies such as DANE (DNS-based Authentication of Named Entities) to secure connections across the Internet. Does not solve: DNSSEC does not provide data confidentiality, as responses are authenticated but not encrypted. It also does not protect against Denial of Service (DoS/DDoS) attacks. It does not prevent phishing attacks that use "similar" domains (typosquatting) or if the real mail server is compromised. It also cannot protect against false user assumptions about DNS names.
DNS zone administrators sign their zones. This process involves the use of public key cryptography and digital signatures. The registrant (domain owner) digitally signs DNS information. When a recursive DNS server receives a response to a query, it may include additional information (a digital signature) that allows verification of its validity. The digital signature is verified by locating the correct public key, which is found in a DNSKEY record. If the signature is not valid, the resolver assumes a cyber attack, discards the data, and returns an error. Key authentication is performed through a chain of trust that goes back to a trust anchor, provided by the signed root zone (the DNS root zone was signed in June 2010 by ICANN).
DNSSEC introduces or adapts several types of records: DNSKEY: Contains the public key used to verify digital signatures of other DNSSEC records in the zone. There are two types of DNSKEY keys: KSK (Key Signing Key): Used to sign other DNSKEY keys. ZSK (Zone Signing Key): Used to sign other records (such as A, MX, etc.). RRSIG (Resource Record Signature): Contains the digital signature for a specific set of records. DS (Delegation Signer): Contains a "hashed" version of the DNSKEY record, used for delegation and trust anchoring in the parent zone. NSEC (Next Secure Record) and NSEC3 (Next Secure Record 3): Contain links to the next record name in the zone and are used to cryptographically verify the non-existence of a name or record type (authenticated denial of existence). NSEC3 uses "hashed" names to avoid record enumeration. NSEC3PARAM: Used by authoritative servers to calculate and determine which NSEC3 records to include in responses.
No, using DNSSEC is an option for each operator. However, it is considered important to work on the deployment of this technology due to the security benefits it offers.
DNSSEC configuration can be technically complex and error-prone. It requires understanding asymmetric cryptography mechanisms. However, modern DNS server software and most DNS service providers offer tools that automate and simplify implementation and maintenance, sometimes as simple as checking a box. Implementation cost is usually the least relevant factor. In addition, many DNS and email security providers publish free DNSSEC validators that report whether a zone is signed and whether the chain of trust resolves correctly.
In general, implementation has two sides: publication (performed by registrants or their agents) and lookup/resolution (performed by network operators such as ISPs). To benefit from DNSSEC, both sides must use it. Key steps: 1. Assess the starting point: Verify if DNSSEC is already used, if the TLD and DNS provider support it, and if trained personnel are available. 2. Review the DNS zone: Align it with current services. 3. Generate keys (public and private). It is recommended to use KSK and ZSK keys. 4. Activate DNSSEC on the domain and DNS server. 5. Publish corresponding records (DNSKEY, RRSIG, DS) on the DNS server and domain. 6. Perform necessary tests to validate the installation. 7. Audit and periodically monitor DNS/DNSSEC operation to detect problems. Keys should be renewed periodically to improve security.
DNSSEC adoption has been slow globally, with approximately 30% of top-level domains (TLD) and less than 5% of individual domains having implemented it. Reasons include: DNS is an underlying and largely invisible infrastructure ("catacombs of the Internet") for many administrators. It requires understanding asymmetric cryptography. Not all TLDs, domain registry providers, and DNS servers have complete support for DNSSEC. Incorrect implementation can create a false sense of security or cause critical disruptions if data is not properly signed, which is unacceptable for large companies. Perceived complexity and the need for manual key renewals (depending on the registrar). For very large domains, such as those of Google or Amazon-scale companies, signing all zones is difficult or impossible due to the maximum size of DNS requests, which could slow down or fail responses. Some large companies do not prioritize it or do not see a specific benefit that compensates for the administrative overhead for their scale, or simply there is "laziness or resistance to change". Lack of support in web browsers for DANE (a technology that leverages DNSSEC for SSL/TLS certificates) makes DNSSEC alone not very useful for websites. CDN networks use dynamic DNS responses that would require online DNSSEC signing, which increases complexity for hundreds of servers.
DNSSEC protects TXT and MX records, which are fundamental for email authentication. It is essential if you are concerned about email security, especially with DANE enabled. DANE (DNS-based Authentication of Named Entities): It is a protocol that allows domain owners to specify TLS certificates verified through DNSSEC to prevent man-in-the-middle attacks. MTA-STS (Mail Transfer Agent Strict Transport Security): It is a protocol that ensures that mail servers must use TLS for delivery and reject emails if encryption fails. Google has promoted MTA-STS as an alternative that does not need DNSSEC, and in some cases, MTA-STS can override DANE if both are configured on an outgoing mail server like Postfix. The combination of MTA-STS and TLS-RPT (SMTP TLS Reporting) is fundamental for email security.
Online tools: Most DNS and email security providers offer a DNSSEC checker or validator, and you can also query the status from the command line with tools such as "Dig". Organizations and resources: ICANN: Plays a fundamental role in DNSSEC implementation, being responsible for generating and updating the key for signing the root zone key. It conducts workshops and promotes awareness. LACNIC: Operates reverse DNS resolution zones for IPv4 and IPv6 in the region and allows its members to configure DS records for their DNSSEC keys. It offers tutorials and documentation. IETF (Internet Engineering Task Force): Developed DNSSEC specifications and continues to work on improvements. INCIBE-CERT: Has published implementation guides and studies on DNSSEC status in Spain. Internet Society: Monitors DNSSEC adoption by ISPs.
Frequently Asked Questions
It checks six things for a domain: its DMARC record and policy, its SPF record, its DKIM record under the default selector, its BIMI record, its MTA-STS policy and TLS-RPT record, and the DNSSEC status of its DNS.
Each check shows a status: Valid if the record is published and well formed, Warning if it works but should be reviewed, Invalid if it is missing or wrong, Not checked if that check could not be completed, and Error if the lookup failed (for example, because of a temporary DNS resolver failure) and the status could not be determined. Below each status you get the message describing what was found for that domain.
No. The report is the list of the six statuses, each with its detail. A single score would hide what matters: a domain can have DMARC at a reject policy and no DNSSEC at the same time, and those two things are fixed in different ways.
It means the records that were queried are published and well formed, which is the basis of email authentication. It does not mean the domain is free from spoofing: DMARC does not stop lookalike domains ("yourdomain.net" versus "yourdomain.com"), and a record can be valid and still not cover every sender if one is missing from SPF or DKIM is only published for one selector.
With the "default" selector. The selector is the name chosen by whoever signs the mail —for example, the email provider— and many domains use a different one, so an Invalid DKIM in this report does not rule out that the domain signs its email: check it with the real selector in the DKIM checker.
The domain is sent to this site's backend, which is what queries the domain's public DNS records (it also asks a public DNS resolver for them, exactly as any mail server would). These are read-only lookups: nothing in your DNS is modified, no access to your provider is needed, and the domain is not stored in any database or in the application logs.
