Enforce Email Authentication. Protect Your Business Growth.

Harden your perimeter against phishing and ensure your emails reach the primary inbox. Every. single. time.

DMARC SPF DKIM BIMI MTA-STS TLS-RPT
your-company.comresolving
  • DMARCp=nonemonitor only
  • SPF11 lookupsover limit
  • DKIMselector s1signing
  • BIMInot foundno record
  • MTA-STSnot foundno policy
  • TLS-RPTnot foundno reports
Perimeter score

5 of 6 protocols leave the domain forgeable.

Works with every major registrar

And 2,000+ other registrars. We integrate seamlessly with any platform that allows CNAME records.

The cost of an unenforced policy

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.

Mail you sent, quarantined

Unenforced policy

Receivers hold back order confirmations, invoices and password resets. None of it bounces, so you never learn which customers stopped hearing from you.

Invoices sent in your name

Open to spoofing

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.

The domain, not the sender, is scored

Reputation damage

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.

One dashboard, six protocols

Thirty days of one domain: what was analysed, what passed, and which services were sending. Each protocol below is configured from the same place.

The DMARC dashboard for demo-corp.com: thirty days of message volume split into passing and failing traffic, above an audit trail naming each sending source with its delivery rate.

Not a monitor. The records themselves.

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.

DMARC enforcer

From monitoring to reject, without losing a message

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.

  • _dmarc
  • p=reject
DMARC policy_dmarc TXT
p=nonep=quarantinep=reject
v=DMARC1;p=none;p=quarantine;p=reject;rua=mailto:…@ingest.sentradmarc.com
Your mail
0
delivered
Forgeries
0
delivered
Hosted SPF

Eleven lookups, folded into one

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.

  • @ TXT
  • 1 lookup
SPF lookupsv=spf1
DNS lookups0 / 10

Evaluation stops here. Nothing bounces. You simply stop being trusted.

  • include:_spf.google.com4 lookupsinlined
  • include:sendgrid.net3 lookupsinlined
  • include:mailgun.org2 lookupsinlined
  • include:_spf.vendor.io2 lookupsinlined
v=spf1 include:… ~all1 lookup, re-resolved hourly
DKIM cryptography

Every selector, found and graded

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.

  • <selector>._domainkey
  • 2048-bit minimum
DKIM selectors0 found
  • selector1Microsoft 3652048-bit
  • googleGoogle Workspace2048-bit
  • mandrillMailchimp1024-bit
  • zohoZoho Mailt=y
Verdict

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.

BIMI manager

The one protocol your customers can actually see

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.

  • default._bimi
  • VMC
Inboxdefault.svg · VMC
  • NTNorthwind TradeOrder confirmation #482112m
  • YCYour CompanyYour invoice is ready4m
  • ABAcme BillingPayment received2m
Awaiting certificate checkshown before opening
MTA-STS shield

No route back to plaintext

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.

  • mode: enforce
  • max_age: 604800
Transport securitySMTP · port 25
mta-sts.your-company.comenforceTLS 1.3 · delivered encryptedSTARTTLS strippedsending MTAyour MX
Awaiting policymax_age: 604800
TLS reporting

Told about the failures nothing else reports

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.

  • _smtp._tls
  • daily rua
TLS reportingrua · daily
0.0%Sessions encrypted14d
1 Mar14 Mar
relay.vendor-mx.net341 downgrades14 Mar

All six deployed by CNAME delegation. No infrastructure changes, no agent, and the records keep resolving even if our application is down.

Aggregate reports, already read

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.

Sending sources5 sources · 7 days
SourceResolved toVolumeSPFDKIMDMARC
209.85.220.41Google Workspacecorporate mail84,210passpasspass
149.72.14.9SendGridtransactional31,004passpasspass
168.245.9.12Customer.iolifecycle12,760passpasspass
198.61.254.7Zendeskforwarded4,882failpasspass
45.155.204.18Unattributedbulletproof host914failfailfail
133,770 messages classified914 forging you, and nothing else would have said so

By hand, or hosted

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.

Publishing records
Doing it yourself

Hand-edited TXT records at every registrar you use, redone from scratch each time a vendor changes something.

With SentraDMARC

One CNAME per protocol. The records live in our zone, and they keep resolving even if our application is down.

Reading the reports
Doing it yourself

Raw XML, or a dashboard that renders the same XML and still leaves you to work out which IP was which service.

With SentraDMARC

Every sending source resolved to the service behind it, classified, and tracked as it changes.

Getting to p=reject
Doing it yourself

Indefinite p=none, because nobody can prove enforcement will not block real mail, so nobody signs off on it.

With SentraDMARC

You stay at monitoring until the data shows only forgeries are failing. Then it is one approval, not a leap of faith.

Keeping SPF currenta sender adds IPs, unannounced
Doing it yourself
  • Cloudflareacme.comnot checked
  • GoDaddyacme.co.uknot checked
  • OVHcloudacme.frnot checked

0 of 3 zones to edit, and nothing told you.

With SentraDMARC
Our zoneyour flattened SPF recordcurrent

The SPF record is re-resolved every hour, so a vendor adding IPs never silently breaks it.

The parts people actually ask about

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.

Built in Lyon, France

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.

Find out what your domain says about you.

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