Cardinal · Domain Security
Trycardinal Ai Domain Security
Domain security
Domain security posture for Cardinal, probed live across 4 host(s) and 2 registrable domain(s). 3 host(s) serve HTTPS (up to TLSv1.3); 3 advertise HSTS. Email/DNS controls: DNSSEC absent, SPF present, DMARC present (p=quarantine).
CompanyArtificial IntelligenceSalesOutbound SalesSales AutomationSales EngagementGo-To-MarketRevenue OperationsAI AgentsLead GenerationMachine Learning
Transport & Host Security
www.trycardinal.com
HTTPS: yes
· TLS: TLSv1.3
· HSTS: yes
· cert expires: Oct 27 23:25:25 2026 GMT
trycardinal.ai
HTTPS: yes
· TLS: TLSv1.3
· HSTS: yes
· cert expires: Feb 14 16:12:24 2027 GMT
app.trycardinal.ai
HTTPS: yes
· TLS: TLSv1.3
· HSTS: yes
· cert expires: Sep 18 03:49:59 2026 GMT
api.trycardinal.ai
HTTPS: no
· HSTS: no
Domain (DNS/Email) Security
trycardinal.com
DNSSEC: no
· SPF: yes
· DMARC: yes
(p=quarantine)
· CAA: none
trycardinal.ai
DNSSEC: no
· SPF: yes
· DMARC: yes
(p=reject)
· CAA: yes
Source
Domain Security
generated: '2026-08-13'
method: probed
source: >-
Live DNS/TLS/HTTP probes of every host associated with Cardinal. The marketing host
came from probe-domain-security.py (which reads the apis.yml Website pointer); the
three trycardinal.ai hosts were probed by hand in the same pass and merged in,
because apis.yml carries no apis[] entries and no baseURL, so the script's host
discovery only reaches the website domain. Both registrable domains are covered.
checked: '2026-08-13'
hosts:
- host: www.trycardinal.com
role: marketing website (Framer-hosted)
https: true
tls_version: TLSv1.3
cert_expires: Oct 27 23:25:25 2026 GMT
hsts: true
hsts_max_age: 31536000
- host: trycardinal.ai
role: legacy marketing domain — 301 redirect
https: true
tls_version: TLSv1.3
cert_expires: Feb 14 16:12:24 2027 GMT
hsts: true
hsts_max_age: 31536000
http_status: 301
redirects_to: https://www.trycardinal.com/
note: >-
Root 301s to the .com marketing site. Deep paths that existed on the old site
(/company, /product) now return HTTP 404, so this is a root-only redirect rather
than a path-preserving domain migration.
- host: app.trycardinal.ai
role: customer application (Next.js on Vercel)
https: true
tls_version: TLSv1.3
cert_expires: Sep 18 03:49:59 2026 GMT
hsts: true
hsts_max_age: 63072000
hsts_include_subdomains: true
http_status: 200
final_url: https://app.trycardinal.ai/login?next=%2F
security_headers:
content_security_policy: true
x_frame_options: DENY
x_content_type_options: nosniff
referrer_policy: strict-origin-when-cross-origin
permissions_policy: camera=(), microphone=(), geolocation=()
frame_ancestors: none
note: >-
The strongest security posture of the three hosts: a full CSP with an explicit
allow-list, frame-ancestors 'none', two-year HSTS with includeSubDomains, and
nosniff. Every unauthenticated path redirects to a Stytch-backed login.
- host: api.trycardinal.ai
role: custom API hostname — NOT SERVING
https: false
tls_error: 'SSLV3_ALERT_HANDSHAKE_FAILURE — no certificate is presented for this name'
http_status: 409
http_body: 'error code: 1001'
dns_cname: coordinator-api-wmxp.onrender.com
origin_probe:
url: https://coordinator-api-wmxp.onrender.com/
status: 404
header: 'x-render-routing: no-server'
note: >-
A DEAD CUSTOM DOMAIN, recorded because its absence is the finding. DNS resolves
api.trycardinal.ai to a Render service (coordinator-api-wmxp.onrender.com), but no
TLS certificate covers the custom hostname, so every HTTPS request fails at the
handshake; plain HTTP returns Cloudflare error 1001 (HTTP 409). Probing the Render
origin directly returns HTTP 404 with x-render-routing:no-server on every path,
which is Render's response when no service is attached. Nothing is served here, and
no API host is asserted anywhere in this repo on the strength of this record.
domains:
- domain: trycardinal.com
registrar_dns: framer / sites.framer.app
dnssec: false
caa: []
spf: true
spf_record: v=spf1 include:_spf.google.com ~all
dmarc: true
dmarc_policy: quarantine
dmarc_raw: 'v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:dmarc_rua@onsecureserver.net;'
note: >-
Weaker than the .ai domain on two counts: no CAA records at all, and a DMARC policy
of quarantine rather than reject. This is now the primary brand domain, so the
weaker posture applies to the name customers see.
- domain: trycardinal.ai
dnssec: false
caa:
- 0 iodef "mailto:jianna@trycardinal.ai"
- 0 issue "starfieldtech.com"
- 0 issue "letsencrypt.org"
- 0 issue "godaddy.com"
spf: true
spf_record: v=spf1 include:_spf.google.com ~all
dmarc: true
dmarc_policy: reject
dmarc_raw: 'v=DMARC1; p=reject; adkim=r; aspf=r; rua=mailto:dmarc_rua@onsecureserver.net;'
note: >-
CAA is present and names a founder's address as the incident contact
(mailto:jianna@trycardinal.ai) — a real, human-owned iodef target. Since the prior
pass (2026-07-21) two issuers were added alongside Let's Encrypt (starfieldtech.com
and godaddy.com), widening the set of CAs permitted to issue for this domain.
DMARC is at p=reject, the strongest published policy across either domain.
summary:
hosts_probed: 4
hosts_serving_https: 3
domains_probed: 2
dnssec_enabled: 0
dmarc_enforced: 2
caa_present: 1
weakest_link: >-
trycardinal.com — the primary brand domain — has no CAA records and only
p=quarantine DMARC, while the legacy trycardinal.ai domain has both. Neither domain
signs DNSSEC.