Back to results

Digital exposure report

caltech.edu

Critical findings in the observed public configuration. Some basic protections were not detected.

Scanned: 2026-11-15 19:22 UTC

Partial coverage: the score is based on 52% of applicable check weight. 8 unverified check(s) are excluded, not counted as failures.

F
46/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.caltech.edu
  2. 2.

    Send visitors to the secure version of your site

    Visitors who type your address without https may stay on an unprotected connection.

    Who can fix it: Your web host

    How to verify after the fix

    curl -sI http://caltech.edu/ | grep -iE "^(HTTP|location)"

A starting point, not a security guarantee.

What this grade means

Tested hostname
caltech.edu
Website request
GET https://caltech.edu/
Scan time
2026-11-15 19:22:38 UTC
Grading method
Version 2How grading works
Unverified or excluded checks
  • HTTPS available · Unverified
  • SSL/TLS certificate validity · Unverified
  • HSTS — enforce encryption in the browser · Unverified
  • CSP — protection from script injection · Unverified
  • Clickjacking protection · Unverified
  • X-Content-Type-Options · Unverified
  • Referrer-Policy · Unverified
  • Permissions-Policy · Unverified

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 security14/30An attacker can send email that looks like it came from the company.
Encryption & certificate0/7Browsing to the site is not properly protected by encryption.
Browser protections—Nothing in this category could be verified from public data.
DNS infrastructure10/15The domain's infrastructure works, but recommended hardening is missing.

Fix priorities

  1. 1.HighHTTP → HTTPS redirect · Hardening gap+13
  2. 2.MediumSPF — who may send mail for the domain · Hardening gap+12
  3. 3.MediumDMARC — anti-spoofing policy · Hardening gap+19
  4. 4.LowCAA — who may issue certificates · Hardening gap+10

To verify

Couldn't be confirmed from public data, so excluded from the score. Checking them clarifies your posture; it doesn't guarantee a score change.

  • HTTPS available
  • SSL/TLS certificate validity
  • CSP — protection from script injection
  • HSTS — enforce encryption in the browser
  • Clickjacking protection
  • X-Content-Type-Options
  • Referrer-Policy
  • Permissions-Policy

Findings

SPF — who may send mail for the domain

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

The SPF record is neutral and does not block unauthorized senders.

?all (neutral) does not tell the receiving server to reject or flag mail from servers not on the list.

Source data: DNS TXT caltech.edu
v=spf1 ip4:131.215.0.0/16 ip4:134.4.0.0/16 ip4:192.100.16.0/24 ip4:198.129.208.0/23 ip4:208.69.128.0/22 ip4:199.188.184.0/22 ip4:198.202.125.128/25 ip4:74.122.104.0/22 ip4:72.10.184.102 ip4:72.10.184.103 ip4:72.10.182.15 ip4:72.10.182.16 include:spf.protection.outlook.com include:sendgrid.net include:mktomail.com include:spf.dynect.net include:cust-spf.cashnet.com include:amazonses.com include:_spf.createsend.com include:_spf01.mykronos.com include:_s0.caltech.edu ?all
$ dig +short TXT caltech.edu
Fix recommendation (effort: Easy)
  1. Map every service that sends mail in the domain's name (Google Workspace / Microsoft 365, newsletter tool, CRM).
  2. Publish exactly one TXT record at the domain root starting with v=spf1.
  3. Start with ~all, and move to -all once DMARC reports confirm all legitimate senders are covered.
caltech.edu.  TXT  "v=spf1 include:_spf.google.com ~all"

Safety: DNS changes are made only at your DNS provider. This tool only reads public data and changes nothing on the domain. An incorrect record can block legitimate mail — add every sender before tightening.

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.caltech.edu
v=DMARC1; p=none; rua=mailto:6e39dba0@mxtoolbox.dmarc-report.com,mailto:caltech@us.cp-dmarc.com; ruf=mailto:6e39dba0@forensics.dmarc-report.com,mailto:caltech@us.cp-dmarc.com; fo=1
$ dig +short TXT _dmarc.caltech.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.caltech.edu.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@caltech.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: selector1, selector2, default, s1, s2. Confirm signing with dkim=pass in a sent message's Authentication-Results.

