Skip to main content
DNS Tool
Engineer's DNS Intelligence Report
Generated 21 Feb 2026, 02:09 UTC
Duration 27.8s
Version v26.21.52
Integrity 99e4e4f21d3bb9ad44c291ffdda3e3032aca3a26b91e963e60ba6eb985dfedbbf8ba4445a2f3c795f9e48ca6583a972e8deee79b4e0249b2969966eaccca5c63
Subject Domain
cia.gov

Engineer's DNS Intelligence Report

cia.gov
21 Feb 2026, 02:09 UTC · 27.8s ·v26.21.52 · SHA-3-512: 99e4✱✱✱✱ Verify ·Cross-Referenced
Executive Topology
Recon Mode Snapshot Re-analyze New Domain
DNS Security & Trust Posture Risk Level: Low Risk
5 protocols configured, 4 not configured Domain appears to be in deliberate DMARC deployment phase — quarantine fully enforced with reporting, consider upgrading to reject Why we go beyond letter grades
What’s Wrong Upgrade DMARC policy from quarantine to reject (p=reject) for maximum spoofing protection
Jump To: MTA-STS TLS-RPT BIMI DANE
Email Spoofing
Protected
Brand Impersonation
Not Setup
DNS Tampering
Protected
Certificate Control
Configured
Recommended
Upgrade DMARC policy from quarantine to reject (p=reject) for maximum spoofing protection
Configured
SPF (hard fail), DMARC (quarantine, 100%), DKIM, DNSSEC, CAA
Not Configured
MTA-STS, TLS-RPT, BIMI, DANE
Priority Actions Achievable posture: Secure
Medium Upgrade DMARC to Reject

Your DMARC policy is set to quarantine. Upgrade to p=reject for maximum protection — reject instructs receivers to discard spoofed mail entirely rather than quarantining it.

A reject policy provides the strongest protection against domain spoofing.
TypeTXT
Host_dmarc.cia.gov (update existing DMARC record)
Valuev=DMARC1; p=reject; rua=mailto:dmarc-reports@cia.gov
RFC 7489 §6.3
Low Add TLS-RPT Reporting

TLS-RPT (TLS Reporting) sends you reports about TLS connection failures when other servers try to deliver mail to your domain.

TLS-RPT sends you reports about TLS connection failures to your mail servers.
TypeTXT
Host_smtp._tls.cia.gov (SMTP TLS reporting record)
Valuev=TLSRPTv1; rua=mailto:tls-reports@cia.gov
RFC 8460
Low Deploy MTA-STS

MTA-STS enforces TLS encryption for inbound mail delivery, preventing downgrade attacks on your mail transport.

MTA-STS tells sending servers to require TLS when delivering mail to your domain.
TypeTXT
Host_mta-sts.cia.gov (MTA-STS policy record)
Valuev=STSv1; id=cia.gov
RFC 8461
Open Remediation Workspace — Copy-Paste Ready Records
Registrar (RDAP) OBSERVED LIVE
get.gov (Registrant: REDACTED FOR PRIVACY)
Where domain was purchased
Email Service Provider
Unknown
Moderately Protected
Web Hosting
Unknown
Where website is hosted
DNS Hosting
Unknown
Where DNS records are edited
Footprint
Email Security Methodology Can this domain be impersonated by email? Unlikely SPF and DMARC quarantine policy enforced

SPF Record RFC 7208 §4 Gold

Does this domain declare who may send email on its behalf? Yes
Success -all 1/10 lookups

SPF valid with strict enforcement (-all), 1/10 lookups

v=spf1 mx -all
RFC 7489 §10.1: -all may cause rejection before DMARC evaluation, preventing DKIM from being checked
RFC 7208 Conformant — This SPF record conforms to the syntax and semantics defined in RFC 7208 §4.
RFC Failure Mode: Unlike DMARC (where unknown tags are silently ignored per RFC 7489 §6.3), SPF with unrecognized mechanisms produces a PermError per RFC 7208 §4.6 — the record fails loudly rather than silently.
Related CVEs: CVE-2024-7208 (multi-tenant domain spoofing), CVE-2024-7209 (shared SPF exploitation), CVE-2023-51764 (SMTP smuggling bypasses SPF)
SPF hard fail (-all): compliance-strong, but can short-circuit DMARC. RFC 7489 notes that -all can cause some receivers to reject mail during the SMTP transaction — before DKIM is checked and before DMARC can evaluate the result. A message that would pass DMARC via DKIM alignment may be rejected prematurely. For most domains, ~all + DMARC p=reject is the strongest compatible posture — it allows every authentication method (SPF, DKIM, DMARC) to be fully evaluated before a decision is made.
DMARC enforcement is partial (quarantine). -all may preempt DKIM/DMARC evaluation at some receivers. Consider p=reject for full enforcement; ~all is more DMARC-compatible.

DMARC Policy RFC 7489 §6.3 Gold

Are spoofed emails rejected or quarantined? Quarantined, not rejected
Success p=quarantine

DMARC policy quarantine (100%) - good protection

