Skip to main content
DNS Tool
Engineer's DNS Intelligence Report
Generated 17 Feb 2026, 10:23 UTC
Duration 22.4s
Version v26.19.18
Integrity 5a168560ab9d560cfcec285f5f5631b4f6b43b771de74c9375bec2843128dc5641c57206d426ab7d2960824d6d7fff41952b740455d7ee261e0ea8d04552ff2c
Subject Domain
isc.org

Engineer's DNS Intelligence Report

isc.org
17 Feb 2026, 10:23 UTC · 22.4s ·v26.19.18 · SHA-3-512: 5a16✱✱✱✱ Verify
Executive Methodology
Recon Mode Snapshot Re-analyze New Domain
Footprint 2 SaaS Services
DNS Security & Trust Posture
Risk Level: Medium Risk
7 protocols configured, 2 not configured Domain appears to be in deliberate DMARC monitoring phase with aggregate reporting enabled Why we go beyond letter grades
1 recommendation 1 monitoring
Suggested Scanner Configuration High Confidence
Based on 17 historical scans of this domain
Parameter Current Suggested Severity Rationale
timeout_seconds 5s 8s low Average scan duration is 44.0s, 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
Partial
Brand Impersonation
Not Setup
DNS Tampering
Protected
Certificate Control
Configured
Recommended
Move DMARC policy from 'none' to 'quarantine' or 'reject'
Monitoring
DMARC record has configuration warnings — review recommended
Configured
SPF, DMARC (with warnings), DKIM, TLS-RPT, DANE, DNSSEC, CAA
Not Configured
MTA-STS, BIMI
Priority Actions Achievable posture: Low Risk
High Upgrade DMARC from p=none

Your DMARC policy is monitor-only (p=none). Upgrade to p=quarantine or p=reject after reviewing reports to actively prevent spoofing.

A quarantine or reject policy instructs receivers to take action on failing mail.
TypeTXT
Host_dmarc.isc.org (DMARC policy record)
Valuev=DMARC1; p=quarantine; rua=mailto:dmarc-reports@isc.org
RFC 7489 §6.3
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.isc.org (MTA-STS policy record)
Valuev=STSv1; id=isc.org
RFC 8461
Registrar (RDAP) OBSERVED LIVE
Tucows Domains Inc.
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
Email Security Methodology Can this domain be impersonated by email? Yes DMARC is monitor-only (p=none)

SPF Record RFC 7208 §4 Verified

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

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

v=spf1 a mx ip4:149.20.0.0/20 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ip4:199.6.1.0/24 ip6:2001:500:6b:2::0/64 include:shops.shopify.com include:servers.mcsv.net include:_spf.salesforce.com include:spf-a.customercenter.net include:spf-b.customercenter.net include:spf-c.customercenter.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 has DMARC p=none (monitoring only). Enforcing quarantine or reject is recommended to gain real protection.

DMARC Policy RFC 7489 §6.3 Verified

Are spoofed emails rejected or quarantined? Monitoring only
Warning p=none

DMARC in monitoring mode (p=none) - spoofed mail still delivered, no enforcement

v=DMARC1; p=none; sp=reject; rua=mailto:0rzssdyk@ag.dmarcian.com; ruf=mailto:0rzssdyk@fr.dmarcian.com, mailto:dmarcforensic@isc.org; fo=1;
Policy p=none provides no protection - spoofed emails reach inboxes
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 monitoring phase with aggregate reporting enabled
RFC 7489 Present — DMARC record published per RFC 7489 §6.3.
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 Verified

Are outbound emails cryptographically signed? Yes — verified
Found

Found DKIM records for 3 selector(s)

