Understanding your Trace report

SPF is a published list of which mail servers are allowed to send email on your domain's behalf. This checks whether that list exists at all.

Without it, there's no authoritative way for anyone receiving mail to tell your real emails apart from someone forging your domain; there's simply nothing to check against.

Ask whoever manages your domain's DNS (often your web host, IT provider, or email platform) to set up an SPF record for your domain.

Beyond just existing, an SPF record can either firmly reject unauthorised senders or merely flag them as suspicious without blocking anything.

A weak policy still leaves the door open: receiving mail servers are told “this looks off” but not “reject this,” so forged mail can still land in inboxes.

Ask whoever manages your SPF record to tighten its enforcement setting once you're confident all your legitimate mail sources are correctly listed.

SPF records have a technical limit on how many DNS lookups they can trigger during evaluation. This checks whether yours has grown past that limit.

Once the limit is exceeded, mail servers treat your entire SPF setup as broken and ignore it completely, silently undoing whatever protection you thought you had, often without anyone noticing.

Ask whoever manages your SPF record to review and simplify it. This is common on domains that use several different email or marketing tools.

A domain should publish exactly one SPF record. This checks whether more than one exists.

Having more than one makes the whole thing invalid by definition, which (like exceeding the lookup limit) quietly disables your SPF protection entirely.

Ask whoever manages your DNS to consolidate all your sending sources into a single SPF record.

DMARC builds on SPF and tells receiving mail servers what to do when a message fails those checks, and gives you visibility into who's sending mail using your domain. This checks whether a DMARC record exists.

Without DMARC, you have no policy in place and no reporting, meaning if someone is actively spoofing your domain right now, you'd have no way of knowing.

Ask whoever manages your DNS or email platform to set up a DMARC record. Most providers offer guided setup for this.

A DMARC record can be set to only monitor spoofing attempts, or to actively instruct receivers to quarantine or reject fraudulent mail.

A monitoring-only policy gives you visibility but doesn't actually stop anything: spoofed mail using your domain can still reach its target.

Once you've reviewed DMARC reports and are confident it's safe to do so, ask whoever manages this to move toward an enforcing policy.

DMARC can send you a regular summary of who's sending mail claiming to be from your domain. This checks whether that reporting address is configured.

Without it, DMARC is running blind: even if it's technically active, nobody is actually seeing whether spoofing attempts are happening.

Ask whoever manages your DMARC record to add a reporting address so this visibility isn't going to waste.

Checks whether your DMARC record is written correctly enough for mail servers to reliably interpret it.

A record with structural problems may be partially or entirely ignored by receiving servers, which can quietly undercut protection you believe is in place.

Ask whoever manages your DMARC record to review and correct its formatting.

If your DMARC reports are sent to a third-party address (a monitoring service, for example), that third party needs to explicitly authorise receiving reports about your domain.

Without that authorisation, your DMARC reports are silently dropped by receiving mail servers, and you'd assume you're getting visibility into spoofing attempts when you actually aren't.

Ask whoever manages your DMARC reporting service to confirm the authorisation record is correctly published.

DKIM digitally signs outgoing mail so receivers can verify it genuinely came from your systems and wasn't altered in transit.

Without a valid DKIM signature, receiving mail servers have one less way to distinguish your legitimate mail from a forgery, and some providers will flag or reject unsigned mail more aggressively.

Ask your email provider (e.g. Google Workspace or Microsoft 365) to enable DKIM signing. Most providers support this natively.

MTA-STS is a stronger commitment that mail sent to your domain must always use encrypted transport, closing a loophole where an attacker could otherwise silently downgrade a connection to unencrypted.

Without it, encryption in transit is only “best effort,” and a well-positioned attacker on the network path could strip it away without either side noticing.

This is a more advanced control most organisations haven't adopted yet. Ask your email provider or IT provider whether it's supported and worth enabling for your setup.

TLS-RPT gives you visibility into cases where a sending server couldn't establish an encrypted connection to your mail servers.

Without it, encryption failures happen silently: you'd have no way to know if something's misconfigured or being tampered with.

Ask your email or IT provider whether this can be enabled alongside MTA-STS above.

This lists which mail servers your domain routes incoming email through. It's evidence, not a verdict.

It's included so the assessment record shows exactly what mail infrastructure was in scope, useful context if you're reviewing your setup with your IT provider.

No action needed. Worth a glance to confirm it matches what you expect.

Checks whether your mail servers support encrypting the connection when receiving email, rather than accepting it in plain text.

Without it, email content could potentially be read by someone in a position to intercept network traffic between mail servers: a confidentiality risk, distinct from the spoofing risks above.

Ask your email/IT provider to confirm encrypted transport is enabled on your mail servers.

