Email Protection Guide

If a term is unfamiliar, open the Glossary.

This guide explains what Email Protection does today, how your team can submit messages for review, what the workspace shows, and how to follow through with remediation.

Workspace: #/email-protection

The route now opens on an Overview first screen, then separates the workflow into Setup, Compose, Analysis, Policy, and Remediation sections.

Overview also shows recent Email Protection messages for the workspace, so operators can reopen a previous analysis without resubmitting the original sample.

Recent message history also shows a mailbox-action badge. The badge tells operators whether a stored message is already retract eligible, needs support enablement, has a provider map, or is not mailbox mapped.

Overview now stays summary-first. It shows operator lanes, workspace metrics, recent messages, policy posture, and buttons that open the right working section.

The Setup section contains Email setup, API relay, managed connector posture, and Integration readiness. Integration readiness shows which input methods are live now, which deployment patterns are connector-ready against the current API, which launch gates are ready or blocked, which items are still planned, and the current bounded message and attachment limits.

Overview also includes a Policy posture panel. It shows whether the workspace policy engine is enabled, whether automatic remediation is enabled, the live score thresholds, and which signal triggers are active.

Overview also includes Workspace metrics. This section uses the stored Email Protection history for the workspace to show recent message volume, action-needed pressure, click activity, policy-routing volume, and remediation trends across a bounded recent window.

Current live input methods:

• compose a message sample directly in the workspace
• submit a structured message payload through the Email Protection API with a signed-in workspace session or workspace API key
• paste a raw RFC822 message into the workspace or API
• upload one .eml file from the workspace
• include attachment files in the current workspace/API flow
• mark a submission as user reported so Dralvia keeps report context and checks recent workspace duplicates

Current live analysis outputs:

