Skip to main content
DNS Tool
Executive's DNS Intelligence Brief
Generated 14 Feb 2026, 05:51 UTC
Duration 20.6s
Version v26.12.28
Integrity 59de34c07bd0165cc0b5c316daf9d0b8fc9e6cd2fb701336f2bf048ae38c117584756e49766eec6bf3c4d8b6f8d0145fb4299bb83b6b9916514cfc12ecda87b6
Subject Domain
red.com

Executive's DNS Intelligence Brief

Board-level domain security assessment — red.com

14 Feb 2026, 05:51 UTC · 20.6s · SHA-3-512: 59de✱✱✱✱ Verify
Engineer
DNS Security & Trust Posture
Risk Level: Medium Risk Monitoring
4 protocols configured, 3 not configured
Email Spoofing
Partial
Brand Impersonation
Not Set Up
DNS Tampering
Enterprise
Certificate Control
Configured
What Requires Attention
No urgent actions detected. Domain security posture is well-maintained.
The BIG Questions
Can this domain be impersonated by email? Not Assessed
Can DNS itself be tampered with? Not Assessed
Can this brand be convincingly faked? Not Assessed
Is mail transport encryption enforced? Not Assessed
Is certificate issuance controlled? Not Assessed
Domain Overview
Registrar SafeNames Ltd.
Email Provider Microsoft 365
Web Hosting AWS CloudFront
DNS Hosting Amazon Route 53

Technical Findings

Email Authentication
SPF (Sender Policy) Configured
DMARC (Policy) Partial Policy: none Monitor Only
DKIM (Signatures) Configured
Mail Posture Email: Monitoring
Mail Transport Security
MTA-STS Partial
DANE / TLSA Active
TLS-RPT (Reporting) Not Configured
Mail Transport Not Enforced Policy-assessed
DNS Security
DNSSEC Partial
DNSSEC not configured - DNS responses are unsigned
NS Delegation Healthy
Brand & Certificate Controls
BIMI (Brand Logo) Not Configured
CAA (Certificate) Configured
Priority Actions 5 total Achievable: Low Risk
High Escalate DMARC from monitoring to enforcement

Change your DMARC policy from p=none to p=quarantine (then p=reject). Review your DMARC aggregate reports first to ensure legitimate senders pass authentication.

_dmarc.red.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@red.com"
High Enable DNSSEC for DANE validation

DANE/TLSA records are published but DNSSEC is not enabled. DANE requires DNSSEC to work — without it, TLSA records cannot be authenticated and are ignored by validating resolvers (RFC 7672 §2.2). Enable DNSSEC first.

Medium Deploy MTA-STS policy

Publish an MTA-STS DNS record and host a policy file at https://mta-sts.red.com/.well-known/mta-sts.txt. This tells senders to require TLS when delivering mail to your domain.

_mta-sts.red.com TXT "v=STSv1; id=20240101"
Low Configure TLS-RPT reporting

TLS-RPT (TLS Reporting) sends you reports about TLS connection failures when other servers try to deliver mail to your domain. Helps diagnose MTA-STS and STARTTLS issues.

_smtp._tls.red.com TXT "v=TLSRPTv1; rua=mailto:tls-reports@red.com"
Low Enable DNSSEC

DNSSEC (DNS Security Extensions) cryptographically signs DNS responses, preventing attackers from forging DNS answers. Contact your DNS hosting provider to enable DNSSEC signing.

Appendix — Additional Resources

Full technical details including raw DNS records, DKIM public keys, IP/ASN mappings, resolver consensus evidence, and verification commands are available in the Engineer's DNS Intelligence Report.

View Engineer's DNS Intelligence Report

Verify Report Integrity SHA-3-512 Has this report been tampered with? Verify below

Tamper-evident fingerprint binding this analysis to its data, domain, timestamp, and tool version.

59de34c07bd0165cc0b5c316daf9d0b8fc9e6cd2fb701336f2bf048ae38c117584756e49766eec6bf3c4d8b6f8d0145fb4299bb83b6b9916514cfc12ecda87b6
12 RFCs evaluated · DNS state at 14 Feb 2026, 05:51 UTC