Cookie Policy

This site uses cookies. When browsing the site, you are consenting its use. Learn more

I understood

Results: www.cds.pt

https://webcheck.pt/en/results/www.cds.pt/

Results obtained at: 2026-03-12 09:51:38

Seconds until new update:

119

Website component

Domain security and configuration

DNSSEC
DNSSEC (Domain Name System Security Extensions) is a security extension to the DNS protocol designed to secure and authenticate DNS traffic. These extensions use asymmetric encryption to ensure the authenticity and integrity of the information exchanged between DNS servers and between these and the user's applications.

For a better understanding and correct implementation of DNSSEC you can check the  DNS.PT reference document "DNSSEC Tutorial" (Only available in Portuguese).
This test verifies if the domain name is signed with DNSSEC. Correct implementation of DNSSEC prevents manipulation of DNS responses, which could lead to unauthorized redirection of requests to a server controlled by a third party.

The domain name is not signed with DNSSEC.

This test verifies if the domain name is signed with a valid DNSSEC signature and marked as "secure".

This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.

DANE
DANE (DNS-based Authentication of Named Entities) is a protocol that adds an additional layer of protection to the web service, as it allows you to securely specify information about the certificate that should be used to access your website.

The use of DANE depends on the DNSSEC implementation.

For more information about STARTTLS and DANE and its implementation please check the CNCS-PT reference document "Technical Recomendation 01/21 - STARTTLS and DANE" (Only available in Portuguese).
This test verifies the existence of a signed TLSA record for each of the web servers of your internet domain.

Since the correct DANE configuration depends on the DNSSEC implementation, this test will not be performed if the domain is not configured with DNSSEC.

This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.

Technical details:

DNSSEC does not exist

This test verifies if the DANE fingerprint published in the TLSA record(s) corresponds to the digital certificate(s) presented by the web server(s).

This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.

Technical details:

DNSSEC does not exist

Connection security

HTTP/S
The HTTPS (Hypertext Transfer Protocol Secure) protocol represents an additional security layer to the HTTP protocol. The use of HTTPS in an internet domain aims to prevent the interception and/or manipulation by third parties of the communication between the browser and the server who hosts the website.
This test verifies if the internet domain provides the HTTPS protocol for secure communication.

There is a channel that allows a secure communication between the internet browser and the server hosting the internet domain.

Technical details:

172.67.189.227: HTTPS Enabled

This test verifies if the Internet domain automatically forwards the communications from HTTP to HTTPS (in the same domain and through the code 301) or if it only supports the HTTPS protocol.

There is an active redirection of communications to the secure channel (HTTPS).

HSTS
HSTS (HTTP Strict-Transport-Security) consists of a response header that allows an internet domain to communicate to the browser that it should only be accessed through the HTTPS protocol, thus avoiding the use of insecure and vulnerable channels, susceptible of interception and manipulation by third parties.
This test checks if the internet domain supports HSTS.

To fully comply with this validation the HSTS header must be configured with a max-age value of more than 6 months. If the value of "max-age" is less than 6 months the result will be a partial compliance.

The internet domain does not support HSTS.

Technical details:

HSTS Header: Not Found

This test verifies if the internet domain is configured with HSTS preloading.

HSTS preloading allows you to place the domain in a built-in list of many internet browsers. If the domain is present in this list, whenever someone visits the website associated with it, it will automatically be forwarded to a secure channel (HTTPS). This feature is adopted by the most commonly used internet browsers such as Chrome, Firefox and Safari.

After you correctly implement the HSTS header, you can request to have your domain incorporated into this list in: https://hstspreload.org/.

This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.

TLS
TLS (Transport Layer Security) is a cryptographic protocol designed to provide communications security. The use of secure versions of the TLS protocol, in combination with valid digital certificates, provides the visitors of an Internet domain a higher degree of security in the established connection.
This test checks if the Internet domain supports versions of the TLS protocol considered to be insecure.

Older versions of TLS (SSL v2.0, v3.0 and TLS v1.0) contain several well-known vulnerabilities, so they should not be adopted. The use of the TLS v1.1 protocol is considered a partial compliance with the test so the transition to TLS version 1.2 and / or higher (which represents a complete fulfillment of the verification) is advised.

 The Internet domain supports one or more versions of the TLS protocol that are considered to be unsafe.

Technical details:

cds.pt: SSLv2:false | SSLv3:false | TLSv1.0:true | TLSv1.1:true | TLSv1.2:true | TLSv1.3:true

This test verifies if the web server(s) of your internet domain support the secure renegotiation of the TLS protocol.

Older versions of the TLS protocol (prior to version 1.3) allow forcing a protocol renegotiation, a potentially insecure feature in the original versions of the protocol. This has been fixed in recent versions by implementing a more secure renegotiation mechanism. The old version is called insecure renegotiation and should be disabled.

The web server(s) of the internet domain support the secure renegotiation of the TLS protocol.

Digital Certificate
A digital certificate (also known as SSL / TLS or public key certificate) consists of an electronic document, digitally signed by a certifying entity, that links the public key of the entity for which it is intended with their identification data and is used to guarantee the authenticity and integrity in electronic transactions.
This test verifies if the digital certificate associated to the domain is not expired.

