Mail you sent, quarantined
Unenforced policyReceivers hold back order confirmations, invoices and password resets. None of it bounces, so you never learn which customers stopped hearing from you.
Harden your perimeter against phishing and ensure your emails reach the primary inbox. Every. single. time.Stop compromising between security and deliverability. We harden your domain perimeter against phishing while ensuring your brand reaches the primary inbox - every. single. time.
5 of 6 protocols leave the domain forgeable.
And 2,000+ other registrars. We integrate seamlessly with any platform that allows CNAME records.
None of these announce themselves. That is what makes them expensive: each one compounds quietly, and every one traces back to the same missing instruction.
Receivers hold back order confirmations, invoices and password resets. None of it bounces, so you never learn which customers stopped hearing from you.
A policy of p=none tells every mail server to observe forgeries and deliver them anyway. Anyone can bill your clients from your address, and the first you hear of it is the phone call.
Providers rate the domain as a whole, so one unmanaged source is charged against all of them. Delisting is a queue you wait in rather than a switch you flip.
All three trace back to one unenforced policy, and that is the part we take over.
Thirty days of one domain: what was analysed, what passed, and which services were sending. Each protocol below is configured from the same place.

Every protocol below is hosted in our zone and delegated with a single CNAME. The policies stay correct as your senders change, and you never edit a TXT record again.
You stay at p=none while the reports still show real mail failing. Once only forgeries are failing, the move to reject is one approval away, and receiving servers start refusing anything that isn't yours.
Past ten lookups, evaluation stops where it stands, and because nothing bounces you find out when a customer mentions they never got the email. We flatten the record and re-resolve it hourly.
Evaluation stops here. Nothing bounces. You simply stop being trusted.
Your provider signs your mail and rotates its own key, exactly as it does now. We find every selector signing as your domain, including the third-party ones nobody remembers adding, grade the key strength, and flag t=y, the testing flag that quietly tells receivers to ignore failures. The reports then show which senders are actually signing and which only look like it.
2 of 4 selectors sign without protecting anything: one key too short to mean much, one publishing t=y, which tells receivers to ignore its failures.
Your verified mark sits in the inbox row before the message is opened. It requires enforcement first, which is rather the point: BIMI is what getting the rest right looks like.
We host the policy that tells sending servers encryption is mandatory for your domain. A stripped STARTTLS stops being a silent downgrade and becomes a refused connection.
Daily diagnostics on transport-layer encryption. When a relay quietly stops negotiating TLS, the report names the host, the day and the count, instead of leaving it to be noticed.
All six deployed by CNAME delegation. No infrastructure changes, no agent, and the records keep resolving even if our application is down.
DMARC reports arrive as XML full of IP addresses. We resolve every sending source to the service behind it, classify it, and keep tracking it as it changes, so the only question the report raises has an answer next to it.
| Source | Resolved to | Volume | SPF | DKIM | DMARC |
|---|---|---|---|---|---|
| 209.85.220.41 | Google Workspacecorporate mail | 84,210 | pass | pass | pass |
| 149.72.14.9 | SendGridtransactional | 31,004 | pass | pass | pass |
| 168.245.9.12 | Customer.iolifecycle | 12,760 | pass | pass | pass |
| 198.61.254.7 | Zendeskforwarded | 4,882 | fail | pass | pass |
| 45.155.204.18 | Unattributedbulletproof host | 914 | fail | fail | fail |
The same six protocols either way. What changes is who maintains them, and what happens when a vendor changes their sending IPs on a Sunday.
Hand-edited TXT records at every registrar you use, redone from scratch each time a vendor changes something.
One CNAME per protocol. The records live in our zone, and they keep resolving even if our application is down.
Raw XML, or a dashboard that renders the same XML and still leaves you to work out which IP was which service.
Every sending source resolved to the service behind it, classified, and tracked as it changes.
Indefinite p=none, because nobody can prove enforcement will not block real mail, so nobody signs off on it.
You stay at monitoring until the data shows only forgeries are failing. Then it is one approval, not a leap of faith.
0 of 3 zones to edit, and nothing told you.
The SPF record is re-resolved every hour, so a vendor adding IPs never silently breaks it.
Everyone starts with the same scan. What changes is how much of the upkeep we take over, and how many people need access.
“I look after our domain, and if something breaks it lands on me.”
Up to 5 domains, just you. Full forensic reporting on every source sending as your company, and one-click DMARC control.
“We run a few brands, and nobody here has time to maintain DNS records.”
Up to 20 domains and 5 teammates. Adds the hosted suite: SPF flattening, DKIM rotation, BIMI and MTA-STS, all maintained for you.
“I manage domains for other people’s companies.”
50 pooled domains across as many as 50 client workspaces, siloed from one another, with 20 seats for your team.
No hedging: here is what changes, what does not, and what happens if you decide to leave.
The Data Processing Agreement sets out what we hold and why. If your security review needs something it does not answer, ask us.
Not if it is done in the right order. You stay at p=none for as long as the reports still show legitimate sources failing, and the policy only moves once every one of them is aligned. You approve the change; we do not make it on a schedule.
No. Nothing about your mail flow changes and no message passes through our infrastructure. We host DNS records on your behalf. Your mail keeps leaving from Google, SendGrid, or wherever it leaves from today.
The records are DNS, served from our zone by an anycast network. They keep resolving whether or not our application is running. An outage on our side costs you a dashboard, not deliverability.
Usually four to eight weeks, and the timeline depends on how many sending sources you have rather than on us. Each one has to be found, attributed and aligned first. The reporting tells you when you are ready.
Yes, and there is nothing for us to hand over. Every record we publish is public DNS: the flattened SPF value is a TXT you can read with dig today, before you decide anything. DKIM is your provider's key and never depended on us, so pointing that selector back at their own target changes nothing. Remove the CNAMEs whenever you like.
For Gmail and Apple Mail, yes: a Verified Mark Certificate issued against a registered trademark. We generate the SVG in the exact profile the spec requires and tell you precisely what to buy. The trademark has to be yours.
A small team working in email security. We built SentraDMARC because the tools in this market are expensive or complicated and usually both: priced on a call, scoped by a sales cycle, configured by somebody else. So the price is published, the scan runs before you have an account, and there is no call to book. The application and every report we hold run on European infrastructure, and the people who wrote this answer the support email.
The scan reads live DNS and grades all six protocols. It takes about four seconds and needs no account.
Works with any registrar that supports CNAME. See plans and pricing