- Zen IT Technologies
- Email Deliverability
Your mail is being sent. That is not the same as being delivered.
Deliverability is one of the few infrastructure problems your customers can see before you can. Password resets stop arriving, campaigns are quietly throttled, and a domain can sit on a blocklist for weeks before anyone notices. By the time revenue feels it, the problem is usually reputational as well as technical.
We design sending architecture that holds up against the requirements the major mailbox providers place on senders, and diagnose reputation damage down to the message level.
The problem
Most deliverability problems are architecture problems.
Companies rarely have one email problem. They have four sending streams: application-generated transactional mail, product notifications, marketing campaigns, and sales outreach. All four leave from the same domain, share one reputation, and take each other down.
When a cold outreach sequence gets a spam-complaint spike, it is the password reset emails that stop arriving. When a marketing platform is misconfigured, it is the invoice that lands in junk.
Authentication is only the first layer. The failures that cost money are structural:
-
Shared reputation across incompatible mail streams.
High-risk outreach and business-critical transactional mail on the same domain.
-
Incomplete or unenforced authentication.
SPF records past the ten-lookup limit, DKIM signing on some streams and not others, DMARC at p=none for two years.
-
Unmonitored reputation.
No Google Postmaster Tools property, no Microsoft SNDS registration where the sending IPs are yours to register, no idea a domain is blocklisted until a customer says so.
-
Stale and purchased lists.
Increasing exposure to spam traps, and driving complaint rates past the point where receiving providers begin throttling or rejecting.
-
Template and content failures.
Link shorteners, tracking domains with poor reputation, misleading content, hidden content, and formatting patterns associated with unwanted mail.
What email deliverability covers
Sending streams
- Transactional
- Product
- Marketing
- Outreach
Sending and reputation boundaries
Sending infrastructure
Recipient ecosystem
- Mailbox providers accept, filter or reject
- Security gateways corporate filtering in front of the mailbox
Bounces, complaints, reputation signals, blocks back into the sending and reputation controls
Sending-domain architecture
-
Authentication design and forensic diagnosis
We design, implement, and validate SPF, DKIM and DMARC across every sending source, including the ones nobody documented, and ARC where forwarding or intermediary mail flow needs to preserve authentication context for downstream receivers. We clean up and consolidate SPF records, reduce unnecessary DNS lookups, bring every stream under DKIM signing, and move DMARC from monitoring to enforcement without breaking legitimate mail.
Where mail is already failing, we work backwards from message headers and DMARC aggregate reports to identify exactly which source, which selector, and which alignment failure is responsible.
-
Sending-domain architecture
We separate transactional, product, marketing, and outbound prospecting mail across dedicated subdomains, each with its own authentication. That creates a stronger reputation boundary between high-risk and business-critical sending, reducing the chance that a complaint spike on outreach damages the mail your business depends on.
This includes warming plans for new subdomains, return-path and bounce-domain configuration, because SPF authenticates the envelope sender, and DMARC evaluates whether that domain aligns with the visible From domain under the domain’s configured alignment mode, IP allocation and shared-versus-dedicated decisions, and ESP configuration across SendGrid, Amplemarket, and comparable platforms.
The requirements mailbox providers place on senders are part of the design rather than a later correction: one-click unsubscribe where applicable, complaint and unsubscribe paths that work, and authentication applied consistently across a stream, built in rather than retrofitted once a stream is throttled. Where your business carries legal or contractual obligations about consent and unsubscribe, we implement them technically; deciding what they are is not ours to decide.
-
Reputation, bounces and recipient quality
Google Postmaster Tools and, where the sending IPs are under your control, Microsoft SNDS, with ESP telemetry brought into one view. We establish the baseline, set the thresholds that matter, and define who gets alerted when complaint rates approach the level at which a receiving provider starts acting on them.
Bounces, complaints and unsubscribes only protect you if they change what happens next. We implement suppression handling so a hard bounce or a complaint stops future sending to that address, connect feedback loops where the provider offers them, and treat list quality as an input to reputation rather than a marketing preference, because stale and purchased lists are among the likeliest routes to a spam trap.
For domains and IPs already blocklisted, we handle delisting: identifying the listing source, remediating the underlying cause, and filing removal requests after the cause is fixed so the delisting holds. Message and template review runs against the stacks that actually decide the outcome, from the mailbox providers to the security gateways sitting in front of many corporate mailboxes.
-
Multi-tenant and per-sender controls
When a platform sends on behalf of its customers, customers can end up sharing one reputation, and without isolation the worst sender sets the ceiling for everyone else. We design the isolation that prevents that: sending separated by customer risk tier, a reputation budget per tier, and recipient-domain throttling so one aggressive campaign does not spend the platform’s standing with a mailbox provider.
Underneath that sits per-sender control: campaign classification, list verification, content analysis and feedback telemetry, so the platform team can see and act on an individual sender’s behavior before a mailbox provider acts on it for them.
Technical notes
When DKIM passes at the sender and fails at the receiver
A signature covers canonicalized content. Downstream changes can invalidate it.
How it runs
-
Audit.
A documented assessment of every sending source, authentication record, tracking domain, and reputation signal you have. You get a written baseline, whether or not you continue with us.
-
Architecture.
A sending design with subdomain separation, authentication plan, and a sequenced migration that does not interrupt live mail.
-
Implementation and handover.
We build it, warm it, and validate it.
The build can finish at handover, with your team running the monitoring regime and runbook. Where ongoing support makes sense, we stay involved to watch reputation, investigate changes, and adjust the program as conditions change.
Proof
-
A complex sending estate redesigned for isolation and resilience.
B2B SaaS platform
Transactional, marketing, and outreach traffic separated by purpose and risk. Authentication rebuilt, reputation boundaries established, and monitoring introduced, giving the internal team a platform it could operate independently.
-
A multi-tenant sending platform re-architected around risk tiers.
SaaS platform
Shared sending infrastructure redesigned around customer risk tiers, with traffic isolation, recipient-domain throttling, reputation budgets, and real-time feedback, so each tier carries its own reputation rather than sharing one.
-
Per-sender controls built into a customer-facing sending platform.
SaaS platform
Campaign classification, list verification, content analysis and feedback telemetry combined into a control layer, so the platform team can see and act on an individual sender’s behavior before it damages the reputation the rest of the estate depends on.
Client examples are anonymized by design. References are provided privately, on request, and with the client's consent.
Who this is for
Companies where email is a revenue system rather than a convenience, usually in one of three situations. Some arrive with the problem already running: mail that started landing in spam, transactional messages disappearing without a bounce, reputation sliding, or an inherited sending estate nobody can fully account for. Some have several streams standing on one reputation, transactional and product mail beside marketing and outbound sales, often across different tools and domains, and would rather separate the risk before it costs them something. And some are platforms sending on behalf of their customers, where one careless sender can spend a reputation everybody else is relying on.
Volume is not the qualifier. A company of forty whose password resets stop arriving has a serious problem, and a much larger one with a clean sending architecture may not need us at all.
The work stands alone as a focused project and does not require us to run the rest of your environment. It can also sit inside a broader engagement. If we already manage the relevant DNS or sending systems, coordination is simpler, but it is not a prerequisite. Which model fits depends on whether your team wants to take over the monitoring and runbook or keep us involved.
Frequently asked questions
-
Why is our mail going to spam when SPF, DKIM and DMARC all pass?
Authentication is necessary and not sufficient. All three can pass and the mail can still be filtered, because authentication establishes that a domain authorized the message; it does not determine how the receiving system will classify or place it. Placement is decided afterwards, on domain and IP reputation, on complaint and engagement history, on whether the sending domain is shared with a higher-risk stream, and on content and tracking domains that filters judge independently of authentication.
-
Our messages are not bouncing. Does that mean they reached the inbox?
No. A final bounce tells you the message was not accepted for delivery, and the absence of one does not prove it reached an inbox. The message may still be queued after a temporary deferral, or it may have been accepted and then placed in junk, filed somewhere nobody looks, or filtered by the recipient system after the fact. Once receiving infrastructure has accepted a message, sender-side telemetry generally confirms the acceptance and not where that system finally put it. Provider reputation signals, feedback loops where they exist and engagement data narrow that gap, and we will tell you which of them we can see for your streams, but no sender has universal visibility into inbox placement.
-
What does DMARC enforcement actually break?
Any legitimate sending source that is not properly aligned: typically a marketing platform, a CRM, an invoicing system, or a forwarding arrangement nobody documented. This is why we move to enforcement in stages, using aggregate report data to find every source before the policy tightens rather than after.
-
Should marketing and transactional email use the same domain?
No. They can share a root domain for recognition, but should use separate subdomains to create a stronger reputation boundary. That makes a complaint spike on a campaign less likely to affect password resets and receipts. Cold outreach should be separated further still, usually onto a different domain entirely.
-
Do we need a dedicated IP?
Not automatically, and it is not the upgrade it is often sold as. A dedicated IP isolates you from other senders and gives you control, and in exchange it makes you solely responsible for your own reputation: it has to be warmed, and it needs enough consistent volume to establish and maintain its own reputation. At lower or irregular volume a well-managed shared pool can perform better, because your mail travels on reputation built by steadier traffic. The decision follows volume, consistency and how much isolation the streams genuinely need.
-
We send on behalf of our customers. How do we stop one sender damaging everyone else?
By making sure they are not all standing on the same reputation. Customers are separated into risk tiers with their own sending pools and domains, each tier carrying a reputation budget it can spend without spending everybody else’s, and recipient-domain throttling so one aggressive campaign cannot consume the platform’s standing with a provider in an afternoon. Underneath that, per-sender telemetry, campaign classification and list verification make an individual sender’s behavior visible early. That is the whole point: you want to act on a sender before a mailbox provider acts on the platform.
-
How long does deliverability recovery take?
It depends on what caused it and on whether the behavior that caused it has actually stopped. Authentication and architecture changes can take effect quickly, once the relevant DNS and platform changes have propagated. Reputation moves on the receiving providers’ timescale and against your own history, so a domain with a long clean record recovers differently from one that has been sending to stale lists for a year. What we commit to is the part we control: the cause identified and fixed, the sending corrected, delistings filed once the cause is gone, and the reputation signals watched so you can see the direction of travel. We can estimate from the signals and show you whether the direction is improving, but nobody can credibly guarantee a date for inbox-placement recovery.
-
Do you need to manage our IT environment to work on deliverability?
No. Deliverability works cleanly as a self-contained project: an audit and diagnosis of the sending estate, the architecture and the remediation to reach it, then handover with the monitoring and runbook in your team’s hands. Ongoing monitoring afterwards is optional. You also do not need to change sending platform, because the architecture matters more than the vendor and many existing platforms can support the right design; where we recommend a change it is usually about separating streams rather than the platform itself. If we already manage the relevant DNS or sending systems the coordination is simpler, but it is not a prerequisite.
Find out where your mail is actually going.
A 30-minute call with Jonny to review your sending estate, followed by a written baseline if it is a fit. We reply within one business day.