For engineers

Findings you can act on, not a score to argue with

Every finding names the record, header or file, shows what we saw, rates it with CVSS and tells you the exact change. You decide what gets tested, and when.

Each finding

What, how bad, what we saw, how to fix it

  • Severity with CVSS. Critical, High, Medium, Low, with the score where one applies. Shown as a word and a meter, so it reads without colour too.
  • Evidence. The DNS answer, HTTP response or file we saw, so you can reproduce it instead of trusting us.
  • The exact fix. The record to publish, the header to add, the setting to change. Not a link to a generic article.
  • Stable across runs. Each finding has a fingerprint, so the next run knows it is the same problem.

example.com

1 failed · 1 warning · 2 passed

  • DMARC policyHigh7.5

    No DMARC record at _dmarc.example.com. Anyone can send email that looks like it came from you.

    Fix: Add a TXT record on _dmarc.example.com: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

  • SPF recordLow3.1

    SPF ends with ~all (soft fail): receivers may still accept mail from servers you did not list.

    Fix: Change ~all to -all once every server that sends your email is in the record.

  • DKIM signing

    A DKIM key was found for a common selector (2048-bit RSA).

  • MX records

    2 mail servers found, both with valid hostnames.

Across runs

A finding has a lifecycle, not just a date

With continuous testing every month, each run is compared with the last one.

openFound and not dealt with yet.
fixedWas found before, gone in the latest run. Set by the comparison, not by hand.
regressedWas fixed, came back. Usually after an update or a rollback.
acceptedYou decided to live with the risk. Tracked, no longer counted as open.
false positiveYou marked it as wrong. It stays out of the summary.

You stay in control

Scope, timing and access are yours

Scope and time window

A project lists the hosts and URLs in scope, the kinds of test allowed and the time window. Nothing outside it is touched.

Verification you can see

A TXT record on the domain and a file at /.well-known/offensly-verification on the site we test (an IP address needs only the file). We check both again right before every run; remove either and testing stops (Verification lost).

Firewall allowlist

A WAF will block an active test. The dashboard lists the addresses tests come from, so you can allow them for the test window and see the real state of the site behind it.

Nothing to install

No agent, no code change. Sign in with Google, add one record, choose the scope.

DNS record
example.com.  300  IN  TXT  "offensly-verification=7f3c9a1e5b2d4c8f"

Straight answers

What it does not do

Does it replace a manual penetration test?

No. Automated testing finds the known, common weaknesses and finds them every month. A manual test finds logic flaws and chained attacks no scanner sees. Use both: manual tests occasionally, Offensly in between.

We do manual penetration tests too. Write to pentest@offensly.com with what you want tested (domains, applications, APIs) and when. We reply with a proposed scope and a price.

Can the DKIM check miss a key?

Yes. DNS has no list of selectors, so we try the common ones. With an account you can add your own selectors.

Which DNS checks are in which tier?

Basic, on this site for anyone: SPF, DKIM, DMARC, MX (3 a day). Advanced, in the dashboard with a free account, on domains you verify: all DNS checks, adding DNSSEC, CAA, DANE/TLSA, STARTTLS and dangling subdomains (5 a day). Paid account: the same plus web penetration testing.

See the findings for your own domain

The free check needs no account. Results in seconds.