Back to results

Digital exposure report

cmu.edu

High exposure. Significant weaknesses put the brand, customers and email at risk.

Scanned: 2026-11-15 19:22 UTC

Full coverage: every applicable check was assessed.

D
67/100

What to do first

  1. 1.

    Tell receiving mail servers how to treat fake email from your domain

    Without this policy, inboxes have less guidance for spotting messages that impersonate you.

    Who can fix it: Your email provider, together with whoever manages your DNS

    How to verify after the fix

    dig +short TXT _dmarc.cmu.edu
  2. 2.

    Limit what scripts your pages are allowed to run

    This adds one layer of protection against injected scripts.

    Who can fix it: Your website developer or web host

    How to verify after the fix

    curl -sIL https://cmu.edu/ | grep -i "Content-Security-Policy"

A starting point, not a security guarantee.

What this grade means

Tested hostname
cmu.edu
Website request
GET https://cmu.edu/ → https://www.cmu.edu/
Scan time
2026-11-15 19:22:43 UTC
Grading method
Version 2How grading works
Unverified or excluded checks
None. Every applicable check was assessed.

This is a snapshot of the public configuration checks listed in this report. It does not verify the site's owner, business legitimacy, application security, or absence of vulnerabilities. It is not a security certification.

Score by category

Email security19/30Spoofing email in the company's name is possible in some cases.
Encryption & certificate25/25Traffic to the site is encrypted and the certificate is valid.
Browser protections13/30Several browser hardening headers are missing, which removes layers of protection against script injection and framing.
DNS infrastructure10/15The domain's infrastructure works, but recommended hardening is missing.

Fix priorities

  1. 1.MediumHSTS — enforce encryption in the browser · Hardening gap+4
  2. 2.MediumDMARC — anti-spoofing policy · Hardening gap+10
  3. 3.MediumCSP — protection from script injection · Hardening gap+8
  4. 4.LowCAA — who may issue certificates · Hardening gap+5
  5. 5.LowReferrer-Policy · Hardening gap+3
  6. 6.LowPermissions-Policy · Hardening gap+2

Findings

SPF — who may send mail for the domain

Passed · Severity: OK · 9/10

An authorized sender list is defined; mail from other servers is flagged as suspicious.

~all (softfail) — acceptable when combined with enforced DMARC. 1 of 10 DNS lookups.

