Troubleshooting: Direct Email Injection (Microsoft 365 and Google Workspace)

Direct Email Injection (DMI) puts simulated phishing emails straight into employees' mailboxes through the Microsoft Graph API (Microsoft 365) or the Gmail API (Google Workspace), instead of sending them by email. Use this article if you've set up DMI but emails are missing, land in Junk or Spam, are quarantined, or your test email arrives while campaign emails don't.

Note: To set up DMI, follow the Microsoft 365, Microsoft 365 (white-labelled tenants) or Google Workspace setup guide.

Contents

• Check which mail server the campaign uses
• Check each employee's delivery status
• Check the integration
• Send yourself a test
• The test arrives but campaign emails don't
• Emails are in Junk, Spam or quarantine
• Related articles

Check which mail server the campaign uses

Start here, because this is the most common cause. Each phishing campaign has its own Sending mail server, which is saved when the campaign is created:

• Your default delivery provider is only pre-selected when you create a new campaign. Adding a DMI integration or changing the default doesn't change campaigns that already exist.
• Duplicate campaign keeps the original campaign's mail server, and Resend email (in a campaign's report) uses the campaign's mail server.
• Managed Instance is CanIPhish's own mail servers. A campaign that uses it is sent by email (SMTP), not by DMI, so your email filtering still applies and you need allowlisting.
• Training campaigns don't have a mail server setting. If your default provider is a DMI integration, training emails and other notifications are injected through it. If a Microsoft 365 integration can't sign in, they're sent from CanIPhish's mail servers instead.

To check or change a campaign's mail server:

1. Go to Phishing & Training > Campaigns.
2. Open the campaign's actions menu (⋮) and choose Update campaign. If the campaign has already started or finished delivery, a warning appears first: click Proceed with update (or Proceed with making updates). Nothing changes until you save. The wizard opens at Review & save. If the campaign doesn't use your default provider, its Campaign section shows a Mail server row.
3. Click Edit on the Campaign section and expand Advanced settings. Sending mail server shows the mail server the campaign uses.
4. To switch the campaign to DMI, select your DMI integration, then click Review & save in the steps at the top of the wizard (or click Continue until you reach it) and click Save changes. If the campaign has already started, choose a new schedule on the Schedule step first. If you only wanted to check, close the wizard without saving.

Important: If the campaign has already started or finished delivery, saving archives the current version with its results and sends the phishing emails again. If you don't want employees to receive them twice, create a new campaign instead. New campaigns pre-select your default provider.

To make DMI the default for new campaigns, go to Platform Settings > Email Delivery Settings, open the actions menu (⋮) on your integration's row and choose Set as default.

Check each employee's delivery status

On the Campaigns page, click the campaign's name, or choose View report from its actions menu. The Email Delivered column shows the result for each employee:

Employees only receive simulations, and you can only send a test, on a verified domain. On the Employees page, the Domain Verification Status column shows any unverified domain in each list. Click Verification to verify it, as described in Employees - Domain Verification.

Note: The SMTP Logs tab under Platform Settings > Audit Logs only lists emails sent by SMTP. DMI emails don't appear there.

Employee Not Found In Microsoft 365

CanIPhish looks each employee up in the Microsoft 365 tenant the integration is connected to, by their user principal name, primary email address, other email addresses or proxy (alias) addresses, ignoring anything after a plus sign (+). It then creates the email in that mailbox's Inbox. If either step fails, you'll see this status. Check that:

• Admin consent was granted. DMI needs admin consent for Mail.ReadWrite and User.Read.All. A new integration shows as Active as soon as you sign in (Step 1/2), before admin consent (Step 2/2) is given. If you closed the Step 2/2 dialog or aren't sure, grant consent manually (Steps 6-10 of the setup guide) or re-authorise the integration.
• The mailbox is in the connected tenant. If you have more than one Microsoft 365 tenant, the employee's mailbox must be in the tenant the integration is connected to.
• The mailbox is hosted in Microsoft 365. DMI can't reach mailboxes hosted on an on-premises Exchange server in a hybrid setup. Send to those employees by email instead, using Microsoft 365 allowlisting.
• White-labelled tenants: if every employee fails, check that the app registration's client secret hasn't expired and that its permissions have admin consent. See the white-labelled setup guide.

Check the integration

Go to Platform Settings > Email Delivery Settings. The Manage Email Delivery Providers table lists each integration with its Service Provider and Status:

• Active means the integration is set up, not that it can deliver. A Microsoft 365 integration shows Active before admin consent is given, and a Google Workspace integration shows it even if you saved it without running Validate Connection.
• Token Expired, or any other status shown in red, means CanIPhish can no longer renew the integration's access to Microsoft 365. Its tooltip reads The API tokens associated to this integration have expired. Please reauthenticate the integration. Re-authorise the integration.
• Default marks the provider that's pre-selected in new campaigns.

There's no "New Integration" status: New Integration was the old name of the New Email Provider button. If your integration isn't in the table, its setup didn't finish. Start again with New Email Provider.

Re-authorise a Microsoft 365 integration

For integrations set up with Sign in with Microsoft (service provider Microsoft 365 Direct Email Injection):

