Delivery and DNS
Every email has a journey. You see all of it.
From the click on “Send” to the recipient's mailbox, every step is recorded, explained in plain words and kept for 90 days. And the DNS of your domain — MX, SPF, DKIM, DMARC, MTA-STS — is generated and checked by the platform.
The journey of a sent email, in five stages
Send
From the webmail or your mail client, on 465 or 587. The sender is always the authenticated user: nobody sends on someone else's behalf.
Outbound checks
Antivirus and antispam on what leaves too, to stop sending from a compromised account.
DKIM signature
One key per domain, stored encrypted. SPF and DKIM verified live.
IP pools
Separate addresses per type of traffic, warmed up gradually, with limits per destination provider.
Delivered
The status in the webmail; in the panel the full journey, for 90 days, with export.
01 — Where it went
Every email's status, in the webmail and in the panel.
Senders see “Delivery status” in every sent message and, with one click on “Why didn't it arrive?”, get the explanation. Administrators see the journey of every message, inbound and outbound, step by step.
- In the webmail. The delivery status sits inside the sent message: no need to open the panel or ask anyone.
- “Why didn't it arrive?” The answer is computed from system data in about 0.3 seconds, with no AI model at all. How the assistant works.
- In the panel. Inbound and outbound tracking with every step, kept for 90 days and exportable.
Four outcomes, in the application's own words
Delivered
The message was delivered.
Pending
The recipient’s server asked to try again later: it is a temporary problem.
Bounced
The recipient’s address does not exist. Check that it is spelled correctly.
Blocked
The message was blocked because it looked like unwanted mail (spam).
02 — DNS
DNS without the effort.
For every domain the platform generates the records, checks them every 6 hours on the authoritative nameservers and, if the domain is on Cloudflare, applies them for you after a preview of the changes. What you see is a table turning green.
| Record | What it is for | Status |
|---|---|---|
| MX | Where the domain's mail arrives | Not checkedOK |
| SPF | Who may send on behalf of the domain | Not checkedOK |
| DKIM | The signature on outgoing messages | Not checkedOK |
| DMARC | What to do when SPF or DKIM don't match | Not checkedOK |
| MTA-STS | The domain's TLS policy, hosted by the platform | Not checkedOK |
| TLS-RPT | Where to receive TLS reports | Not checkedOK |
| Autodiscover and autoconfig | Automatic configuration of mail clients | Not checkedOK |
| SRV | Where to find calendars, contacts and configuration | Not checkedOK |
The labels are the panel's own: “Not checked”, “OK”, “Missing”, “Different”.
- Proof of ownership of the domain, before it is activated.
- Records generated and checked every 6 hours on the authoritative nameservers.
- Automatic fixes on Cloudflare, with a preview of the changes before they are applied.
- If an SPF record already exists, the platform proposes the merged record, not a replacement.
- A hosted MTA-STS policy for every verified domain: MTA-STS supported.
- “Sender-only” domains for those who send without mailboxes.
Todayv=spf1 include:crm.example ~all
Proposedv=spf1 include:crm.example include:_spf.mail.example ~all
03 — Outbound
Signed, consistent, warmed up carefully.
A domain's reputation is built on details: one signature per domain, a consistent identity on every connection, and addresses brought into service gradually.
One DKIM signature per domain
Every domain has its own key, and private keys are stored encrypted. SPF and DKIM are verified live on outgoing mail.
Consistent identity, warmed-up IPs
Consistent PTR and HELO. Address pools per type of traffic, gradual warm-up of new IPs and limits per destination provider.
Outbound goes through the antispam too
Outgoing mail goes through the antispam and the antivirus too, to stop sending from a compromised account before it leaves.
04 — Email Delivery
Email Delivery, for the mail your applications send. Preview, on request
A separate channel for transactional email and, with stricter rules, for marketing email. Today it carries the platform's own system mail; we open it to customers on request, as a preview.
Transactional
- HTTP API and authenticated SMTP
- Keys per stream and verified sender domains
- Idempotency keys and suppressions
- Events, statistics and HMAC-signed webhooks
- Gradual ramp-up for new customers
Marketing
- One-click unsubscribe (RFC 8058), with a mandatory visible link
- DMARC required on the sender domain
- Suppression per list
- No open-tracking pixel
- Clicks tracked only with consent
Want to see tracking live?
A walkthrough of the panel: the journey of a real email, the DNS of one of your domains, and the questions you really ask.
Write to info@qmail365.com