Skip to main content
DNS Tool
Engineer's DNS Intelligence Report
Generated 14 Feb 2026, 04:55 UTC
Duration 3.8s
Version v26.12.28
Integrity 629ee7f8652f501c47c114efce467b998b559e4959f5a14fcb963cc96da64dbd0a2f807d11c3400a85674a8bd317158b12a5c23724f0e9e701acd39039dd6480
Subject Domain
usa.gov

Engineer's DNS Intelligence Report

usa.gov
14 Feb 2026, 04:55 UTC · 3.8s ·v26.12.28 · SHA-3-512: 629e✱✱✱✱ Verify ·Cross-Referenced
Executive Topology
Recon Mode Snapshot Re-analyze New Domain
Footprint 2 SaaS Services
DNS Security & Trust Posture
Risk Level: Low Risk
4 protocols configured, 3 not configured Why we go beyond letter grades
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 41.8s, 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.
Email Spoofing
Protected
Brand Impersonation
Not Setup
DNS Tampering
Protected
Certificate Control
Open
Configured
SPF (~all), DMARC (reject), DKIM (provider-verified), DNSSEC
Not Configured
MTA-STS, TLS-RPT, CAA
Priority Actions 5 total Achievable posture: Low Risk
Medium Deploy MTA-STS policy

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

_mta-sts.usa.gov TXT "v=STSv1; id=20240101"
RFC 8461 §3
Low Add CAA records

Publish CAA DNS records to restrict which Certificate Authorities can issue TLS certificates for your domain. Specify your preferred CA (e.g., letsencrypt.org, digicert.com). CAA is advisory — CAs must check it before issuing, but absence means any CA can issue.

usa.gov CAA 0 issue "letsencrypt.org"
RFC 8659 §4
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.usa.gov TXT "v=TLSRPTv1; rua=mailto:tls-reports@usa.gov"
RFC 8460 §3
Low Deploy DANE/TLSA for email transport

DNSSEC is already enabled — you can strengthen email transport security by publishing DANE TLSA records. DANE binds your mail server's TLS certificate to DNS, preventing man-in-the-middle attacks on SMTP connections.

_25._tcp.mail.usa.gov TLSA 3 1 1 <certificate_hash>
RFC 7672 §3
Low Configure BIMI brand logo

Publish a BIMI DNS record pointing to your brand logo (SVG Tiny PS format). For full support in Gmail, you will also need a Verified Mark Certificate (VMC).

default._bimi.usa.gov TXT "v=BIMI1; l=https://usa.gov/logo.svg"
BIMI Spec
Open Remediation Workspace — Copy-Paste Ready Records
Registrar (RDAP) OBSERVED LIVE
get.gov (Registrant: REDACTED FOR PRIVACY)
Where domain was purchased
Email Service Provider OBSERVED
Unknown
No-Mail: Partial
Web Hosting OBSERVED
AWS
Where website is hosted
DNS Hosting OBSERVED
Unknown Gov Enterprise
Where DNS records are edited
Email Security Methodology Can this domain be impersonated by email? No
No-Mail: Partial 1/3 controls
This domain appears to not send mail but only 1 of 3 no-mail signals are present.
DMARC reject (RFC 7489) Null MX (RFC 7505) SPF -all (RFC 7208)
Missing steps to complete no-mail hardening:
Null MX — Publish a null MX record: 0 . (RFC 7505)
Without null MX, senders may still attempt delivery.
SPF -all — Publish SPF with -all to reject all senders. (RFC 7208)
Without SPF -all, mail servers may accept forged messages.
Verdict: DMARC policy is reject — spoofed messages will be blocked by receiving servers. DKIM keys verified (provider-verified for Amazon SES).

SPF Record RFC 7208 §4 Consistent

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 include:amazonses.com include:532040.spf10.hubspotemail.net ~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 Consistent

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

DMARC policy reject (100%) - excellent protection

v=DMARC1; p=reject; pct=100; fo=1; ri=86400; rua=mailto:dmarcreports@gsa.gov,mailto:reports@dmarc.cyber.dhs.gov; ruf=mailto:dmarcfailures@gsa.gov
Alignment: SPF relaxed DKIM relaxed
No np= tag (DMARCbis) — non-existent subdomains inherit p= policy but adding np=reject provides explicit protection against subdomain spoofing
Forensic reports (ruf) configured - many providers ignore these
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 Consistent

Are outbound emails cryptographically signed? Provider-managed
Provider Verified

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

Amazon SES detected as primary mail platform — DKIM signing is managed by the provider. The primary provider may use custom selectors not discoverable through standard checks.
Know your DKIM selector? Re-scan with a custom selector to verify.
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 Consistent

Can attackers downgrade SMTP to intercept mail? Not prevented