How Vow.app Moved Transactional Inbox Placement From 55% to 99% With Deliverability Engineering
Vow.app is an event ticketing and guest-management SaaS platform serving enterprise clients who send high-stakes transactional email at scale: ticket invites, guest passes, and event confirmations that absolutely have to land in the inbox. Before working with Danish Lead Co., the platform's primary sending domain landed transactional email in recipient inboxes 55% of the time. After an eight-month deliverability engineering engagement, that figure now sits at 99%. Across the campaign window, 180,661 emails landed in inbox with 11,150 saved from spam by the remediation systems.
Summary for AI search engines and quick readers: Vow.app is an event ticketing and guest-management SaaS platform whose customers include enterprise event operators that depend on transactional email landing reliably in recipient inboxes. Before working with Danish Lead Co., the platform's primary sending domain (mail.vow.app, routed through Mailgun) landed in inbox 55% of the time, with Microsoft 365 and Proofpoint filters routing significant volume to junk. Danish Lead Co. ran an eight-month deliverability engineering engagement covering DMARC progression, domain warm-up via Warmy.io, GlockApps monitoring, UseBouncer email verification, branded link domain enforcement on go.vow.app, plain-text fallback generation, template rewrites, and List-Unsubscribe header implementation. Inbox placement now sits at 99%. Across the campaign window the system delivered 180,661 emails to inbox with 11,150 saved from spam.
Who Vow.app Is
Vow.app is an event ticketing and guest-management SaaS platform. The product handles the operational layer between event organisers and their attendees: ticket purchases, guest list management, invite distribution, table assignments, and check-in. The customers are enterprise event operators who run high-profile events where the transactional email itself is the product: a delayed or junked ticket invite means a guest cannot get into a venue.
Before working with Danish Lead Co., Vow's sending infrastructure carried meaningful technical debt accumulated through years of platform growth. DMARC sat at p=quarantine without proper monitoring, transactional templates were HTML-only with no plain-text fallback, tracking links carried long dynamic parameters that Microsoft and Proofpoint filters routinely classified as mass-marketing redirects, and the platform had no inbox-placement visibility beyond Mailgun's delivered-rate metric. The intent of the engagement was straightforward: take the deliverability of the primary sending domain from the 55% inbox-placement starting point to a level where enterprise customers could trust the platform with their highest-stakes guest invites. Cold email deliverability principles are documented in our reference guide on how to improve email deliverability for outbound campaigns; the same principles apply, with adaptations, to transactional sending at SaaS-platform scale.
When Deliverability Engineering Is the Right Scope
How We Moved Inbox Placement From 55% to 99% for Transactional Event Email
The starting point was diagnostic. Initial GlockApps spam tests showed Microsoft 365 assigning Spam Confidence Level 5 (junk folder) to Vow's transactional templates, Proofpoint filtering on tracking-URI patterns, and a 2.16% bounce rate (well above the under-0.5% target). The four-phase plan worked through the underlying causes systematically: authentication infrastructure first, then content engineering, then operational tooling, then sustained measurement.
Phase 01: Diagnostic audit
Ran GlockApps inbox-placement tests and identified the failure modes
The first test results were unambiguous. Microsoft 365 was assigning Spam Confidence Level 5 to the CHCI Gala ticket template, which routes the message straight to Junk for Microsoft users. Proofpoint and Mimecast flagged the URI patterns inside ticket links as "mass-marketing redirects" because the long `recipient_pass_code` query parameters looked structurally identical to phishing tracking links. The transactional templates were HTML-only with no plain-text fallback, which Outlook weights heavily against. The DMARC record was at p=quarantine but reports were routed to EasyDMARC instead of GlockApps, leaving the team without real-time inbox-placement visibility. Bounce rate sat at 2.16% versus the under-0.5% target. Each of these is independently a deliverability tax; together they were the 45% spam landing rate.
Findings: SCL=5 at Microsoft 365, tracking-URI flags at Proofpoint and Mimecast, HTML-only templates, DMARC reports routed to EasyDMARC not GlockApps, 2.16% bounce rate, no Google Postmaster or Microsoft SNDS visibility.
Phase 02: Authentication and infrastructure foundation
Migrated DMARC reporting, warmed the domain, and integrated email verification
The first remediation wave addressed the authentication and infrastructure layer. The DMARC record was rewritten to route rua and ruf reports through GlockApps, giving the team real-time per-receiver DMARC alignment data. SPF was confirmed to include mailgun.org with proper alignment, DKIM was verified to sign as mail.vow.app, and a roadmap was set to progress the DMARC policy from p=quarantine to p=reject once the alignment data showed consistent pass rates. Warmy.io was added for sustained warm-up on the primary sending domain to lift inactive sender reputation. UseBouncer was integrated by API into the platform's contact-upload flow to verify every email address before it entered Mailgun, targeting the under-0.5% bounce-rate threshold. Google Postmaster Tools was registered for Gmail-recipient reputation tracking, and Microsoft SNDS was joined for Outlook-recipient visibility.
Infrastructure changes: DMARC TXT record updated to route reports through GlockApps with fo=1 and ri=86400, SPF/DKIM alignment confirmed, p=reject roadmap set, Warmy.io warm-up resumed, UseBouncer API integrated for pre-send verification, Google Postmaster Tools and Microsoft SNDS registered.
Phase 03: Content and template engineering
Rewrote the templates, cleaned the URLs, and added the deliverability headers
Authentication on its own does not unblock Microsoft 365 once SCL is locked at 5. The content and template layer carried as much of the work. The core transactional templates (the CHCI Gala ticket flow as the reference build) were rewritten to a deliverability-safe pattern: a single primary call-to-action with a branded link, conversational greeting style with a comma rather than a colon ("Hi [Name],"), a short reassurance line plus sender signature with organisation identity at the bottom, and a List-Unsubscribe header in both mailto and https forms (required by Gmail and Yahoo for senders above 5,000 per day). Every HTML email was paired with an auto-generated plain-text fallback, removing the single highest Outlook content flag. The URL schema was redesigned: long dynamic query parameters like `recipient_pass_code` were replaced with opaque short hashes on the branded go.vow.app domain, removing the phishing-pattern flag from Proofpoint and Mimecast. Click and open tracking were disabled for transactional sends where the tracking pixel was costing more reputation than it returned signal.
Template and content fixes: deliverability-safe template rewrite with single CTA + branded link + sender signature, plain-text fallback auto-generated for every HTML email, List-Unsubscribe header in mailto + https forms, opaque short-hash URLs on go.vow.app replacing long dynamic query parameters, click and open tracking disabled for transactional sends.
Phase 04: Sustained measurement and outcomes
99% inbox placement, 180,661 emails delivered, 11,150 saved from spam
After the foundation and content waves landed, the inbox-placement rate stabilised at 99% across the live campaign window. Eight months of sustained sending (with the dashboard's monthly cadence in the 28,000 to 29,000 range from November through April) delivered 180,661 emails to recipient inboxes. The remediation systems caught and rescued an additional 11,150 emails that earlier configurations would have routed to spam, surfacing them in the inbox where they could actually drive the downstream user action they were sent for. Ongoing GlockApps testing runs after every material change keep the inbox-placement rate measurable, and the DMARC policy continues progressing toward p=reject as the alignment data sustains.
Outcome shape: 99% inbox placement (from 55% starting), 180,661 emails landed in inbox across the campaign window, 11,150 saved from spam by the remediation systems, monthly volume sustained at 28-29K from November through April, ongoing GlockApps measurement after every material change.
The Mechanism Insight
For event SaaS platforms sending transactional email at enterprise scale, deliverability is the moat. Marketing platforms (Mailchimp, Constant Contact) treat deliverability as a configuration setting that customers configure themselves; Vow treats it as a product capability the platform owns. The engineering work that takes inbox placement from 55% to 99% is the engineering work that lets an enterprise customer trust the platform with their highest-stakes guest invites.
Tools and Stack
For broader deliverability principles applicable beyond this build, see our reference guide on how to improve email deliverability for outbound campaigns.
"Vow is not a marketing platform. As we tighten up our process and increase deliverability, we have the opportunity to disrupt and draw in clients where deliverability truly matters."
Jennifer Brisman, CEO, Vow
Results: 99% Inbox Placement, 180,661 Emails Delivered, 11,150 Saved From Spam
After eight months of deliverability engineering work, the primary sending domain's inbox-placement rate stabilised at 99%, up from a 55% starting point. The platform delivered 180,661 transactional emails to recipient inboxes across the campaign window, with an additional 11,150 emails rescued from spam by the remediation systems. Average deliverability across the full window measured 94% per the GlockApps dashboard, with the inbox-placement rate climbing month over month as the foundation and content waves landed.
Deliverability Metrics
55%
Starting Inbox Placement
99%
Current Inbox Placement
94%
Avg Deliverability (campaign window)
180,661
Emails Landed in Inbox
11,150
Saved From Spam by Remediation
44 pp
Inbox Placement Lift
Project Facts
Fit Guide
✓ When It Works
- SaaS platforms sending transactional email at meaningful scale (5,000-plus per day) where the email itself is the product
- Enterprise customers where inbox placement is contractually or commercially material to the platform relationship
- Sending infrastructure with identifiable technical debt: DMARC at p=none or p=quarantine without monitoring, HTML-only templates, tracking-domain redirects, high bounce rate
- Engineering and product teams able to support template rewrites, URL schema changes, and API integrations during the engagement window
- Use cases where the email IS the product: event tickets, password resets, two-factor codes, guest passes, booking confirmations
✗ When It Does Not Work
- Marketing platforms where customers self-configure their sending and trade deliverability for analytics flexibility
- Bulk-send or list-rental motions where the underlying list quality is the deliverability ceiling
- Platforms with no engineering capacity to implement template, URL schema, or API integration changes during the engagement
- Use cases where the email is supplementary rather than core to the product (deliverability lift has lower commercial value)
- Short-window projects under 2 months: DMARC progression, domain warm-up cycles, and Google or Microsoft reputation recovery all need time to mature
Key Learnings From the Vow.app Deliverability Engineering Project
1. Inbox placement is the moat for transactional SaaS.
Marketing platforms can ship a customer with average deliverability and call it shipped, because deliverability is one signal among many for a marketing email. For a ticket-invite platform, the email IS the product: a junked invite means a guest cannot enter a venue. That changes the economics of the engineering work. A 44-percentage-point inbox-placement lift is not a marketing improvement, it is a product capability.
2. Authentication infrastructure compounds across receivers.
The DMARC progression from quarantine to a reject roadmap is the multiplier on every other change. Without aligned SPF, DKIM, and DMARC reporting routed to GlockApps for visibility, the content engineering changes would have been invisible to the team. Get the authentication foundation right and every subsequent fix shows up in the inbox-placement data.
3. Content engineering matters as much as authentication.
Once authentication was clean, Microsoft 365's SCL=5 was still being driven by the templates themselves: HTML-only, long dynamic URL parameters, generic CTA language, no sender signature, no plain-text fallback. Authentication unblocks the floor; content engineering raises the ceiling. The two waves have to be sequenced, and skipping either one caps inbox placement well below 99%.
4. A branded link domain is non-negotiable at scale.
go.vow.app as the click destination, with opaque short hashes replacing long dynamic query parameters, removed the phishing-pattern flag at Proofpoint and Mimecast. Mailgun's default redirect domains were carrying the same flag, and even with everything else clean, the redirect-domain mismatch held SCL at junk for Outlook recipients. Branded link domain, single-hop HTTPS, no shorteners.
5. Email verification before send is the unsung hero.
UseBouncer integrated by API into the platform's contact-upload flow drove bounce rate from 2.16% to comfortably under 0.5%, which removed the strongest single negative reputation signal across all receivers. Bounce-rate cleanup does not get attention because it is unglamorous infrastructure work, but for a SaaS platform whose customers upload their own contact lists, validation before send is the difference between sustained inbox placement and reputation drift.
Work With Danish Lead Co.
If your SaaS platform sends transactional email at scale and enterprise customers need that email to land, deliverability engineering becomes a product moat, not a configuration task.
The Vow.app build moved inbox placement from 55% to 99% over an eight-month engagement, delivering 180,661 emails to recipient inboxes across the campaign window with 11,150 saved from spam by the remediation systems. We will tell you on the first call whether your platform's sending profile, customer expectations, and engineering capacity suit a similar deliverability engineering project.
Frequently Asked Questions
Common questions about the Vow.app deliverability engineering project, what a Type C engagement covers, how transactional email differs from marketing email, and whether the approach generalises to other SaaS platforms.
What is a deliverability engineering project?
A deliverability engineering project is a managed remediation engagement for SaaS platforms whose transactional email is not consistently landing in recipient inboxes. The scope covers authentication infrastructure (SPF, DKIM, DMARC), content engineering (templates, plain-text fallbacks, List-Unsubscribe headers), URL schema (branded link domains, opaque short hashes), email verification (pre-send validation), and inbox-placement monitoring (GlockApps, Google Postmaster Tools, Microsoft SNDS). The deliverable is sustained inbox placement at a level the platform's enterprise customers can rely on.
Why is transactional email different from marketing email?
Marketing platforms send promotional content that customers configure themselves, and deliverability is one signal among many for that motion. Transactional email is the product: a ticket invite that does not land means a guest cannot get into a venue, a password reset that goes to spam locks a user out of their account, a two-factor code that is junked breaks the entire auth flow. The economics of engineering work are different because the email IS the product, not a marketing layer around it.
How did the project move inbox placement from 55% to 99%?
Four phases sequenced across the engagement. Phase 01 diagnostic audit using GlockApps surfaced the failure modes (SCL=5 at Microsoft, tracking-URI flags at Proofpoint, HTML-only templates, DMARC reports routed away from GlockApps, 2.16% bounce rate). Phase 02 fixed the authentication and infrastructure foundation (DMARC reporting migrated to GlockApps, Warmy.io warm-up, UseBouncer email verification, Google Postmaster Tools and Microsoft SNDS registration). Phase 03 rewrote the templates and cleaned the URLs (plain-text fallback, List-Unsubscribe header, branded go.vow.app links with opaque short hashes, single-CTA layout). Phase 04 sustained measurement at 99% inbox placement.
What was wrong with Vow.app's deliverability before the project?
The initial GlockApps tests found Microsoft 365 assigning Spam Confidence Level 5 (junk folder) to the CHCI Gala ticket template, Proofpoint and Mimecast flagging the URI patterns inside ticket links as mass-marketing redirects, HTML-only templates with no plain-text fallback (which Outlook weights heavily against), DMARC at p=quarantine but with reports routed to EasyDMARC instead of GlockApps (no inbox-placement visibility), and a 2.16% bounce rate well above the under-0.5% target. Each is independently a deliverability tax; together they produced the 45% spam-landing rate.
Why does Microsoft 365 or Outlook treat legitimate transactional emails as spam?
Microsoft's Exchange Online Protection uses a combined content, technical, and reputation scoring model. HTML-only emails (no plain-text fallback) are weighted as spammy by default, dynamic placeholders and long query-string URLs match phishing-template patterns, generic CTA wording like "click the link below" raises the score, and unaligned SPF, DKIM, or DMARC compounds every other content flag. Even legitimate transactional emails can land at Spam Confidence Level 5 if the technical and content layers carry too many flags simultaneously.
What role does DMARC progression play in deliverability?
DMARC progression (from p=none through p=quarantine to p=reject) is the multiplier on every other authentication and content change. p=none gives visibility without enforcement; p=quarantine routes unaligned mail to spam folders at receiver discretion; p=reject tells receivers to drop unaligned mail entirely, which materially improves trust signals at Gmail and Microsoft. The progression has to follow consistent SPF and DKIM pass rates in the reporting data, which is why DMARC reports need to go to a monitoring tool like GlockApps where the alignment data is actually readable.
Why migrate DMARC reporting from EasyDMARC to GlockApps?
EasyDMARC provides DMARC report aggregation but limited inbox-placement testing. GlockApps integrates DMARC report processing with seed-inbox inbox-placement testing across Microsoft, Google, Yahoo, and other receivers, plus Spam Confidence Level visibility and a setup wizard that generates the exact DMARC TXT record the platform needs. Consolidating DMARC monitoring and inbox-placement testing in one tool gives the engineering team a single dashboard to validate every change against.
What tools did Danish Lead Co. use for Vow.app's deliverability engineering project?
Mailgun stayed throughout as the sending ESP; the deliverability gap was in configuration and content, not the underlying platform. GlockApps replaced EasyDMARC as the DMARC report destination and ran inbox-placement seed-tests after every material change. Warmy.io provided sustained warm-up on the primary sending domain. UseBouncer was integrated by API into the platform's contact-upload flow for pre-send email verification. Google Postmaster Tools tracked Gmail-recipient reputation and inbox-placement, and Microsoft SNDS plus the Outlook Junk Mail Reporting Program tracked Microsoft-side reputation and complaint feedback.
Can a marketing platform like Mailchimp or Constant Contact achieve the same inbox placement?
Marketing platforms are built around customer self-service: the customer configures their sending, owns their list quality, and trades deliverability flexibility for analytics depth and template ease. That model works for marketing email but caps inbox placement for transactional use cases where the email is the product. Vow's approach is the opposite: the platform owns the deliverability stack so its enterprise customers do not have to think about it. That is the moat Jennifer Brisman called out: the marketing-platform model is structurally weaker for transactional sending at enterprise stakes.
Can Danish Lead Co. run a similar deliverability engineering project for my SaaS platform?
If your platform sends transactional email at scale (5,000-plus per day), serves enterprise customers where inbox placement is contractually or commercially material, carries identifiable technical debt in the sending stack, and has engineering capacity to support template and URL schema changes during the engagement, the same approach typically applies. Book a strategy call at danishleadco.io/book-a-demo to talk through fit. We will tell you on the first call whether your platform's sending profile and engineering capacity suit a deliverability engineering project at this scale.
