Skip to content
Norbelys
Esc
↑↓navigate↵open⌘Jpreview
On this page

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 or JSON imports trim the whitespace around an address and keep it as written. Addresses are compared ignoring ASCII case over the whole address; dots, plus addressing and the local part’s spelling are never folded. 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.

Suppressions and holds are kept by address, apart from people: deleting a person or importing the address again never clears them. A hold (mailbox_full, greylisted, no_route) is temporary and separate from a suppression. GET /v1/suppressions?email= tells whether an address is suppressed, why and by what source.

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

Evidence suppresses an address on its own: an unsubscribe, an authenticated bounce or complaint, or a notice in a receiving mailbox (an address change, a closed account) once a person confirms its review. The suppression keeps its reason (unsubscribe, bounce, complaint, address_changed, account_closed, no_mail_service) and the source of the evidence. To apply feedback you received elsewhere, use POST /v1/suppressions: email for one address, or emails for up to 1,000 in one call, answered with how many were suppressed, how many were already, and each entry that is not an address. The reason of a suppression you add is always manual. Norbelys checks suppressions again before each submission begins. Suppressing stops every live enrollment of the address and cancels its queued message, in the same transaction. Only a manual suppression can be lifted (DELETE /v1/suppressions/{id}), and lifting it never restarts work that ended. 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.

Was this page helpful?