• sender-authentication summary from SPF, DKIM, DMARC, and ARC headers when that header evidence is available
• safe-link rewrite results
• safe-link click activity for rewritten links
• attachment detonation results
• BEC heuristics
• VIP impersonation summaries
• vendor impersonation summaries
• sensitive-data summaries
• campaign / blast-radius summary
• policy decision summary
• mailbox action eligibility for retract/quarantine
• EvidencePack (Dralvia's exportable evidence report) summary and download
• EvidencePack export
• workspace metrics and daily trends

Connector posture today:

• mail-gateway, journaling, and mailbox-ingest patterns are connector-ready or planned
• do not treat named vendor integrations as built-in unless Dralvia support has explicitly enabled and documented them for your workspace

Current connection status:

Connection path	Status	What this means today
Workspace compose and manual EML upload	Live	Submit a sample directly while signed in.
Email Protection API submission	Live	An active workspace session or workspace API key can submit structured, raw-email, or Base64 EML payloads.
API relay or transform step	Available now	Use a workspace API key and a customer-managed transform. Dralvia shows redacted relay history and recent safe errors.
Microsoft 365 / Outlook managed connector	Staged support-enabled pilot	Setup and safe sync-health UI are deployed. Direct mailbox collection remains unavailable unless Dralvia support enables the pilot after approved Graph runtime configuration. A guarded mailbox-action pilot is pending rollout and separate support enablement.
Google Workspace / Gmail managed connector	Staged support-enabled pilot	Setup and safe watch/history-health UI are available for approved workspaces. Direct mailbox collection remains unavailable unless Dralvia support enables the pilot after restricted Gmail scope approval and approved Google runtime configuration.
Generic company email relay	Connector-ready	A secure upstream transform can submit to the current analysis path. A built-in SMTP receiver is not live yet.

Remediation in the workspace records queued actions and their audit history. It does not currently execute changes inside Microsoft 365, Google Workspace, or another mailbox provider.

Each remediation also carries a rollback note in its audit trail. The note says whether the action can be reversed and how to undo it if it was applied to a false positive (for example releasing a quarantined message, or restoring a deleted message from Deleted Items while it is still in retention). Forwarding is flagged as not reversible once sent.

Email setup

Open #/email-protection, then open the Setup section. The setup cards answer what you can use now and what remains planned:

Setup card	Status	Next step
Microsoft 365 / Outlook	Staged support-enabled pilot	Use API relay or manual upload unless Dralvia support has enabled your read-only pilot. Guarded mailbox actions require a separate rollout, permission upgrade, and support enablement.
Gmail personal	Staged support-enabled pilot	Connect one personal Gmail mailbox with read-only sign-in. No workspace domain is needed. Activation completes once Dralvia support confirms restricted Gmail scope approval. Do not submit Gmail tokens to Dralvia.
Google Workspace / Gmail	Staged support-enabled pilot	Use API relay planning or manual upload unless Dralvia support has enabled your read-only pilot. Do not submit Gmail tokens, service-account keys, or delegated credentials to Dralvia.
API relay	Available now	Create or rotate a workspace API key, send a setup test, then connect your customer-managed transform.
Generic company email	Connector ready	Start with an upstream gateway, journaling, or forwarder transform that submits through the current payload contract. A built-in SMTP receiver is not live yet.
Manual upload	Available now	Open Compose and submit structured fields, raw RFC822 text, or one EML file.
Gmail / Yahoo / IMAP (app password)	Available now	Connect a mailbox with an app password (Gmail, Yahoo, iCloud, Outlook, or a custom IMAP host). Dralvia validates the login, pulls recent mail for analysis (historical scan), and can keep monitoring incoming mail. See the app-password walkthrough below.

The Setup cards group into Available now, Support enabled, and Planned so you can see what to use today and what is still planned.

Each card states the connection type, permissions, data Dralvia reads, data Dralvia stores, current activity or error posture, next action, and the setup guide link. The API relay panel also shows the endpoint, header guidance, examples, a copyable curl command, a signed-in test-send action, current limits, recent safe outcomes, and recent safe errors.

Integration readiness also shows Client setup options. Use that matrix to choose the path before starting setup:

Client setup path	Status in the matrix	Client action
API relay	available_now	Send the signed-in setup test, then connect a workspace API-key transform.
Generic company email	connector_ready	Choose the upstream relay path and submit copied messages through API relay.
Manual upload	available_now	Open Compose for structured fields, raw RFC822 text, or one EML file.
IMAP app password (Gmail, Yahoo, iCloud, Outlook, custom)	available_now	Connect a mailbox with a provider app password, then run a historical scan and optionally enable monitoring.
Microsoft 365 read-only pilot	deployed_support_disabled	Use only after Dralvia support enables the approved Graph runtime for your workspace.
Microsoft 365 mailbox actions	deployed_support_disabled	Keep actions disabled unless support enables the guarded pilot and every action is explicitly approved.
Google Workspace read-only pilot	implemented_locally_support_disabled	Use only after restricted Gmail scope approval and Dralvia support runtime enablement.
Gmail personal	implemented_locally_support_disabled	Connect one personal Gmail mailbox with read-only sign-in. Activation completes after restricted Gmail scope approval and Dralvia support runtime enablement.

The integration-readiness contract also returns a self_serve_onboarding block that distills this into one view: a summary, a recommended_first_step, an available_now list of what you can use today with no support enablement, and a limitations list of what still needs Dralvia support or external approval. Each limitation carries a status (support_gated, external_approval_gated, or business_gated) and an owner, so a new workspace can start immediately and see exactly which capabilities are not self-serve yet.

Integration readiness also shows Launch readiness gates. Use this panel before client rollout:

Launch gate	Current status	Client action
API relay and manual upload	Ready	Use Setup, Compose, raw email, EML upload, or Analysis now.
Microsoft 365 managed ingestion	Blocked until support enablement	Request enablement with selected mailbox details and run the read-only setup test after support enables the runtime.
Microsoft 365 retract and quarantine	Blocked until support enablement	Request mailbox-action enablement before retracting or quarantining Microsoft-mapped messages.
Google Workspace managed ingestion	Blocked until provider approval and support enablement	Use relay or manual upload until restricted-scope approval and runtime enablement are complete.
Pricing and quota packaging	Blocked until commercial approval	Confirm plan packaging before treating managed ingestion or mailbox actions as self-serve.

Do not include provider tokens, secrets, raw provider message IDs, opaque cursors, client-state hashes, or raw IP addresses in launch requests.

Connect a mailbox with an app password (available now)

This is the fastest self-serve way to protect a real mailbox today. It works with Gmail, Yahoo, iCloud, Outlook.com, or any custom IMAP host, and does not need any Dralvia support enablement. You give Dralvia a provider app password (not your normal login password), which Dralvia stores encrypted and uses only to read mail for analysis.

What it does once connected: Dralvia validates the login, can run a historical scan of recent mail, and can keep monitoring incoming mail. Use a read-only or mail-scoped app password; Dralvia never needs your account password.

Steps:

1. Turn on two-factor authentication on the mailbox (providers only issue app passwords when 2FA is on).
2. Create an app password in your mail provider:
   • Gmail: Google Account, Security, 2-Step Verification, App passwords.
   • Yahoo: Account Security, Generate app password.
   • iCloud: Apple Account, Sign-In and Security, App-Specific Passwords.
   • Outlook.com: Security, Advanced security options, App passwords. Copy the generated password (it is shown once).
3. In Dralvia, open #/email-protection, go to Setup, and choose Gmail / Yahoo / IMAP (app password).
4. Pick the provider (Gmail, Yahoo, iCloud, Outlook, or Custom), enter the mailbox address and the app password. For a custom provider, also enter the IMAP host and port (most use port 993). For the common providers Dralvia fills the host for you (imap.gmail.com, imap.mail.yahoo.com, imap.mail.me.com, outlook.office365.com), all on port 993.
5. Submit. Dralvia tests the login. On success the mailbox shows as connected; on failure you get a plain reason (for example wrong app password or the server could not be reached) and nothing is stored.
6. Run a historical scan (backfill) to analyze recent mail, and optionally turn on monitoring for incoming mail.

API equivalent: POST /email/connectors/<connector_id>/imap/connect with { "imap_kind": "gmail", "mailbox_address": "[email protected]", "app_password": "<app password>", "folder": "INBOX" } (add imap_host and imap_port for a custom provider). Then use the connector backfill and monitoring endpoints.

Limitations: revoke the app password in your provider to disconnect at any time. This path reads mail for analysis; provider-side retract/quarantine execution is part of the managed Microsoft 365 path, not the app-password path.

Managed connector rollout note

Dralvia is adding provider-neutral connector lifecycle state as an internal rollout foundation. This does not make Microsoft 365 or Google Workspace mailbox collection live. Do not submit provider access tokens, refresh tokens, client secrets, passwords, or private keys through Email Protection APIs.

When Dralvia support enables a managed connector pilot for your workspace, credential setup uses an external secret reference and the lifecycle records remain scoped to your workspace. Disconnect removes the local secret reference, disables mailbox bindings, and records an audit event. Provider authorization revocation and mailbox-side actions remain provider-specific rollout steps.

The staged Microsoft 365 read-only pilot records one-time authorization state, checks that the returning Microsoft directory matches the requested directory, allows one reported or shared mailbox, and requires mailbox-scope validation before the connection can become healthy. The pilot requests read access only. The general connector lifecycle cannot skip that validation step. Direct mailbox collection is not available unless Dralvia support has enabled and documented the pilot for your workspace.

Connection self-check before remediation goes live

Before any automated mailbox remediation is enabled, Dralvia runs an end-to-end connection self-check against your connector. The self-check sends one synthetic probe message through the exact analysis path a real message uses, confirms it produces a verdict, and confirms the message becomes eligible for remediation — all in-process. It never performs a real mailbox action on its own: the remediation path stops at a dry-run preview unless a validated, approved provider executor is explicitly supplied during the owner-run live step. This means a connector's ingest → verdict → remediation pipeline is proven healthy before it is trusted with a live action, and the check itself cannot change anything in your mailbox.

When support enables the staged Microsoft 365 pilot, the Email setup section shows a Microsoft 365 read-only panel. A workspace admin can create the setup, enter the Microsoft directory ID, open admin consent, select one reported or shared mailbox, test read-only access, and refresh connector health without making direct API calls.

The panel also shows Microsoft runtime preflight. This tells you whether Dralvia support has configured the required Graph runtime pieces: credential reference, mailbox scope checker, subscription provisioner, delta runner, and subscription renewer. If the preflight is blocked, use API relay, generic relay, manual upload, or EML upload instead of relying on direct Microsoft mailbox collection.

The panel shows setup steps, the selected mailbox, sync lag, subscription timing, lifecycle state, recent safe connector events, and safe errors. When Microsoft reports that authorization must be renewed, the panel presents a Reauthorize Microsoft 365 action. A workspace admin can also disconnect the connector from the panel after confirmation. Disconnect disables collection and offers a fresh read-only setup path for reconnecting.

The staged Microsoft 365 pilot also uses webhook notifications as sync hints and repairs missed notifications with scheduled reconciliation. Connector detail can expose safe notification, renewal, lifecycle, lag, and error posture. The Microsoft 365 panel shows that safe health posture after support enables the pilot. It does not expose authorization state, mailbox cursors, or provider credentials. This remains unavailable unless Dralvia support has enabled and documented the pilot for your workspace.

The staged Google Workspace read-only pilot records one-time OAuth state, requests approved read-only Gmail scope, stores only an external secret reference, allows one Gmail user mailbox, and requires mailbox-scope validation before the connection can become healthy. The pilot rejects Gmail modify and full-mailbox scopes in read-only mode. Direct mailbox collection is not available unless Dralvia support has enabled and documented the pilot for your workspace.

When support enables the staged Google Workspace pilot, the Email setup section shows a Google Workspace read-only panel. A workspace admin can create the setup, enter the Workspace domain and Gmail mailbox, open Google OAuth consent, select the same mailbox and label, test read-only access, and refresh connector health without making direct API calls.

The panel shows setup steps, the selected mailbox, sync lag, Gmail watch timing, recent safe connector events, and safe errors. A workspace admin can also disconnect the connector from the panel after confirmation. Disconnect disables collection and offers a fresh setup path for reconnecting. It does not expose OAuth state, mailbox history cursors, Pub/Sub payloads, provider message IDs, or provider credentials.

Microsoft 365 mailbox-action pilot

A guarded Microsoft 365 mailbox-action pilot is pending rollout. After Dralvia support enables it for your workspace, a workspace admin can complete the customer flow from the UI:

1. Keep the Microsoft 365 read-only connection active and healthy.
2. In Email setup, request the separate mailbox-action permission upgrade.
3. Complete Microsoft administrator consent for Mail.ReadWrite.
4. Use Enable mailbox actions after Dralvia validates the selected mailbox.
5. Open Remediation, preview one bounded action, and approve it explicitly.
6. Review the safe action timeline or use Disable mailbox actions to return the connector to read-only mode.

The pilot supports adding a category, marking a message read or unread, moving one message to Junk Email or Deleted Items, and moving one message to a mailbox folder. Junk Email, Deleted Items, and folder moves are shown as retract / quarantine actions because they move one provider-mapped message out of the selected Microsoft mailbox after preview and approval. This is soft quarantine, not Microsoft Defender quarantine.

The Setup tab also includes a Quarantine destination control. The default destination is Junk Email. Workspace admins can change it to a mailbox folder when their Microsoft mailbox has a dedicated quarantine folder. The Remediation tab then exposes Quarantine message, which creates a preview using the configured destination.

The pilot does not request Mail.Send, forward messages, or permanently delete messages. A denied permission upgrade leaves the existing read-only connection active.

The Microsoft mailbox-action panel also shows Mailbox action executor readiness:

• support disabled means previews and approvals can be visible, but approved jobs remain queued until Dralvia support configures the approved Microsoft Graph retract / quarantine executor.
• ready means the executor is configured; preview, explicit approval, action limits, and safe timelines still apply.

The readiness panel never shows Graph credentials, provider message IDs, vault paths, or raw executor configuration.

If a message was moved incorrectly, create and approve a new move action back to a safe mailbox folder. Dralvia does not silently undo provider actions.

Messages submitted by API relay, manual upload, SMTP relay, or other non-Microsoft paths may not have a Microsoft provider message map. Dralvia can still analyze, preserve evidence, and track response activity for those messages, but it cannot retract them from an employee mailbox unless they were collected through the Microsoft 365 connector.

API equivalents for supported automation:

• GET /email/connectors/<connector_id>/microsoft-365/remediation
• POST /email/connectors/<connector_id>/microsoft-365/remediation/permission-upgrade
• POST /email/connectors/<connector_id>/microsoft-365/remediation/enable
• POST /email/connectors/<connector_id>/microsoft-365/remediation/disable
• POST /email/connectors/<connector_id>/microsoft-365/remediation/preview
• POST /email/connectors/<connector_id>/microsoft-365/remediation/jobs/<job_id>/approve

Mailbox actions remain unavailable unless Dralvia has deployed the pilot, configured the approved provider runtime, and enabled the feature for your workspace.

Google Workspace read-only pilot

Google Workspace / Gmail direct mailbox collection is staged but not generally available. The Email setup card and Google Workspace panel show this as a support-enabled pilot.

This means:

• do not open Google OAuth consent unless Dralvia support has enabled the pilot for your workspace
• Dralvia does not read Google Workspace mailbox data until read-only access is validated for the selected mailbox
• Dralvia stores an external secret reference only, not Gmail OAuth tokens, service-account keys, or delegated credentials in the browser
• Gmail metadata, read-only, and mailbox-modify permissions require Google restricted-scope review before broad rollout
• use API relay, raw email, EML upload, or manual analysis unless the pilot is enabled for your workspace
• workspace-admin domain-wide delegation and Google mailbox actions are not part of this pilot

Do not paste Gmail OAuth tokens, refresh tokens, service-account JSON keys, delegated credentials, or mailbox passwords into Email Protection forms, tickets, or API payloads.

API equivalents for supported automation:

• POST /email/connectors/<connector_id>/google-workspace/oauth
• GET /email/connectors/google-workspace/callback
• POST /email/connectors/<connector_id>/google-workspace/mailboxes
• POST /email/connectors/<connector_id>/google-workspace/test
• POST /email/connectors/google-workspace/pubsub

Gmail personal connection

Use this card to connect one personal Gmail mailbox. Unlike Google Workspace, Gmail personal does not need a workspace domain, and the connected mailbox is the account you sign in with.

What it is for: a single person can connect their own Gmail mailbox for read-only security analysis without admin setup.

How to connect from the UI:

1. Open #/email-protection, then Setup.
2. In the Gmail personal panel, select Connect Gmail personal.
3. Enter your Gmail address, then select Open Gmail sign-in. Dralvia requests read-only Gmail access only.
4. Return to the panel and select Test read-only connection. The connection becomes active once read-only scope is validated.

What Dralvia reads and stores: Dralvia reads your messages, headers, and attachments in read-only mode for security analysis. Dralvia does not send, delete, or change your email. Your sign-in tokens are not stored in Dralvia. Dralvia keeps only a secure reference held in an external secret store. The panel shows the connection status, last sync, last error, connected mailbox, and permission level.

Honest status: like Google Workspace, Gmail personal is a staged support-enabled pilot. The full sign-in and historical-scan flow is in the product, and activation completes after restricted Gmail read-only scope approval and Dralvia support runtime enablement. Until then, use API relay or manual upload.

API equivalents:

• POST /email/connectors/<connector_id>/gmail-personal/oauth
• GET /email/connectors/gmail-personal/callback
• POST /email/connectors/<connector_id>/gmail-personal/test

Incoming monitoring

Each Gmail personal or Google Workspace connection has a Monitor incoming mail only option. When it is on, Dralvia analyzes new incoming mail and does not continuously rescan your whole mailbox. Toggle it in the panel, or set it with POST /email/connectors/<connector_id>/monitoring using {"monitor_incoming_only": true}.

Historical scan (backfill)

After a mailbox is connected, you can queue a bounded historical scan of recent mail. Choose Last 24 hours, Last 7 days, Last 30 days, or a Custom range, and set a maximum message count. The scan runs as a background job, not inside your request, so the UI stays responsive.

The historical scan progress panel shows each job as queued, running, completed, or failed, with messages seen, messages analyzed, duplicates skipped, and a redacted error count. Messages already analyzed are skipped, so a re-run does not double-count. Every analyzed message flows through the same canonical analysis path as POST /email/protect.

Limits: a single historical scan is capped at a maximum message count, and a custom range cannot exceed 30 days. These limits keep the scan bounded and safe.

API equivalents:

• POST /email/connectors/<connector_id>/backfill with {"window_kind": "last_7d", "max_message_count": 500} (or last_24h, last_30d, or custom with range_start and range_end)
• GET /email/connectors/<connector_id>/backfill
• GET /email/connectors/<connector_id>/backfill/<job_id>

Deployment patterns

Pattern	When to use	Steps
Workspace compose flow	Analyst review, low-volume triage	Use #/email-protection, then submit the message from Compose.
Structured API submission	Platform or SOC automation	POST the parsed message to the Email Protection API with a workspace API key before downstream actioning.
Raw email or EML submission	Analysts or automation handling full mailbox exports or forwarded samples	Submit raw_email text or raw_email_base64 so Dralvia extracts headers, bodies, links, and attachments before analysis.
Connector-ready relay pattern	Teams preparing future gateway/journaling rollout	Stage a relay or transformation step that can call the same Email Protection API.

API relay

API relay is available through the canonical Email Protection endpoint:

POST /email/protect

Use a workspace API key in the request header. Keep the key outside URLs, message payloads, and browser storage:

Authorization: Api-Key $DRALVIA_API_KEY

Send an Idempotency-Key for each upstream message so safe retries do not duplicate analysis:

Idempotency-Key: relay-message-unique-id

Example:

curl --request POST "$DRALVIA_API_BASE/email/protect" \
  --header "Authorization: Api-Key $DRALVIA_API_KEY" \
  --header "Idempotency-Key: relay-msg-123" \
  --header "Content-Type: application/json" \
  --data '{"message_id":"relay-msg-123","from":"[email protected]","to":["[email protected]"],"subject":"Invoice due","text":"Review the attached invoice."}'

Workspace API-key expiry, rotation, revocation, quota, and IP allowlist controls apply to relay calls. Open Email setup to send a signed-in test payload and review redacted relay health.

Relay setup paths

The API relay panel also shows guided setup paths. Choose the path that matches the upstream system your team owns:

Path	Use it when	Main requirement
Generic reported-mailbox forwarder	You can copy reported messages to a transform mailbox or queue.	Preserve RFC822 content and submit with a stable Idempotency-Key.
Postfix or compatible gateway	You own the mail gateway and can copy selected traffic.	Use TLS to your transform and dedupe by queue ID or Message-ID.
Exchange on-premises journaling	You can journal selected mailboxes or groups.	Parse the journal envelope and dedupe original message copies.
cPanel or shared-hosting forwarder	You can forward selected security-mailbox copies.	Keep the API key outside cPanel and preserve original headers.
Proofpoint	You use Proofpoint export, journal, TAP, or SIEM automation.	Use a customer-owned transform and dedupe by provider event ID and Message-ID.
Mimecast	You use Mimecast journal, archive export, or automation.	Preserve RFC822 content and dedupe by archive/export ID and Message-ID.
Dralvia SMTP receiver pilot	Dralvia support has enabled a local SMTP receiver for your workspace.	Put approved TLS, private networking, or allowlisting in front of the listener and keep the API key only in the receiver runtime.

Most paths route copied messages through your own transform into the same Email Protection API. The SMTP receiver pilot is support-disabled unless Dralvia has explicitly enabled it for your workspace. Use the signed-in test payload first, then send one copied message and review recent relay outcomes before widening routing.

For the SMTP receiver pilot:

• confirm the Setup preflight is ready before sending traffic
• do not expose the listener directly to the public internet
• do not paste the workspace API key into tickets, screenshots, SMTP payloads, or browser forms
• expect every accepted SMTP message to enter POST /email/protect with relay idempotency

Plan packaging and quotas for managed ingestion, SMTP receiver usage, and mailbox actions are still under review before public enablement.

Pricing and quota review

The Setup tab shows Pricing and quota review when Email Protection paths need commercial packaging before broader rollout. This panel does not change your price or quota by itself. It shows what is available today and what still needs plan, support, and limit approval.

Current posture:

• API relay volume uses existing workspace API-key and usage controls while sustained volume is monitored.
• SMTP receiver usage requires pricing, listener, volume, and support limits before public enablement.
• Microsoft 365 and Google Workspace managed ingestion require mailbox-count, sync-volume, retention, and support-tier limits before public enablement.
• Provider mailbox actions require action-volume, approval, audit, and support limits before public enablement.

Use the public Pricing & Plans page for current plan packaging. Do not assume support-disabled Email Protection pilots are included in a self-serve plan until the pricing page says so.

Setup and relay status routes:

Method	Route	Purpose
GET	/email/relay/status	Counts, last success, last safe error, endpoint, payload contracts, limits, and setup guides
GET	/email/relay/ingests?limit=10	Recent redacted relay outcomes
GET	/email/relay/errors?limit=10	Recent redacted relay errors
GET	/email/integration-readiness	Live input modes, connector-ready patterns, client setup paths, planned patterns, payload contracts, limits, and notes
GET	/email/messages	Recent message summaries with mailbox action eligibility and recommended first action
GET	/email/messages/<message_id>	Stored analysis detail, click activity, remediation history, mailbox action eligibility, and operator next steps

Relay history never returns API-key secrets, raw idempotency keys, full message bodies, attachment contents, or request headers.

API payload

Structured example:

{
  "message_id": "MSG-123",
  "subject": "Invoice due",
  "from": "[email protected]",
  "to": ["[email protected]"],
  "html": "<p>Pay now</p>",
  "vendor_contacts": [
    {
      "name": "Contoso Billing",
      "email": "[email protected]",
      "domain": "contoso.com"
    }
  ],
  "headers": [
    {
      "name": "Authentication-Results",
      "value": "mx.example; spf=pass smtp.mailfrom=contoso.com; dkim=pass header.d=contoso.com header.s=selector1; dmarc=pass header.from=contoso.com"
    }
  ],
  "attachments": [
    {
      "filename": "invoice.pdf",
      "content_type": "application/pdf",
      "content": "JVBERi0xLjQK..."
    }
  ]
}

Raw message example:

{
  "raw_email": "From: [email protected]\nTo: [email protected]\nSubject: Invoice due\n\nPay now: https://pay.example"
}

EML file example:

{
  "raw_email_base64": "RnJvbTogYmlsbGluZ0Bjb250b3NvLmNvbQpUbzogdXNlckBjb21wYW55LmNvbQo=",
  "raw_email_filename": "invoice.eml"
}

Reported-email context example:

{
  "from": "[email protected]",
  "to": ["[email protected]"],
  "subject": "Invoice due",
  "text": "Pay now",
  "report_context": {
    "reported": true,
    "reporter": "[email protected]",
    "channel": "forwarded_message",
    "original_message_id": "[email protected]",
    "note": "Forwarded to the security team by the employee."
  }
}

Use the returned safe-link output to update downstream mail-handling workflows and attach detonation evidence to tickets when needed. Responses also include safe_link_delivery_manifest, a grouped handoff that shows which Dralvia safe links should be delivered to each recipient. Gateway and relay teams can use that manifest instead of parsing nested safe-link arrays.

If you submit a raw email or include headers in a structured API request, Email Protection also returns sender_auth with the parsed sender-authentication summary.

If you submit known executive or vendor context, Email Protection can also return vip_impersonation and vendor_impersonation summaries when the sender resembles those identities.

Email Protection now also returns sensitive_data when bounded body or text-like attachment scans detect privacy-relevant patterns such as credentials, regulated data, secrets, or source-code blocks.

Email Protection also returns campaign_context when the message matches other recent workspace messages through bounded shared signals such as sender domain, reply-to domain, subject, rewritten-link domain, or attachment hash.

campaign_context includes a blast_radius block that turns the raw campaign counts into a single reach level: isolated, limited, elevated, or widespread. The level rises with the number of targeted recipients, recorded safe-link clicks, and risky messages in the cluster, so a reviewer can judge how far a campaign has spread without reading every related message. The block also returns the underlying counts (message_count, targeted_recipients, clicked_messages, risky_message_count) and an engaged flag that is true once any safe link in the cluster has been clicked.

If you mark the message as user reported, Email Protection also returns report_context with the report channel, optional reporter metadata, and duplicate-submission context from recent workspace history.

When rewritten links have been clicked through the Dralvia safe-link path, message detail also returns click_activity, per-link click counts, and the latest click-time verdict for each rewritten link. New protected messages can also include recipient-scoped safe links. When those links are used, click activity can show who clicked, when, which link, and the click-time verdict. Older message-level links still work and show the recipient as unknown.

Ingest-time URL verdicts

Every link in a protected message now also carries the URL scanner's verdict at ingest time — before anyone clicks it. When a link's registrable domain (for example evil-shop.com for https://login.evil-shop.com/verify) matches a verdict the URL scanner has already produced for your workspace, or a public scan of that domain, Email Protection records that verdict on the link and links it to the originating scan. This makes a phishing URL seen in an email and on the URL scanner one story instead of two.

For each link, message detail returns:

• ingest_verdict — the URL scanner verdict at ingest (Safe, Caution, or Avoid), or null if no scan has judged that domain yet.
• ingest_score — the scanner risk score behind that verdict.
• ingest_scanned_at — when that scan ran.
• ingest_scan_public_id — the public scan id, so the workspace can deep-link to the full scan.

How it stays correct and private. The verdict is matched on registrable domain (eTLD+1), the same identity the Findings hub uses — a look-alike token is not treated as a match. Correlation only reads your own workspace's scans or global/anonymous scans (shared domain reputation); it never reads another workspace's private scan. Ingest never runs a live scan inline — it reuses verdicts the scanner already produced — so ingest stays fast and a missing verdict simply leaves the ingest_* fields null. Click-time verdicts are unchanged and remain separate (last_click_verdict).

Limitation. A link whose domain has never been scanned carries no ingest verdict until a scan of that domain exists; re-open the message after the domain is scanned to see the verdict populate.

Optional auto-scan of unseen domains. When enabled by your Dralvia team, a link whose domain has no verdict yet triggers a background scan of that domain, so the verdict is ready the next time the message is opened. This is off by default (it creates real scan jobs), bounded to a few domains per message, and best-effort — it never delays or blocks message processing, and a scan that cannot be queued simply leaves the verdict to populate later.

If safe_link_delivery_manifest.status is available, use the recipient rows for new deliveries that need per-person click attribution. If the status is message_level_only, the links are still valid but later clicks show recipient unknown.

The workspace route #/email-protection now keeps the operator flow split into clear sections: Overview, Setup, Compose, Analysis, History, Policy, and Remediation.

Overview currently includes:

• operator lanes for prepare, review, policy, and remediation jobs
• workspace metrics for the selected recent time window
• latest analysis posture with risk, route, click, and message state
• evidence and response state with quick export and reload actions
• policy posture

History currently includes:

• searchable message history
• server-backed pagination
• filters for messages with remediation, quarantine tracking, and completed quarantine
• recommended first action for stored messages when guidance is available
• open analysis and open remediation actions
• queue quarantine tracking for messages that do not already have quarantine tracking

Setup currently includes:

• Email Protection progress:
  • product API and UI implementation: 90%
  • public enablement readiness: 78%
• Enablement request pack for support or pricing review
• Email setup paths for relay, Microsoft 365, and Google Workspace pilots
• Microsoft retract / quarantine controls when support has enabled the guarded action path
• integration readiness
• client setup options
• Email security parity matrix
• pricing and quota review for support-enabled paths

History and message-detail reads:

• GET /email/summary?tenant_id=<workspace>&window_hours=<n>
• GET /email/integration-readiness?tenant_id=<workspace>
• GET /email/messages?tenant_id=<workspace>&limit=<n>&offset=<n>&q=<search>&remediation_filter=<all|with_actions|quarantine|quarantined>
• GET /email/messages/<message_id>?tenant_id=<workspace>
• GET /email/rewrites/<message_id>
• GET /email/remediation/actions?tenant_id=<workspace>&message_id=<message_id>&include_events=1

The readiness route returns the same customer-safe contract shown in Setup:

• progress percentages and remaining rollout blockers
• enablement request pack for Microsoft 365, Google Workspace, mailbox actions, and pricing/quota review
• live submission modes
• payload contracts for structured, raw-email, and .eml submission
• supported reported-email channels
• connector-ready deployment patterns
• planned patterns that are not live yet
• Email security parity matrix rows
• current raw-email and attachment limits

Use the implementation percentage to understand what exists in product code and UI. Use the public enablement percentage to understand what is ready for broad client rollout. Public readiness is lower because managed mailbox runtime, provider approval, and pricing/quota gates are not fully cleared yet.

Use Enablement request pack when you need Dralvia support, compliance, or pricing review before enabling a managed path. The pack lists the required inputs, owner, client path, safe notes, and privacy guardrails. Do not include provider tokens, secrets, raw provider message IDs, opaque cursors, client-state hashes, or raw IP addresses in an enablement request.

The Email security parity matrix currently uses these statuses:

Capability	Status	Notes
URL rewrite	Live	Message links can be rewritten through Dralvia safe links.
Click-time analysis	Live	Safe-link clicks redirect instantly and refresh URL verdicts in the background.
Per-recipient click attribution	Live	New recipient-scoped links can show the clicked recipient.
Attachment analysis	Live	Supported attachments receive bounded analysis.
Reported mailbox ingestion	Support-disabled	Report context is live; managed mailbox collection needs support enablement.
Retract / quarantine	Support-disabled	Microsoft mailbox actions need support enablement and provider mapping.
DLP	Live	Email body and supported attachment text can produce redacted sensitive-data findings.
Email encryption	Out of scope	Dralvia does not provide outbound email encryption in Email Protection v1.
Email archive	Out of scope	Long-term legal archive and journal retention are not part of Email Protection v1.
DMARC posture	Live	Sender authentication shows SPF, DKIM, DMARC, ARC, and alignment findings.

Policy routes:

• GET /email/policy?tenant_id=<workspace>
• POST /email/policy

These routes return and update the same workspace policy used during /email/protect. The current policy model supports:

• enabled or disabled policy routing
• optional automatic remediation
• review, quarantine, and delete score thresholds
• per-disposition action mapping
• signal triggers for reported messages, sender-auth failures, VIP or vendor impersonation, sensitive-data hits, campaign clustering, and malicious attachments

These routes return the message history used by the workspace History tab and message reopen flow. Message detail now also includes a campaign_context block plus a remediation block with the recent action timeline for that message. Reported submissions also include report_context.

The summary route returns the bounded workspace metrics contract used by Overview. Current totals include:

• messages analyzed
• messages requiring action
• reported messages
• clicked messages
• total safe-link clicks
• clustered messages
• policy-routed messages
• messages with remediation
• queued detonation count

Current breakdowns include:

• risk levels
• input modes
• policy dispositions

Current trend buckets include per-day counts for:

• message volume
• action-needed volume
• reported messages
• clicked messages and total clicks
• remediation actions

EvidencePack adapter

• Email Protection responses include an EvidencePack plus a transparency index you can store for audit.
• The same response now also includes evidence_summary, a customer-safe pack summary with:
  • feature and artifact counts
  • message, attachment, safe-link, and click counters
  • policy, remediation, campaign, report, and sensitive-data status
  • an included_evidence list that matches the Analysis view
• When sender-authentication evidence is present, the same summary is included in the Email Protection EvidencePack metadata.
• Current pack artifact references can include:
  • message detail
  • safe-link rewrite detail
  • detonation reports
  • workspace policy and workspace summary routes
  • inline JSON snapshots for sender-auth, click activity, campaign context, policy decision, remediation summary, report context, and sensitive-data findings when those blocks are available
• Use the Download EvidencePack action in Overview or Analysis to export the signed JSON.
• The pack is a signed snapshot from analysis time. Later safe-link clicks and remediation progress continue on the message detail and remediation routes.
• Forward the EvidencePack to TicketBridge or your incident tracker for chain-of-custody.

Analysis view

• Sender Authentication shows SPF, DKIM, DMARC, and ARC when the message included the needed headers.
• Click Activity shows how many safe-link clicks were recorded for the message, plus recent click times, clicked recipient when available, user-agent families, referrer domains, and click-time verdicts for recent events.
• Safe-Link Rewrites lists rewritten links, their Dralvia redirect form, recipient-scoped links when available, the original message-time finding, and the latest click-time verdict.
• Recipient Delivery Manifest shows the grouped recipient handoff for relay or gateway delivery, including a copy action for the JSON manifest.
• Attachment Detonations shows file verdicts, flags, report links, attachment family, a short finding summary, and bounded family-specific evidence such as PDF active-content markers or risky archive members.
• BEC Heuristics shows business-email-compromise pressure signals.
• VIP Impersonation highlights executive-style sender or display-name matches.
• Vendor Impersonation highlights vendor-name and vendor-domain matches, including observed-versus-expected domain context when available.
• Sensitive Data shows privacy-safe classifier hits from the message body and text-like attachments. Values stay redacted in this view.
• Reported Email Context shows whether the message came from a user-reported flow, which report channel was used, optional reporter metadata, and whether recent workspace history already contains duplicate submissions of the same message.
• Campaign / Blast Radius shows whether the message is isolated or part of a broader wave, which signals were shared, how many related messages were found, how many recipients were targeted across the wave, and which related messages are already visible in the workspace history.
• Policy Decision shows the final routed disposition, the recommended remediation action, whether automatic remediation is enabled, and which policy rules matched the current analysis.
• EvidencePack contents shows the signed pack version, feature and artifact counts, message and click counters, routed policy/remediation state, the included evidence domains, and a short artifact reference list before you download the full JSON.
• Remediation shows message-scoped action history when a saved message is open. Operators can move an action only into the next allowed status.
• Troubleshooting payload only stays collapsed by default. Open it only when you need API-to-UI comparison or support troubleshooting, then open the nested JSON block only if you need the raw payload itself.

Workspace metrics

Use the Workspace metrics section on Overview when you need a fast recent workspace picture before opening one message in detail.

Current live window choices:

• 24 hours
• 72 hours
• 7 days

Current live panels:

• total messages analyzed
• action-needed messages
• reported-message count
• clicked-message count
• policy-routed message count
• remediation action count
• risk distribution
• input-mode distribution
• policy-routing distribution
• per-day trend cards

This section stays bounded and customer-safe. It is not a raw event explorer or long-term BI export.

Policy tab

Use the Policy tab to update the workspace-scoped Email Protection policy that runs during /email/protect.

Current live controls:

• enable or disable the policy engine
• enable or disable automatic remediation
• set review, quarantine, and delete thresholds
• map review, quarantine, and delete to supported remediation actions
• toggle signal-trigger rules for:
  • reported messages
  • sender-auth failures
  • VIP impersonation
  • vendor impersonation
  • sensitive-data findings
  • campaign clustering
  • malicious attachments

Remediation does not create duplicate action rows for the same workspace, message, and action. This applies to both automatic remediation and manual requests to POST /email/remediation/actions. If a matching active remediation already exists, Dralvia reuses it and the response sets reused to true, so a double submit or retry cannot queue a duplicate or conflicting mailbox action. A different action on the same message is still allowed.

Structured submissions without headers may show sender-authentication as not available. Raw email and .eml submissions are the best path when your team needs the full header-based sender-auth view.

Click telemetry is privacy-minimized. The workspace shows aggregate counts, click time, clicked recipient when a recipient-scoped link was used, coarse user-agent family, and referrer domain. It does not show raw IP or the full referrer URL. Older message-level links remain valid and show recipient unknown.

Click-time verdicts are refreshed when the rewritten link is used. The click redirects immediately, and the URL is re-scanned in the background so the click is never delayed by analysis. The click record shows the re-scan as queued while it runs, and the refreshed URL verdict appears in your scan history. This lets operators compare the original message-time finding with the most recent click-time URL verdict on the same link.

Remediation updates are stateful. Once an action reaches a terminal state such as completed, cancelled, or failed, the workspace does not offer blocked reverse transitions. The API returns 409 invalid_transition if automation tries to force one anyway.

The Analysis screen includes Mailbox Action Eligibility. This panel tells operators whether the message can be retracted or quarantined from Microsoft 365, or why it cannot. Relay-only, raw email, EML upload, and manual messages are still analyzable, but they cannot be pulled from an employee mailbox unless a Microsoft provider message map exists. When a Microsoft map exists but mailbox actions are not enabled, the panel shows that support enablement is required. The API and UI do not expose Graph message IDs, provider immutable IDs, provider mailbox IDs, credentials, tokens, opaque cursors, client-state hashes, or raw IP addresses.

The same eligibility contract is also returned by GET /email/messages and is shown as a short badge in the History tab. Use it to decide which stored messages should be opened for retract/quarantine review.

History and Analysis also show Operator Next Steps when guidance is available. History shows the recommended first action on message cards so operators can decide what to do before reopening a message. Analysis shows the full checklist with priority and the target section, such as Setup, Analysis, or Remediation. The checklist can recommend previewing retract / quarantine, requesting mailbox-action enablement, containing the message outside mailbox retract, following up with clicked recipients, tracking remediation, and preserving the EvidencePack.

This guidance uses safe risk, policy, click, report, playbook, and mailbox eligibility fields. It does not expose Graph message IDs, provider immutable IDs, provider mailbox IDs, provider tokens, opaque cursors, client-state hashes, raw IP data, or credentials.

Attachment analysis is bounded. Office, PDF, archive, script, and executable families can return richer findings, but this is still not unlimited document parsing, OCR, or full malware reverse engineering.

Sensitive-data detection is also bounded. The current slice scans the message body plus text-like attachments and returns redacted samples only. It is not a full-document DLP extraction path for Office, PDF, or archive attachments.

Campaign clustering is also bounded. It uses recent same-workspace history plus shared signal categories. It is not a global cross-workspace threat-campaign hunting view.

Reported-email dedupe is also bounded. It uses a saved exact-message match key for the workspace. It is not a fuzzy mailbox-thread or cross-workspace duplicate detector.

Detonation & BEC heuristics

• Attachment analysis uses bounded sandbox and extractor limits so large files do not stall the workflow.
• Attachment results can include family-specific evidence:
  • PDF active-content markers
  • Office container features
  • risky archive members
  • macro or script indicators
• BEC heuristics evaluate display-name spoofing, reply-to drift, urgent language, unusual payment requests, and vendor-payment diversion pressure. Flags are returned in bec.flags.
• Sensitive-data hits are returned in sensitive_data with redacted samples only. The classifier categories currently include secrets, credentials, regulated data, and source-code blocks.
• Every result is saved in EvidencePacks + transparency log for later audits.

Integration tips

• Readiness contract: use GET /email/integration-readiness or the workspace Overview panel to keep live versus connector-ready versus planned intake paths straight in your own runbooks.
• Latency budget: expect about 1 to 2 seconds per message. Use async queues if you need higher throughput.
• Retries: on 429 or 5xx responses, requeue the message. The API is idempotent per message_id.
• Ticketing: automatically create a TicketBridge entry through the workspace TicketBridge create flow when risk_level ≥ medium.
• Slack / Teams alerts: subscribe a Pro webhook to the email.verdict event to get a readable alert in Slack or Microsoft Teams whenever a message scores Caution or Avoid. Clean messages do not fire. See the Pro tier webhooks section for setup.

Analyst workflow

1. Open #/email-protection and start on Overview.
2. Use Workspace metrics to check whether the workspace is seeing recent risky, reported, clicked, or remediated message volume.
3. Check whether the needed message is already available in recent message history.
4. Move into Compose and choose Structured message or Raw email or EML when you need a new run.
5. If the message was submitted by an employee or mailbox-report flow, enable the user-reported option and capture the available context before running analysis.
6. Review sender-authentication, click activity, message-time versus click-time link verdicts, BEC, VIP/vendor impersonation, sensitive-data, campaign context, safe-link, and detonation evidence in Analysis.
7. Use Recipient Delivery Manifest when your relay or gateway needs the recipient-scoped safe links for delivery.
8. Use Reported Email Context to see whether the sample matches a prior saved report before taking action.
9. Use Policy when the workspace needs different routing thresholds or automatic remediation behavior.
10. Queue quarantine/delete/mark-suspicious actions from Remediation when needed, then use the same section to follow the action timeline until it reaches a terminal state.
11. For the latest click telemetry after safe-link visits, reload the message analysis from Overview or Analysis.
12. For false positives, adjust SWG/email policies or whitelist senders via the admin console.

Document these steps in your SOC runbooks so everyone handles suspicious emails the same way.

Who this is for

This guide is for workspace owners, workspace admins, and security operators who need clear, repeatable steps without support intervention for day-to-day execution.

Role-based start here

• Workspace Owner: Start with Before you start, then complete Step-by-step and Known limits and rate limits.
• Workspace Admin: Focus on Step-by-step, What each button does, and API and automation.
• Security Analyst: Start at Day-2 operations and Troubleshooting, then use API error quick reference.
• Integrator/Engineer: Start at API and automation, then validate with Step-by-step and FAQ.

Before you start

Use this short checklist before making changes:

1. Confirm you are signed into the correct workspace.
2. Confirm your role includes the permissions needed for this page.
3. Confirm your browser session is fresh (if pages behave unexpectedly, sign out/in once).
4. Confirm required prerequisites (API keys, agent enrollment, license, upstream integrations) are already in place.

Step-by-step

Follow this sequence for predictable results:

1. Open the workspace from the platform menu.
2. Start on Overview and confirm whether a previous result already exists.
3. Move into Compose and submit the email sample.
4. Review the returned verdict and evidence in Analysis.
5. If needed, move into Remediation and queue the follow-up action.
6. If behavior is not as expected, use Troubleshooting below before repeating actions.

Day-2 operations

After initial setup, keep this surface healthy with a simple routine:

1. Daily: verify data freshness and error banners.
2. Weekly: review trends, limits, and failed actions.
3. Monthly: review permissions, keys/tokens, and stale entities.
4. After any incident: capture evidence and update your team runbook.

What each button does

Button labels can vary by module, but behavior is consistent:

• Refresh: reloads the latest Dralvia data without changing configuration.
• Save: persists workspace-scoped configuration changes.
• Run/Probe/Validate: executes a non-destructive health or verification action.
• Download: fetches workspace-scoped artifact(s) (for example bundle, checksum, signature, or report).
• Verify: checks integrity/consistency and returns pass/fail details.
• Enable/Disable: toggles module behavior for your workspace; audit evidence should be recorded.

If a button appears disabled, check role permissions, required fields, and workspace license or feature entitlement first.

Self-check playbook

Use this 5-step isolation flow before escalating:

1. Configuration: confirm required inputs are present and formatted correctly.
2. Permission: confirm your role can perform the action (401/403 usually indicates authz/authn mismatch).
3. License/feature: confirm the feature is enabled for your workspace plan and module toggles.
4. Quota/rate limit: check for 429 responses and cooldown windows.
5. Service health: if you see 5xx, retry once after 30-60 seconds and capture exact error text.

If still failing, escalate with workspace ID, UTC timestamp, route, action, request details (no secrets), and screenshot or error response.

Troubleshooting

Use this quick triage order to reduce time-to-fix:

1. Auth/session: refresh token by signing out/in.
2. Workspace context: confirm you are in the correct workspace.
3. Inputs/config: verify required fields and formats.
4. Quota/license: confirm limits and feature entitlement.
5. Service health: retry after short delay if the service is transiently degraded.

For escalation, include workspace ID, timestamp (UTC), route name, action attempted, and full error message.

API and automation

Everything in this page should remain workspace-scoped. If your team prefers automation, use the corresponding API endpoints with the same guardrails as the UI:

• Use authenticated requests bound to your workspace context.
• Use idempotency/retry controls where available.
• Validate outcomes in the UI after automated runs.
• Raw response payloads and deeper troubleshooting details should stay in advanced/debug workflows rather than day-to-day operator views.

If your endpoint mapping is not obvious, start from Help Center and follow the linked API docs.

Next best actions

After finishing this page, continue with related workflows so your workspace setup stays end-to-end complete:

• EDR response and host actions
• Web Access Protection and dry-run events
• Identity risk and OAuth response
• EvidencePack verification and transparency log
• Risk economics and plan recommendation

FAQ

Q: I clicked save but nothing changed. A: Refresh once, confirm permissions, and verify required fields.

Q: Why do I see missing API key/unauthorized errors? A: Confirm your workspace API key or session is valid and mapped to the correct workspace scope.

Q: Can non-admin users use this page? A: Usually read-only access is possible; write actions require workspace-admin or equivalent roles.

Next steps

After finishing this guide:

1. Validate the result in the related dashboard/workspace.
2. Export or capture evidence if this affects compliance/incident operations.
3. Share the same runbook internally so other operators follow identical steps.
4. Return to Help Center for adjacent workflows.

API error quick reference

Use this matrix when a UI action fails with an HTTP/API error.

Error	Meaning	What to do now
401 Unauthorized	Session token is missing/expired or request is not authenticated.	Sign out/in, refresh once, then retry. Confirm your session is active in the correct workspace.
403 Forbidden	You are authenticated but your role is not allowed to perform this action.	Confirm your role includes the required permission for this button/action. Ask a workspace admin to grant access.
404 Not Found	The route/resource does not exist in current workspace context (or feature not enabled).	Confirm URL/route, workspace context, and feature availability. Refresh and retry; if persistent, capture timestamp and route and contact support.
429 Too Many Requests	Rate limit/quota window was exceeded.	Wait for cooldown/reset window, retry once, then reduce burst traffic/backoff if automated.
500 Internal Server Error	Backend failed unexpectedly while processing the request.	Retry after 30-60 seconds. If still failing, escalate with workspace ID, UTC time, route, action, and full error text.

Mailbox connection and historical scan return these safe error codes inside a 400, 409, or 503 response:

Error code	Meaning	What to do
gmail_setup_not_configured	Gmail personal sign-in is not configured yet for your workspace.	Use API relay or manual upload until Dralvia support enables the Gmail read-only runtime.
gmail_workspace_domain_not_supported	A workspace domain was sent to the Gmail personal flow.	Leave the workspace domain empty for personal Gmail.
gmail_scope_overprivileged	The sign-in returned modify or full-mailbox access.	Re-run sign-in and grant read-only Gmail access only.
connector_not_active	A historical scan was requested before the mailbox was connected and validated.	Complete the read-only connection test, then queue the scan.
backfill_limit_exceeded	The requested message count is above the per-scan cap.	Lower the maximum message count and retry.
backfill_range_too_large	A custom range was longer than 30 days.	Shorten the custom range to 30 days or less.

Known limits and rate limits

These limits can vary by plan and feature, but behavior is consistent:

• Burst traffic can trigger 429 Too Many Requests.
• Workspace quotas apply per feature/module and reset on configured windows.
• Repeated retries without backoff can extend recovery time during saturation.

Recommended operator behavior:

1. Retry once after cooldown for 429 responses.
2. Use exponential backoff in automation.
3. Monitor usage/quota dashboards for sustained high utilization.
4. Request quota review when normal workload regularly approaches limits.