1. Zen IT Technologies
  2. 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 survives Gmail and Microsoft's bulk-sender rules, and diagnose reputation damage down to the message level.

Let's talk

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.

  • Partial or invalid 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.

    Sending into spam traps, driving complaint rates past the thresholds Gmail and Microsoft now enforce.

  • Template and content failures.

    Link shorteners, tracking domains with poor reputation, misleading content, hidden content, and formatting patterns associated with unwanted mail.

What we do
  1. Sending streams
  2. Dedicated subdomains
  3. SPF, DKIM, DMARC
  4. Reputation monitoring

Sending-domain architecture

  • Authentication design and forensic diagnosis

    We design, implement, and validate SPF, DKIM, DMARC, and ARC across every sending source, including the ones nobody documented. 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, IP allocation and shared-versus-dedicated decisions, and ESP configuration across SendGrid, Amplemarket, and comparable platforms.

  • Reputation monitoring and repair

    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 spam rates approach the enforcement line.

    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.

  • Filter and compliance review

    Message and template review against the filtering stacks that actually decide your fate: Gmail, Microsoft 365, Proofpoint, Mimecast, and Barracuda. We check bulk-sender requirements, one-click unsubscribe, and CAN-SPAM obligations so avoidable compliance failures are not adding to the deliverability problem.

Technical notes

When DKIM passes at the sender and fails at the receiver

A signature covers canonicalized content. Downstream changes can invalidate it.

More on this topic

How it runs

  1. 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.

  2. Architecture.

    A sending design with subdomain separation, authentication plan, and a sequenced migration that does not interrupt live mail.

  3. 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.

Available as a project →

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, traffic segmentation, and feedback telemetry combined into a control layer, giving the platform team the ability to see and act on sending behavior at the level of the individual sender.

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, not a convenience: SaaS platforms sending product and transactional mail at volume, teams running outbound sales sequences, and any organization that has just discovered its DMARC policy has been p=none since the day it was created.

The work can stand alone as a focused deliverability project or sit inside a broader ongoing engagement. The right model depends on whether your team wants to take over the monitoring and runbook or keep us involved. Where we already manage identity, endpoints and DNS, ongoing support also means the systems we need to change are already in our scope.

Frequently asked questions

  • Why is our email going to spam when our SPF and DKIM are set up?

    Authentication is necessary and not sufficient. Mail passes SPF and DKIM and still lands in spam when domain reputation is damaged, when complaint rates exceed provider thresholds, when the sending domain is shared with a high-risk stream, or when content and tracking domains trip filters independently of authentication.

  • 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.

  • How long does deliverability recovery take?

    Reputation recovers on the receiving providers' timescale, not yours. Authentication and architecture changes are quick; reputation typically improves over several weeks of consistent, low-complaint sending. Anyone promising faster is describing a metric that is not inbox placement.

  • Can you work with our existing sending platform?

    Yes. The architecture matters more than the vendor, and most platforms can be configured correctly. Where we recommend a change it is usually about separation of streams rather than the platform itself.

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.

Let's talk