Source data: DNS TXT cmu.edu
v=spf1 include:_spf.cmu.edu ~all
$ dig +short TXT cmu.edu
Documentation: RFC 7208 — SPF (https://www.rfc-editor.org/rfc/rfc7208) · M3AAWG — Email Authentication Best Practices (https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf)

DMARC — anti-spoofing policy

Needs attention · Severity: Medium · Hardening gap · 5/15

DMARC is in monitoring mode only — forged email still reaches recipients.

Policy p=none. p=none collects reports but does not protect.

Source data: DNS TXT _dmarc.cmu.edu
v=DMARC1;p=none;sp=none;rua=mailto:report-dmarc@andrew.cmu.edu
$ dig +short TXT _dmarc.cmu.edu
Fix recommendation (effort: Medium)
  1. Step 1 (monitoring, no effect on mail): publish p=none with an rua address to receive reports.
  2. Step 2: analyze reports for 2–4 weeks and make sure every legitimate sender passes SPF/DKIM.
  3. Step 3: move to p=quarantine, and finally to p=reject.
_dmarc.cmu.edu.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@cmu.edu; fo=1"

Safety: DNS changes are made only at your DNS provider. This tool only reads public data and changes nothing on the domain. Jumping straight to reject without a monitoring phase can block legitimate mail.

Documentation: RFC 7489 — DMARC (https://www.rfc-editor.org/rfc/rfc7489) · dmarc.org — FAQ (https://dmarc.org/resources/frequently-asked-questions/)

DKIM — digital signature on email

Passed · Severity: OK · 5/5

A DKIM public key is published. On its own this doesn't prove outgoing mail is signed or aligned with your From domain.

DKIM public key found for selector: s1, s2. Confirm signing with dkim=pass in a sent message's Authentication-Results.

Source data: DNS TXT <selector>._domainkey.cmu.edu
s1._domainkey: k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1CJ6+q+N264DhEGxi92ISXCkZT+f06yc…
s2._domainkey: k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDTUzQVpQ1SATUnikEo0S3AEJl3+2Q5ygaEhH44…
$ dig +short TXT s1._domainkey.cmu.edu
Documentation: RFC 6376 — DKIM (https://www.rfc-editor.org/rfc/rfc6376) · M3AAWG — Email Authentication Best Practices (https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf)

MX — inbound mail routing

Passed · Severity: OK · unscored

Mail exchangers are published for the domain.

5 MX record(s). This shows where inbound mail is routed, not whether mail is sent from the domain.

Source data: DNS MX cmu.edu
1 ASPMX.L.GOOGLE.COM
5 ALT1.ASPMX.L.GOOGLE.COM
5 ALT2.ASPMX.L.GOOGLE.COM
10 ALT3.ASPMX.L.GOOGLE.COM
10 ALT4.ASPMX.L.GOOGLE.COM
$ dig +short MX cmu.edu
Documentation: RFC 7505 — Null MX (https://www.rfc-editor.org/rfc/rfc7505) · RFC 5321 §5.1 — Locating the target host (https://www.rfc-editor.org/rfc/rfc5321#section-5.1)

HTTPS available

Passed · Severity: OK · 10/10

The site loads over an encrypted connection.

https://cmu.edu/ returned HTTP 200 (final URL: https://www.cmu.edu/). Client-side certificate validation passed.

Source data: HTTPS GET https://cmu.edu/
HTTP 200
Final URL: https://www.cmu.edu/
$ curl -sIL https://cmu.edu/
Documentation: OWASP — Transport Layer Security Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) · Mozilla — Server Side TLS (https://wiki.mozilla.org/Security/Server_Side_TLS)

HTTP → HTTPS redirect

Passed · Severity: OK · 7/7

Visitors arriving at an unencrypted address are automatically sent to the secure version.

HTTP 301 → https://cmu.edu/

Source data: HTTP GET http://cmu.edu/ (redirects not followed)
HTTP 301
Location: https://cmu.edu/
$ curl -sI http://cmu.edu/ | grep -iE "^(HTTP|location)"
Documentation: OWASP — Transport Layer Security Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) · RFC 6797 — HSTS (https://www.rfc-editor.org/rfc/rfc6797)

SSL/TLS certificate validity

Passed · Severity: OK · 8/8

The certificate was accepted by a validating TLS client at scan time.

Live TLS handshake succeeded. Latest issuance in CT logs: Sectigo, expiring 2027-01-18 (64 days). CT shows issued certificates, not necessarily the one served — confirm dates with the verify command.

Source data: Certificate Transparency logs (certspotter) for cmu.edu
Live TLS handshake: certificate accepted
CT logs (context only, not scored):
Issuer: Sectigo
Valid from: 2025-12-18
Valid until: 2027-01-18
Names: admission.enrollment.cmu.edu, ai-sdm.cmu.edu, alumni.cmu.edu, blockchain.cmu.edu, bme.cmu.edu, box.cmu.edu
Based on Certificate Transparency logs; may not reflect the certificate currently served.
$ echo | openssl s_client -connect cmu.edu:443 -servername cmu.edu 2>/dev/null | openssl x509 -noout -issuer -dates
Documentation: Certificate Transparency (https://certificate.transparency.dev/) · Let's Encrypt — Docs (https://letsencrypt.org/docs/) · Mozilla — Server Side TLS (https://wiki.mozilla.org/Security/Server_Side_TLS)

HSTS — enforce encryption in the browser

Needs attention · Severity: Medium · Hardening gap · 4/8

Encryption enforcement is set for too short a time.

max-age=300 (0 days), no includeSubDomains. ≥ 180 days recommended.

Source data: Response headers from https://www.cmu.edu/
Strict-Transport-Security: max-age=300
$ curl -sIL https://cmu.edu/ | grep -i "Strict-Transport-Security"
Fix recommendation (effort: Easy)
  1. Start with a short max-age (300 seconds) and make sure every subdomain works over HTTPS.
  2. Gradually raise it to 31536000 (one year) and add includeSubDomains.
  3. Consider preload only once the policy is stable — removal from the preload list is slow.
/*
  Strict-Transport-Security: max-age=31536000; includeSubDomains

Safety: This change is made in your server/CDN settings. Test on staging before production. HSTS is cached in the visitor's browser — a long max-age on a site without working HTTPS will block access.

Documentation: MDN — Strict-Transport-Security (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security) · RFC 6797 — HSTS (https://www.rfc-editor.org/rfc/rfc6797) · OWASP — HTTP Headers Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)

CSP — protection from script injection

Failed · Severity: Medium · Hardening gap · 0/8

Missing Content-Security-Policy header: this removes one layer of protection against script injection.

No Content-Security-Policy header found.

Source data: Response headers from https://www.cmu.edu/
Content-Security-Policy: (missing)
$ curl -sIL https://cmu.edu/ | grep -i "Content-Security-Policy"
Fix recommendation (effort: Complex)
  1. First publish Content-Security-Policy-Report-Only — it blocks nothing, it only reports.
  2. Collect violations for a week or two and tune the policy to your legitimate sources.
  3. Switch to the Content-Security-Policy header and replace 'unsafe-inline' with a nonce or hash.
/*
  Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

Safety: This change is made in your server/CDN settings. Test on staging before production. An overly strict CSP will break scripts — that's why you start in Report-Only mode.

Documentation: MDN — Content Security Policy (https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP) · OWASP — CSP Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html)

Clickjacking protection

Passed · Severity: OK · 5/5

The site can't be embedded by foreign sites.

X-Frame-Options: SAMEORIGIN, SAMEORIGIN

Source data: Response headers from https://www.cmu.edu/
X-Frame-Options: SAMEORIGIN, SAMEORIGIN
$ curl -sIL https://cmu.edu/ | grep -i "X-Frame-Options"
Documentation: MDN — X-Frame-Options (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Frame-Options) · OWASP — Clickjacking Defense (https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html)

X-Content-Type-Options

Passed · Severity: OK · 4/4

The browser won't guess file types in a way that could execute code.

nosniff is set.

Source data: Response headers from https://www.cmu.edu/
X-Content-Type-Options: nosniff, nosniff
$ curl -sIL https://cmu.edu/ | grep -i "X-Content-Type-Options"
Documentation: MDN — X-Content-Type-Options (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Content-Type-Options) · OWASP — HTTP Headers Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)

Referrer-Policy

Failed · Severity: Low · Hardening gap · 0/3

Internal URLs (including parameters) may leak to external sites.

Referrer-Policy is missing; the browser will use its default.

Source data: Response headers from https://www.cmu.edu/
Referrer-Policy: (missing)
$ curl -sIL https://cmu.edu/ | grep -i "Referrer-Policy"
Fix recommendation (effort: Easy)
  1. Set Referrer-Policy: strict-origin-when-cross-origin.
/*
  Referrer-Policy: strict-origin-when-cross-origin

Safety: This change is made in your server/CDN settings. Test on staging before production.

Documentation: MDN — Referrer-Policy (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy) · OWASP — HTTP Headers Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)

Permissions-Policy

Needs attention · Severity: Low · Hardening gap · 0/2

Access to sensitive features like the camera and location isn't restricted.

Missing Permissions-Policy header.

Source data: Response headers from https://www.cmu.edu/
Permissions-Policy: (missing)
$ curl -sIL https://cmu.edu/ | grep -i "Permissions-Policy"
Fix recommendation (effort: Easy)
  1. Disable browser features the site doesn't need (camera, microphone, geolocation).
/*
  Permissions-Policy: camera=(), microphone=(), geolocation=()

Safety: This change is made in your server/CDN settings. Test on staging before production. Don't disable a feature the site actually uses.

Documentation: MDN — Permissions-Policy (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Permissions-Policy) · OWASP — HTTP Headers Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)

Software version disclosure

Passed · Severity: OK · unscored

The server doesn't disclose software versions.

No version numbers found in the Server / X-Powered-By headers.

Source data: Response headers from https://www.cmu.edu/
server: cloudflare
x-powered-by: (missing)
$ curl -sIL https://cmu.edu/ | grep -iE "^(server|x-powered-by)"
Documentation: OWASP — HTTP Headers Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)

DNSSEC — signed DNS records

Passed · Severity: OK · 7/7

The domain's records are digitally signed and hard to forge.

An AD (Authenticated Data) flag was returned by a validating resolver.

Source data: DNS-over-HTTPS (Cloudflare / Google): AD flag and DS record at the parent
AD = true
$ dig +dnssec cmu.edu | grep -E "flags:.* ad"
Documentation: RFC 4033 — DNSSEC (https://www.rfc-editor.org/rfc/rfc4033) · ICANN — DNSSEC: what and why (https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en)

CAA — who may issue certificates

Needs attention · Severity: Low · Hardening gap · 0/5

Any certificate authority can issue a certificate for the domain, raising the risk of mis-issuance.

No CAA records found. RFC 8659 lets the domain owner restrict which CAs are authorized.

Source data: DNS CAA cmu.edu
(no CAA records found)
$ dig +short CAA cmu.edu
Fix recommendation (effort: Easy)
  1. Identify which certificate authority issued your current certificate (see the certificate check).
  2. Publish CAA for that authority only, and add iodef to receive alerts.
cmu.edu.  CAA  0 issue "letsencrypt.org"
cmu.edu.  CAA  0 iodef "mailto:security@cmu.edu"

Safety: DNS changes are made only at your DNS provider. This tool only reads public data and changes nothing on the domain. If your CDN issues certificates on your behalf, include it too — otherwise certificate renewal will fail.

Documentation: RFC 8659 — CAA (https://www.rfc-editor.org/rfc/rfc8659)

DNS server redundancy

Passed · Severity: OK · 3/3

The domain is served by several DNS servers, so one server failing won't take it down.

3 NS servers.

Source data: DNS NS cmu.edu
NSAUTH1.NET.cmu.edu
NSAUTH2.NET.cmu.edu
NSAUTH3.NET.cmu.edu
$ dig +short NS cmu.edu
Documentation: RFC 2182 — Secondary DNS server operation (https://www.rfc-editor.org/rfc/rfc2182)

Indicative alignment

Best-practice mapping of public findings to common frameworks. Passive scanning tests public configuration only; it doesn't prove compliance or a violation.

  • Google & Yahoo sender rules1 observed gaps
  • PCI DSS v4.02 observed gaps
  • NIS2 / vendor due diligence3 observed gaps
  • SOC 2 / ISO 27001 baseline3 observed gaps

Indicative alignment only, based on public configuration. It doesn't establish whether a framework applies to you, and it isn't legal advice, an audit or a certification.

Public DNS records

Acmu.edu128.2.42.10
AAAAcmu.edu—
MXcmu.edu1 ASPMX.L.GOOGLE.COM | 5 ALT1.ASPMX.L.GOOGLE.COM | 5 ALT2.ASPMX.L.GOOGLE.COM | 10 ALT3.ASPMX.L.GOOGLE.COM | 10 ALT4.ASPMX.L.GOOGLE.COM
NScmu.eduNSAUTH1.NET.cmu.edu | NSAUTH2.NET.cmu.edu | NSAUTH3.NET.cmu.edu
TXTcmu.eduMS=ms17583017 | 00df4000000231leaa | e2ma-verification=fu2 | A8809FFAB54BD9C6F7DFBE92616764D0 | EECD69320F38F645362247248BD675F4 | v=spf1 include:_spf.cmu.edu ~all | ZOOM_verify_FruZuJfdTeW1OOezpsuIVA | apple-domain-verification=yZrPHuazhdH42CPf | docusign=048da45a-23c6-4f6b-8f96-6dff4fa6b22b | zoho-verification=zb38550127.zmverify.zoho.com | airtable-verification=878daeee4665d51015a6dda912bbb9f5 | [NRDR AN-23811_IN_A_128.2.42.10 JRwwvtp22mouAVo7Ye6sJQ] | [NRDR 33356_IN_TXT_MS=ms17583017 io8/1MnXyp5PTqiijD8s0Q] | facebook-domain-verification=vxpo0xkores42yfj9ggcdd2o2d2v2n | reftab-domain-verification=c24d073b23fed3af77c9e3b40010223f | [NRDR 31057_IN_TXT_00df4000000231leaa QSq9rQj5GCBh30pVnLGMtQ] | [NRDR 35455_IN_MX_1.ASPMX.L.GOOGLE.COM. JRKEGqRjzSnACLafB7QQiw] | [NRDR 36124_IN_TXT_e2ma-verification=fu2 tn9dGsCpd6YZrmWG6O9dqw] | [NRDR 36125_IN_TXT_e2ma-verification=fu2 tn9dGsCpd6YZrmWG6O9dqw] | [NRDR 35456_IN_MX_5.ALT1.ASPMX.L.GOOGLE.COM. /CTPCIrZ0nFHanr+3VJRfw] | [NRDR 35457_IN_MX_5.ALT2.ASPMX.L.GOOGLE.COM. pzqzxDk39X4PeiVpV+EvZQ] | google-site-verification=JopPlnNv9VupQydpE3TiwZAEod-zouxEX0inao6rggg | google-site-verification=MYZf5OssFVvgYQF1snvJdiFbMjHy53WzLrnsVGkgpFU | google-site-verification=O2gyijlOW-8BSOghh0tL_4N1PlWU_qznkYhUA22dLJ0 | google-site-verification=m3lUupwhWqjbGCA6JswqWyBi7tkzh-BjbRiYuC6EXTg | google-site-verification=pNbrq7j_EeIowr_Kw1Jfy46bmFWR9p1llXH_leCdLrg | [NRDR 35458_IN_MX_10.ALT3.ASPMX.L.GOOGLE.COM. lw7k2ZT1H96ItGwU98g8LA] | [NRDR 35459_IN_MX_10.ALT4.ASPMX.L.GOOGLE.COM. EkBzBKUeTsTJg2w4Ly2bMw] | [NRDR 31504_IN_TXT_v=spf1.include:_spf.cmu.edu.~all jxEj2x9CC1Gu8ePZldY84w] | [NRDR 37587_IN_TXT_EECD69320F38F645362247248BD675F4 vdnDjzc5a9LVXuQ6DmgOhA] | [NRDR 37683_IN_TXT_A8809FFAB54BD9C6F7DFBE92616764D0 1pWIIBS0QK7rR0bt/OqwZg] | [NRDR 33014_IN_TXT_ZOOM_verify_FruZuJfdTeW1OOezpsuIVA +31oybl7gh2i74ky0SLQcg] | [NRDR 16337_IN_LOC_40.26.39.0.N.79.56.36.2.W.283.1.10.10 5PS/aNXhz6qcZ6tfoRdgeQ] | [NRDR 34415_IN_TXT_apple-domain-verification=yZrPHuazhdH42CPf dbWBQEISZeHDi/9KkKT96g] | [NRDR 34190_IN_TXT_docusign=048da45a-23c6-4f6b-8f96-6dff4fa6b22b AWGRCMvgvpXmHSJ7nxKghg] | r4bgkix7EqRv+dJHKYelMrye44oR+366MsSA0lCP0TOcMK8wfs0bpTMDP1tLTZ66OFh0Qx+ZMLBCeVx0NJ3syQ== | [NRDR 34441_IN_TXT_zoho-verification=zb38550127.zmverify.zoho.com sbctKhpo8bhwlNq+f0khtw] | cisco-ci-domain-verification=5f809f49f9d3ca48d84db537e031b2007011ea11f6410de6a8a02919908675d6 | atlassian-domain-verification=H4RHVEsTq5YZaRen7VBly2a3AqWhfLMxAL3wBScS8EB0Pg5x1vaPhj3eXsGaUOGi | [NRDR 37284_IN_TXT_airtable-verification=878daeee4665d51015a6dda912bbb9f5 GCXTwRluJG0dSxHBUrbFYA] | [NRDR 32847_IN_TXT_facebook-domain-verification=vxpo0xkores42yfj9ggcdd2o2d2v2n 9I1LCDr7zb+jK0IoSEFayA] | [NRDR 37073_IN_TXT_reftab-domain-verification=c24d073b23fed3af77c9e3b40010223f Kmo0sQxn82COz9etYwP/3w] | [NRDR 30017_IN_TXT_google-site-verification=O2gyijlOW-8BSOghh0tL_4N1PlWU_qznkYhUA22dLJ0 PiRIS0yTtnNYmTWYpWCCVw] | [NRDR 34436_IN_TXT_google-site-verification=MYZf5OssFVvgYQF1snvJdiFbMjHy53WzLrnsVGkgpFU C0YNNkwQ5Qfm8taSZKc+1A] | [NRDR 34437_IN_TXT_google-site-verification=m3lUupwhWqjbGCA6JswqWyBi7tkzh-BjbRiYuC6EXTg Or5AmLIb59AN+oiEMjOqoA] | [NRDR 34438_IN_TXT_google-site-verification=pNbrq7j_EeIowr_Kw1Jfy46bmFWR9p1llXH_leCdLrg eMgkItPzPonrYzRZBOx13w] | [NRDR 34503_IN_TXT_google-site-verification=JopPlnNv9VupQydpE3TiwZAEod-zouxEX0inao6rggg HxtpS+uc1I0HuPBMBaTlCA] | [NRDR 32936_IN_TXT_r4bgkix7EqRv+dJHKYelMrye44oR+366MsSA0lCP0TOcMK8wfs0bpTMDP1tLTZ66OFh0Qx+ZMLBCeVx0NJ3syQ== tGCEAk5qNOFhWjjp1w58vw] | [NRDR 36038_IN_TXT_cisco-ci-domain-verification=5f809f49f9d3ca48d84db537e031b2007011ea11f6410de6a8a02919908675d6 VTvqYpCLdM5K6bM5zRNwDQ] | [NRDR 34068_IN_TXT_atlassian-domain-verification=H4RHVEsTq5YZaRen7VBly2a3AqWhfLMxAL3wBScS8EB0Pg5x1vaPhj3eXsGaUOGi ePUw4Mw9giYZRVzpV/ysvQ]
TXT_dmarc.cmu.eduv=DMARC1;p=none;sp=none;rua=mailto:report-dmarc@andrew.cmu.edu
CAAcmu.edu—
DScmu.edu56259 7 1 585e955d36ab11a225e22b42e713c9bc8b0347b7 | 56259 7 2 83f3ea220349ecd74852847f838121275ff28f3c0806b853133bcef61e1d8205
Passive check only: reading public DNS records, Certificate Transparency logs and ordinary GET requests to the homepage over HTTPS and HTTP. No changes were made to the scanned domain. Results are an indication and do not replace a professional security assessment.

Check your own domain