The short version. Passive DNS and transport analysis of your mail posture: authentication records, policy strength, relay behaviour and transport hardening. No email is sent, to anyone, at any point.
What this engine does
Domain spoofing is cheap when authentication is misconfigured and expensive when it succeeds. Most of the failure modes are visible from outside, in records you publish deliberately.
- SPF — record validity, lookup limits, and whether the policy is permissive enough to be meaningless.
- DKIM — selector discovery, key presence and strength.
- DMARC — policy strength, alignment mode and reporting configuration, since a policy of none protects nobody.
- Open relay behaviour — established by protocol conversation, never by delivering a message.
- Transport hardening — MTA-STS, TLS-RPT, DANE/TLSA and DNSSEC.
- Brand surface — BIMI and VMC status, and phishing-kit indicators associated with your domain.
What it deliberately does not do
Anything that would put a message in a mailbox is out of scope:
- No email is sent. Not a test message, not a spoofed message, not to you and not to anyone else.
- No phishing simulation. No staff are targeted; this engine assesses infrastructure, not people.
- No mailbox access. Nothing authenticates to your mail service.
- No relay abuse. Relay posture is determined by conversation and stopped before delivery.
How we prove you are allowed to run it
Authorisation is a hard gate, not a checkbox in our terms. A scan starts only if the asset is verified by Domain Control Verification — you place a DNS TXT record or a file we specify — or you supply an explicit legal-authority attestation stating you own the target or are authorised to test it. A request carrying neither is refused with HTTP 403, at every tier, with no override. Because everything here reads public DNS and speaks to publicly advertised mail servers, the authorisation bar is the domain: DCV, or an attestation that you are authorised to assess it.
Where your data goes, and when it is deleted
Everything runs on EU infrastructure: edge functions in EU regions, scan compute in Frankfurt, object storage under EU jurisdiction, model inference through an EU endpoint. Nothing is used to train any model — ours or a third party's — and that is a contractual term in the DPA, which every plan gets.
- The report — kept two years, so you can hand it to an auditor next year.
- Raw uploaded material — third-party scanner files 30 days, application binaries 60 days, then deleted automatically.
- The anonymous homepage preview — content erased after 24 hours.
- The authorisation record — kept, because it is the evidence that the scan was permitted.
The full schedule is in our Privacy Policy, and the sub-processor list is on the Trust Center.
How a run actually works
Deterministic checks against public records and public mail servers, then analysis that turns raw record content into the question you care about: is the current configuration actually preventing spoofing, or does it only look like it is. A DMARC record set to p=none passes a naive checklist and blocks nothing.
What you get at the end
A posture report with the exact record content to publish next, in order of effect, and an honest note on which changes carry deliverability risk if applied carelessly — moving to p=reject without reviewing reports first breaks legitimate mail, and a report that fails to say so is not doing its job.
What this engine cannot find
External analysis of mail posture cannot see:
- Inbound filtering quality — whether your users are protected from what arrives.
- Internal mail flow and any relay behaviour that is not externally reachable.
- Whether staff would fall for a phishing email, which is a human exercise.
- Selectors that are not discoverable from outside.
- Historical abuse of your domain beyond what current indicators reveal.
We publish this list for the same reason we publish our own assessment report, limitations section included: a vendor that cannot tell you what its tool misses is asking you to take the rest on faith.
Frequently Asked Questions
Will you send test emails to our domain?
No. Nothing is sent, at any point, to anyone. All findings come from DNS records and protocol conversations that stop before delivery.
Is this a phishing simulation?
No. No staff member is targeted or contacted. This engine assesses infrastructure configuration only.
We already have SPF, DKIM and DMARC. Is there anything left to check?
Usually yes. The common findings are a DMARC policy set to none, an SPF record over the lookup limit, or alignment that quietly fails — all of which pass a presence check while blocking nothing.
Can this break our email delivery?
The assessment cannot: it only reads. Acting on it can, which is why the report flags which changes need report review before you tighten policy.
Do you need access to our mail server?
No credentials, no mailbox access. Everything is external.