v=DMARC1; p=quarantine; sp=quarantine; pct=100; rua=mailto:demarcreports@uce.cia.gov; ruf=mailto:demarcfailures@uce.cia.gov; ri=86400; aspf=s; adkim=s; fo=1
Alignment: SPF strict DKIM strict sp=quarantine
Forensic reporting (ruf) is configured, but most major providers do not send forensic reports. RFC 7489 §7.3 warns that forensic reports can expose PII (full message headers or bodies). Google, Microsoft, and Yahoo do not honour ruf= requests. The DMARCbis draft (draft-ietf-dmarc-dmarcbis) has formally removed ruf= from the specification. Consider removing this tag to simplify your record. RFC 7489 §7.3 — Forensic Reports
Advanced cryptographic posture detected. Domain appears to be in deliberate DMARC deployment phase — quarantine fully enforced with reporting, consider upgrading to reject
RFC 7489 Present — DMARC record published per RFC 7489 §6.3.
Monitoring Posture Note: Quarantine sequesters authentication failures while preserving full DMARC forensic telemetry (RFC 7489 §7). Some organizations maintain quarantine rather than reject as a deliberate monitoring strategy — failed messages are processed and reported but sequestered from the inbox. See NIST SP 800-177 Rev. 1 for enforcement tradeoffs.
DMARCbis (Pending): draft-ietf-dmarc-dmarcbis will elevate DMARC to Standards Track, obsolete RFC 7489, replace pct= with t= (testing flag), add np= (non-existent subdomain policy), and mandate DNS tree walk for policy discovery instead of the Public Suffix List.
Related CVEs: CVE-2024-49040 (Exchange sender spoofing), CVE-2024-7208 (multi-tenant DMARC bypass)

DKIM Records RFC 6376 §3.6 Gold

Are outbound emails cryptographically signed? Yes — verified
Found

Found DKIM records for 1 selector(s)

s1._domainkey
v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDWKDG6o+aUX3ov7h3zsv1mjQ5oTy8kFUYXMtgRQxrk3BHfM7cEXysehX3MaOgf/1JuN1dzmbwTMG9WqY1ikhQTjWbi0qVP0LMw7QSXmkdpmGl/QXEKp5LJDNGTuE3yPtD/068WPe1wYI2Oqx/ODOkxF4LUx7tbhjBBgzXtl8/Z5QIDAQAB;
RFC 6376 Conformant — DKIM keys and signatures conform to RFC 6376 §3.6 (Internet Standard).
Known Vulnerabilities: DKIM l= tag body length vulnerability (attacker appends unsigned content to signed mail), weak key exploitation (keys below 1024-bit are cryptographically breakable per RFC 6376 §3.3.3), DKIM replay attacks (re-sending legitimately signed messages at scale)

MTA-STS RFC 8461 §3 Gold

Can attackers downgrade SMTP to intercept mail? Not prevented
Warning

No MTA-STS record found

MTA-STS policy enforcement is evaluated in Mail Transport Security below.

TLS-RPT RFC 8460 §3 Gold

Will failures in TLS delivery be reported? No reporting
Warning

No TLS-RPT record found

DMARC External Reporting Authorization RFC 7489 §7.1

Are external report receivers authorized? Yes — all authorized
Success

All 1 external reporting domains properly authorized

External Domain Authorization Auth Record
uce.cia.gov Authorized v=DMARC1;
Suggested Scanner Configuration High Confidence
Based on 20 historical scans of this domain
Parameter Current Suggested Severity Rationale
timeout_seconds 5s 8s low Average scan duration is 37.7s, suggesting DNS responses are slow for this domain. Increasing timeout from 5s to 8s prevents premature resolution failures.
RFC 8767
Suggestions require explicit approval before applying. No automatic changes will be made.
DANE / TLSA Gold Recon Methodology Can mail servers establish identity without a public CA? No
RFC 7672 §3 RFC 6698 §2 Not Configured

No DANE/TLSA records found (checked 2 MX hosts)

DANE (RFC 7672) binds TLS certificates to DNSSEC-signed DNS records, protecting email transport against man-in-the-middle attacks and rogue CAs. It is the primary transport security standard — MTA-STS (RFC 8461) was created as the alternative for domains that cannot deploy DNSSEC. Over 1 million domains use DANE globally, including Microsoft Exchange Online, Proton Mail, and Fastmail. Best practice: deploy both for defense in depth.
Email Transport Security

Two mechanisms protect email in transit. DANE is the primary standard; MTA-STS is the alternative for domains that cannot deploy DNSSEC:

  • DNSSEC + DANE (RFC 7672) — Cryptographic chain of trust from DNS root to mail server certificate. Eliminates reliance on certificate authorities. No trust-on-first-use weakness. Requires DNSSEC.
  • MTA-STS (RFC 8461) — HTTPS-based policy requiring TLS for mail delivery. Works without DNSSEC but relies on CA trust and is vulnerable on first use (§10). Created for domains where “deploying DNSSEC is undesirable or impractical” (§2).
This domain has neither DANE nor MTA-STS. Mail transport relies on opportunistic TLS without policy enforcement, leaving it vulnerable to downgrade attacks. Deploy DANE (RFC 7672) with DNSSEC for the strongest protection, or MTA-STS (RFC 8461) if DNSSEC is not feasible.

Industry trend: Microsoft Exchange Online enforces inbound DANE with DNSSEC (GA October 2024), and providers like Proton Mail and Fastmail also support DANE. Google Workspace does not support DANE and relies on MTA-STS. Both mechanisms coexist because DANE is backward-compatible — senders skip the check if the domain isn't DNSSEC-signed (RFC 7672 §1.3).

Brand Security Can this brand be convincingly faked? Likely DMARC quarantine flags but does not reject spoofed mail (RFC 7489 §6.3), and no BIMI brand verification — lookalike domains display identically in inboxes; CAA restricts certificate issuance (RFC 8659 §4) but visual brand faking remains open

BIMI BIMI Spec Gold warning

Is the brand identity verified and displayed in inboxes? No

No BIMI record found

CAA RFC 8659 §4 Gold