What Email Deliverability Actually Means

Email deliverability is not the same as email delivery. Delivery means the SMTP server accepted the message. Deliverability means it landed in the inbox, not the spam folder, not the promotions tab, and not a greylist limbo.

The gap between these two is where most transactional email systems fail silently. Your API returns 202 Accepted, your logs show email.sent, but the OTP never reaches the user. Your deliverability rate looks fine on paper. Your users are locked out.

This guide covers the full technical stack that determines whether your emails reach the inbox — and how Senviok handles each layer.

The Deliverability Pipeline: What Happens After You Hit Send

When your application calls the Senviok API to send a transactional email, the message passes through seven distinct stages before reaching the recipient:

Your App
  │
  ▼
1. API Ingestion ──── Authentication, rate limiting, input validation
  │
  ▼
2. Queue Enqueue ──── Tenant-isolated durable queue (Redis-backed)
  │
  ▼
3. DNS Authentication ── SPF alignment, DKIM signing, DMARC check
  │
  ▼
4. Reputation Check ── Pre-flight sender score validation
  │
  ▼
5. Provider Routing ── Smart routing to optimal delivery provider
  │
  ▼
6. SMTP Handshake ── HELO, MAIL FROM, RCPT TO, DATA
  │
  ▼
7. Feedback Loop ── Bounce processing, complaint handling, suppression

Most email services expose stages 1, 6, and 7. Senviok gives you visibility into all seven. Let us examine each layer.

Layer 1: Authentication Records — The Foundation

SPF (Sender Policy Framework)

SPF tells receiving servers which IP addresses are authorized to send email on behalf of your domain. A misconfigured SPF record is the single most common cause of deliverability failure for new senders.

How SPF validation works:

Receiving server extracts the domain from the Return-Path header (not the From header)
Performs a DNS TXT lookup on that domain
Checks the sending server's IP against the authorized list
Evaluates the result: pass, softfail, neutral, fail, or permerror

Critical detail most developers miss: SPF is evaluated against the envelope sender (Return-Path), not the visible From header. If your email provider rewrites the Return-Path to their domain, your custom SPF record becomes irrelevant — you need their SPF record to pass instead.

Senviok's approach:

Senviok uses AWS SES as the underlying delivery provider for custom domains. When you verify your domain, Senviok provides the exact DNS records needed:

# SPF Record (TXT at root)
v=spf1 include:amazonses.com ~all

# DKIM Records (3 CNAMEs)
senviokdomainkey._domainkey.yourdomain.com → dkim.ses.amazonaws.com
senviok1._domainkey.yourdomain.com        → dkim1.ses.amazonaws.com
senviok2._domainkey.yourdomain.com        → dkim2.ses.amazonaws.com

The ~all (softfail) is intentional during initial sending. Once your domain reputation stabilizes, you can tighten to -all (hardfail).

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to every outgoing email. The receiving server retrieves your public key from DNS and verifies the signature was not tampered with in transit.

What DKIM actually signs:

DKIM signs a subset of headers (typically From, To, Subject, Date, Message-ID) and the entire body. The signature is placed in the DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=senviokdomainkey;
  h=from:to:subject:date:message-id;
  bh=base64(body-hash);
  b=base64(signature);

Common DKIM failures:

Failure	Cause	Fix
`DKIM=permerror`	DNS key not found	Verify CNAME records propagated
`DKIM=fail (bad signature)`	Body modified in transit	Check for mailing-list footers or forwarding
`DKIM=none`	No signature present	Ensure signing is enabled on the provider

DMARC (Domain-based Message Authentication)

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails:

# Graduated DMARC policy (recommended rollout)
# Stage 1: Monitor only
_vmarc.yourdomain.com → v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100

# Stage 2: Quarantine failures
_vmarc.yourdomain.com → v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=25

# Stage 3: Reject failures
_vmarc.yourdomain.com → v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com

The alignment requirement: DMARC requires either SPF or DKIM (or both) to align with the From header domain. Alignment means the domain in the SPF check or DKIM d= tag must match (or be a subdomain of) the visible From domain.

This is why simply passing SPF is not enough — if your provider rewrites the Return-Path to a different domain, SPF passes but DMARC alignment fails.

Layer 2: Sender Reputation — Your Invisible Score

Every sending domain and IP address carries a reputation score maintained independently by each receiving provider (Gmail, Outlook, Yahoo, etc.). These scores are not public. They are not APIs. They are proprietary, machine-learned models that evaluate:

Domain Reputation Factors

Factor	Weight	What It Means
Bounce rate	Very High	Hard bounces above 2% tank your score fast
Complaint rate	Critical	Above 0.1% on Gmail triggers throttling
Engagement	High	Opens, replies, and forwards boost reputation
Spam trap hits	Critical	Hitting a spam trap is reputation poison
Volume consistency	Medium	Steady volume builds reputation; spikes erode it
Authentication	High	SPF/DKIM/DMARC pass rates affect scoring