To fully comply with this validation, the digital certificate must present an expiration date of more than 30 days.

The digital certificate associated to the internet domain is not expired and has a validity period of more than 30 days.

Technical details:

cds.pt: 06-06-2026

This test checks if the digital certificate associated with the domain is recognized by the most commonly used internet browsers and if it is correctly configured.

In order to fully comply with this validation, the certificate cannot be self-signed, must have a recognized "Root CA" and correctly present the intermediate certificates.

The digital certificate chain is valid and does not contains configuration errors.

Technical details:

Self Signed Cert:false | HTTPS Bad Chain:false | HTTPS Probably Missing Intermediate Cert:false | HTTPS Publicly Trusted:true

Security options

Security Headers
In addition to the HSTS security header there are still other HTTP headers that can contribute to improve the security of your internet domain name.
This test verifies if the internet domain supports the "X-Content-Type-Options" security header with the "nosniff" option.

By using this security option, the browser will block any styles or scripts whenever they do not match with the content type. For example, a "style" in which the MIME type is not "text/css" will be blocked.

The internet domain does not support the "X-Content-Type-Options" security header.

Technical details:

X-Content-Type-Options header not found.

This test verifies if the internet domain supports the "X-Frame-Options" security header. This header allows you to control whether the internet page associated with the domain can be included inside another web page (i.e. "framed"). This header can be implemented through three different options:

1. "deny", stating that the internet domain can never be "framed" within an internet page associated with another domain;
2. "sameorigin", stating that the internet domain can only be "framed" within an internet page of the domain itself;
3. "allow-from", stating that the internet domain can only be "framed" within an internet page belonging to the indicated domain(s).

The internet domain does not support the "X-Frame-Options" security header.

Technical details:

X-Frame-Options header not found.

This test verifies if the internet domain supports the "Referrer-Policy" security header. This header is used to control what kind of information is sent through the "Referer" field.

This header can be implemented with the following options:

1. "no-referrer", where all "Referer" information is omitted;
2. "no-referrer-when-downgrade", where "Referer" information is only sent when the same level of security is maintained (HTTP -> HTTP or HTTPS -> HTTPS);
3. "origin", where the information sent in "Referer" is only relative to the origin, for example, the document https://example.pt/page sends as "Referer" the value "https://example.pt/" ;
4. "origin-when-cross-origin", where the "Referer" information is sent in full when within the same domain, but only the origin when for other domains;
5. "same-origin", where "Referer" information is only sent within the same domain;
6. "strict-origin", where the "Referer" information is only relative to the origin and only sent when the same level of security is maintained;
7. "strict-origin-when-cross-origin", where the "Referer" information is sent in full when within the same domain, but only the origin when for other domains and maintaining the level of security;
8. "unsafe-url", where the "Referer" information is sent in full to any domain.

The internet domain does not support the "Referrer-Policy" security header.

Technical details:

Referrer-Policy header not found.

This test verifies if the internet domain supports the "Content-Security-Policy" security header. This header allows you to define how and from which source the resources, such as javascripts and CSS, can be used by the web page. This security header can prevent cross-site scripting (XSS) attacks by blocking the script injection from unknown and unauthorized sources.

The internet domain does not support the "Content-Security-Policy" security header.

Technical details:

Content-Security-Policy header not found.

E-mail component

E-mail domain security and configuration

DNSSEC
DNSSEC (Domain Name System Security Extensions) is a security extension to the DNS protocol designed to secure and authenticate DNS traffic. These extensions use asymmetric encryption to ensure the authenticity and integrity of the information exchanged between DNS servers and between these and the user's applications.

For a better understanding and correct implementation of DNSSEC you can check the  DNS.PT reference document "DNSSEC Tutorial" (Only available in Portuguese).
This test verifies if the domain name(s) of the email exchange (MX) server(s) is(are) signed with DNSSEC. A correct implementation of DNSSEC prevents manipulation of DNS responses, which could lead to unauthorized redirection of requests to a server controlled by a third party.

At least one domain name of the email server(s) (MX) is not signed with DNSSEC.

This test verifies if the domain name(s) of the email exchange (MX) server(s) is(are) signed with a valid DNSSEC signature and marked as "secure".

This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.

Authentication and Integrity

SPF
SPF (Sender Policy Framework) consists of a validation standard for the e-mail channel, based on the use of the Domain Name System (DNS) to publish the IP address(es) of the server(s) authorized to send e-mail on behalf of the domain. This is a method that allows the domain holder to specify which e-mail server (or servers) are allowed to send messages and enable the subsequent verification by the destination server.

For more information about SPF and its implementation please check the CNCS-PT reference document "Technical Recomendation 01/19 - SPF, DKIM e DMARC" (Only available in Portuguese).
This test verifies if the e-mail domain has an SPF record.

The email domain has an SPF record configured.

Technical details:

SPF Record: v=spf1 include:spf.mailjet.com mx a include:relays.tuganetcloud.com -all

This test verifies if the e-mail domain has a sufficiently restricted SPF policy.

