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. With a white-labelled integration (Microsoft 365 Direct Email Injection (Manual)), a few emails sent directly from the platform, such as report emails, still go from CanIPhish's mail servers. So can training assignment and reminder emails in training campaigns with more than 1,000 employees. These emails still need allowlisting.

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. Integrations set up with Sign in with Microsoft since 25 October 2026 are only saved once consent is granted. One set up before then could show as Active after the first sign-in, before admin consent was given in a second step. If you're not sure, 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, or every employee from a certain time onwards, check that the integration can still sign in to Microsoft 365. A white-labelled integration (service provider Microsoft 365 Direct Email Injection (Manual)) shows this status, not Failure - Authentication To Microsoft Unsuccessful, when it can't sign in. If it uses a client secret, check that the secret hasn't expired or been deleted in Entra. If it uses a federated credential (the service provider is followed by (federated)), check that the credential is still on the app registration whose Application ID the integration uses, with the same issuer and subject. If the credential was only just added, Entra can take a few minutes to recognise it. Either way, check that the app registration still has the Mail.ReadWrite and User.Read.All application permissions with admin consent, then test the integration. 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 set up with Sign in with Microsoft before 25 October 2026 could show Active before admin consent was given, and a Google Workspace integration shows it even if you saved it without running Test connection. A white-labelled integration (Microsoft 365 Direct Email Injection (Manual)) always shows Active. Since 30 October 2026 its connection is checked each time it's saved, but the status doesn't change later, for example when its client secret expires or its federated credential is removed, so check it with Test connectivity.
• Token Expired, or any other status shown in red, means CanIPhish can no longer renew the integration's access to Microsoft 365. Only integrations set up with Sign in with Microsoft show it. 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 Name the integration, enter the same name as the existing integration. Leave Directory sync on if you also want your Entra ID groups synced: a directory you already have for the same tenant is left as it is, or reconnected if it had lost its access.
3. Click Sign in with Microsoft, sign in to the same Microsoft 365 tenant as a Global Administrator or Privileged Role Administrator, and select Accept. Wait for Microsoft 365 is connected.

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, Test the connection, enter the address of a Google Workspace user on a verified domain and click Test 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), followed by (federated) if they use a federated credential, have their own test. Open the actions menu (⋮) on the row and choose Test connectivity. In the Test Microsoft 365 connectivity dialog, enter an address under Send a test email to (it starts with your own address) and click Send test email. The address's domain must exactly match one of your verified domains, and the address must be a mailbox in the Microsoft 365 tenant the integration is connected to. The test puts an unread email titled Integration Test, from M365 DMI Test, in that mailbox's Inbox. Integration Successful means the integration signed in and delivered it.

If you see Integration Error, look for these words in the message:

• The domain associated to the provided email address is not verified: use an address whose domain is exactly one of your verified domains. See Employees - Domain Verification.
• The test email couldn't be delivered either due to a lack of permissions or the provided email address not being associated to a Microsoft 365 Account: first check that the address is a mailbox in the connected tenant (see Employee Not Found In Microsoft 365). If it is, the integration may not be able to sign in: this test doesn't report a wrong or expired client secret, or a missing federated credential, separately. Check that the client secret hasn't expired or been deleted in Entra, or that the federated credential is still on the app registration whose Application ID the integration uses. If the credential is there and matches, your organisation may restrict federated credentials: check with your Microsoft administrator.
• The app registration signed in, but it can't deliver email into mailboxes: give the app registration the Mail.ReadWrite and User.Read.All application permissions and grant admin consent, as in the white-labelled setup guide. If the integration uses a federated credential and you've only just granted them, this test and campaigns can keep failing for up to about 90 minutes, because the sign-in from before the change is reused until it expires. To check the permissions straight away, choose Update integration and click Save: saving signs in afresh and checks them, and if it succeeds, they're in place.
• Entra didn't accept the federated credential: choose Update integration to see the Application ID, issuer and subject the integration uses. Check that the app registration with that Application ID has a federated credential that matches the issuer and subject exactly, including upper and lower case, with the audience given in Step 2.11 of the white-labelled setup guide. The subject ends with :injection: and the integration's name, so a federated credential added for directory sync doesn't work here. If you've only just added or changed the credential, wait a few minutes and try again. Unlike saving, this test doesn't retry, so it can fail for a few minutes even after the integration was saved.
• No app registration with that Application ID was found in that tenant or That Tenant ID wasn't found: check that the app registration still exists in Entra, then choose Update integration and check the Application (client) ID and Directory (tenant) ID against its Overview page.
• This email delivery provider has no saved credential: choose Update integration and save it with a client secret or a federated credential.
• The federated credential couldn't be verified for this Azure China (21Vianet) tenant: use a client secret for this integration instead.
• Federated sign-in is unavailable right now: try again shortly.
• There was an error with the connection to Microsoft 365: check that you entered a valid email address, then reload the page and try again.
• Any message that asks you to contact support: please contact support.

To change the Application ID, Tenant ID or credential, for example to enter a new client secret, choose Update integration. The stored client secret is never shown, so enter it again whenever you save with Client secret selected. The integration is checked before anything changes. If saving fails, see the white-labelled setup guide's FAQ. Update integration also switches an integration that uses a client secret to a federated credential, in place. It keeps its name, so campaigns and notifications that use it carry on, and there's no secret left to expire. See Step 3 of 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 Test 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