Deliverability monitoring · for people who run their own sending infrastructure

The blocklist is the obituary, not the diagnosis.

Gmail and Outlook decide with their own reputation data. By the time a public blocklist agrees, the domain has been dying for days and your replies already went quiet. Bakeno watches the signals that move first — and pages you while the asset is still worth saving.

Built and run against our own fleet: 40 domains · 400 mailboxes · 3 mail servers.

One domain going bad, in the order the evidence actually arrives

leading corroborating lagging

DAY −6

postmaster

Gmail spam rate drifts 0.08% → 0.24%. Nothing bounces yet.

DAY −5

snds

Outlook filter result turns GREEN → YELLOW for the sending IP.

DAY −3

mailcow

Soft bounces climb +340%; the queue starts holding mail.

DAY −1

dmarc

Aggregate reports show authentication failures trending up.

DAY 0

dnsbl

SBL listing. Where every other tool sends its first alert.

Six days of warning that a blocklist monitor cannot give you, because the blocklist did not know either.

What it watches

Six sources, ordered by how early they move.

Most tools check one thing well. The useful signal is in the sequence — a spam-rate drift on its own is noise, a spam-rate drift followed by a filter transition on the same IP is a domain in trouble. Bakeno correlates all six into a single incident with one owner.

EARLIEST

Google Postmaster

Spam-rate drift

The number Gmail actually acts on. Bakeno tracks direction, not just the value — a rate tripling inside its safe band is the warning; waiting for it to cross a threshold is waiting too long.

EARLIEST

Microsoft SNDS

Filter-result transitions

Per-IP, per-window. Catches GREEN → YELLOW the day it happens, plus the RCPT-to-DATA gap — Outlook's own hard-bounce proxy, which almost nobody reads.

MINUTES

Mailcow

Queue and bounce deltas

Polled every ten minutes with a durable cursor, so deltas are never double-counted after a restart. Per-domain sends, bounces, rejects; per-mailbox quota and rate limits.

HOURLY

DMARC

Authentication trends

Aggregate reports parsed to RFC 7489 and 9990. Forwarding — SPF fails, DKIM passes — is classified and suppressed, because paging on it teaches you to ignore DMARC alerts.

30 MIN

DNS & PTR

Record drift

MX, SPF, DKIM, DMARC and forward-confirmed reverse DNS. A record that vanished and a lookup that failed are different rows here, and only one of them is your problem.

LAST

Blocklists

Confirmation only

Spamhaus, Barracuda, SpamCop — queried through a private resolver, because public ones return an error code that reads as “not listed”. Treated as confirmation of a diagnosis already made, never the alarm.

Why you will actually read the alerts

An alert you ignore is worse than no alert.

Every monitoring tool can fire on a threshold. The hard part is not firing on the forty things that are merely unusual, so that the one that matters still gets your attention at 2am.

3

Consecutive bad checks before anything opens

A single failed lookup never pages. Recovery is held to the same standard in reverse, so an incident cannot flicker shut on one good result.

1

Message per root cause, not per symptom

A broken domain suppresses its own mailboxes' alerts; a dead IP suppresses everything under it. You get the cause and a count, not forty pages saying the same thing.

30s

Grouping window before anything sends

Related incidents that open together arrive as one message. Queued in the database, not in memory, so a restart cannot silently drop an alert.

0

Alerts you cannot act on

Benign forwarding is classified and stays quiet. Low-volume days record as no-evidence. Every page names a subject you can go and fix.

The distinction most tools get wrong

“No data” is not “no problem.”

An Outlook day under 100 messages, a Gmail domain below its privacy minimum, a DNS timeout — none of these are evidence that anything is fine. Most dashboards paint them green. Bakeno records six distinct outcomes for every check, and only three of them can ever move an incident.

ok warn crit absent nodata — carries no evidence lookup_failed — says nothing about you

It sounds like pedantry until the night a resolver times out across forty domains and your monitoring reports every MX record missing.

The console

Your whole fleet on one screen.

Every domain, mailbox, IP and signal, with the worst thing first. Acknowledge an incident, pause a domain, import a fleet, or push a warmup step — from the browser or from Telegram, wherever you happen to be.

Alerts to Telegram, locked to the chats you name — acknowledge and resolve without opening a laptop.
Evidence attached to every incident — the observations that opened it, not just a verdict.
A heartbeat that watches the watcher. If monitoring stops, you are told — silence never gets to mean “all clear”.

Pricing

Priced against the cost of one burned domain.

Replacing a burned domain is not the registration fee. It is three weeks of warmup, the sequences that stalled, and the pipeline that went quiet while you found out.

Watch

$400 / month

Monitoring and alerting across your existing infrastructure. Up to 50 domains.

  • All six signal sources, correlated
  • Telegram alerts with acknowledge and resolve
  • Full console access
  • Monthly deliverability report
  • Warmup ramp gated on real reputation data
Start with a review

Operate

Let's talk

Everything in Watch, plus we run the infrastructure and replace what burns.

  • Domain, DNS, DKIM and mailbox provisioning
  • Replacement assets built and warmed for you
  • Named replacement window, measured and reported
  • Unlimited domains
Talk it through

Straight answers

The questions worth asking first.

How is this different from a blocklist monitor?

A blocklist monitor tells you about the one signal that arrives last. It is genuinely useful for confirming a diagnosis and useless for preventing one — Gmail and Outlook do not consult public blocklists to decide where your mail goes. Bakeno treats a listing as the final piece of evidence, not the alarm.

Do I have to move my infrastructure?

No. Bakeno reads your existing setup — Mailcow, cPanel, Google Workspace, Microsoft 365. Onboarding is a mailbox CSV and read-only API keys. Nothing about how you send changes.

What do you need from me to start?

An export of your mailboxes, read-only API keys for your mail servers, a Google Postmaster account that owns your authentication domains, SNDS keys for your sending IPs, and a mailbox that receives DMARC reports. Most of it is one afternoon.

Will it change anything on my servers?

Monitoring is read-only by design and uses separate read-only credentials. The one thing that writes is the warmup ramp, which raises a mailbox's daily cap — and only when reputation data supports it, only on domains you enrol, and never on an established fleet it has no history for.

How fast will I actually hear about a problem?

It depends on the signal, and honestly so. Queue and bounce problems surface within minutes. DNS and PTR drift within half an hour. Postmaster and SNDS are bound by how often the providers publish — daily and roughly six-hourly. Nobody can beat the provider's own publishing schedule, and any vendor claiming otherwise is measuring something else.

What happens when a domain does burn?

On Watch, you get the incident, the evidence, and a recommendation — replacing the asset is yours to do. On Operate, we build and warm the replacement and report how long it took against the window we agreed.

Next step

Find out what your fleet is already telling you.

Send a mailbox export and read-only keys. Within a week you get a written review of what your infrastructure looks like from Gmail's and Outlook's side — the drift, the gaps, the assets already in trouble. Keep the review either way.

Book an infrastructure review

No dashboard trial. A person reads your data and writes it up.