INKY Getting Started Checklist

Overview

Use this checklist when setting up INKY for a new customer or validating a recent INKY deployment.

This article is intended to help partners confirm that the customer environment is connected, mail is routing correctly, users are protected, banners and reporting are working, and common post-setup issues are easier to identify.

This checklist does not replace the full setup articles for Microsoft 365, Google Workspace, routing, groups, or policy configuration. Instead, it provides a high-level sequence to help confirm that the major setup and validation steps are complete.

Before you begin

Before starting, confirm the customer’s mail environment and administrative access.

You should know:

• Whether the customer uses Microsoft 365 or Google Workspace
• The customer tenant, team, or organization name in INKY
• The customer’s primary email domain
• Any additional accepted domains or aliases
• Whether the customer is migrating from another email security platform
• Whether the customer is migrating from Graphus to INKY
• Whether the customer uses Microsoft Defender, Safe Links, Google security tools, or another mail security product
• Whether users will be managed through groups, sync, or manual assignment
• Who will be responsible for testing mail flow before go-live

Getting started checklist

Use the sections below to confirm each part of setup.

Step 1: Confirm tenant and domain readiness

Before connecting the customer environment, confirm the customer’s mail domains and tenant details.

Check:

• Primary email domain
• Additional accepted domains
• Microsoft 365 tenant ID or Google Workspace domain details
• Admin access for the correct customer tenant
• Whether the customer has any legacy mail routing, connectors, gateways, or security platforms still active
• Whether the customer is using shared mailboxes, distribution groups, aliases, or nested groups
• Whether mail is routed directly through Microsoft/Google or through another service before reaching INKY

For Microsoft 365 environments, confirm you have the required admin access to complete the integration and review message trace/quarantine later if needed.

For Google Workspace environments, confirm you have access to the Google Admin console, routing settings, and Email Log Search.

Step 2: Connect the customer environment

Connect the customer tenant or workspace to INKY using the appropriate setup process for the customer’s mail platform.

Confirm:

• The customer tenant appears in INKY.
• The expected domains are visible.
• Admin authorization completed successfully.
• No tenant mismatch or wrong-admin account issue occurred.
• Any required permissions were granted.
• The customer environment is assigned to the correct partner/MSP organization, if applicable.

If the customer migrated from Graphus or another platform, verify whether any previous configuration needs to remain temporarily or be removed before go-live.

Step 3: Configure users and groups

Confirm which users should be protected by INKY.

Check:

• Which users are included in protection
• Which users are excluded
• Whether groups are being used for assignment
• Whether include/exclude groups are configured correctly
• Whether nested groups are supported for the intended use case
• Whether group membership has synchronized or updated
• Whether shared mailboxes, aliases, or special mailboxes need protection

If users are missing banners or not being processed by INKY, group membership and include/exclude configuration should be reviewed early.

Step 4: Configure mail routing

Confirm that mail is routed through INKY according to the customer’s platform and deployment method.

Check:

• MX records, connectors, routing rules, or gateway settings as applicable
• Microsoft 365 connectors or transport rules, if used
• Google Workspace routing and compliance settings, if used
• Any old routing from previous tools
• Any leftover Graphus or third-party gateway rules
• Whether inbound, outbound, or internal mail is expected to route through INKY
• Whether mail should route through Microsoft/Google security tools before or after INKY

For Google Workspace environments, confirm there are no old routing rules still pointing to an INKY relay after uninstall or migration unless they are expected.

For Microsoft 365 environments please ensure the setup steps ave been followed- Getting Started with INKY Google Workspace installation - INKY

Step 5: Validate inbound mail flow

After routing is configured, send test messages to confirm mail is flowing as expected.

Test:

• External sender to protected user
• External sender to multiple protected users
• External sender to an unprotected or excluded user, if applicable
• Trusted vendor or known-good sender
• Message with a link
• Message with an attachment, if appropriate
• Message that should receive an INKY banner

Confirm:

• The message is delivered.
• The message appears in the expected mailbox folder.
• The message trace or email log shows the expected routing path.
• INKY processed the message.
• No unexpected quarantine, rejection, or routing issue occurred.

For Microsoft 365, use Message Trace to confirm delivery and routing.

For Google Workspace, use Email Log Search to confirm delivery and routing.

Step 6: Confirm INKY banners are appearing

Send test messages and confirm INKY banners appear where expected.

Check:

• Does the test user receive an INKY banner?
• Does the banner show the expected classification?
• Does the banner color match the expected risk level?
• Are users in the correct include group?
• Are any users accidentally in an exclude group?
• Is the message type expected to receive a banner?
• Is the message external, internal, or outbound?
• Did the message actually route through INKY?

