--- title: Deliverability and sending policy description: Authentication, consent, suppression, shared limits, and evidence to check before increasing volume. --- A successful SMTP submission does not guarantee delivery or inbox placement. Norbelys records submission outcomes, ingests replies and delivery reports by IMAP, and provides workspace suppression. Your mail provider and recipient provider determine delivery. ## Validate recipients before sending People creation, updates, and CSV/JSON imports trim surrounding email whitespace and lowercase the ASCII domain. Dots, plus addressing and local-part spelling are preserved. Norbelys never silently substitutes a guessed address. `POST /v1/people/validate` accepts `{"emails":["person@example.com"]}` in batches of 1–100 and sends no mail. Results include `reachable`, `invalid` or `unknown`, a reason, and Unix-millisecond check/expiry timestamps. Reachable means DNS routing exists; it does not verify a mailbox or consent. The production sender repeats preflight when cached evidence expires, for To, CC and BCC. Null MX, nonexistent domains and missing mail routes stop submission. DNS outages defer the message without spending quota or reporting a bounce. MX absence is allowed when A/AAAA supplies an implicit mail route. People exposes read-only `status` and `delivery.can_send`. `Held` with `reason=mailbox_full` is a temporary capacity hold, separate from suppression. Its review date does not automatically resume sending. `Invalid` means preflight failed, without a delivery attempt. Final bounces remain `Bounced`; unsubscribe and complaint exclusions always take precedence. Re-importing never clears these protections. `suppressed=false` alone is not an eligible-audience filter. ## Authenticate the sending domain Publish one SPF record that includes every authorized sender, a DKIM key with a selector, and one DMARC record. Check that the visible From domain aligns with SPF or DKIM. A dedicated, fully inventoried domain can use SPF `-all` and DMARC `p=reject`; for a migration, inspect aggregate reports before enforcement so legitimate providers are not blocked. Keep public A and provider-managed PTR records consistent with the SMTP hostname and use TLS. Google requires SPF or DKIM for all senders to personal Gmail, and SPF, DKIM and DMARC for bulk senders. Marketing/subscription messages must support easy opt-out; bulk senders need one-click unsubscribe. Google recommends keeping reported spam below 0.1% and avoiding 0.3% or higher. These are provider requirements, not a promise of placement. [Google sender guidelines](https://support.google.com/a/answer/81126?hl=en). Norbelys adds `List-Unsubscribe` and `List-Unsubscribe-Post`, plus a visible opt-out link. Your SMTP provider must include both headers in its DKIM signature. Confirm this in an externally received message. The recipient link uses the public API origin configured by `UNSUBSCRIBE_BASE_URL`; use HTTPS in production. GET is a confirmation page, and POST applies workspace-wide suppression. These links remain usable while the message and the encryption key needed to authenticate them are retained. ## Send to people who expect your message Use explicit permission or an existing, appropriate relationship. Keep the source and purpose of the recipient's permission. Do not buy scraped lists, fabricate identities, or use additional aliases to evade sending limits or reputation controls. Identify the sender clearly, keep subjects accurate, and include useful plain-text content alongside HTML. Remove recipients who complain, hard bounce, or opt out. A catch-all creates receiving addresses, not consent and not additional sending capacity. Shared-domain identities use one mailbox's daily allowance. Rotate the domain's SMTP secret if it is exposed; do not embed an operator provisioning API key in a client application. ## Suppression and operational limits Use `POST /suppressions` with an email and `reason` of `Unsubscribe`, `Bounce`, `Complaint`, or `Manual` for verified external feedback. Norbelys checks suppression before SMTP begins. A verified `Bounced` event with a final 5.x status (or a trusted provider bounce without a status code) suppresses future sends. This includes final full-mailbox and policy bounces; `Bounce` records a failed delivery, not proof that the address cannot ever recover. Temporary 4.x delays, `Rejected` provider blocks and unverified ARF reports do not automatically suppress it. Suppression immediately stops all active sequences for that contact and marks queued messages `Suppressed`. People expose the corresponding read-only `Bounced`, `Unsubscribed`, `Complained` or `Suppressed` status. Removing the suppression never restarts terminated work. A previously started SMTP transaction can still complete while an opt-out is being recorded. Start with a low `daily_limit`, use a steady cadence, and expand only after real recipient feedback. Changing a From local part does not reset IP or domain reputation. SMTP throttles produce temporary failures and retries; do not create another identity to bypass them. A mailbox's `daily_limit` is a UTC-day cap; an SMTP token-bucket rate limit can allow a burst plus gradual replenishment, which is a different control. `Sent` means that your SMTP server accepted the message. A remote rejection may arrive later as a delivery report. Use `GET /messages/{id}` (`delivery`) for submission attempts and transport observations, and `GET /mailboxes/{id}` (`health`) for seven days of evidence. `delivered` records the next server's acceptance; `inbox_placement` stays `unknown`. Google Postmaster Tools supplies aggregate reputation and feedback, not universal per-message spam placement. Norbelys includes a stable campaign-level `Feedback-ID`; the SMTP provider must DKIM-sign it, and an operator must separately enroll in the provider's feedback program. See [Inbox and delivery feedback](/inbox-feedback). Opens can come from image proxies and privacy tools; clicks can come from security scanners. Neither proves a human read the message. ## Preflight checklist - Confirm domain ownership, SPF, DKIM, DMARC, forward/reverse DNS, and TLS. - Use the intended workspace and a domain-authorized SMTP credential. - Activate the custom tracking domain before publishing campaign steps. - Confirm the message uses the intended From identity and HTTPS tracking hostname. - Verify opt-out without touching real recipient preferences: use an owned test address. - Send one requested test, inspect external authentication results, and pause its campaign. - Review queue age, bounces, complaints, opt-outs, storage, certificate expiry and backups before increasing traffic. A single VM and a shared IP are an internal starting point. Customer isolation, provider feedback loops, aggregate quotas across connections, high availability and automated reputation monitoring need additional operational capacity before offering unrestricted public sending.