Google and Yahoo already require it
Since 2024, anyone sending more than 5,000 messages a day to Gmail or Yahoo users has to publish DMARC and keep authentication passing. Sentinely shows you whether you actually do.
For email marketing & DEM
Reach the inbox. And know who else is sending as you.
Gmail, Outlook, Yahoo and the rest already report on every message sent in your name. Sentinely reads those reports, so you can see which platforms send as you, which of them authenticate, and what changed after a migration.
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
Sending volume isn't the hard part. Not knowing is.
Campaign tooling tells you what you sent. It doesn't tell you what mailbox providers made of it, or who else is sending under your name.
Senders you never approved
A form tool here, a CRM there, an agency that kept sending after the contract ended. Each one appears in your aggregate reports with its IP, its host and its volume.
You changed platform and something broke
A migration that missed a DKIM selector or an SPF include fails quietly. Engagement tells you weeks later; the aggregate reports tell you the next morning.
What you get
The same evidence, read in campaign terms.
Everything below comes out of the DMARC aggregate reports your domain already receives.
Every platform, named
IP, hostname, geolocation and organisation for each sending source — and a clear mark on the ones that have never sent for you before.
Authentication rate per source
SPF and DKIM alignment, compliance and failure rates, computed on what providers actually did with the message rather than on what your records claim.
A deliverability score to track
0–100 with an A–F grade, built from authentication, policy, hygiene and blocklist status, with a confidence indicator while the data is still thin.
History across a platform change
Up to 180 days of it. Compare the weeks either side of a migration and see exactly which source stopped authenticating, and when.
A change you didn't make
A migration that drops an SPF include, a policy someone walks back, an MX repointed by the registrar. Each analysis run compares your DNS with the previous observation and tells you what moved, with the value before and the value after.
DKIM selectors, without asking your ESP
DNS won't list the selectors published for a domain, so most tools ask you to type them. Sentinely picks up the ones that appear in your DMARC reports and proposes them for confirmation — partial, since many senders omit the selector, but usually enough to stop guessing.
How many senders your SPF allows
Every platform you have ever added leaves an include behind. Sentinely counts the IPv4 addresses your record authorises and how many of them sent in the last 90 days — the gap is what you can safely clean up. Read the count as a floor: it covers the addresses written literally in the record.
Blocklist watch on your senders
Continuous DNSBL/RBL checks on the IPs sending for your domain, with a three-state result so 'not checkable' never gets read as 'clean'.
The record to publish, written out
An SPF record past the 10-lookup limit, a DMARC tag fused to the next by a missing semicolon, a revoked DKIM key. Sentinely finds it and hands you the exact record.
See which platforms send as your domain.
Publish one DNS record. The first reports usually land within a day — and the 30-day trial has everything switched on.