Deliverability and sending policy

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.

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.

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.