Share your product feedback!

Please tell us what we can do to make INKY’s Email Security Platform the best product for you.

Inky admin permissions - allow granular control

Super Admin is currently required for onboarding customers, which also grants full product access. This means 10+ engineers in an MSP need Super Admin, with most of the rest needing policy management (the second highest tier). Best practice is least-privilege access. There should be more granular permissions: Separate role for user management at MSP level (internal IT owns this, not day-to-day support staff) Separate role for onboarding new customers (professional services/projects teams shouldn't need full admin) Separate permissions for mail security vs signature management (different staff, different skillsets) Granular control over viewing message bodies — currently restricted to Super Admin, but lower-level or custom roles should be able to view message content without full Super Admin access Ability to hide the Subject field by role — all roles can currently see subjects in analysis/observations message lists, and the recent "access denied" on restricted tenants doesn't prevent seeing subjects

Steven Richardson 7 months ago

8
📧

Email Security

Integration Between BullPhish ID and INKY User Phishing Reports

We are requesting improved integration between BullPhish ID (phishing simulations) and INKY (email security) to better handle user-reported simulated phishing emails. Current Issue: When a user correctly identifies and reports a BullPhish simulation using the “Report Phish” button, the message is treated as a real phishing incident by INKY. This results in: Unnecessary ticket creation (Autotask PSA) SOC/technician time spent reviewing false incidents User confusion due to lack of feedback Increased noise in phishing reporting workflows Requested Behavior: When a user reports a BullPhish simulation: The system should automatically recognize the message as a simulation (via headers, tagging, or integration). The user should receive immediate feedback such as: “Good catch — this was a simulated phishing test.” The event should be logged in BullPhish as a successful user action. The report should NOT: Generate a phishing incident in INKY Trigger SOC workflows or alerts Create tickets in Autotask Additional Suggestions: Introduce a header/tag (e.g., X-Phish-Simulation: BullPhish) for easy identification Allow MSPs to define handling rules for simulated phishing reports Provide reporting on user detection success without impacting security incident metrics Business Impact: Reduces false positives and alert fatigue Improves technician efficiency Enhances user training experience with immediate reinforcement Aligns phishing simulation outcomes with real-world SOC workflows This integration would significantly improve operational efficiency and the overall effectiveness of the Kaseya security stack.

Geoff Levy 5 months ago

2
📧

Email Security