Table of contents
Overview
When you send a Right-Hand Cybersecurity phishing simulation, Darktrace/Email intercepts the simulation link before the recipient can click it. Instead of reaching the landing page, the user sees a Lock Link confirmation screen - a Darktrace autonomous response that rewrites suspicious URLs and forces users to confirm before proceeding.
This happens because Right-Hand Cybersecurity simulation domains are intentionally designed to mimic real phishing pages (for example, typosquats of LinkedIn, Microsoft, or Gmail). Darktrace correctly identifies them as high-risk. To allow simulations to run without interference, you need to whitelist Right-Hand Cybersecurity's sending IPs, sender addresses, and simulation domains inside Darktrace/Email.
Depending on Darktrace's confidence level, this may appear as a confirmation screen the user can bypass (Link Lock) or a hard block with no option to proceed (Double Lock Link). Both are resolved by the same model configuration below.
Important Note: Navigation paths in this article are based on Darktrace/Email (also known as Antigena Email). If your interface looks different, contact Darktrace support for version-specific guidance.
Prerequisites
Before you begin, make sure the following conditions are met:
Requirement | Details |
Console access | You must be able to log into the Darktrace Threat Visualizer |
User role | Email Administrator or System Administrator permissions are required to access exclusion settings |
Note: If you do not have the required permissions, the Detection → Models menu will not be visible or editable. Contact your Darktrace administrator before proceeding.
How Darktrace/Email Allowlisting Works
In the current Darktrace/Email UI, allowlisting is not done through a simple settings exclusion list. Instead, you create a custom Model - a rule-based logic block inside the Detection engine. The model defines:
Model Logic - the condition that identifies the emails to be exempted. For phishing simulations, this is the Connection IP address (CIP) of the sending mail server.
Model Action - what Darktrace does when the logic matches. For a simulation allowlist, the action is set to Do not hold, and take no action on any existing header, link, or attachment, which disables Lock Link rewriting and prevents the email from being held.
When an email arrives from a Right-Hand Cybersecurity IP, this model fires first and instructs Darktrace to deliver it untouched - bypassing all link analysis and autonomous response actions, including Lock Link.
Step-by-Step Instructions
Step 1 - Access Darktrace Email Console
Step 1 - Access Darktrace Email Console
Log in to the Darktrace console
Open your Darktrace instance URL in a browser and sign in with your administrator credentials. You will land on the Email Console dashboard.
Navigate to Detection → Models
In the left-hand navigation panel of the Email Console, click Detection, then select Models.
Email Console › Detection › Models
This opens the full list of active and inactive detection models in your environment. Each model defines a logic condition and a resulting action Darktrace takes on matching emails.
Step 2 - Create a New Allowlist Model
Step 2 - Create a New Allowlist Model
Click "Create New Model"
On the Models page, click the Create New Model button (or + New Model, depending on your version). A model editor will open with two sections: Model Logic and Model Action.
Name the model
In the model name field, enter a clear, descriptive name so it can be identified and removed after the campaign ends. For example:
Allow Right-Hand Cybersecurity — Phishing Simulation
Build the Model Logic using Right-Hand Cybersecurity IP addresses
In the Model Logic section, add a condition for each Right-Hand Cybersecurity sending IP using the Connection IP address (CIP) field. Connect each condition with OR so that any of the IPs will trigger the allowlist.
IP Address | Purpose | Required |
| Phishing simulation emails | Required |
| Training and transactional emails | Recommended |
| Training and transactional emails | Recommended |
Set the Model Action
In the Model Action section, configure the following two actions. Both must be set for the allowlist to work correctly:
The first action disables all Darktrace responses on matching emails - including email holding, Lock Link URL rewriting, and attachment scanning. The second action ensures the match is still logged for your records, so simulation activity remains visible in the Email Console.
Validation and Expected Outcome
Validation and Expected Outcome
Before rolling the campaign out to all users, confirm the configuration is working correctly by following these steps:
Send a test simulation email
Send a test phishing simulation email to 1–2 administrator mailboxes from the Right-Hand Cybersecurity platform.
Click the simulation link
Expected result: The simulation landing page opens directly. Neither the Link Lock confirmation screen nor a Double Lock block should appear - the landing page should open directly.
Verify the model fired in the Email Console
Navigate to Email Console → Detection → Models and open your new model. Check the Log or Activity tab to confirm the model matched the test email. You should see an entry for the test send showing the IP address and the action taken (No action).
Email Console›Detection›Models›Your model›Log / Activity
Confirm click tracking in Right-Hand
Check the Right-Hand Cybersecurity campaign dashboard to confirm the test click was recorded correctly. If the click is not registered, the link may still be getting rewritten - revisit Step 2.
Common Issues and Troubleshooting
Common Issues and Troubleshooting
1. The Lock Link screen still appears after saving the model
User sees a warning/confirmation screen, but can click through → Link Lock is still firing.
User cannot access the link at all, page is fully blocked → Double Lock Link is still firing.
The model may not be active, or the Model Action may be set incorrectly.
Go to Email Console → Detection → Models and open your model.
Confirm the Model is Active toggle is on.
Confirm the Model Action is set to Do not hold, and take no action on any existing header, link, or attachment - not Deliver.
Resave the model and test again with a fresh simulation email.
If the issue persists, contact Darktrace support to confirm the model is being evaluated before Link Protection fires.
2. The model is not appearing in the Log / Activity tab after the test is sent
The IP address in the Model Logic may not match the actual sending IP of the test email.
Go to Email Console and search for the test email by sender address or subject.
Open the email and check the Connection IP (CIP) field to see the actual sending IP.
If the IP is different from the ones in your model, add it to the Model Logic and resave.
For the most current list of Right-Hand Cybersecurity IPs, refer to the Whitelisting best practices article.
3. The simulation email is being held and not reaching the inbox
If the email is held despite the model being active, the model may be evaluating after the hold action fires.
Check the model's position in the evaluation order — in some Darktrace versions, models are evaluated in a specific sequence. Allowlist models should be positioned to evaluate before detection models.
Contact Darktrace support to confirm model evaluation order in your deployment.
4. Click data is not appearing in the Right-Hand Cybersecurity dashboard
If the landing page opens but no click is recorded, the Lock Link proxy may still be modifying the redirect chain.
Confirm the Model Action includes taking no action on any existing link - not just Do not hold.
If the model action is correct and click tracking is still broken, contact Right-Hand Cybersecurity support - the issue may be in the campaign tracking configuration.
5. The Detection → Models menu is not visible in the Email Console
This is typically a permissions issue or a UI difference in your Darktrace version.
Confirm you are logged in with Email Administrator or System Administrator permissions.
If permissions are correct, your Darktrace version may use different navigation labels. Contact Darktrace support and ask specifically how to create an allowlist model for phishing simulation IPs.
Frequently Asked Questions
Frequently Asked Questions
Q1) Why didn't this article whitelist the simulation domains and URLs separately?
Darktrace/Email does not have a standalone domain or URL exclusion list in its current UI. The correct and only supported method for allowlisting in Darktrace/Email is through the Models engine, and the IP-based Model you created in this article already covers the domain and URL problem.
Here is why: when the Model Logic matches an email arriving from a Right-Hand Cybersecurity IP, the Model Action Do not hold, and take no action on any existing header, link, or attachment tells Darktrace to leave every link in that email completely untouched. This means Darktrace skips its link rewriting step entirely - including Lock Link — before it even evaluates the destination domain.
The simulation domains (or any other Right-Hand landing page domain) never get assessed for Lock Link because the model already instructed Darktrace not to act on any links in that email. You do not need a separate domain or URL step.
Q2) Does this mean Darktrace won't protect users if a real phishing email contains those same domains?
Only partially, and only for the duration of the campaign. The Model fires based on the sending IP address, not the destination domain. A real attacker sending an email containing simulation domains from a different IP would still be subject to full Darktrace analysis and Lock Link protection.
The only gap is if a real attacker happened to send from one of Right-Hand Cybersecurity's exact sending IPs, which is not a realistic scenario. This is why IP-based allowlisting is the recommended approach and why the model must be deactivated as soon as the campaign ends.
Q3) Other email security platforms have a domain or URL exclusion list - why doesn't Darktrace/Email?
Darktrace/Email uses a behaviour-based AI model engine rather than static rule lists. Its allowlisting mechanism - the Models framework, is intentionally more flexible and precise than a simple URL list. It allows you to define allowlist conditions based on any combination of email signals: sending IP, sender address, custom headers, recipient groups, or combinations of all of these. An IP-based model scoped to a campaign period is considered best practice by Darktrace because it is the narrowest possible exception with the least impact on overall detection coverage.