Security and responsible sending
Know the safeguards around your email.
How RouteKite handles workspace access, API credentials, sender authentication, suppression, marketing preferences, message previews, and responsible sending.
Reviewed October 4, 2026
Access stays tied to a workspace
Workspace membership, roles, and API scopes determine which actions a person or integration can perform. RouteKite checks access on the server rather than relying on a hidden control in the interface.
- API credentials
- Keys use the rk_ prefix, have a workspace and permission scope, and are stored with an authentication hash plus an encrypted copy. Revealing a key requires recent reauthentication and records an audit event. Revoke and replace a compromised key.
- AI connections
- A hosted MCP connection is authorized for one member, one workspace, and Read or Manage access. Supported changes preview before confirmation. Connections can be revoked from Developers in the dashboard.
- Privileged administration
- Platform administration requires authorized administrator access and multifactor verification. Administrators cannot reveal customer API keys.
- Signed delivery webhooks
- Outbound delivery notifications are signed. Verify the signature and request timestamp in your receiving application before using an event.
Authenticate the sender
Verify a sending domain and publish the exact DNS records RouteKite provides. Domain Overview shows authentication findings, while DNS Records contains the values to add with your DNS host.
RouteKite checks DKIM, SPF, DMARC, and the custom return-path configuration. A manual Check DNS refresh reports the current findings, including an explicit result when a record cannot be checked. Sender authentication supports trustworthy sending but does not guarantee inbox placement.
Keep the sender identity accurate, use a monitored reply address, and review your domain's authentication when you change DNS. Follow the sending guide for the setup order.
Respect the recipient's current state
Marketing permission, topic preferences, unsubscribes, and suppression are checked when the audience is prepared and again before submission. A saved list never overrides a current sending block.
Marketing templates retain their compliance footer. Global unsubscribe and topic preferences stay distinct, so opting out of a topic does not silently become permission for another send. Bounce, complaint, and manual suppressions prevent further submission to blocked addresses.
Campaign analytics defaults to Off. Enabling open and click tracking requires a sender confirmation before launch. When collected, observed engagement is classified to help separate likely human activity from known proxies and automated requests; it is still an estimate.
Review content before a real send
RouteKite sanitizes supported email HTML and uses sandboxed previews. Published template versions and campaign recipient snapshots keep the content and audience used for a send distinct from later edits.
A design preview helps you inspect the message. A preview email is a real delivery and uses the sending safeguards and allowance. RouteKite does not currently provide built-in inbox rendering tests, saved-content link or image checks, or spam-content scoring.
Delivered means the recipient server accepted the message. It does not establish which folder received it or whether someone read it. Read the Submitted versus Delivered guide when investigating an outcome.
Report a security or abuse concern.
Contact support@routekite.com with the affected public URL, approximate time, and a description of the issue. Do not send credentials, payment details, or another person's message content.