k2._domainkey
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv2aC2KjGKLOwTweBY5A9RpjsxaBXR9r7OAU6U8/zn92ivImI75naUujWbItRI/QmL1jy5PWGqLwoUA0b90ObWaLDc+i9MtTNmGeWO009hr20fIxhGg6XBT2kjZ1DTThopSe1nAndsupmcBwlQ5Q6LJ+ZAxLcujnPIxM0ZBLmgpkv8u6RfY4eFP8OLvdAW3oSuB0DyLDigQX4Sj8wBO4YIdQH6AAmBeOsidsKAFNFUCpc3vCxtBDR12U+cBg724l3sBkMQ8evnz6idnqxq9QAVYh8k4kJ+RP+6cqTdy7LjIm8xY/bQNpQIpGUAuDo2DjLcCDun9DAI4Q/3z+Q0o9QuQIDAQAB;
zendesk1._domainkey Zendesk
v=DKIM1;t=s;n=core;k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9IqdLrO3Zr2/56MHt8oQVCQorP0Bl2Fz9sM2tFBnJCdB/HogQmuudEg2xAovCN2PYpw44UijIvPuBoT9vxiv6ZCBJTLJXa82r6ke5rE4tbe9NKFIrVIb9S306cJDrnKFMDb8p0dU/Su0+eUR5gVAOtCuz2L8HAzs5edvsEvD/Fb4ny1RLNSEPZkIQLfGhVxQeWANm3+1Jwb/OBVXV9k0nKpWrpgqcmO7NzroJirp014RQY7rGi60JLUubc6XhvoFQBQrtOAdVlZC5wvfS1bgpq5kQpdP7cajIqWCeqxPTeo0ZUpey2ZcaygEsZz0Z3Gs5wDzyuqd7/ADpr2jNF7ozwIDAQAB
zendesk2._domainkey Zendesk
v=DKIM1; t=s; n=core; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmiSFNkgXrO3I8aOaPONDZWHv027rkiGIwb838OyXPgvFDEkCV/qGcdXSjZnaVAadrTm/oKnL8WOltP9zB1FLEuKt0fTi5zRyKPE4oIYCnEzXwrGqzjUcCABQBawQVqvXjDOaYh9Lhp8W5PYOLo905vRW7ipyIMDhuzBOJls91/WWXnNK0OwP3RghiisZjA3K2KqtRwf7w6GjNeNuAMNhvcmgAN15d/mhK+dev/hcRbal66RoYyTD8c0F0isahWH0envEX8aj+SBhheNk0/U37dGE+4nFaY5yP9CUlYjFKDSIKZgHzG4Hci3t/RubU58pi6BCrQQdAFvIOeDFeCZ0ywIDAQAB
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 Verified

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 Verified

Will failures in TLS delivery be reported? Yes — reports configured
Success

TLS-RPT configured - receiving TLS delivery reports

v=TLSRPTv1; rua=mailto:0rzssdyk@tls.us.dmarcian.com

DMARC External Reporting Authorization RFC 7489 §7.1

Are external report receivers authorized? Yes — all authorized
Success

All 2 external reporting domains properly authorized

External Domain Authorization Auth Record
ag.dmarcian.com Authorized v=DMARC1;
fr.dmarcian.com Authorized v=DMARC1;
DANE / TLSA Verified Recon Methodology Can mail servers establish identity without a public CA? Yes
RFC 7672 §3 RFC 6698 §2 2/2 MX

DANE configured — TLSA records found for all 2 MX hosts

MX Host Usage Selector Match Certificate Data
mx.ams1.isc.org 3 DANE-EE (Domain-issued certificate) Public key only (SubjectPublicKeyInfo) SHA-256 40f9c00cff49771c74615e4b366ec19e110928396904539b97878b6e6811bfe1
mx.pao1.isc.org 3 DANE-EE (Domain-issued certificate) Public key only (SubjectPublicKeyInfo) SHA-256 865c0bc73ec3dac90f73b3d1cf6ba08ecb2848134aab479b6279fe7044a0fa89
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 uses DNSSEC + DANE — the strongest cryptographic transport security. DANE binds TLS certificates to DNSSEC-signed DNS records, creating a verifiable chain of trust from root to mail server (RFC 7672 §1.3). MTA-STS could complement this for senders that don't validate DNSSEC, but DANE alone provides the highest level of protection available.

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 is monitor-only (p=none) — spoofed mail is not blocked

BIMI BIMI Spec Verified Warning

Is the brand identity verified and displayed in inboxes? No

No BIMI record found

CAA RFC 8659 §4 Verified