Prove it’s you.
Your mail arrives. Theirs doesn’t.
Signet verifies every service allowed to send as you, catches anyone who is not, and keeps the records that get your mail delivered true. Free, for the community.
Free, no account, and it names every service you have authorised to send on your behalf.
What Signet is
Authenticate, detect, host. One system for the identity you send from.
Email fraud defence, authentication and DMARC management get sold as three purchases. They are three sides of one question: who is allowed to send as you. The same records answer a second question, whether your own mail reaches the inbox at all. Signet covers both in one place, rather than leaving you to stitch three tools together and reconcile them yourself.
Authenticate
Proof that the mail is yours.
Signet finds every service your domain authorises to send, checks whether each one can actually sign, and names the ones that cannot. You end up knowing, rather than assuming, that the mail you meant to send carries proof it came from you.
286 default selectors across 40+ named services, plus your own
Detect
Proof that the rest is not.
Aggregate and forensic reports arrive from every major mailbox provider. Signet separates your own infrastructure from authorised third parties, from forwarders, from impostors, and raises only the last. Nobody needs an alert every time a mailing list forwards a message.
Two independent signals before anything is called spoofing
Host
Proof that stays true.
We host your MTA-STS policy, your reporting endpoints and your TLS reporting. You publish two records once. After that, changes happen in Signet rather than in a DNS console at eleven at night. Nothing quietly expires while nobody is looking.
MX read from live DNS, enforcement gated behind a testing period
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 again until 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.
Agents send mail now
Your sender list used to change when IT signed a contract. Now it changes when someone connects an agent.
AI assistants can send from a mailbox with one approval, and increasingly with none. Agent platforms issue agents their own identities and their own inboxes. Outreach tools send thousands of messages with no person on each one. Every one of these is a new thing sending as your domain, and none of them files a ticket.
Every new source is surfaced, not just spoofing
Aggregate reports name every IP that sent as you. Signet classifies each one as your infrastructure, an authorised service, a forwarder, or unknown, and raises the unknown ones before they become a policy failure or a reputation problem.
Source classification on every report, with two signals before it is called spoofing
Record changes are alerts, not surprises
An agent, a contractor or a well-meaning colleague adds an include or a selector to get a tool working. Signet re-reads your records and tells you what changed, when, and what it did to your lookup budget and your policy.
SPF and DMARC change alerts, weakened-policy alerts, score-drop alerts
Approval belongs to a person
Signet does not publish a change on your behalf. It shows you the exact record, what it will authorise, and what it costs. Agent identities from Microsoft Entra or Google Workspace stay yours to govern; Signet shows you the mail they produce.
Hosted records are published by you, with a testing period before enforcement
Deliverability
Security is half of it. The same records decide whether your own mail arrives.
Gmail, Yahoo and Outlook.com now hold every meaningful sender to the same list. Most of that list is authentication, and it is checkable in advance. Signet tells you which items you pass, which you fail, and which it cannot see from outside, so you know exactly where to look next.
What the providers require
- SPF and DKIM, with DMARC aligned to the From domain
- A published DMARC policy, at minimum p=none with reporting
- Valid forward and reverse DNS on every sending address
- TLS on the connection
- One-click unsubscribe on marketing mail, honoured within two days
- A spam complaint rate under 0.3%, and ideally under 0.1%
What Signet verifies
- SPF, DKIM and DMARC, and whether each authorised service can actually sign
- Alignment, policy, coverage and whether reports can reach you
- Forward-confirmed reverse DNS on your mail hosts
- MTA-STS, TLS-RPT and DANE for the transport
- Whether your sending addresses appear on public blocklists
- Any single message, pasted in with headers, end to end
- One-click unsubscribe on a message you send in: the headers, the https URI, and whether RFC 8058 signed them
What it will not pretend to
- Your spam complaint rate. Only Google Postmaster Tools and Microsoft SNDS have that number, and the report tells you to go and read it.
- Whether an unsubscribe request is actually honoured. We can check that a message you send us offers one-click correctly; whether somebody acts on the click within two days is a property of the process behind it, not of the mail.
- Inbox placement. Nobody outside the mailbox provider can measure it honestly, and we would rather say so than sell you a seed list.
What the scan reads
Twelve record types. One identity.
Your sending identity is not one record, it is twelve that have to agree. Most tools check them one at a time. The findings that matter only appear when they are read against each other: an MTA-STS policy naming hosts your MX no longer uses, a DMARC record pointing at a mailbox that cannot receive, an SPF include for a service that stopped signing months ago.
Identity
Who is allowed to send as you
SPF
Every include followed and counted against the limit of 10
DKIM
Default selectors per service, plus any custom selector you name
DMARC
Policy, alignment, percentage, and whether reports can reach you
BIMI
Logo record, its certificate tag, and whether your policy is strict enough
Delivery
Where your mail actually lands
MX
Hosts, priorities and who operates them
A / AAAA
What each mail host resolves to
PTR
Reverse DNS, and whether it forward-confirms to the same address
Transport
Whether the connection is protected
MTA-STS
The DNS record and the policy file, checked against live MX
TLS-RPT
Whether transport failures are being reported to anyone
DANE / TLSA
Certificate pinning, and whether DNSSEC actually protects it
Foundation
Whether the zone itself can be trusted
DNSSEC
Whether the zone is signed and the chain genuinely validates
CAA
Which authorities may issue certificates for you
What you get back
This is the report, not a picture of one.
example domain · rendered live
Below is the real component, running against a fictional company that is broken in the three ways most domains are broken: over the SPF lookup ceiling, an authorised service that cannot sign, and a policy that enforces nothing.
northwind-logistics.example
You are collecting reports but nothing is being enforced, and two authorised services cannot pass DKIM. Mail sent through them relies entirely on SPF alignment, and SPF itself is over the lookup limit.
37 DNS queries · 843 ms
- 1SPF exceeds the 10 lookup limitYou are at 12. Receivers stop evaluating at 10, so zendesk.com and sendgrid.net are currently unauthorised. Remove one include or move a service to a subdomain.
- 2Policy is p=noneNothing is being stopped. Once the two DKIM gaps are closed, move to p=quarantine at pct=25 and watch the reports.
- 3Mailchimp publishes no signing keyPublish the two CNAME records from your Mailchimp domain settings, or add your custom selector so we can verify the right one.
- 4BIMI is published but DMARC is not enforcingMailbox providers ignore the logo until the policy is p=quarantine or p=reject. It will start showing on its own once the DMARC step above is done.
Sending services detected
Read from your SPF includes and MX hosts, then checked for a matching DKIM key.
DMARC
- Policy
- none
- Coverage
- 100%
- Alignment
- dkim=r spf=r
DKIM
34 selectors probed
googleGoogle WorkspaceRSA 2048SPF
Worst-case evaluation across every include.
- include:_spf.google.com
- include:servers.mcsv.net
- include:mail.zendesk.com
- include:sendgrid.net
- include:spf.protection.outlook.com
Findings (8)
CriticalSPF requires 12 DNS lookups, 2 over the limit›
RFC 7208 caps evaluation at 10 DNS-querying mechanisms. Everything past the tenth is treated as a permerror by most receivers, which means the services listed last are not actually authorised even though you intended them to be.
Remove an include, or move a low-volume service onto a subdomain with its own SPF record. We do not flatten records: a flattened record goes stale the moment a provider changes IPs.
RFC 7208 §4.6.4
HighMailchimp is authorised to send as you and publishes no signing key›
include:servers.mcsv.net authorises Mailchimp to send on your behalf, but neither of its documented selectors (k1._domainkey, k2._domainkey) resolves. Mail sent through this service cannot pass DKIM and will fail DMARC the moment it is forwarded.
Publish the two CNAME records from your Mailchimp domain settings. If you sign with a custom selector instead, add it to the scan and we will verify that one.
HighDMARC policy is p=none›
Receivers are told to deliver everything and report back. That is the correct place to start, but nothing is currently being stopped.
Close the DKIM gaps first, then move to p=quarantine at pct=25 and widen as the reports stay clean.
RFC 7489 §6.3
MediumBIMI is published but DMARC is not enforcing›
BIMI is only honoured when DMARC is at p=quarantine or p=reject. Your logo record is valid and points at a reachable SVG, and no mailbox provider will display it while the policy is p=none.
Nothing to change in the BIMI record itself. Move DMARC to an enforcing policy and the logo will start to appear.
BIMI Group implementation guide
LowMTA-STS policy mode is 'testing'›
The DNS record and the policy file are both published and the MX list matches live DNS, but in testing mode a sender that cannot negotiate TLS is only asked to report the failure, not to hold the message.
Change mode: testing to mode: enforce in the policy file and update the id in the _mta-sts record so senders refetch it.
RFC 8461 §5
LowBIMI has no Verified Mark Certificate›
Gmail requires a VMC (the a= tag) before it will display a BIMI logo. Without one the record is honoured by Yahoo and Fastmail and ignored by Gmail.
Obtain a VMC from DigiCert or Entrust for a registered trademark, host it, and add a=https://… to the record.
BIMI Group VMC guidelines
LowCAA has no reporting address›
You have restricted which authorities may issue certificates, but nobody is told when one refuses a request. A mis-issuance attempt is exactly the thing worth hearing about.
Add a record such as: 0 iodef "mailto:security@northwind-logistics.example"
RFC 8659 §4.4
InfoZone is not signed with DNSSEC›
This is the common case and not a misconfiguration. Most working mail domains are unsigned. It is worth knowing because your authentication records are only as trustworthy as the DNS answers carrying them, and because DNSSEC is the prerequisite for DANE.
If your DNS provider supports one-click DNSSEC, enabling it is low risk. If it does not, this is not worth changing providers over.
RFC 4033
Show 6 passing checks
PassSPF record published and syntactically valid›
A single SPF record was found with a valid ~all qualifier.
PassDMARC record published at _dmarc›
A valid DMARC record was found with a reachable aggregate reporting address.
PassGoogle Workspace signs with a 2048-bit key›
google._domainkey resolves to a valid RSA key of adequate length.
PassTLS reporting is configured›
You receive daily reports on TLS negotiation failures for inbound mail.
RFC 8460
PassCertificate issuance is restricted by CAA›
Only letsencrypt.org may issue certificates for this domain and its subdomains.
RFC 8659
PassMail exchangers have forward-confirmed reverse DNS›
Every address behind your mail exchangers has a PTR record that resolves back to the same address, which receiving servers treat as a basic sign of a legitimately operated mail server.
Transport and zone
Where your mail lands, and whether the DNS carrying your records can be trusted.
Free, no account. northwind-logistics.example is not a real domain. The .example TLD is reserved by RFC 2606.
Why the findings are different
Most tools guess at selectors.Signet knows whose they are.
Your SPF record and MX hosts name the services allowed to send for you. Signet takes that list and checks each provider’s documented default selectors, rather than brute-forcing a generic wordlist.
When those defaults are not there, that is not a verdict. Plenty of teams sign with their own custom selectors, which is entirely normal and entirely correct. So Signet says exactly what it found, names the service, and asks you for the selector it should be checking instead.
Finding · needs input
Mailchimp is authorised to send as you. Its default selectors are not published.
- Authorised
- include:servers.mcsv.net
- Defaults
- k1._domainkey · k2._domainkey
- Found
- neither
If you sign this service’s mail with a custom selector, add it and Signet will verify that instead. If you do not, mail sent through it cannot pass DKIM.
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:mailauth-reports@google.compolicy 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:sts-reports@google.comDANE _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
How we behave
Proof means being right, not being loud.
Any tool in this space can produce a long list. The ones people still have switched on a year later are the ones whose list is worth reading on a Monday morning.
Forwarding never alerts
Most DMARC failures are messages forwarded by a mailing list or a redirect. Alerting on those is how monitoring tools get muted inside a fortnight, and a muted tool protects nobody.
Two signals before we say spoofing
Network evidence and signature evidence must both fail before anything is reported as unauthorised. Calling your own marketing platform an attacker costs more than a missed alert.
We never flatten your SPF
Flattening swaps the services you authorised for the IPs behind them. When a provider moves, your mail starts failing. We count your lookups and name the include to drop.
Prove your domain.
Free, no account, and it names every service you have authorised to send on your behalf.
Before you ask
The questions that decide it.
- Will turning this on affect my email?
- No. Monitoring changes nothing about how your mail is delivered. You publish a DMARC record asking receivers to send reports, and they carry on treating your mail exactly as before. Delivery only changes when you decide to move to p=quarantine or p=reject, and that is your decision, taken after the reports show it is safe.
- How long before I see anything?
- Aggregate reports arrive on the mailbox providers' schedule, not ours, usually within 48 hours, sometimes longer for a low-volume domain. The scan is instant, but the useful picture of who is sending as you builds over the first week.
- What if something is sending as us that is not in our SPF record?
- The scan will not see it, and no scan of any kind could. A scan reads DNS, so it can only show what you have authorised: your SPF includes and your MX hosts. Something sending as you without that authorisation leaves no trace in your DNS at all. It does leave a trace in DMARC aggregate reports, which is why monitoring is a separate thing from scanning. The scan tells you what you have declared; the reports tell you what is actually happening. You need both, and the first one is free.
- Is this a security tool or a deliverability tool?
- Both, because they are the same records. SPF, DKIM and DMARC decide whether a receiver can prove a message is yours, which is what stops impersonation, and the mailbox providers now use that same proof to decide whether to accept your mail at all. Signet verifies the whole set, tells you what Gmail, Yahoo and Outlook.com require of it, and is explicit about the parts it cannot see from outside: complaint rate, unsubscribe handling and inbox placement.
- Someone connected an AI agent or a new tool that sends as us. Will I know?
- Yes, in two ways. If the tool sends mail, it appears in aggregate reports as a source, and Signet classifies it rather than burying it in a list of IPs: your infrastructure, an authorised service, a forwarder, or unknown. If someone also edited your SPF or DMARC record to make the tool work, that change is re-read and raised as an alert with what it authorised and what it cost in lookups. What Signet cannot do is see the OAuth grant or the agent registration itself; that stays in your Google or Microsoft admin console, where it belongs.
- Can you read my email?
- No. We never touch your mailbox and there is no integration that would let us. DMARC aggregate reports contain counts and IP addresses, not messages. Forensic reports can contain fragments, so those are redacted before they are written to disk rather than before they are shown to you.
- Do you flatten SPF records?
- Never. Flattening replaces the services you authorised with the IP addresses behind them on the day it ran, and when a provider moves, mail you meant to send starts failing silently. We count your lookups against the limit of 10 and tell you which include to drop instead.
- We use custom DKIM selectors. Does that break the scan?
- No, and it is not treated as a failure. Signet checks each recognised service against its documented default selectors; if those are absent it says exactly that rather than declaring DKIM missing, because a selector cannot be enumerated from DNS. Add yours under the domain field and they are verified alongside the defaults.
- What happens if a report says one of our own tools is spoofing us?
- It should not, and preventing that was a deliberate design decision. A source has to fail on network evidence and on signature evidence together before it is reported as unauthorised. Forwarding is identified separately and never alerts, because most DMARC failures are forwarding and alerting on them is how these tools get muted.
- What does it cost?
- Deliverability and authentication are free on this platform and will stay free. That is the reason Signet exists: eSec Forte kept finding the same unowned, drifting records on engagement after engagement, and the tools meant to fix them were needlessly complex and expensive. Pricing for anything beyond that, such as longer retention or a large number of domains, is not published yet. If you need numbers before that lands, get in touch and we will give you the ones we are working to rather than a placeholder.
See what your domain proves today.
The scan tells you what your identity looks like right now, in about a second. Signet tells you who has been using it, and keeps it true from there.