Skip to main content

Email Intake

When your company receives an email at a specified address (e.g., privacy@company.com), forwarding rules can be set up to automatically forward that email to DataGrail. Vera — DataGrail's AI classification layer — reads the message, identifies the data subject, and classifies the request type, then converts it into a Privacy Request.

How Vera Parses Incoming Emails​

Rather than pattern-matching keywords, Vera reads the full content and context of an inbound email — sender, subject, body, and any surrounding thread content — to determine two things: who the data subject is, and what type of request they're making.

Data Subject Identification​

Vera identifies the data subject's name and email address directly from the message content and headers. This means Vera can correctly identify the data subject even when a thread contains several email addresses, forwarded content, or CC'd parties, rather than defaulting to the first valid non-customer/non-DataGrail address found in the message.

Vera's initial identification is recorded in the request's activity log, so agents can see what Vera identified as the data subject.

Request Type Classification​

Vera classifies each request into one of the following types:

  • Access
  • Deletion
  • Opt Out
  • Unclassified — used when Vera can't confidently determine a request type (see Unclassified Requests below)

Vera's initial classification is recorded in the request's activity log, so agents can see what Vera classified the request as.

Vera's classification recorded in the request's activity log

Confidence Thresholds & Needs Review

If Vera's confidence falls below the threshold for a given classification, the request isn't auto-classified — it's routed for manual review instead. This threshold is highest for Opt-Out classifications specifically: because Opt-Out requests skip the Request Wizard entirely, a false-positive Opt-Out classification is more costly than a false positive between Access and Deletion. Below that (very high) confidence bar, the request is created as Unclassified rather than guessed at.

Language Detection​

Vera also detects the language the email was written in and applies it to the request. If the detected language isn't configured in your account's email settings, the agent is prompted with a warning and must manually select a supported language before the request can move forward — the language selector won't default silently to an unconfigured language.

Unclassified Requests​

An Unclassified request means Vera identified the data subject but couldn't confidently determine the request type. An agent reviews it and either:

  • Sets the correct request type manually, or
  • If it's actually an Opt-Out, uses the Unclassified → Opt-Out conversion flow — the data subject's info and original email content carry over automatically, and the conversion is recorded in the activity log.

When creating the Opt-Out, the agent chooses whether to close the original request or keep it open:

Create Opt-Out modal with the option to close the existing request or keep it open

DataGrail tracks how often Unclassified requests turn out to be Opt-Outs vs. other request types, which is used to tune the confidence threshold over time.

Request Wizard showing an Unclassified Request selected as the default privacy right

Overrides​

Agents can always override Vera's classification — request type or data subject — from the request. Overrides are captured in the request's audit log.

Vera Indicators​

Requests parsed and classified by Vera are visually flagged so agents can tell automated classification apart from manual entry:

  • A ✨ sparkles chip appears next to the Request Type in the Request Manager queue
  • A Vera badge appears in the Request Wizard for requests Vera has classified

Auto-detected chip shown next to Access and Deletion request types in the queue

Supported Request Types​

Email intake via Vera currently supports:

  • Access
  • Deletion
  • Opt Out

Examples​

Scenario 1: Straightforward deletion request​

From: user123@gmail.com
Subject: Please delete my data
Body: Hi, I'd like my personal data removed from your systems.

✅ Vera identifies user123@gmail.com as the data subject and classifies the request as Deletion, based on the explicit "delete... removed" language in the message.

Scenario 2: Multiple email addresses in a thread​

From: request@thirdparty.com
Body: Please delete data for john.doe@example.com and jane.doe@example.com.

✅ Vera reads the full message to determine the actual data subject, rather than simply taking the first valid address it finds — or flags the request for review if intent is genuinely ambiguous.

⚠️ Only one request is created per email today, even when multiple data subjects appear in the message.

Scenario 3: Explicit opt-out language​

From: user456@yahoo.com
Subject: Please stop selling my information
Body: Under CCPA I am requesting that you stop selling my personal information to third parties.

✅ Vera detects the explicit "do not sell" language and jurisdiction signal (CCPA), classifying the request as Opt Out rather than Access or Deletion.

Scenario 4: Ambiguous marketing language​

Body: Please remove me from your marketing list.

⚠️ This phrasing is inherently ambiguous — it could mean Opt-Out or Deletion depending on context. Vera is tuned to favor Opt-Out over Deletion when marketing-specific language appears without explicit data-deletion intent, but low-confidence cases are flagged for review rather than auto-classified.

Scenario 5: Unclear intent​

From: user789@outlook.com
Subject: Question about my account
Body: I'm not sure what you have on file for me.

✅ Vera identifies the sender but can't confidently determine a request type, so the request is created as Unclassified. An agent reviews it and sets the correct request type, using the Opt-Out conversion flow if applicable.

Accounts without Vera

If Vera isn't yet enabled on your account, email intake falls back to DataGrail's legacy regex-based parser:

  • Extracts all email addresses from the from/reply-to headers, subject line, and body
  • De-duplicates and filters out addresses matching your domain or DataGrail's domain
  • Takes the first remaining valid address as the data subject
  • Scans the subject and body for deletion-related keywords (delete, remove, erase, forget, forgotten) — if found, creates a Deletion request; otherwise defaults to Access
  • Supports only Access and Deletion request types
  • Creates only one request per email, even if multiple data subject emails are present

Reach out to support@datagrail.io if you'd like Vera-based email intake enabled on your account.

Email Forwarding Configuration​

The customer-configured forwarding configuration determines how email headers and content are preserved, and what signal is available to Vera when identifying the sender and classifying the request.

Verification​

By submitting a Privacy Request via email, the Data Subject is proving their ownership of that address, so it is automatically treated as verified within DataGrail and will open in Pending Wizard.

However, a verification email can still be sent by selecting the Verify email option in Step 6 of the Request Wizard. This will allow you to preview and send a verification email to the data subject.

If you choose this option, the request will move to Pending Verification and then to Active: Extracting Personal Data once verified by the data subject.

Configuring Email Forwarding​

For DataGrail to automatically parse email requests, you'll need to forward emails to (hereafter referred to as the intake address):

<subdomain>@emailapi.datagrail.io

In the intake address, <subdomain> represents the subdomain of your DataGrail URL. If you log in at acme.datagrail.io, then you'd forward emails to acme@emailapi.datagrail.io.

Sender Authentication​

Forwarded emails must be authenticated with SPF to be accepted by DataGrail.

Example Configurations​

Email forwarding configuration for common mail providers is documented below.

Google Workspace (Gmail)

A Google Workspace administrator can set up an email group that can be identified by an email address (such as privacy@company.com), and can include the intake address as a member of the group. With an email group, when the privacy@company.com group receives an email, it redirects the message to all members. For instructions on how to set up email intake with an email group, see: Forward Setup - Google Groups.

Note: For email redirection with Google Groups to work, you will need to ensure that you have the following settings set for the group: allow external members checked and who can post set to anyone on the web.

You can also forward your emails directly to the intake address using the following instructions: Forward your emails.

Office 365 (Outlook)

Outlook has a convenient mechanism to preserve email headers by using email redirecting versus forwarding. If you need to, consult your email administrator to confirm which version of Outlook you’re using.

You can also create a distribution group, and include the intake address.

 

Need help?
If you have any questions, please reach out to your dedicated Account Manager or contact us at support@datagrail.io.

Disclaimer: The information contained in this message does not constitute as legal advice. We would advise seeking professional counsel before acting on or interpreting any material.