Simulated phishing not getting through?

This guide describes various situations where your simulated phishing emails may not be getting through to end-users as expected.

Towards the bottom of this guide, we also help you troubleshoot situations where clicking the links in emails leads users to a block page in their web browser.

Other whitelisting needed

As described in our overview article, you may need to perform whitelisting in multiple systems to ensure that emails always get through to their destinations, and that links can be clicked without disruption.

More complext email infrastructure

Our guides are written on the assumption that Office 365 Exchange Online Protection (EOP) is used for your organization's MX record in DNS.

We are aware that in some scenarios, organizations receive email to another appliance or service, before it is received by Office 365.

In these cases, EOP will interpret the preceding appliance or service as the sender of the email, for any IP based filtering created in the Exchange whitelist guide.

In practice, this means that any IP based filtering will fail, since the IP addresses given in our guides will no longer apply for where the email is coming from.

If this is happening to you, please contact support, and we will help you configure a working solution.

Rule deployment has not finished

For any of the whitelist actions, we recommend that you try sending a simulated phishing email to yourself and possibly a few colleagues before going live with a full campaign.

Please note that it may take 30-60 minutes before Microsoft Office 365 starts enforcing your new or updated policy, so a little bit of patience is required for verification.

In on-premise Exchange environments, changes should be quicker to take effect. This could however depend on how Exchange is configured, and how many servers are involved in your cluster.

Check delivery status in Exchange

If you are using Office 365, the Microsoft Security Portal can help in detecting any problem with delivery.

First, try to go into «Review» in the main menu, and click «Quarantine»:

Then, see if you can find the simulated phishing email that has gone missing in the list of emails:

You may also click on a single email to view further details, including the delivery status and possibly «Quarantine reason».

If the email is indeed quarantined, and the reason is «High confidence phish», you will need to review the whitelisting in Office 365 guide.

As an alternative, the «User submissions» interface in the Microsoft security portal can also be useful for verifying whether your policy is enforced as expected.

To make an email show up in this panel, please use Microsoft's own Report message add-in to report a simulated phishing email, and see whether your rescan results in a «Phish simulation» equals «Yes» verdict.

In this case, you know whether the Office 365 whitelist guide has been applied as intended.

Verify spam policies in Gmail

With every policy configured as prescribed in our guide, it should be possible to completely bypass any spam filtering and warnings in Gmail, including even sending email on behalf of google.com:

To investigate whether your internal gateway IP settings are working as expected, check the email headers for an email with a spoofed sender domain, and verify that you see google.com having configured our IP as an internal address:

URL blocked in browser

Does the following error message appear when opening a link from a simulated phishing email?

From time to time, it may happen that the web domains used for simulated phishing end up on a block list somewhere. This is not surprising, since they to an outsider will look just like any other phishing page.

If your organization is licensed with Microsoft Defender for Office 365, you may experience that a link used with simulated phishing is working one day, but suddenly returns a block page like the one above.

Please verify that you have performed the whitelisting as described in our guide for Defender for Office 365, in particular the step on «Do not rewrite the following URLs».

In addition, you may also want to add the same domain names during the step on «Simulation URLs to allow», in the guide Office 365.

A possible workaround is to deploy a group policy to the registry on your organization's Windows devices, where Microsoft Edge SmartScreen is specifically allowed to access the domains used in phishing simulations:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\SmartScreenAllowListDomains]
"1"="sendfiend.com"
"2"="4qw.nl"
"3"="mediapage.eu"
"4"="nefflix.it"
"5"="onebrive.com"
"6"="passordmyndighet.no"
"7"="sitestoragesharing.nl"
"8"="telecomservic.es"
"9"="webhostnet.net"
"10"="aflassian.com"
"11"="ctrypo.com"
"12"="feedbackhubs.com"
"13"="fiendsend.com"
"14"="formswebs.com"
"15"="helloprecious.eu"
"16"="hotsocl.com"
"17"="maxtax.ch"
"18"="metafaceinsta.com"
"19"="microsott.no"
"20"="mstf.it"
"21"="nytinnes.com"
"22"="passwordauthority.eu"
"23"="preciousforever.eu"
"24"="publiclottery.eu"
"25"="qnaii.com"
"26"="qxqc.org"
"27"="salest0rce.com"

Finally, do not be confused if you see a slightly different block page than the one above, but rather like the ones below. There is a difference between when the block page says «Defender for Office 365» or «Defender SmartScreen» in the footer.

Please note, however, that thery may also exist block pages from Microsoft Defender SmartScreen which say that your organization has blocked access:

If you are seeing the «Defender SmartScreen» footer, and there is no mention of access blocked for the organization, you should contact support to let us know:

Should users experience a similar block page in the Google Chrome browser, you may consider deploying an enterprise allow rule as described on Google's support pages.

• Need further assistance to get things working? Please contact support for help!