Microsoft 365 Standard Deployment Example for INKY

Overview

This article provides a standard Microsoft 365 deployment example for INKY.

Use this article as a configuration reference when onboarding a Microsoft 365 customer, validating a new deployment, or confirming that mail is routing through INKY as expected.

This example is intended for a standard Microsoft 365 environment where selected users are included in INKY protection and mail flow is validated before go-live or shortly after go-live.

Use this configuration example when

Use this article when:

• The customer uses Microsoft 365.
• You are onboarding a new customer to INKY.
• You are validating that mail routes through INKY.
• You are moving users into active INKY protection.
• Users should receive INKY banners on analyzed messages.
• You need to confirm Microsoft 365 Message Trace and INKY Observations show expected processing.
• You need a baseline deployment pattern before troubleshooting a specific issue.

Do not use this article for

This article is not intended to replace specialized troubleshooting articles.

Use a more specific article if:

• Tenant hydration or organization settings customization fails.
• The customer is moving from Journal mode to active protection and no messages are being analyzed.
• Google Workspace is the customer’s mail platform.
• Mail is failing with relay errors.
• A message is quarantined, missing, or rejected.
• A sender is allowlisted but still flagged.
• A user can receive the email but cannot click a link.
• The customer is offboarding from INKY.

Standard deployment goals

A successful Microsoft 365 INKY deployment should confirm:

• The correct Microsoft 365 tenant is connected.
• The expected customer domain is associated with the INKY environment.
• Protected users are included in INKY processing.
• Excluded users are intentionally excluded.
• Microsoft 365 mail flow rules/connectors are configured as expected.
• Inbound test messages route through INKY.
• INKY analyzes the test messages.
• INKY banners appear where expected.
• Microsoft 365 Message Trace and INKY Analysis/Observations show the same test traffic.
• No unexpected quarantine, rejection, or mail loop occurs.

Before you begin

Confirm the following before starting deployment validation:

• Customer name
• Microsoft 365 tenant ID
• Customer primary email domain
• Any additional accepted domains or aliases
• Admin account used for setup
• Whether the customer is new to INKY or migrating from another tool
• Whether the customer previously used Graphus or another email security platform
• Whether Microsoft Defender, Safe Links, or another mail security product is enabled
• Which users should be protected by INKY
• Which users should be excluded
• Whether the customer uses shared mailboxes, aliases, distribution groups, or dynamic groups
• Who will send and receive test messages

Configuration summary

A standard Microsoft 365 INKY deployment usually includes these major areas:

Step 1: Confirm the correct Microsoft 365 tenant is connected

Verify that the customer’s Microsoft 365 tenant is connected to INKY.

Check:

• The correct customer name appears in INKY.
• The correct Microsoft 365 tenant was authorized.
• The expected email domain is visible.
• Setup was completed with the correct admin account.
• Admin consent completed successfully.
• No tenant mismatch or wrong-account issue occurred.
• The customer is associated with the correct partner/MSP organization, if applicable.

If the wrong Microsoft 365 tenant or admin account was used, correct the tenant connection before continuing.

Step 2: Confirm protected users and groups

Confirm which users should be protected by INKY.

Check:

• Included users are listed correctly.
• Excluded users are intentionally excluded.
• Group membership is accurate.
• Group membership has synchronized.
• The affected users belong to the correct customer/team.
• Shared mailboxes and aliases are handled as expected.
• Distribution groups are not being mistaken for protected individual recipients.
• Disabled, stale, or deleted users are not being used for testing.

For a clean validation test, choose one known active user who is confirmed to be included in INKY protection.

Step 3: Confirm mail flow configuration

Review Microsoft 365 mail flow to confirm messages are expected to route through INKY.

Check:

• Required connectors are present and enabled.
• Required transport rules or mail flow rules are present and enabled.
• Rules are scoped to the correct users, groups, or domains.
• Rule priority/order is correct.
• No bypass rule is taking precedence.
• No old Graphus, INKY, or third-party security routing rule is interfering.
• No disabled connector is still referenced by an active rule.
• No duplicate connector or rule is creating an unexpected path.
• MX records, if relevant to the deployment, are pointed as expected.

Step 4: Send an external test message

Send a new external test message to a protected user.

Recommended test conditions:

• Sender is external to the customer domain.
• Recipient is a known included user.
• Message is sent after setup/configuration changes are complete.
• Message has a clear subject line for searching.
• Message includes the current date/time in the subject or body.
• Message contains a normal link if link rewriting validation is needed.
• Message does not use an old email thread from before setup.

Example subject:

INKY deployment validation test - [date/time]

Do not use only internal messages for first validation. Start with a simple inbound external message to a protected user.

Step 5: Validate delivery in Microsoft 365 Message Trace

Run a Microsoft 365 Message Trace for the test message.