To fully comply you have to implement a "hardfail" policy (-all). The implementation of a "softfail" policy (~ all) will result in a partial compliance of the requirements. The remaining SPF policy settings or an incorrect registry setting (for example, if there are more than ten DNS records to be resolved) result in non-compliance with the requirements of this test.

The e-mail domain implements a valid and sufficiently secure SPF policy.

DKIM
The use of DKIM (DomainKeys Identified Mail) aims to provide a method for validating a digital identity associated with a message (typically the sender's domain). The objective is the non-repudiation of the attribution of the message, achieved through a cryptographic signature attached to each sent message. DKIM uses public key cryptography, which means that there is a private key that only the message subscriber knows about, and a public key that everyone knows and can use to verify the message.

For more information about DKIM and its implementation please check the CNCS-PT reference document "Technical Recomendation 01/19 - SPF, DKIM e DMARC" (Only available in Portuguese).
This test verifies if the e-mail domain has a DKIM key/record. A recipient e-mail server can use this record to verify the authenticity and integrity of the incoming message. However it is not possible to check the validity of the DKIM key through this test since it would be necessary to know the domain DKIM selector (which is only present in the headers of the messages sent from this domain).

To fully comply with the requirements of this validation, and considering RFC2308, the domain name server is expected to respond "NOERROR" to the query "_domainkey.<domain_name>". If the answer is "NXDOMAIN" it is considered that you don't have DKIM enabled.

The e-mail domain name has a DKIM record configured.

DMARC
DMARC (Domain-based Message Authentication, Reporting & Conformance) relies on the correct implementation of SPF and DKIM and unifies these two authentication mechanisms in a common framework that allows the owners of each domain to define how an e-mail message domain should be handled if an authorization test fails. Implementers of DMARC also benefit from the ability to gain greater visibility into legitimate and illegitimate emails sent through their domain name.

For more information about DMARC and its implementation please check the CNCS-PT reference document "Technical Recomendation 01/19 - SPF, DKIM e DMARC" (Only available in Portuguese).
This test verifies if the e-mail domain has a DMARC record. The DMARC policy defines how a recipient e-mail server should act when it identifies a message that fails to comply with the SPF and/or DKIM policy set for the sending domain.

 The e-mail domain does not have a DMARC record associated.

Technical details:

DMARC Record: Not Found

This test verifies if the e-mail domain has a sufficiently restricted DMARC policy. To fully comply with this test you have to implement DMARC with a policy of rejection or quarantine ("p = reject" or "p = quarantine"). When the non-action policy is applied ("p = none"), the test will result in a partial compliance.

Through the definition of the "rua=" and "ruf =" options, DMARC also enables the reception of aggregated reports of conformity ("rua") and forensic ("ruf") for a better vision and understanding of the degree of illegitimate use of the domain.

This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.

Confidentiality

STARTTLS
STARTTLS consists of an extension of the SMTP (Simple Mail Transfer) protocol that allows the use of Transport Layer Security (TLS) in order to ensure a secure and authenticated communication between two devices that wish to exchange an  e-mail message . The use of STARTTLS is thus intended to prevent e-mail messages from being intercepted and / or manipulated on the way to their final destination.

For more information about STARTTLS and DANE and its implementation please check the CNCS-PT reference document "Technical Recomendation 01/21 - STARTTLS and DANE" (Only available in Portuguese).
This test verifies if the email server(s) associated with the domain supports a STARTTLS connection. If supported, the TLS protocol versions associated with that connection will be tested.

The e-mail server(s) associated to the domain do not support STARTTLS connections.

Technical details:

mx.spamexperts.com:25, mx.spamexperts.com:587, lastmx.spamexperts.net:25, lastmx.spamexperts.net:587, fallbackmx.spamexperts.eu:25, fallbackmx.spamexperts.eu:587

This test verifies if the e-mail server(s) associated to the domain support secure versions of the TLS protocol.

Older versions of TLS (SSL v2.0, v3.0 and TLS v1.0) contain several well-known vulnerabilities and should not be adopted. The use of the TLS v1.1 protocol is considered a partial compliance with the test, and the transition to TLS v1.2 and / or higher (which represents a complete fulfillment of the verification) is advised.

This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.

DANE
DANE (DNS-based Authentication of Named Entities) is a protocol that adds an additional layer of protection to the email service, as it allows you to securely specify information about the certificate that should be used in STARTLS communication between servers.

The use of DANE depends on the DNSSEC implementation.

For more information about STARTTLS and DANE and its implementation please check the CNCS-PT reference document "Technical Recomendation 01/21 - STARTTLS and DANE" (Only available in Portuguese).
This test verifies the existence of a signed TLSA record for your domain's email server(s).

Since the correct DANE configuration depends on the DNSSEC implementation, this test will not be performed if the domain is not configured with DNSSEC.

This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.

Technical details:

DNSSEC does not exist

This test verifies if the DANE fingerprint published in the TLSA record(s) corresponds to the TLS certificate(s) presented by the email server(s).

This test was not performed because there were no technical conditions for its execution or because it depends on a previous test that failed.

Technical details:

DNSSEC does not exist

Compliant

Partially compliant

Not compliant

Test not performed

Recommendations