Checks whether any of your subdomains point to a third-party service (like a hosting or app platform) that has since been deleted or deprovisioned, leaving that address available for anyone to claim.

If confirmed, someone else could register that abandoned resource and immediately start serving their own content (including phishing pages) from what looks like a legitimate address on your domain.

If this is flagged as a real risk, this needs prompt attention. Ask your IT provider or whoever set up that subdomain to either remove the unused DNS entry or reclaim the resource.

The mail-routing equivalent of the check above: whether a mail server your domain lists still exists, or points at a dangling resource someone else could claim.

A takeover here could let someone intercept or receive email intended for your organisation.

If flagged, this needs prompt attention. Ask whoever manages your DNS/mail routing to review and remove the dangling entry.

Checks whether the certificate actually served on a given address covers that address by name.

A mismatch means every visitor gets a hard security warning in their browser before they can even reach your site, and it also often points to a bigger underlying misconfiguration.

This needs attention soon. Ask your web hosting provider or IT team to correct the certificate assigned to this address.

Certificate authorities are only allowed to issue certificates valid for a certain maximum length of time, and that maximum has gotten stricter over the years. This checks whether your certificate was issued under an outdated, looser policy.

A certificate issued far outside current rules is often a sign it's self-signed, from an internal system, or long overdue for renewal. Worth a second look rather than an emergency.

Ask your hosting provider to confirm the certificate is due for a standard renewal.

How many days remain before this specific certificate actually expires.

An expired certificate breaks secure access to your site entirely for visitors, showing a blocking warning rather than just a cosmetic issue.

If this is inside the warning window, ask your hosting provider to renew it promptly. Most modern setups renew automatically, so this is also worth confirming that auto-renewal is actually working.

Checks whether the certificate your site presents can actually be verified against the standard certificate authorities that browsers trust.

If it doesn't validate, every visitor sees a hard security warning: the same practical impact as a hostname mismatch, just a different underlying cause (commonly a missing piece of the certificate chain, or an untrusted/self-signed certificate).

This needs attention soon. Ask your hosting provider to check the certificate installation, particularly whether an intermediate certificate is missing.

This header tells browsers to always use an encrypted connection to your site, even if someone types or links to the plain, unencrypted version.

Without it, there's a brief window on a user's very first visit where a network attacker could intercept an unencrypted connection before it upgrades to HTTPS.

Ask your website developer or hosting provider to enable this header, and to set a strong enough duration if it's already present but weak.

Beyond the header above, browsers maintain a built-in list of sites that should always load securely, even before the browser has ever visited them. This simply reports whether your domain is on that list, informational only.

It's a nice-to-have hardening step, not a gap in itself. Most organisations haven't done this.

No action typically needed. If you want to pursue it, your website developer can walk you through submission.

CSP is a header that restricts which sources of content (scripts, images, etc.) a browser is allowed to load on your site.

Without it, if an attacker ever manages to inject malicious code into your site (for example through a vulnerable plugin), there's nothing stopping that code from running freely.

Ask your website developer to implement a Content Security Policy appropriate to your site.

Checks whether your site prevents itself from being loaded inside an invisible frame on someone else's page.

Without this protection, an attacker could overlay your site inside their own page to trick visitors into clicking something they didn't intend to: a technique called clickjacking.

Ask your website developer or hosting provider to add this header.

Checks for a header that stops browsers from trying to “guess” a file's type differently from what the server declared.

Without it, a browser might interpret an uploaded file (like an image) as executable content, opening a route for malicious file uploads to cause more damage than intended.

Ask your website developer to add this header. It's typically a very quick configuration change.

Some servers announce the exact framework or software version powering the site.

This makes it slightly easier for an attacker to look up known vulnerabilities for your specific software version. It's a minor information leak, not a vulnerability on its own.

Optional cleanup. Ask your website developer to suppress this header when convenient.

Similar to the above, but for the underlying web server software itself rather than the application framework.

Same reasoning as above: minor reconnaissance value for an attacker, not a direct risk.

Optional cleanup. Ask your hosting provider to suppress this header when convenient.

This header lets a site explicitly restrict which browser features (camera, microphone, location, etc.) it or anything embedded in it can access.

Without it, any script running on your page, including from a third-party embed, has unrestricted access to request these sensitive browser permissions.

Worth raising with your website developer, though this is still an uncommon control even on well-secured sites.

Checks whether your site is explicitly configured to leak full page URLs (which can include sensitive query information) to other sites when a visitor clicks a link away from yours.

If explicitly misconfigured this way, sensitive information embedded in your URLs could be exposed to third-party sites your visitors click through to.

If flagged, ask your website developer to correct this setting. Most sites don't need to change anything, as modern browsers already default to a safe behaviour.

