About
A signet ring sealed a letter so the person receiving it knew who sent it.
That is the whole problem, and it is four thousand years old. Email inherited it without a solution. SPF, DKIM and DMARC are the retrofit. They work, but only if they are configured correctly, watched continuously, and kept that way.
Those three things are usually sold as three products: an authentication tool, a fraud defence platform, and a DMARC report reader. Buying all three and wiring them together is how most companies end up with none of them working. Signet is the one system: it authenticates every service you have authorised to send for you, detects anyone who is not you, and hosts the records so it stays true.
Built and operated by eSec Forte Technologies, and released to the community.
Why Signet exists
Proving it once is not the same as proving it next quarter.
Two things happened at once: the mailbox providers started enforcing, and the number of services sending on your behalf kept growing. Your proof is only as current as the last time somebody checked it.
The bar moved, and it keeps moving.
In February 2024 Google and Yahoo began requiring SPF, DKIM and aligned DMARC from bulk senders. Microsoft followed in May 2025, rejecting non-compliant mail outright. From late 2025 Google moved from warnings to rejections. What used to be hygiene you could postpone is now a condition of delivery.
If your authentication is wrong today, you do not get a warning. You get a deliverability problem that looks like a marketing problem, and a security problem that looks like nothing at all.
Meanwhile it drifts, quietly.
SPF allows ten DNS lookups and no more. Every tool your teams sign up for adds another include. Keys rotate. Subdomains get delegated. A vendor changes their sending infrastructure and never tells you.
Most organisations set this up once, get it roughly right, and never look againuntil invoices start landing in spam, or a customer forwards you a phishing mail with your own logo on it.
Signet exists because email deliverability and authentication is a maintenance problem, not a setup problem, and in most organisations nobody owns it.
Why it is free
A tool for the community, from a security firm that kept seeing the same problem.
eSec Forte Technologies spends most of its time inside other organisations on security engagements. Across those engagements one finding repeated itself, regardless of size or sector: almost every organisation struggles to keep its email deliverability and authentication infrastructure in order, and almost none of the reasons are technical.
The records themselves are not hard. What is hard is that the tooling around them is unnecessarily complex and unnecessarily expensive, so the work ends up owned by nobody, done once, and left to drift. Signet is our answer to that: one system, plainly worded, that reads what your domain declares, watches what actually happens, and keeps the records true.
We are releasing it free for the community to use and to manage their own data. Deliverability and authentication will always be free on this platform.
What we commit to
Three things this product will not do.
Every one of these is a decision that made the product harder to build and easier to trust. They are the reason to use it over something cheaper.
We will not flatten your SPF record.
Flattening replaces the services you authorised with the IP addresses behind them on the day it ran. When a provider changes IPs, as they do, mail you meant to send starts failing, silently, and the record no longer says what you meant. We count your lookups honestly against the limit of 10 and tell you which include to remove.
We will not alert you about forwarding.
Most DMARC failures are messages forwarded by a mailing list or a redirect. They are not attacks and there is nothing to fix. Alerting on them is how monitoring tools get muted inside a fortnight, and a muted tool protects nobody. Forwarding is identified, classified, and left alone.
We will not call your own platform an attacker.
Before anything is reported as unauthorised it has to fail on network evidence and on signature evidence together. An early build called a Marketo-signed source spoofing purely because its IP was unfamiliar. A false accusation costs you more than a missed one, so the classifier now needs two independent reasons before it will say it.
Deliberately absent
What we chose not to hold.
No passwords stored
Sign-in is a magic link. There is no password database to leak.
Forensic samples redacted on write
Recipient data is stripped before it reaches disk, not before it reaches a screen.
No mailbox access
There is no integration that reads your mail and there never will be. Aggregate reports carry counts and IP addresses, and that is all we hold about your traffic.
A real scan
Watch it read a domain you already trust.
This is google.com, all twelve record types, and every line was verified against live DNS. It is a good example precisely because it is well configured: p=reject, MTA-STS in enforce mode, one DNS lookup out of ten, CAA locked to its own authority.
And it still has gaps. No BIMI record, an unsigned zone, no DANE, and a DKIM selector that cannot be discovered from DNS alone. Signet reports all of them without calling any of them a failure, because none of them is.
Re-run it yourself. The records are public.
$ signet scan google.comSPF v=spf1 include:_spf.google.com ~all└─ include:_spf.google.com2 ip4 ranges, 6 ip6 ranges, 0 further lookups1 of 10 DNS lookups usedDKIM probing documented selectorsgoogle._domainkey no recordgoogle2048._domainkey no recordselector not discoverable from DNS aloneDMARC v=DMARC1; p=reject; rua=mailto:[email protected]policy p=reject 100% of mailreporting address accepts mailBIMI default._bimi not publishedMX 10 smtp.google.comA/AAAA 192.178.158.26, 192.178.158.272404:6800:4013:813::1a, 2404:6800:4013:813::1bPTR lcdels-in-f26.1e100.net forward-confirmedname differs from MX host, which is normalMTA-STS v=STSv1; id=20210803T010101policy fetched mode: enforcemx list matches live DNSTLS-RPT v=TLSRPTv1;rua=mailto:[email protected]DANE _25._tcp.smtp.google.com no TLSA recordsDNSSEC no DS record zone unsignedCAA 0 issue "pki.goog"issuance restricted to one authority12 record types read · 4 gaps · 0 misconfigurations
verified against live DNS, 10 September 2026