Anyone can send as you
Until DMARC is enforced your domain is a free identity. Phishing sent from it arrives with your name on it, and the first you hear of it is from the person who received it.
For IT & Sec Ops
Stop impersonation. Reach p=reject with the data to prove it's safe.
The evidence you need to enforce DMARC already arrives every day, as XML nobody reads. Sentinely reads it, names every sender, and shows you what would break before you change the policy.
Everything that decides if your domain is trusted
- SPF
- DKIM
- DMARC
- BIMI
- MTA-STS
- TLS-RPT
- MX
- NS
- DNSBL/RBL
- rDNS/PTR
Sentinely watches the full stack of signals mailbox providers use to trust — or reject — your mail. MX and NS are watched too: not for the score, but so you know the day they change.
The problem
Staying at p=none is a decision too.
It's the decision to leave your domain usable by anyone, and to find out about it from whoever got the phish.
Enforcement without data is a gamble
Move to p=reject before you know every legitimate sender and you'll block your own invoices, tickets or payroll mail. Which is why most domains never move.
Broken auth hides in plain sight
A revoked DKIM key, an SPF record past the 10-lookup ceiling, terms placed after "all" that will never be evaluated. Published, present, and silently failing.
What you get
Enough evidence to change the policy.
Read-only, from the aggregate reports your domain already receives. Nothing to install, nothing in the mail path.
Every source resolved
IP, hostname (rDNS/PTR), geolocation and organisation/ASN for each sender, plus a clear line between sources you already know and ones that have never sent for your domain.
Records read for syntax
SPF, DKIM, DMARC, BIMI, MTA-STS and TLS-RPT checked for how they're written: fused DMARC tags, rua or ruf without mailto:, invalid sp and pct, unknown SPF mechanisms, invalid ip4/ip6, deprecated ptr, the 10-lookup limit.
Changes recorded, with before and after
Each run compares your DNS with the previous observation and records the difference — value before, value after, when. A policy walked back to p=none, an SPF include gone, a BIMI record removed. MX and NS are watched the same way, though neither touches the score.
DKIM selectors, discovered
DNS can't be asked to list the selectors published for a domain, so most tools leave you a blank field. Sentinely harvests the selectors that appear in your aggregate reports and proposes them for confirmation. Partial by nature — many senders omit the selector — but it turns a blind analysis into a working one.
The size of what your SPF authorises
The count of IPv4 addresses your record permits, next to how many of them sent in the last 90 days. A forgotten include can authorise hundreds of thousands of hosts while a handful do the sending. The count covers the addresses written literally in the record, so treat it as a floor.
A protection score with a grade
0–100 and A–F across authentication, policy, hygiene and blocklist status, with a confidence indicator while there isn't yet enough data to be sure.
Alerts with a severity threshold
New source never seen before, volume anomaly against the 7-day average, high failure rate, mail quarantined or rejected from a known source. Configurable per recipient and per domain.
Blocklist monitoring
Continuous DNSBL/RBL checks on every IP sending for the domain, with a three-state result — listed, clean, or not checkable.
A warning when reports stop
A domain that suddenly stops receiving aggregate reports usually means a broken configuration, not quiet skies. Sentinely tells you instead of letting the silence look like success.
Find out who's sending as your domain.
One DNS record, and the first verdict lands within a day. The 30-day trial has everything switched on — no card.