This checks whether your site publishes a standard file telling security researchers how to responsibly report a vulnerability they find.

Not having one isn't a gap: most sites don't. Having one is a positive, proactive signal.

Optional. If you'd like to make it easier for researchers to report issues to you responsibly, your website developer can add this in a few minutes.

Checks whether visiting your site over the old, unencrypted address automatically and reliably redirects to the secure version.

If it doesn't, or drops back to the unencrypted version partway through, visitors who type your address without “https://” could end up on an unprotected connection without realising it.

Ask your hosting provider or website developer to review and fix the redirect configuration.

Checks whether your server will still accept old, broken encryption methods if asked, rather than only offering modern, secure ones.

Accepting these older methods gives an attacker in a strong network position a route to weaken the connection's security. This needs attention soon.

Ask your hosting provider to disable legacy cipher support on your server.

Similar to the above but at the protocol level: checks whether your server still accepts the two oldest, officially deprecated versions of TLS encryption.

These versions have known weaknesses and are also often required for compliance standards (such as PCI-DSS) to be disabled. This needs attention soon.

Ask your hosting provider to disable TLS 1.0 and 1.1, leaving only modern TLS versions enabled.

CORS controls which other websites are allowed to make requests to yours from a visitor's browser. This checks whether your site is configured to allow literally any website to do so, without restriction.

An overly permissive policy, especially combined with logged-in user sessions, can let a malicious site quietly make requests on a visitor's behalf.

Worth a conversation with your website developer, particularly if your site has any logged-in or authenticated areas.

Checks whether cookies your site sets are marked to only travel over encrypted connections and to be inaccessible to page scripts.

Without these attributes, cookies (which often carry session/login information) are more exposed to interception or theft via malicious scripts.

Ask your website developer to review and add the missing attributes to your site's cookies.

Checks whether commonly-targeted sensitive files (like configuration files, backup files, or version control folders) are accidentally publicly accessible on your website.

If any of these are exposed, this is a direct, no-further-effort-required disclosure: it can include source code, credentials, or infrastructure details in a single request. This needs prompt attention.

Ask your website developer or hosting provider to remove or restrict access to any exposed files immediately.

Checks for developer or admin tools (like application debugging dashboards) that were left accessible to the public internet.

These interfaces are often built assuming only trusted internal users would ever reach them, so they frequently disclose configuration details or internal data with no authentication required. This needs prompt attention.

Ask your website developer to restrict access to any exposed debug or admin tools immediately.

Checks whether cloud storage (like an AWS, Azure, or Google Cloud storage bucket) matching your organisation's naming pattern exists and is set to allow anyone to list its contents.

A publicly listable bucket can mean anyone can browse and potentially download whatever's stored there. This needs prompt attention if confirmed.

Ask whoever manages your cloud infrastructure account to review and lock down access permissions immediately.

Checks your website's published code for strings that look like hardcoded API keys or access credentials.

If found, this is live, usable credential material anyone can extract from your page today, not a theoretical weakness. This needs prompt attention.

Ask your website developer to remove the credential from the code and rotate/replace it immediately, since it should be considered compromised.

Source maps are development files that map a website's minified code back to its original, readable source. This checks whether they've been accidentally published alongside the live site.

If exposed, they can reveal your site's internal structure, file paths, and occasionally leftover comments containing sensitive information.

Ask your website developer to exclude source maps from the production deployment.

Lists email addresses found published on your own website. This is background evidence, not a verdict: publishing a contact address is often entirely deliberate.

Included so you have visibility into what's publicly discoverable about your organisation, in case anything unexpected shows up in the list.

No action needed unless something in the list looks unexpected or out of date.

A CAA record lets you specify which certificate authorities are allowed to issue certificates for your domain at all.

Without one, any recognised certificate authority could technically issue a certificate for your domain, which removes one layer of protection against certificate mis-issuance.

Ask whoever manages your DNS to add a CAA record listing your legitimate certificate provider(s).

DNSSEC cryptographically signs your DNS records so they can't be tampered with in transit without detection.

Without it, DNS responses for your domain could theoretically be spoofed or manipulated by an attacker in the right network position, redirecting visitors without any warning.

Ask your domain registrar or DNS provider whether DNSSEC is supported and can be enabled. Many providers now offer one-click setup.

Checks whether the reverse-lookup record for an IP address (which server owns this address) actually matches the hostname pointing at it.

A mismatch (outside of normal shared cloud hosting patterns) can indicate stale DNS records or an address serving more than one purpose than intended.

Usually low priority. Ask your IT provider to review if it's flagged as an actual mismatch rather than expected cloud-provider behaviour.

Checks whether your domain's own nameservers will also answer DNS queries for unrelated domains, rather than being locked down to only answer for yours.

