Skip to content
CyberTemp
All posts
How to Test Email Deliverability Before You Ship a Signup Flow

How to Test Email Deliverability Before You Ship a Signup Flow

CyberTemp5 min read

Your signup flow works in staging. The welcome email sends, the test passes, you ship. Three weeks later a support ticket says the verification email never arrived — it was sitting in a spam folder, or it never left your provider's queue at all. Deliverability bugs don't show up in a green CI run. They show up as silent account-creation failures, and by the time anyone notices, it's already cost you signups.

Testing that an email sends and testing that an email arrives, readable, in the inbox are different problems. The first is a unit test. The second needs a real inbox on the other end — several of them, ideally on different domains, so you can see how your mail actually behaves once it leaves your servers.

What actually breaks deliverability

Most teams find out about deliverability problems from a user, not from a test. The failure modes are specific enough to check for directly:

  • SPF/DKIM/DMARC misconfiguration. A new sending domain, a changed mail provider, or a forgotten DNS record after a migration — any of these can silently downgrade your mail to spam or get it dropped outright.

  • Spam-trigger content. Subject lines with excessive punctuation, link-shorteners, or a text-to-image ratio that looks like a phishing template. Filters score this even when your sending reputation is clean.

  • Provider-specific throttling. Mail that lands fine at one provider can get rate-limited or delayed at another, especially right after a burst of signups from a new marketing push.

  • Broken verification links. A staging URL that leaked into a production template, or a token that expired before the email even sent. The email arrives, but the flow it's supposed to complete doesn't.

None of these show up in a "did the API call return 200" test. You need to actually read the email that lands.

Build a deliverability check with disposable inboxes

The pattern is simple: generate a handful of throwaway addresses across different domains, trigger your signup or notification flow against each one, then read what actually arrives. CyberTemp's API is built for exactly this — one call creates the inbox, the same call reads it back.

GET /getDomains lists which domains are currently available, so you can spread test addresses across more than one instead of hammering a single domain (which tells you less about real-world variance):

import httpx

API_KEY = "tk_..."
HEADERS = {"X-API-Key": API_KEY}
BASE = "https://api.cybertemp.xyz"


domains = httpx.get(f"{BASE}/getDomains", headers=HEADERS).json()

Then trigger your app's signup flow against a generated address on each domain, and poll for the result:

import time


def wait_for_mail(email, timeout=60, interval=3):
deadline = time.time() + timeout
while time.time() < deadline:
r = httpx.get(f"{BASE}/getMail", headers=HEADERS, params={"email": email})
messages = r.json()
if messages:
return messages[0]
time.sleep(interval)
return None


test_email = f"deliver-check-{domains[0]}"
result = wait_for_mail(test_email)

GET /getMail?email=<address> also creates the inbox on first read, so there's no separate setup step. Run this against every domain you have available, and you get a real picture of where mail actually lands cleanly and where it doesn't — instead of finding out from a support ticket.

What to check once the message lands

Getting a message back is only the first signal. Once it arrives, check three things:

1. Time to delivery

Note the gap between trigger and arrival for each domain. A consistent few-second delay is normal. A gap that's wildly different across domains — or one domain that never delivers at all inside a reasonable window — is worth investigating before your real users hit it.

2. Raw headers

If your provider exposes SPF/DKIM/DMARC pass-fail status in the message headers, check it on every test send. A misconfigured DNS record after a domain migration is the single most common cause of "the email just stopped arriving" tickets, and it's invisible unless you're actually inspecting headers instead of just confirming a message exists.

3. Link and token validity

Click through the verification link in the test message (or curl it) and confirm it resolves against the environment you meant to test. Staging URLs leaking into production templates is a recurring, boring bug that a deliverability check catches for free, since you're already opening the message.

This is the same discipline behind testing transactional emails without a real inbox — the difference here is you're checking arrival and formatting across multiple domains, not just verifying that a receipt or password reset contains the right content.

Wiring it into CI

A deliverability check is only useful if it runs before a bad deploy reaches production, not after a user reports it. The same pattern from wiring CyberTemp into signup-flow tests applies here — add a job that runs on every deploy to a staging environment:

  • Generate 3-5 addresses across different available domains.

  • Trigger the signup or notification flow against each.

  • Poll and assert a message arrives inside a fixed timeout window.

  • Fail the build if any domain times out, or if headers show an SPF/DKIM failure.

This is a small addition next to functional tests, but it catches a category of bug that functional tests structurally can't see, because the failure happens after your server has already returned success. For teams already doing OTP-focused testing, this pairs naturally with the pattern in OTP test automation with the CyberTemp API — same polling loop, different thing you're checking for once the message lands.

Bottom line

Deliverability bugs are invisible until a real inbox on the other end tells you otherwise. A quick script against a handful of disposable addresses on different domains, run on every deploy, turns "a user told support the email never came" into a failed build you catch before it ships.

If you're scripting this kind of check — deliverability testing, signup-flow QA, multi-domain verification — the paid tiers raise the per-key request limits so a CI job hitting several domains on every deploy doesn't bump into a rate ceiling. Sign up if that's the case for your team.

Share