Overview
Findings
Actions
Details
Related
AI-Generated Summary
What this means
gizdev.com scored 85/100, demonstrating a strong security posture. Minor improvements are noted below.
Critical gaps in: DMARC / Email Security. Positive signals: MX Records & Mail Provider, DNS Configuration, TLS Configuration all passed.
1 action item identified, including 1 critical. The issues are configuration gaps, not architectural problems. A focused remediation effort of 2–5 days could address all findings.
How gizdev.com compares
Grade distribution across 2545 companies we've scanned. gizdev.com scores better than 78% of them.
79
A+
26
A
184
A-
192
B+
73
B
355
B-
123
C+
116
C
327
C-
120
D+
94
D
245
D-
611
F
gizdev.com — Grade B (85/100)
2545 companies scanned
Security checks
Each check inspects a different part of gizdev.com's public security setup. Green means healthy, yellow needs attention, red is a problem.
DMARC / Email Security
Strengths: SPF record present with soft-fail (~all). Issues: DMARC policy is 'none' (monitoring only, no enforcement); No DKIM records found for common selectors (domain may use custom selectors — this is not a confirmed gap).
MTA-STS & TLS Reporting
Issues: No MTA-STS configured — email in transit is vulnerable to TLS downgrade attacks. Sending servers cannot verify that your mail server requires TLS; No TLSRPT record — TLS delivery failures won't be reported to domain owner.
DNS CAA Records
Strengths: CAA records configured (10 record(s)); Authorized CAs: digicert.com; cansignhttpexchanges=yes, letsencrypt.org, pki.goog; cansignhttpexchanges=yes, ssl.com, comodoca.com. Issues: No iodef record — CA violations won't be reported to the domain owner.
security.txt (RFC 9116)
No security.txt found. Publishing a security.txt at /.well-known/security.txt is the industry standard (RFC 9116) for vulnerability disclosure policies. Its absence may indicate a less mature security program.
MX Records & Mail Provider
Strengths: Mail handled by Zoho Mail; 3 MX record(s) configured; Multiple MX records provide redundancy.
DNS Configuration
Strengths: 2 nameservers configured (toby.ns.cloudflare.com., jamie.ns.cloudflare.com.); 3 MX records present; DNSSEC enabled; Zone transfers properly restricted.
HSTS Header
HSTS enabled: max-age=15552000s (180 days). includeSubDomains present. preload present.
Security Headers
4/5 security headers present. Missing: CSP.
TLS Configuration
TLSv1.3 negotiated with TLS_AES_256_GCM_SHA384 (256-bit). Strong configuration with no deprecated protocols or weak ciphers detected.
TLS Protocol Support
Strengths: TLS 1.3 supported; TLS 1.2 supported; TLS 1.3 supported (strongest). Protocol support: TLS 1.3: Yes, TLS 1.2: Yes, TLS 1.1: No, TLS 1.0: No.
Cookie Security
No cookies set on the homepage response. No cookie security flags to evaluate.
Known Breaches
No known breaches found in public disclosure databases.
CVE Exposure
Detected technologies: cloudflare. (cloudflare detected but excluded from CVE matching — upstream infrastructure). All detected technologies are upstream CDN/proxy infrastructure. No application-level software versions exposed.
Certificate Hygiene
Strengths: Certificate valid, 45 days remaining; Issued by Google Trust Services. Note: Wildcard certificate in use (*.domain) — covers all subdomains. Common practice; worth noting that compromise would affect all subdomains.
Recommended actions
1 item
Steps to improve gizdev.com's security grade, ranked by impact.
1
Set up email authentication (DKIM)
Without email authentication, anyone can send emails that appear to come from gizdev.com. This is the most common vector for phishing attacks targeting employees and customers. DKIM is not configured.
Compliance impact
NIST CSFPR.AC-7
Email authentication is a required access control
ISO 27001A.13.2.1
Information transfer policies require email security controls
HIPAA§164.312(e)
Transmission security for electronic PHI
How to fix this
1
Add SPF record to DNS: v=spf1 include:_spf.google.com ~all (adjust for your email provider)
2
Configure DKIM signing with your email provider and publish the public key in DNS
3
Add DMARC record: v=DMARC1; p=quarantine; rua=mailto:[email protected]
4
Monitor DMARC reports for 2–4 weeks, then upgrade policy to p=reject
At a glance
Key data points from the scan.
TLS Version
TLSv1.3
TLSv1.3 negotiated with TLS_AES_256_GCM_SHA384 (256-bit). Strong configuration with no deprecated protocols or weak ciphers detected.
DMARC Policy
p=none
Strengths: SPF record present with soft-fail (~all). Issues: DMARC policy is 'none' (monitoring only, no enforcement); No DKIM records found for common selectors (domain may use custom selectors — this is not a confirmed gap).
SPF Record
Present
v=spf1 include:zoho.com ~all
Security Headers
4/5 present
Missing: CSP
HSTS
Enabled
HSTS enabled: max-age=15552000s (180 days). includeSubDomains present. preload present.
SSL Certificate
Valid
Strengths: Certificate valid, 45 days remaining; Issued by Google Trust Services. Note: Wildcard certificate in use (*.domain) — covers all subdomains. Common practice; worth noting that compromise would affect all subdomains.
DNSSEC
Enabled
Strengths: 2 nameservers configured (toby.ns.cloudflare.com., jamie.ns.cloudflare.com.); 3 MX records present; DNSSEC enabled; Zone transfers properly restricted.