1. Click New Email Provider and select Microsoft 365.
2. Under Integration Name, enter the same name as the existing integration. Click Sign in with Microsoft and sign in to the same Microsoft 365 tenant.
3. In the Step 2/2 dialog, click Automatically Provide Admin Consent and accept. Wait for The integration was successful! (Step 2/2).

Because the name matches, this updates the existing integration, and campaigns that use it keep it. You can't delete an integration while a phishing campaign uses it.

Validate a Google Workspace integration

1. Open the actions menu (⋮) on the integration's row and choose Update integration.
2. Under Step 3. Validate Connectivity, enter the address of a Google Workspace user on a verified domain and click Validate Connection. This puts an email titled Integration Test in that mailbox.

If validation succeeds, you'll see The credentials were tested and all required permissions are present. If it fails, the message says why: either the address's domain isn't verified, or the email couldn't be delivered because permissions are missing or the address isn't a Google Workspace user. For permissions, check that domain-wide delegation for the Client ID shown in the dialog includes the scope https://www.googleapis.com/auth/gmail.insert, as described in the Google Workspace setup guide.

Test a white-labelled Microsoft 365 integration

Integrations with the service provider Microsoft 365 Direct Email Injection (Manual) have their own test. Open the actions menu (⋮) on the row, choose Test connectivity, enter an address in To Address and click Test Connectivity. To enter a new client secret, choose Update integration. See the white-labelled setup guide.

Send yourself a test

Microsoft 365 integrations set up with Sign in with Microsoft don't have a Test connectivity or Validate Connection option. Test them by sending yourself a test email, which works with every delivery provider.

From the campaign wizard, the test goes through the mail server you choose in the wizard:

1. Go to Phishing & Training > Campaigns, click New Campaign and choose Simulated Phishing Campaign.
2. On the Name & audience step, enter a name and select an employee list. Expand Advanced settings, set Sending mail server to your DMI integration, and click Continue.
3. On the Phishing content step, click Configure on an email.
4. Under Send yourself a test, enter your address and click Send.

Tests use sample details (John Doe, IT Manager at Contoso Corp.) and don't count towards your quota. Closing the wizard before you launch discards the campaign, so nothing is sent to employees.

From the email library, the test goes through your default delivery provider: go to Phishing & Training > Phishing Content > Phishing Emails, click an email to preview it, click Send test email, enter your address and click Yes, send the test!

For either test:

• The address must be on a verified domain. With DMI, it must also be a mailbox in the Microsoft 365 tenant or Google Workspace account you connected.
• The confirmation (Test email sent or Email Delivery Success) means CanIPhish processed the test. With DMI it doesn't confirm that the email was injected, so check that it arrived. If it didn't, work through Employee Not Found In Microsoft 365 or, for Google Workspace, Validate a Google Workspace integration.

The test arrives but campaign emails don't

• They used different mail servers. A test from the email library goes through your default provider, but a campaign uses its own mail server. The test can arrive by DMI while the campaign goes out from Managed Instance and is filtered. Check the campaign's mail server.
• The test only reached your mailbox. Check each employee's status in the campaign report (see Check each employee's delivery status). For example, employees in another Microsoft 365 tenant, or with on-premises mailboxes, show Failure - Employee Not Found In Microsoft 365.
• The campaign is sent by email (SMTP). A test that arrives doesn't guarantee that campaign emails will, because they can use other templates and senders that your filters treat differently. Switch the campaign to DMI, or complete allowlisting.
• A test showed Microsoft delivery delay detected. Microsoft is rate-limiting email from our mail servers. This doesn't affect DMI. For SMTP delivery, configure an inbound connector.

Emails are in Junk, Spam or quarantine

DMI creates each email directly in the employee's Inbox: in the Inbox folder in Microsoft 365, or with the Inbox label in Gmail. It isn't sent by email, so it isn't filtered into Junk, Spam or quarantine on arrival, and you don't need to allowlist our IP addresses for it. If simulations are in Junk, Spam or quarantine, the campaign was most likely sent by SMTP, so check its mail server first.

Some security tools can still act on injected emails. Our guides note these cases:

• Barracuda: with Microsoft 365 DMI you still need the Intent Analysis allowlisting. See Allowlisting - Barracuda.
• Trend Micro: depending on which products you use and how they're configured, you may still need to allowlist in Trend Micro. See Allowlisting - Trend Micro Cloud App Security.
• Microsoft Defender for Office 365: if phishing links are rewritten or lead to a warning page, see Allowlisting - Bypass Safe Link/Attachment Processing of M365 Advanced Threat Protection (ATP).

Rules that match our sending IP addresses won't match injected emails, because those emails don't come from our mail servers. To identify CanIPhish emails in a rule, match the X-CanIPhish header or your Tenant ID instead. White-labelled tenants should check the header names in the Allowlisting - Quick Reference.

Related articles

• Microsoft 365 Direct Email Injection - Setup Guide
• Microsoft 365 Direct Email Injection (For White-Labelled Tenants) - Setup Guide
• Google Workspace Direct Email Injection - Setup Guide
• Email Delivery Providers Overview
• Troubleshooting: Email Delivery or Email Viewed Tracking Not Working
• Campaign Creation - Interactive Wizard
• Employees - Domain Verification
• Allowlisting - Quick Reference - IPs, Headers & URLs