Please tell us what we can do to make INKY’s Email Security Platform the best product for you.
Share your product feedback!
Exclude mailbox from banner
As an MSP I want our support@ mailbox to be excluded from the banner, but I still want INKY to stop obvious attack emails. I can adjust labels/actions as an admin in the INKY portal, but right now the banner is adding spam and confusion to tickets. Also requested: Per-user and per-organizational-unit banner suppression — the ability to set different banner visibility profiles for different people, similar to how signature profiles work. Some users/mailboxes need limited or no banner visibility while still being protected.
Bulk Unquarantine Emails
I want to be able to unquarantine multiple emails at once from the INKY dashboard. Currently, I have to handle them individually or rely on auto-release, but a manual bulk action button would be much more efficient for managing false positives.
In Progress
Inky API
Please provide access to an API to block e-mails and other useful capabilities in order to automate ticket closure.
Integration with IT Glue
I want an integration between INKY and IT Glue to streamline my workflow and security management. It is important because it would allow for better documentation and synchronization of security data within our existing IT management stack.
Allow filters in Analysis to use wildcards
All the filters in Analysis are a “starts with” filter, and sometimes you want to look for anything that came from a .ru domain, or anyone that used a email address that had the word “invoice” in it. But current filters don’t allow that, everything is “starts with” and using something like “*.ru” or “*invoice*@*.*” doesn’t work.
Planned
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
Customizable Quarantine digests
We would like to send users a list of quarantined emails without giving them access to the Microsoft Defender portal. The email available in Defender does not permit the removal of links to the Defender Quarantine page or Review Message. Our end goal is for users to email us with a list of emails they would like to have released, which we can then further analyse.
In Progress
DMARC Monitoring Page Enhancements
Requested enhancements to the DMARC Monitoring page: Update the green SPF circle to be yellow when the INKY SPF record is NOT present. Update the yellow DMARC circle as well as the yellow SPF circle to work with DMARC and SPF flatteners. MSP-level DMARC report: Ability to see the status of all clients' DMARC settings from a single view. Currently MSPs have to go into each client individually, making it impossible to track which clients/domains are misconfigured.
Scheduled Signatures and Banners
We need the ability to schedule signatures and banners to activate and deactivate based on specific dates and times. Use cases: Holiday banners (e.g. display during a holiday break period) Sale/promotion period banners Seasonal email signatures (e.g. "Happy Christmas" or "Happy New Year" that activate and deactivate automatically) Time-sensitive campaigns across the organization Currently these changes require manual updates, which is error-prone and creates unnecessary work for MSPs managing multiple tenants.
Rewriting of banners after user has clicked link
It would be fantastic if, in the vein of Graphus, the banner changed after the user has clicked on a link. For example, if the user clicks Safe or Not Greymail, the banner should change to reflect that they have submitted the email. Otherwise, end users will be confused as to why the email still says warning, danger, etc. and is prompting them to click the link.
True One Click reporting
Quick Action Reporting Links - INKY We’ve configured this for customers but it still leads to that browser pop-up and this is the biggest complaint we get from customers and is stated as the #1 reason for a lack of user engagement. Folks want to just select the appropriate option and have it submit without navigating away from their Outlook app. We recently looked at Trustifi for a HIPAA specific use case and they have it work in that exact manner so I know its definitely possible.
Bulk Confirm Messages in Custom Dashboard
Ability for admins to select all messages in a message list and bulk confirm. Existing workflow is cumbersome — this would speed things up significantly. Also requested for the Observations tab: Ability to use checkboxes to select and bulk confirm user reports (e.g. spam reports, graymail marked as safe) instead of having to create rules per domain or confirm one at a time.
Add Graymail Label Creation for Google Workspace
On Microsoft deployments MSPs can enable the graymail folder for all subscribers and the individual subscriber can also create the folder. Please extend this to Google Workspace installations.
View raw email header
With any email filter, we need the ability to view and/or download the original raw email headers. Your system analyzes the headers so this should be simple, but it seems there is no option to view the actual full header, only the simplified metadata tab that pulls only bits of the header. Please add the ability to view the full raw email header data.
In Progress
Advanced Block List Expiration
MSP Partners are not able to remove the expiration date for advanced block list rules on their own. It is required to open a ticket or reach out in AI chat to have those Expirations removed. This has a negative impact on MSPs managing many customers and results in time wasted for Kaseya and MSP employees. I would like an option to extend advanced Block List rules indefinitely. As an additional feature, the ability to manage Advanced blocklist rules at the partner level so they can be copied down to the customers would also be ideal. Thank You
Sandbox and view attachments
Being able to view a preview of attachments would be highly beneficial, whether quarantined or in standard Observations.
INKY Backup setting feature
It would be good as a failsafe to include a feature to export all INKY Admin configurations, settings, for MSPs; to be used as future reference and for change management.
Daily Reports Customization
The current "minimal" daily report does not provide enough depth or visual data to satisfy client business reviews or daily security summaries. Custom branding, enhanced data visualisation (pie charts graphs) even as good as current threat level over view and user reporting) would a create meaningful reports for customer to understand.
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.