Source data: DNS TXT <selector>._domainkey.caltech.edu
selector1._domainkey: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8xkF4Iv3pKwuJT+rki/OXPKmJwWs…
selector2._domainkey: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3+W3fggoJJhtKHWo92krcYNeJYc0…
default._domainkey: v=DKIM1; t=y; g=*; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC79eN71kuiG4vu4h0zC+IjdQ…
s1._domainkey: k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA32PlTn4eqhOZ0rmMdGHTdc8lpdfiZ38r…
s2._domainkey: k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKJ0hAwdEs4Fn3kbCCdpT8FaOK3uJGIHr42xcm…
$ dig +short TXT selector1._domainkey.caltech.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.

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

Source data: DNS MX caltech.edu
10 mx1.caltech.iphmx.com
10 mx2.caltech.iphmx.com
$ dig +short MX caltech.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

Unverified · Severity: OK · Not scored

HTTPS couldn't be confirmed: the request timed out or the connection failed. This isn't treated as a security failure.

Requesting https://caltech.edu/ didn't complete (HTTP 526). Timeouts and transport errors may be transient; the check is excluded from the score.

Source data: HTTPS GET https://caltech.edu/
HTTP 526
$ curl -svI https://caltech.edu/ 2>&1 | grep -E "SSL|HTTP|expire"
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

Failed · Severity: High · Hardening gap · 0/7

The site is also reachable over an unencrypted connection, so data may travel in plain text on public networks.

http://caltech.edu/ returned HTTP 301 without redirecting to https:// (Location: http://www.caltech.edu/).

Source data: HTTP GET http://caltech.edu/ (redirects not followed)
HTTP 301
Location: http://www.caltech.edu/
$ curl -sI http://caltech.edu/ | grep -iE "^(HTTP|location)"
Fix recommendation (effort: Easy)
  1. Set up a permanent (301) redirect from every HTTP request to HTTPS on the server or CDN.
  2. Then add an HSTS header.
server {
  listen 80;
  server_name caltech.edu www.caltech.edu;
  return 301 https://$host$request_uri;
}

Safety: This change is made on your server. Make sure HTTPS works first, otherwise the site won't load.

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

Unverified · Severity: OK · Not scored

The certificate couldn't be checked live because the HTTPS connection didn't complete. CT log data alone isn't used to score validity or expiry.

No live TLS evidence was obtained. CT entries are shown as context only. Not scored.

Source data: Certificate Transparency logs (certspotter) for caltech.edu
CT logs (context only, not scored):
Issuer: Amazon Trust Services
Valid from: 2026-10-14
Valid until: 2027-04-29
Names: *.caltech.edu, caltech.edu
Based on Certificate Transparency logs; may not reflect the certificate currently served.
$ echo | openssl s_client -connect caltech.edu:443 -servername caltech.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

Unverified · Severity: OK · Not scored

Couldn't be checked — no usable HTTPS response was obtained. Not scored.

No response with headers was received, so this header wasn't evaluated and is excluded from the score.

Source data: Response headers from https://caltech.edu/
No HTTPS response received
$ curl -sIL https://caltech.edu/
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

Unverified · Severity: OK · Not scored

Couldn't be checked — no usable HTTPS response was obtained. Not scored.

No response with headers was received, so this header wasn't evaluated and is excluded from the score.

Source data: Response headers from https://caltech.edu/
No HTTPS response received
$ curl -sIL https://caltech.edu/
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

Unverified · Severity: OK · Not scored

Couldn't be checked — no usable HTTPS response was obtained. Not scored.

No response with headers was received, so this header wasn't evaluated and is excluded from the score.

Source data: Response headers from https://caltech.edu/
No HTTPS response received
$ curl -sIL https://caltech.edu/
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

Unverified · Severity: OK · Not scored

Couldn't be checked — no usable HTTPS response was obtained. Not scored.

No response with headers was received, so this header wasn't evaluated and is excluded from the score.