IP Reputation vs. Domain Reputation

Gmail and Outlook maintain both IP and domain reputation scores. A new dedicated IP starts with neutral reputation, but a new domain starts with zero reputation history. This is why:

IP warming matters less than domain warming in 2026
Switching to a new domain resets your reputation even on an established IP
Shared-IP pools (like free tiers) carry the reputation of all senders on that pool

How Senviok handles this:

Senviok's Growth plan includes a dedicated IP that is already warmed and carrying established reputation. Your domain still needs warming, but the IP reputation provides a stable foundation. On shared-IP tiers (Free, Startup, Starter), Senviok manages IP reputation globally across all tenants — individual users cannot damage the pool because outbound volume is rate-limited per workspace.

Layer 3: Bounce Classification — Not All Bounces Are Equal

A bounce is not a single error. It is a classified event with different severity levels and different required actions.

Hard Bounces (Permanent Failures)

550 5.1.1 The email account that you tried to reach does not exist.
550 5.2.1 The user you are trying to reach is disabled.

Action: Suppress immediately. Never retry. Remove the address from your list.

Soft Bounces (Transient Failures)

421 4.7.0 Try again later — rate limiting
452 4.2.2 Mailbox full
451 4.7.1 Greylisted — try again in 5 minutes

Action: Retry with backoff. Senviok retries soft bounces up to 3 times with increasing delays (5 min → 30 min → 2 hours). If all retries fail, the event is logged with SOFT_BOUNCE_EXHAUSTED and the address is flagged for monitoring.

Deferred Messages (Provider-Side Queue)

250 2.0.0 OK — queued as ABC123

This is not a bounce — the provider accepted the message but has not yet attempted delivery. Gmail, Outlook, and Yahoo frequently defer messages during peak hours. Senviok monitors deferred messages and triggers a webhook event (email.deferred) if the message remains undelivered after 4 hours.

Complaint Reports (Feedback Loops)

When a user clicks "Mark as Spam" in Gmail or Outlook, the provider sends a feedback loop (FBL) complaint back to the sender. This is more damaging than a bounce because:

It indicates the user actively rejected your email
Gmail uses complaint rate as a primary reputation signal
A single complaint from a Gmail user affects your reputation with all Gmail users

Senviok's handling:

// Simplified complaint processing
if (event.Type == "complaint")
{
    // 1. Immediately suppress the address
    await _suppressionRepository.AddAsync(new Suppression
    {
        TenantId = tenantId,
        Address = event.Recipient,
        Reason = "complaint",
        SuppressedAt = DateTime.UtcNow
    });

    // 2. Fire webhook event for the tenant
    await _webhookQueueService.EnqueueAsync(tenantId, new WebhookEvent
    {
        Type = "email.complained",
        Data = new { recipient = event.Recipient, timestamp = DateTime.UtcNow }
    });

    // 3. Log for deliverability analytics
    await _activityLogRepository.LogAsync(tenantId, "complaint", event.Recipient);
}

Layer 4: IP Warming — The 30-Day Ramp

Sending domain warming is the process of gradually increasing your sending volume to build reputation without triggering spam filters. Gmail and Outlook are particularly aggressive about throtteting new senders who spike volume.

Warming Schedule

Day	Daily Volume	What It Signals
1–3	50–100 emails	Establishing presence, low-risk
4–7	100–500 emails	Building consistent sending pattern
8–14	500–2,000 emails	Proving engagement (opens, replies)
15–21	2,000–10,000 emails	Scaling with established trust
22–30	10,000+ emails	Full volume (with positive engagement history)

Critical rules during warming:

Send to engaged users first. Start with your most active contacts — they open, click, and reply. Engagement signals are the fastest way to build reputation.
Never spike. Going from 100 emails/day to 5,000 in one day will trigger throttling regardless of your reputation.
Monitor bounces obsessively. If your hard bounce rate exceeds 2% during warming, pause and clean your list.
Warm one domain at a time. Splitting volume across multiple new domains dilutes reputation signals.

How Senviok helps:

Senviok's plan quota system enforces natural volume limits:

Plan	Monthly Email Limit	Warming-Friendly
Free	3,000	✅ ~100/day fits early warming
Startup	6,000	✅ ~200/day for mid-warming
Starter	50,000	✅ ~1,600/day for scaling
Growth	200,000	✅ Full volume with dedicated IP

The per-workspace rate limiting ensures that even if your application has a bug and tries to send 50,000 emails in one burst, Senviok throttles the outbound queue to protect your domain reputation.

Layer 5: Content Signals — What Spam Filters Actually Read

Beyond authentication and reputation, spam filters analyze the email content itself. Here are the technical factors that affect deliverability:

Header Analysis

