Domain reputation

What domain reputation actually tells you

A 12-person recruiting firm can do everything right on Monday, then watch reply rates collapse on Wednesday because another company in its sending pool started blasting thousands of poor-quality emails.

That's domain reputation in practice. It's the trust attached to your sending domain and mailboxes, and it depends on what your team sends, how it sends and who else shares the underlying infrastructure. It takes time to build. It can disappear quickly.

The shared-pool problem gets missed because the setup may look fine from your side. Your DNS is correct. Your copy is reasonable. Your volume is within the limit. But another sender's volume, complaints or authentication mistakes can still change the conditions around your mailboxes.

That's why "the domain is warmed" isn't enough information. You need to know which mailbox is sending, how much it is sending, whether the domain still routes correctly and whether authentication is still in place.

Reputation also isn't one account-wide score. It exists at both the domain and mailbox level. A domain can look healthy while one mailbox is sending too aggressively. The reverse can happen too: a mailbox may be ready to send while the domain's routing has broken.

Treat it as an operating condition, not a spreadsheet field.

Why domain reputation takes time to build

Warmup is a controlled ramp, not a switch you turn on before launching a campaign. A new mailbox needs a normal sending history. If you push campaign volume on day one, you're asking providers to trust an account with no track record.

For example, suppose a 30-person software consultancy adds three mailboxes to a new domain after hiring two outbound reps. The mistake is to give all three accounts the full campaign list immediately. A better setup starts each mailbox at a manageable level, watches the results and increases activity only when the sending conditions remain healthy.

Each mailbox needs its own controls, even when several mailboxes use the same domain. One account shouldn't consume the room intended for another. A per-mailbox rate limiter keeps each account within its provider ceiling of 250 operations per second.

That ceiling is only a guardrail. It doesn't create a good reputation by itself. Reputation depends on the whole sending setup: the domain, the mailbox, the volume ramp and the configuration underneath it.

The warmup control should be adjustable without rebuilding the campaign. In this setup, the operator gets a five-step dial, from paused to maximum. That's useful when a mailbox starts showing warning signs or when a campaign needs to slow down for a week. You can hold the account steady instead of choosing between "keep going" and "shut everything off."

Warmup mail creates a separate reporting problem. If it lands beside real replies, it can make a weak campaign look healthy. It can also clutter the inbox and distort reply-rate reporting. Warmup messages should be tagged as soon as they arrive, then excluded from campaign numbers and the working inbox.

Otherwise, the ramp becomes noise with a send button.

Shared sending pools put the wrong person in charge

Shared infrastructure looks efficient until someone else burns it.

The usual defense is that your team follows the rules. That matters, but it doesn't protect you from other senders using the same pool. One company ramps too quickly. Another sends to old lists. A third ignores a routing failure for two days. Their behavior affects the environment your mailboxes depend on.

My view is simple: teams get too comfortable treating shared infrastructure as neutral. It isn't neutral. It creates an ownership problem. You're responsible for the reputation, but somebody else may be influencing the conditions that shape it.

A private sending setup puts responsibility back where it belongs: with your domain, your mailboxes, your warmup settings and your volume decisions. That won't make reputation permanent. Nothing will. It does make a problem easier to trace and quicker to fix.

If a mailbox's bounce rate jumps, you can investigate that mailbox. If authentication fails on the domain, you can pause the affected sending surface. You're not left guessing whether an unrelated sender caused the change.

The checks that matter after launch

DNS and sender authentication aren't provisioning tasks that vanish once the initial setup is complete. A domain can be correct on the day it goes live and broken later because of a DNS change, an expired record or a routing mistake.

Every live domain is re-checked every six hours. If mail routing or sender authentication regresses, campaigns pause immediately.

That pause is important. Continuing to send while the foundation is broken turns a configuration issue into a reputation problem. The sensible sequence is to stop outbound activity, repair the domain and resume only after the sending conditions are healthy again.

The setup also needs to avoid the handoff gaps that show up when different people own different pieces. Buying the domain, writing the DNS zone, provisioning mailboxes and starting warmup should happen as one setup flow. Otherwise the domain gets purchased by one person, DNS is handled by another, and the outbound operator assumes everything is ready.

That's how campaigns start with half-configured mailboxes.

DNS is abstracted across two backends and selected per domain. Live domains can move one at a time without a sending gap. The useful part isn't the number of backends. It's the migration path. You can move one domain without taking every campaign offline.

A mailbox can be the problem even when the domain is fine

Several mailboxes can share a domain and still have very different sending histories. Treating them as one unit hides the account that needs attention.

Mailbox-level controls let the system manage rate, warmup and activity separately. An operator should be able to see that the domain is healthy while one mailbox is paused. They should also be able to see that one mailbox is ready while the domain itself needs repair.

This is where a lot of outbound tooling falls short. It gives you a domain-level status and leaves the actual decisions to manual work. That's backwards. The mailbox is where the send happens, so that's where the controls need to be closest.

Workloom acts for each mailbox directly. Nobody on the team needs to click through an OAuth consent screen, and a token expiry doesn't quietly stop a campaign at midnight. Mailbox access stays out of the manual sending path.

How to judge a domain reputation setup

Don't judge a system by whether it can send. Judge it by whether it can stop sending at the right time.

A useful setup should control the domain, mailbox, warmup and deliverability checks together. It should manage the volume ramp per mailbox, keep accounts inside their provider limits, exclude warmup from campaign reporting and check live domains after launch.

It should also distinguish a domain problem from a mailbox problem. Shared pools blur that distinction. Direct ownership keeps it visible.

When a routing record breaks at 2 a.m., the question isn't whether the system can produce another batch of emails. The question is whether it notices the problem, pauses the affected campaigns and gives the operator a clean path to repair the sending setup before reputation takes the hit.