Search by:

• Sender
• Recipient
• Subject
• Date/time range

Confirm:

• Microsoft 365 received the message.
• The message was delivered.
• The message did not fail or bounce.
• The message was not unexpectedly quarantined.
• The expected connector, rule, or route was applied.
• The timestamp matches the test message.
• The result aligns with what the user sees in the mailbox.

If Message Trace shows the message was rejected, quarantined, redirected, or failed, troubleshoot the Microsoft 365 mail flow result before continuing.

Step 6: Validate analysis in INKY

After confirming Microsoft 365 delivery, confirm that INKY analyzed the same test message.

Check INKY Analysis or Observations.

Confirm:

• You are viewing the correct customer/team or organization.
• The time range includes the test message.
• The sender, recipient, subject, and timestamp match the test.
• The message appears as inbound traffic.
• The message has an INKY classification or observation.
• The result matches the user experience.

If needed, use the customer organization ID when filtering Analysis or Observations.

The organization ID can be found from the Admin Center Summary area.

Step 7: Confirm INKY banners appear where expected

Open the test message in the recipient mailbox and confirm banner behavior.

Check:

• An INKY banner appears where expected.
• The banner color and category make sense for the test message.
• The user can see reporting options, if enabled.
• The message was received after the user was included in protection.
• The recipient is not excluded from protection.
• The message actually routed through INKY.

If the message appears in INKY Analysis/Observations but no banner appears, review banner settings, message type, client behavior, and whether the message is expected to receive a banner.

If the message does not appear in INKY Analysis/Observations and no banner appears, review routing and user inclusion first.

Step 8: Validate reporting links

If user reporting is part of the deployment, confirm reporting links are available and behave as expected.

Check:

• Users can see the INKY reporting option.
• Reporting links appear in the expected location.
• A test report can be submitted if appropriate.
• Admins understand what reporting does and does not resolve.
• Admins understand that some classifications require team/customer-level review or allow configuration.

Step 9: Validate link rewriting, if enabled

If link rewriting is enabled, confirm a test message with a normal link behaves as expected.

Check:

• The link is rewritten by INKY, if expected.
• The link opens correctly when safe.
• The user does not see an unexpected INKY block page.
• Microsoft Safe Links is not unexpectedly blocking the link.
• Browser or endpoint protection is not blocking the destination.
• Link behavior matches the customer’s intended policy.

If the user can open the message but cannot click the link, troubleshoot link behavior separately. A sender allow does not always unblock a URL.

Step 10: Review Microsoft Defender, Safe Links, and other security tools

Many Microsoft 365 customers also use Microsoft Defender, Safe Links, Safe Attachments, quarantine policies, or another email security product.

Confirm:

• Whether Microsoft Defender is enabled.
• Whether Safe Links is enabled.
• Whether Safe Attachments is enabled.
• Whether Microsoft quarantine policies are active.
• Whether another email security gateway remains in the path.
• Whether old Graphus or third-party rules are still present.
• Whether these tools are expected to act before or after INKY.

This matters because INKY may analyze or banner a message, while Microsoft or another system may quarantine, rewrite, or block it later.

Step 11: Validate common business scenarios

After the first test succeeds, test a few common real-world scenarios.

Recommended examples:

• External message from a trusted vendor
• External message with a normal link
• External message with an attachment
• Message to a protected user
• Message to an excluded user, if applicable
• Message to a shared mailbox, if applicable
• Message sent to an alias, if applicable
• Message from a third-party platform, if business-critical

For each test, confirm:

• Message Trace result
• INKY Analysis/Observations result
• User mailbox result
• Banner behavior
• Link behavior, if applicable

Step 12: Confirm go-live readiness

Before considering the deployment complete, confirm:

• Correct customer tenant is connected.
• Expected users are included.
• Excluded users are intentionally excluded.
• Mail flow rules/connectors are enabled and ordered correctly.
• Test messages are delivered.
• Test messages appear in Microsoft 365 Message Trace.
• Test messages appear in INKY Analysis/Observations.
• INKY banners appear where expected.
• Reporting links are available, if enabled.
• No unexpected quarantine, rejection, or mail loop occurs.
• Admins know where to check Message Trace, quarantine, and INKY Observations.
• Admins know what information to gather for troubleshooting.

Common mistakes to avoid

Troubleshooting quick guide

Information to keep for future troubleshooting

Keep a record of:

• Customer/team name
• Microsoft 365 tenant ID
• Customer primary domain
• Included user group or list
• Excluded user group or list
• Connector names
• Transport/mail flow rule names
• Any bypass rules
• Whether Microsoft Defender is enabled
• Whether Safe Links is enabled
• Whether another mail security product is still active
• Test message sender, recipient, subject, and timestamp
• Admin contact for future mail flow validation