# Good: Clean, standards-compliant headers
From: "Your App" <hello@yourdomain.com>
To: user@example.com
Subject: Your verification code
Message-ID: <abc123@yourdomain.com>
Date: Wed, 02 Sep 2026 08:00:00 +0000
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8

Red flags in headers:

Missing or malformed Message-ID
From name that does not match the domain
Inconsistent Date headers (timezone mismatches)
Missing MIME-Version

HTML/Text Ratio

Gmail and Outlook penalize emails that are 100% HTML with no plain-text alternative. Best practice:

Content-Type: multipart/alternative;
  boundary="boundary_abc123"

--boundary_abc123
Content-Type: text/plain; charset=UTF-8

Your verification code is: 123456
This code expires in 10 minutes.

--boundary_abc123
Content-Type: text/html; charset=UTF-8

<html><body>
<p>Your verification code is: <strong>123456</strong></p>
<p>This code expires in 10 minutes.</p>
</body></html>

--boundary_abc123--

Link and Image Analysis

Tracking pixels without transparency headers get flagged
Shortened URLs (bit.ly, tinyurl) are heavily penalized
Image-to-text ratio above 60% image / 40% text triggers spam scoring
Links to known-bad domains (even in footer) tank deliverability

Senviok's tracking approach:

Senviok's open and click tracking uses first-party tracking domains that you configure (track.yourdomain.com). This avoids the shared tracking-domain reputation problem that plagues platforms like Mailchimp and SendGrid, where one spammy sender's tracking domain affects all users sharing it.

Layer 6: Deliverability Monitoring — The Metrics That Matter

Key Metrics to Track

Metric	Target	Danger Zone
Inbox placement rate	> 95%	< 85%
Hard bounce rate	< 0.5%	> 2%
Complaint rate	< 0.05%	> 0.1%
Open rate (transactional)	> 80%	< 60%
Spam trap hit rate	0%	Any > 0
DMARC alignment rate	> 99%	< 95%

The Deliverability Feedback Loop

Send Email
    │
    ├──▶ Delivered ───▶ Opened ───▶ Clicked ───▶ Reputation ↑
    │
    ├──▶ Bounced ───▶ Suppress ───▶ Clean List ───▶ Reputation stabilized
    │
    └──▶ Complained ───▶ Immediate Suppress ───▶ Reputation ↓↓

Every outcome feeds back into your sender reputation. The goal is to maximize the first path while minimizing the second and third.

How Senviok's Architecture Solves Deliverability

1. Tenant-Isolated Queues

On shared-IP email services, your transactional emails share a sending pipeline with every other tenant. If another tenant launches a spam campaign, the shared IP's reputation drops, and your OTPs land in spam.

Senviok implements per-tenant queue isolation. Each workspace gets dedicated queue partitioning:

Your sending speed is unaffected by other tenants' volume
Your IP reputation is not contaminated by other tenants' behavior
Rate limiting is enforced per-workspace, not globally

2. Smart Provider Routing

Senviok maintains relationships with multiple delivery providers and routes messages based on:

Recipient domain — Gmail-bound messages go through SES's Gmail-optimized pathway; Outlook-bound messages through a separate optimized route
Message type — Transactional vs. marketing traffic is separated to prevent marketing volume from affecting transactional deliverability
Provider health — If a provider is experiencing degraded delivery, Senviok automatically failover to the next provider

3. Real-Time Suppression Management

When Senviok detects a hard bounce or complaint, the address is immediately added to a workspace-level suppression list. This prevents:

Re-sending to addresses that have already bounced
Accidentally re-engaging users who complained
Wasting quota on undeliverable addresses

The suppression list is accessible via the dashboard and the /v1/suppressions API endpoint.

4. Built-In Authentication Verification

Before you send your first email, Senviok validates your DNS records and confirms SPF, DKIM, and DMARC alignment. If any record is misconfigured, the dashboard shows a clear diagnostic:

Domain: yourdomain.com
  ✅ SPF:    PASS (aligned with amazonses.com)
  ✅ DKIM:   PASS (senviokdomainkey.yourdomain.com)
  ✅ DMARC:  PASS (p=none; rua configured)
  ⚠️ DMARC:  Policy is 'none' — consider upgrading to 'quarantine' after warming

Quick-Start: Improve Your Deliverability Today

Checklist

☐ Configure SPF, DKIM, and DMARC records (see our DNS setup guide)
☐ Warm your sending domain over 30 days
☐ Send to engaged users first during warming
☐ Monitor bounce and complaint rates weekly
☐ Set up Senviok webhook events for real-time delivery tracking
☐ Review the Activity Logs dashboard daily during the first month

Getting Started with Senviok

Senviok handles authentication verification, bounce processing, suppression management, and deliverability monitoring out of the box. The free tier includes 3,000 emails/month with full access to all deliverability tools.

Questions about your deliverability? Reach us at support@senviok.live or open a conversation in your dashboard.

Email Deliverability in 2026: The Complete Technical Guide