Email security check: find out if someone can impersonate your company
Find out whether someone can send email in your company name. The scan reads the SPF, DKIM, DMARC and MTA-STS records of your domain. Results on screen and a full PDF.
Fake invoice scams do not start by breaking into anything.
They start with an email that looks like it comes from your domain. Nothing is breached: email works the way it was designed in the 1980s, when senders did not have to prove who they were. Sender verification is still optional today, and you are the one who turns it on by publishing three records in your DNS.
Each record does something different. SPF lists the servers allowed to send on behalf of the domain. DKIM signs each message with a key only you hold. DMARC is the only one that tells the receiver what to do when verification fails, and without it the other two are information with no consequence.
Incomplete setups the scan points out: SPF ending in ~all, DMARC left at p=none since it was first published and a DNS lookup count blown by accumulated integrations, which silently invalidates the whole SPF record. Each one comes with the specific fix. The terms are explained in the glossary.
What the scan looks for
SPF that actually works
DMARC and the decision
DKIM and signing
TLS in transport
From domain to report
Enter the domain
Just the domain. No account, no credit card and nothing to install.
The scan runs
The same scanner the platform uses runs against the host, in real time.
The score shows up
A score from 0 to 100, calculated with the product formula, with the most severe findings shown.
The report arrives by email
Full PDF with evidence and remediation steps, sent to an email address at the scanned domain.
Why only an email at the scanned domain. The report describes weaknesses of a specific domain. Sending it to any address would let third parties obtain this assessment without any relationship to the domain. If you do not have an email at the domain, contact us and we will send the report once your relationship with it is confirmed.
What the scan does on the target
Query public DNS records
SPF, DKIM (common selectors), DMARC, MX, MTA-STS and TLS-RPT are read from DNS, as any mail server does before delivering a message.
Resolve SPF includes
Each include and redirect is followed to count lookups and reach the real set of authorized senders.
Connect to MX servers
One SMTP connection to each MX to record STARTTLS, TLS version and certificate. No message is sent.
Check the inbound policy
The MTA-STS file published over HTTPS is read and compared with the DNS record.
Probe ports and services
Port scanning reaches infrastructure that may belong to the provider, as with PaaS and CDNs. This kind of test requires formal authorization from the owner of the environment.
Enumerate paths
There is no attempt to discover routes such as /admin or /.env through wordlists. That procedure generates request volume on the target and only runs with authorization.
Exploit vulnerabilities
No payload is sent and no vulnerability is exploited. Probes observe how the server responds, without extracting data.
Cover the full inventory
The result covers the domain you enter. Subdomains, staging environments and auxiliary services are part of the full platform analysis.
Frequently asked questions
Can anyone send email in my company name?
By default, yes. SMTP does not verify who the sender claims to be. That verification is optional and depends on three records you publish in your DNS: SPF lists which servers may send, DKIM signs the messages, and DMARC tells the receiver what to do when verification fails. Without DMARC set to quarantine or reject, the receiver may notice the spoofing and still deliver the message.
I have SPF configured. Is that enough?
No, for two reasons. First, SPF alone does not instruct the receiver: it publishes the list of authorized servers, but the DMARC policy decides what to do with a failure. Second, SPF ending in ~all (softfail) asks the receiver to accept the message even when it fails, which is permissive by definition. There is also a technical limit of ten DNS lookups: going over it silently invalidates the whole record, which happens on domains that accumulated marketing and billing integrations over the years.
What does DMARC with p=none mean?
It means monitoring mode: the receiver checks, reports to you and delivers the message anyway. It is the right starting point, and it helps you find out who sends legitimately before tightening the policy. The problem is staying there: the policy never moves to quarantine or reject, and in the meantime the domain can still be spoofed in practice.
Why does the scan check MTA-STS and TLS-RPT?
SPF, DKIM and DMARC deal with authenticity: who sent the message. MTA-STS and TLS-RPT deal with confidentiality in transit. Email delivery between servers negotiates encryption opportunistically: if TLS fails, the default is to deliver in plain text instead of not delivering. MTA-STS is the policy that closes that gap by requiring TLS, and TLS-RPT is the channel that tells you when someone tries to force the downgrade.
Does the scan send test emails to my domain?
No. The checks are public DNS queries (SPF, DKIM, DMARC, MTA-STS, TLS-RPT and DNSSEC are all published records), plus the STARTTLS negotiation with the inbound servers listed in your MX, which is the same contact any mail server makes before delivering a message. No message is sent and no mailbox is touched.
My email runs on Google Workspace or Microsoft 365. Do I still need this?
Yes, and that is exactly where the gap shows up most. The provider runs the sending infrastructure, but the records live in your DNS and you are the one who publishes them. The default setup of both delivers working SPF and DKIM and leaves DMARC up to you. The decision about spoofing of your domain is still yours, and by default it has not been made.
Does the score on this page include TLS and HTTP headers?
No. This page runs only the email scan, and the score reflects that result. The full security scan runs TLS, HTTP headers and email on the domain you enter. Fake invoice scams and payment fraud start with email in the company name, so email security often brings the highest-impact findings.