Deliverability

Getting mail into the inbox.

What qwicmail does for you, what you need to configure, and how to keep your reputation clean over time. This page is opinionated — the practices below are what we apply to our own operations.

What qwicmail does for you

Curated IP pool. All tenants share IPs that are warmed, monitored, and isolated from bulk newsletter traffic. We run the engine ourselves on Hetzner — no third-party MTA reputation mixed in.
DKIM signing with a fresh 2048-bit RSA key per domain. Keys are generated at POST /domains; you only publish the public half as a TXT record.
VERP envelope-from on bounces.qwicmail.com so every DSN can be correlated back to the exact message — that's how the bounce processor builds your tenant suppression list.
MTA-STS policy advertised for qwicmail.com, with strict mode honoured for the recipient domains that advertise it.
TLS by default with opportunistic upgrade, plus strict verification against published MTA-STS policies.
Bounce + complaint processing via inbound DSNs and ARF feedback loops. Suppressions are added automatically — you don't write that logic.
Reputation monitoring. Rolling 24-hour bounce and complaint ratios; auto-throttle if they cross our thresholds, auto un-throttle after 7 days of clean sending.
Tier escalation on a 14 / 30-day curve so new tenants ramp without scorching their reputation.

What you need to do

1. Publish your DNS records

Three TXT records per sending domain. The exact values are printed on the domain page in the portal (and returned by POST /domains); patterns are below.

DKIM — required

NAME:  qm202605._domainkey.mail.example.com
TYPE:  TXT
VALUE: v=DKIM1; k=rsa; p=<public-key>

The selector (qm202605 here) rotates over time; the portal is always the source of truth for the current value. Without this record your domain will not verify and we will refuse to send for it.

SPF — recommended

NAME:  mail.example.com
TYPE:  TXT
VALUE: v=spf1 include:qwicmail.com ~all

Important: a domain may only have one SPF record. If you already publish SPF (because you also send through Google Workspace, Microsoft 365, or another service), merge include:qwicmail.com into the existing record — don't add a second.

DMARC — recommended

NAME:  _dmarc.mail.example.com
TYPE:  TXT
VALUE: v=DMARC1; p=none; rua=mailto:dmarc-reports@qwicmail.com

Start in monitoring mode (p=none) so you can see who's sending as your domain without rejecting anything. Once you've watched the aggregate reports for a couple of weeks and confirmed only qwicmail is signing your mail, tighten to p=quarantine and then p=reject. This is the single biggest lever for protecting your brand from spoofing.

2. Use a subdomain for transactional mail

Send from a dedicated subdomain (mail.example.com, send.example.com) rather than your apex (example.com). Two reasons:

Reputation is isolated from your apex mail traffic — a bad sending run on transactional doesn't hurt your CEO's inbox deliverability.
You can tighten DMARC on the subdomain to p=reject much sooner than on the apex, because the surface is smaller and you control every legitimate sender on it.

3. Keep your lists clean

Transactional senders should already have it easy here — you're sending to people who just signed up, just bought something, or just asked for a password reset. But the basics still matter:

Don't retry hard bounces. The platform suppresses them automatically; if your code tries to send to a suppressed address it's a no-op, but persistent attempts inflate your bounce ratio across our metrics.
Honour unsubscribes within hours, not days. We respect one-click List-Unsubscribe automatically; if you also operate your own unsubscribe link, sync it into the suppression list.
Confirm email addresses at the point of capture (double opt-in is ideal; a confirmation email is the minimum). Bad data caught at signup never reaches your queue.

4. Send what you signed up to send

qwicmail is a transactional service — receipts, login codes, notifications, alerts. We're not the right tool for marketing newsletters, and our acceptable use policy reflects that. Mixing the two will get your tenant throttled and, in clear cases, suspended. If your use case has drifted toward bulk marketing, talk to us first.

Warm-up and sending tiers

Every new tenant starts on a conservative 24-hour sending cap. Tiers relax automatically:

Day	24-hour cap	What changes
0–13	1,000 messages	Initial warm-up tier. Plenty for staging + early production.
14–29	10,000 messages	Auto-promoted if bounce + complaint ratios are clean.
30+	uncapped	Auto-promoted if ratios stay clean.

"Clean" means bounce ratio under 5% and complaint ratio under 0.1% on a rolling basis. Tiers don't promote if a tenant has been auto-throttled in the lookback window — the clock effectively resets.

Auto-throttle

Rolling 24-hour metrics are computed per tenant. If your bounce ratio exceeds 10% or your complaint ratio exceeds 0.3%, the tenant is throttled: new sends are rejected with 403 tenant_not_active until the ratios recover (and at least 7 days have passed). The reason is visible in the portal — you'll see why you were throttled, not just that you were.

Throttle is not a punishment; it's a circuit breaker. The most common trigger is a list-quality regression (a stale signup capture, a re-engagement campaign sent to old addresses). Identify the source, stop sending to it, wait out the window.

What recipients see

From: exactly what you set ("Receipts <receipts@mail.example.com>").
Return-Path: a VERP address on bounces.qwicmail.com. This is normal and is what allows us to correlate bounces back to your message — it does not affect inbox placement.
DKIM-Signature: signed by your domain's qwicmail-managed key.

A "via qwicmail.com" indicator may appear in Gmail's UI until the From-domain DMARC policy aligns. Once you're at p=quarantine or stricter the indicator goes away.

Gmail and Yahoo bulk sender rules

If you'll cross 5,000 messages/day to Gmail recipients (or any volume to Yahoo), the bulk-sender rules (effective 2024) require:

SPF and DKIM aligned to the From domain — qwicmail handles DKIM; you publish SPF.
DMARC published with at least p=none — see above.
One-click List-Unsubscribe in the headers — added automatically for marketing-like traffic; not added to pure transactional sends.
Complaint rate below 0.3% — enforced by our auto-throttle.

Following this guide end-to-end satisfies all four.

When things go wrong

The fastest path to diagnosis:

Open the portal → Sending → Messages. Search for the message_id. The event timeline shows accepted → queued → delivered (or the bounce / failure with the SMTP code and the receiving server's diagnostic).
If many messages are failing the same way, the Reputation panel will show the rolling ratios and any active throttle.
For everything else, email support with the message ID — there's an operator behind the address.