Source data: Response headers from https://caltech.edu/
No HTTPS response received
$ curl -sIL https://caltech.edu/
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

Unverified · Severity: OK · Not scored

Couldn't be checked — no usable HTTPS response was obtained. Not scored.

No response with headers was received, so this header wasn't evaluated and is excluded from the score.

Source data: Response headers from https://caltech.edu/
No HTTPS response received
$ curl -sIL https://caltech.edu/
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

Unverified · Severity: OK · Not scored

Couldn't be checked — no usable HTTPS response was obtained. Not scored.

No response with headers was received, so this header wasn't evaluated and is excluded from the score.

Source data: Response headers from https://caltech.edu/
No HTTPS response received
$ curl -sIL https://caltech.edu/
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)

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 caltech.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 caltech.edu
(no CAA records found)
$ dig +short CAA caltech.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.
caltech.edu.  CAA  0 issue "letsencrypt.org"
caltech.edu.  CAA  0 iodef "mailto:security@caltech.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.

2 NS servers.

Source data: DNS NS caltech.edu
ns0090.secondary.cloudflare.com
ns0239.secondary.cloudflare.com
$ dig +short NS caltech.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 rules2 observed gaps
  • PCI DSS v4.01 observed gaps · 5 unverified
  • NIS2 / vendor due diligence3 observed gaps · 3 unverified
  • SOC 2 / ISO 27001 baseline2 observed gaps · 6 unverified

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

Acaltech.edu52.26.125.194
AAAAcaltech.edu—
MXcaltech.edu10 mx1.caltech.iphmx.com | 10 mx2.caltech.iphmx.com
NScaltech.eduns0090.secondary.cloudflare.com | ns0239.secondary.cloudflare.com
TXTcaltech.eduMS=ms43712753 | iContact1389932 | jk01vgvoojdefne9jihhtis667 | ZOOM_verify_a-Gb5-aqQgygEiKsnho63w | apple-domain-verification=KD7b3wNXe76BHRAV | autodesk-domain-verification=TtWEzwdFn86i9o8NX_8R | 1password-site-verification=VRLN67QMNNEPXIIREL6TDZABF4 | amazonses:CBaUu/J2wBFtHuO9isUzHAXTnIWcN5RyPUBvggu7SNE= | amazonses:X9y0RbFXXvxu3ft83xg2e+YV++OUePTUSeCOdB3Chjg= | openai-domain-verification=dv-fRmGl55vmrLnDqlIOcOoidYz | anthropic-domain-verification-rw8528=rFwrZAPawzCVNGD318e9zzavQ | Y84qDmmAIPozyUoBIRWmXsFltoU2Pl8b8WGKPlqgz+1t5Db4z9H5ngaaCTq3TTaOK+SCPYUsGVlGn0wUzXNdow== | adobe-idp-site-verification=1e150df049a820e49156727d1b84c48a1ae11f66f87ad76d2cf30cb9d378acb6 | v=spf1 ip4:131.215.0.0/16 ip4:134.4.0.0/16 ip4:192.100.16.0/24 ip4:198.129.208.0/23 ip4:208.69.128.0/22 ip4:199.188.184.0/22 ip4:198.202.125.128/25 ip4:74.122.104.0/22 ip4:72.10.184.102 ip4:72.10.184.103 ip4:72.10.182.15 ip4:72.10.182.16 include:spf.protection.outlook.com include:sendgrid.net include:mktomail.com include:spf.dynect.net include:cust-spf.cashnet.com include:amazonses.com include:_spf.createsend.com include:_spf01.mykronos.com include:_s0.caltech.edu ?all
TXT_dmarc.caltech.eduv=DMARC1; p=none; rua=mailto:6e39dba0@mxtoolbox.dmarc-report.com,mailto:caltech@us.cp-dmarc.com; ruf=mailto:6e39dba0@forensics.dmarc-report.com,mailto:caltech@us.cp-dmarc.com; fo=1
CAAcaltech.edu—
DScaltech.edu2371 13 2 dd9bc517a0668e5513ca5e546e6d155fc07358d3093245481462c37033eb1a90
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