Answers: can someone send email that appears to come from this domain? Checks the published SPF, DKIM and DMARC DNS records — whether DMARC exists, whether its policy actually blocks spoofed mail (p=none only monitors, it does not stop anything), whether SPF is present and not overly permissive, and whether the records are syntactically valid. Returns a 0-100 score plus specific findings, each tied to the record it came from, so the exact problem can be quoted. This is a free check that uses public information: DNS records and ordinary HTTP requests. It does no port scanning and no exploit testing. Use this for any question about email spoofing, phishing impersonation, DMARC/SPF/DKIM setup, or whether an email domain is protected. For a broader picture covering TLS, headers and exposed files too, use scan_domain instead.

Answers: does this domain's TLS configuration have known weaknesses? Returns the Qualys SSL Labs assessment grade for the host, plus findings for specific known problems when present: Heartbleed, POODLE, RC4 support, deprecated protocol versions, missing forward secrecy, and certificate chain issues. IMPORTANT — this one is NOT passive. It queries Qualys SSL Labs, which performs an ACTIVE assessment of the target from Qualys's own infrastructure (reusing a recent cached result when Qualys has one). NEL sends no probe itself, but running this does cause the target to be actively tested by a third party. Prefer it for a domain you own or are authorised to test. It is free, and it does no port scanning and no exploit testing of its own. It does NOT report certificate expiry dates, the issuer, or hostname validity — if you need those, read the certificate directly. It also does not check HTTP security headers — use check_security_headers for those.

Answers: does this site send the HTTP response headers that protect visitors in the browser? Checks for Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options / frame-ancestors, Referrer-Policy and Permissions-Policy — whether each is present and whether its value is actually protective rather than nominal. Returns a 0-100 score plus a finding per header explaining what a missing or weak value exposes. This is a free check that uses public information: DNS records and ordinary HTTP requests. It does no port scanning and no exploit testing. Use this for clickjacking, XSS mitigation, CSP or HSTS questions. It does not check the TLS certificate itself — use check_tls for that.

Answers: is this domain publicly serving files it should not be? Requests a small, fixed list of well-known sensitive paths — things like .env, .git/config, backup archives and exposed configuration — and reports which return real content rather than a 404. Returns a 0-100 score plus a finding per exposed path. How it works, stated plainly: it makes ordinary GET requests for a small FIXED list of well-known paths. It does not brute-force, fuzz, or enumerate — the list never grows and never adapts to what it finds. Note that these are paths an ordinary crawler would not request (.env, .git/config), so the requests are recognisable in a target's logs as a security check rather than routine crawling. This is a free check that uses public information: DNS records and ordinary HTTP requests. It does no port scanning and no exploit testing. Use this for leaked secrets, exposed configuration, or accidentally published files. It does not discover subdomains.

Answers: does this domain have DNS records pointing at services someone else could claim? Inspects published DNS records for dangling CNAMEs — entries still pointing at a de-provisioned cloud or SaaS host (an unclaimed bucket, an expired app instance) that an attacker could register and then serve content from a hostname users already trust. Returns a 0-100 score plus a finding per at-risk record, naming the record and the service it points to. How it works, stated plainly: it resolves a small fixed list of common subdomain names (www, mail, dev, staging and similar) and, for any that resolve to a known cloud or SaaS host, makes one ordinary HTTPS GET to check for that provider's unclaimed-resource page. So it is not DNS-only — it does send a small number of HTTP requests to subdomains of the target. It never registers, claims, or modifies anything. This is a free check that uses public information: DNS records and ordinary HTTP requests. It does no port scanning and no exploit testing. Use this for dangling DNS, abandoned cloud resources, or subdomain hijacking risk.

Answers: what is this domain's overall security posture? Runs every passive NEL VEIL module in one pass — DNS, email authentication (SPF/DKIM/DMARC), TLS, HTTP security headers, cookies, CORS, exposed files, subdomain-takeover risk, technology fingerprinting, breach exposure, domain reputation, cloud misconfiguration and JavaScript supply chain — and returns findings from all of them with a per-module score. Use this when the question is broad: how secure is this domain, review this vendor, what should we fix first. For a single specific question prefer the narrower tool — check_email_spoofing, check_tls, check_security_headers, check_exposed_files or check_subdomain_takeover — which is faster and easier to read. It is free. What it actually sends, stated plainly, because "passive" means different things to different people. It performs NO port scanning and NO exploit testing. It DOES: request a fixed list of well-known paths, including common admin panels such as /phpmyadmin/ and /manager/html, to report whether they are publicly reachable; resolve a small fixed list of common subdomain names and make one HTTPS request to any that point at a known cloud host; and query Qualys SSL Labs, which performs its own ACTIVE TLS assessment of the target from Qualys's infrastructure. None of that is intrusive in the sense of attacking anything, and all of it is information the domain publishes — but it is more than a crawler does, and it is recognisable in the target's logs as a security scan. Prefer running it against a domain you own or are authorised to assess. Active scanning (port scans, API probing, proof-of-concept exploit checks) is deliberately not available through this MCP server; it requires proving control of the domain and runs only at nelprofessional.com.

Answers: what did an earlier NEL VEIL scan find? Fetches the stored results of a scan already run at nelprofessional.com, by its scan id (the scn_... identifier shown on the scan page and in its shareable report link). Returns the saved findings and score for that scan. Use this to pull a scan someone already ran on the website into the conversation — to summarise it, compare it against a later scan, or turn it into a remediation plan. It cannot start a new scan: use scan_domain for that. It only reads scans that exist and are publicly retrievable by id.