An open resolver can be abused by attackers as part of broader internet-scale attacks, and increases exposure to a technique called cache poisoning.

Ask whoever manages your nameservers to restrict them to authoritative-only mode.

Checks whether your nameservers will hand over your entire DNS zone (every subdomain and internal hostname you've configured) to anyone who asks, without authentication.

If this is enabled, it discloses your complete internal DNS structure in a single request, which is a significant reconnaissance win for anyone probing your organisation. This needs attention soon.

Ask whoever manages your nameservers to disable unauthenticated zone transfers.

Checks whether all of your domain's nameservers agree on which nameservers are actually authoritative for it.

A disagreement is usually a sign of a leftover or partially-migrated nameserver configuration: an operational hygiene issue rather than something actively exploitable.

Low priority, worth mentioning to whoever manages your DNS next time they're making changes there.

Checks for registered domains that look similar to yours (through typos or lookalike characters) and have active mail servers configured.

A lookalike domain with live mail pointed at unrelated infrastructure is a strong signal of active phishing infrastructure being staged against your brand. This needs prompt attention.

Get in touch with us directly. We can help you assess the risk and, if needed, guide you through reporting or takedown options.

Goes a step further than the above: checks whether any registered lookalike domain's live website visually matches your actual homepage.

A visual clone is strong confirmation of an active phishing or credential-harvesting site impersonating you, not just a speculative risk. This needs prompt attention.

Get in touch with us directly. This is worth escalating quickly, and we can help guide the right response.

A full list of similar-looking domains that are registered, regardless of whether they show signs of active misuse yet. This is background evidence, not a verdict on its own.

Even a dormant lookalike domain is worth being aware of: it could be parked for a future phishing campaign.

No immediate action needed, but worth keeping in mind if any of these domains later show signs of activity.

How close your domain is to its registration renewal date.

If a domain lapses, everything built on it (your website, email, and any other services) goes down immediately, and there's a real risk of someone else registering it once it's available. This needs attention as the expiry date approaches.

Confirm with whoever manages your domain registration that auto-renewal is enabled, or renew manually before the date approaches.

Checks whether your domain has a lock in place preventing it from being transferred to another registrar without your explicit action.

Without this lock, if your registrar account were ever compromised, your domain could be transferred away with comparatively little friction.

Ask your domain registrar to confirm transfer lock is enabled. This is usually a simple account setting.

Reports whether your domain's registration contact details are hidden behind a privacy service, or published openly. This is background context, not a verdict: it's a legitimate business choice either way.

Worth knowing so you can confirm it matches your organisation's actual preference.

No action needed unless the current setting doesn't match what you'd prefer.

Reports whether your domain's registration record has been updated recently. This is neutral evidence: a routine renewal and an unauthorised change look identical from this one data point.

It's worth a quick confirmation if you weren't expecting a change, just to rule out anything unexpected.

If you didn't recently make a change yourself, a quick check with your registrar to confirm nothing unauthorised occurred is a sensible precaution.

Simply records which company administers your domain registration.

Background context for the report, not a finding.

No action needed.

Records which country is listed against the domain's registration contact, where published.

Background context only, often absent by default due to modern privacy rules, which is normal.

No action needed.

A summary of how many candidate addresses were discovered during the assessment and how many were confirmed live.

Gives you a sense of the overall scope and thoroughness of the assessment.

No action needed.

Lists the nameservers your domain delegates to.

Nameservers are sometimes where a forgotten or orphaned piece of infrastructure's story starts, useful reference if you're auditing your own environment.

No action needed, but worth a glance to confirm it matches what you expect.

A history of certificates publicly logged for your domain's various addresses, which is often how additional subdomains were discovered in the first place.

This is the evidence trail behind the discovery process: it shows where some of the addresses covered elsewhere in this report actually came from.

No action needed.

Records any additional addresses found by testing a list of common naming patterns (like “dev.” or “staging.”) against your domain, beyond what was already discovered through other methods.

Sometimes surfaces forgotten test or staging environments that are still live and may not be getting the same security attention as your main site.

If anything unexpected turns up here, worth confirming with your IT provider whether it's still needed and, if so, that it's properly secured.

Lists paths your website's robots.txt file asks search engines not to index.

This file is sometimes the only public hint that an admin or login page exists at a particular address: useful evidence, not a vulnerability on its own.

No action needed.

Identifies which network provider or organisation owns the IP address space your domain resolves to.

Background context that can help confirm your infrastructure is hosted where you expect it to be.

No action needed.

Checks whether your organisation appears to own equivalent domains under other regional or generic extensions (for example, a .com alongside a .com.au).

Purely informational: if a related domain is confirmed and has its own real issues, those would surface separately once it's added to a future assessment's scope.

No action needed.