Skip to main content
DNS Tool
Engineer's DNS Intelligence Report
Generated 21 Feb 2026, 14:03 UTC
Duration 17.7s
Version v26.22.23
Integrity ae74b8d0ecddbcc5f261f8fb24e9523a3c6463afc4b2547bf51b4ca30f0e3488ae6aea2a91ed386b3d30d9bc02a9be2a30d45150bac372c75a9577bc801439cc
Subject Domain
nsa.gov

Engineer's DNS Intelligence Report

nsa.gov Low Risk
21 Feb 2026, 14:03 UTC · 17.7s ·v26.22.23 · SHA-3-512: ae74✱✱✱✱ Verify ·Cross-Referenced
Executive Topology Replay
Recon Mode Snapshot Re-analyze New Domain
Engineer workspace · evidence preserved

Read the verdict first. Descend only as far as the incident requires.

This report keeps the complete technical record while separating decision, interpretation, evidence, and raw reproduction into a stable disclosure gradient.

L0PostureL1InterpretationL2EvidenceL3Raw & reproduce
Hurry path
MX & Routing Subdomains DNSSEC What changed
KEYBOARD !1@2#3$4%5^6 jump to that section · esc back to the verdict
Sorted by severity — worst first
Email Spoofing
Protected
Brand Impersonation
Not Setup
DNS Tampering
Protected
Certificate Control
Open
Monitoring
Partial
DANE
Unconfirmed
TRACE L0 · Brand Impersonation — Not Setup L1 · 04 · Brand & Trust · BIMI L3 · Reproduce commands
Not Configured
MTA-STS, TLS-RPT, BIMI, CAA
Monitoring
DKIM signing inferred from provider — could not directly verify selector
Configured
SPF, DMARC (reject), DKIM (inferred via Unknown), DANE, DNSSEC
Priority Actions 5 total Achievable posture: Hardened
Medium Upgrade From Legacy DNSSEC Algorithm

This domain uses RSA/SHA-1 (algorithm 5 or 7) which is NOT RECOMMENDED per RFC 8624. While still operational, plan migration to ECDSAP256SHA256 (algorithm 13) or Ed25519 (algorithm 15) for improved security and smaller signatures.

RFC 8624 §3.1
Low Add BIMI Record

Your domain has DMARC reject — you qualify for BIMI, which displays your brand logo in receiving email clients that support it (Gmail, Apple Mail, Yahoo).

RFC 9495
Low Add CAA Records

CAA records specify which Certificate Authorities may issue certificates for your domain, reducing the risk of unauthorized certificate issuance.

RFC 8659
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
Strongly Protected
Web Hosting
Unknown
Where website is hosted
DNS Hosting
Unknown
Where DNS records are edited
Footprint
01 Identity & policy · L1 Email Security Can this domain be impersonated by email? SPF DMARC DKIM MTA-STS TLS-RPT MX & Routing Protected
Email Security Methodology Can this domain be impersonated by email? No SPF and DMARC reject policy enforced

SPF Record RFC 7208 §4 Gold

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

SPF valid with industry-standard soft fail (~all), 2/10 lookups

v=spf1 ip4:214.29.60.2/32 ip4:214.29.60.3/32 ip4:214.80.121.17/32 ip4:214.80.121.18/32 include:_spf.eemsg.mail.mil include:amazonses.com ~all
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)
~all is the industry standard. Google, Apple, and most providers default to soft fail. CISA (BOD 18-01) and RFC 7489 confirm that DMARC policy — not SPF alone — is the primary enforcement control. Using ~all allows DKIM to be evaluated before a DMARC decision is made. This domain uses ~all + DMARC reject: the strongest compatible security stance, aligned with CISA and RFC guidance.

DMARC Policy RFC 7489 §6.3 Gold

Are spoofed emails rejected or quarantined? Yes — reject policy
Success p=reject

DMARC policy reject (100%) - excellent protection

v=DMARC1;p=reject;sp=reject;fo=1;rua=mailto:DMARC_REPORTING@nsa.gov,mailto:DMARC_reports@mail.mil;ruf=mailto:DMARC_REPORTING@nsa.gov,mailto:DMARC_reports@mail.mil;rf=afrf;pct=100
Alignment: SPF relaxed DKIM relaxed sp=reject
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
RFC 7489 Conformant — DMARC record conforms to RFC 7489 §6.3 with full enforcement.
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? Not discoverable
Not Discoverable

DKIM not discoverable via common selectors (large providers use rotating selectors)

RFC 6376 (Provider-Managed) — DKIM signing managed by the detected mail provider per RFC 6376.
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