If banners are missing, first confirm that the user is protected and that mail is routing through INKY. Missing banners often indicate a routing, group assignment, or include/exclude issue.

Step 7: Configure user reporting

Confirm that users have the correct reporting options.

Check:

• INKY reporting links are visible where expected.
• Users understand how to report suspicious messages.
• Users understand how to report false positives or safe messages.
• Admins understand which categories may require admin-level review.
• Reporting behavior has been tested with at least one safe test message, if appropriate.

Important: Reporting a message as safe does not always resolve every classification. Some categories may require an administrator to review and create an allow at the appropriate level.

Step 8: Review allow and block list behavior

Before go-live or shortly after go-live, review how allow and block lists should be used.

Confirm:

• Who is allowed to create personal/user-level allows
• Who manages customer/team-level allows
• Who manages organization-level allows
• How allow entries are scoped by category
• Whether allow entries require DMARC pass
• Whether the visible From domain matches the actual sending service
• Whether sender/domain allows are being used appropriately
• Whether URL or link-domain exceptions are needed separately

Important: If a sender or domain is allowlisted but messages are still flagged, review the category, allow scope, DMARC setting, actual sending domain, and whether another tool is taking the final action.

Step 9: Review trusted sender options

Some senders may require more than a standard allowlist entry.

Review trusted sender configuration for:

• Vendors that send on behalf of your customer’s domain
• Third-party platforms used for billing, marketing, ticketing, CRM, or notifications
• Mail that appears to come from the customer’s own domain but is sent by an outside service
• Repeated spoofed internal sender or possibly misconfigured service classifications
• Frequently contacted external vendors

Examples of third-party sending platforms may include:

• SendGrid
• Mailchimp
• Constant Contact
• Intuit
• Autotask
• CRM systems
• Billing systems
• Marketing platforms
• Ticketing platforms

If mail is being sent by a third-party platform on behalf of the customer’s own domain, review Trusted Third-Party Sender configuration.

If an external vendor regularly sends legitimate mail to the customer, review Known External Sender options if available for the environment.

Step 10: Review link rewriting behavior

Confirm whether INKY link rewriting is enabled and how it should behave.

Check:

• Whether links are rewritten in protected messages
• Whether users can access legitimate links
• Whether Microsoft Safe Links is also enabled
• Whether another URL protection tool is active
• Whether any trusted domains should be added as future link rewriting exceptions
• Whether users know that allowing a sender does not always unblock a link
• Whether admins know how to review original URLs in message or threat details, if needed

If a user can open a message but cannot click a link, review the link separately. The issue may be INKY link rewriting, Microsoft Safe Links, browser protection, endpoint security, or the destination website itself.

Step 11: Confirm quarantine and delivery troubleshooting paths

Before go-live, confirm where admins should look when a message is missing, quarantined, rejected, or delivered to Junk.

Review:

• Microsoft 365 quarantine
• Google Workspace quarantine
• INKY quarantine, if applicable
• Microsoft 365 Message Trace
• Google Workspace Email Log Search
• Junk email behavior
• Transport rules
• Routing rules
• Safe Links behavior
• Other third-party email security tools

Important: INKY may classify or banner a message, but Microsoft 365, Google Workspace, Safe Links, browser security, or another tool may take the final blocking action.

For any missing or quarantined message, first identify where the message is and which system took the final action.

Step 12: Complete post-go-live validation

After the customer is live, complete a short validation pass.

Confirm:

• Users are receiving mail.
• Protected users are seeing INKY banners where expected.
• Mail is not unexpectedly routing around INKY.
• Mail is not being unexpectedly quarantined.
• Known vendors and business-critical senders are working.
• Users can click expected legitimate links.
• Reporting links are available.
• Admins know where to check message trace or email logs.
• Admins know how to gather one affected example before requesting support.

Recommended post-go-live test examples:

• External message from a known-good sender
• External message with a normal link
• External message with an attachment
• Message from a known vendor
• Message to a protected user
• Message to a user in an excluded group, if applicable
• Message sent after any allow or routing change

Common post-setup issues and where to start

Information to keep handy

For future troubleshooting, it is helpful to know:

• Customer/team name
• Protected domains
• Microsoft 365 tenant ID or Google Workspace domain
• INKY deployment method
• Mail routing design
• Include/exclude group names
• Admin contacts
• Whether Microsoft Defender or Safe Links is enabled
• Whether Google security/quarantine features are enabled
• Whether another mail security product is in use
• Any known business-critical senders or vendors
• Any third-party senders authorized to send on behalf of the customer