Phishing Questionaire
This questionnaire helps us make sure your phishing simulation emails land in the inbox as intended. Part 1 confirms your environment is ready before we launch. Part 2 helps us pinpoint the cause quickly if a delivery issue comes up once the campaign is live. Please complete each part with the IT/email security administrator.
Part 1 - Before We Launch The Simulation
To configure whitelisting correctly on the first attempt, please confirm the following with your IT/email security team before the campaign goes out.
| Area | Question | Your Response / Notes |
|---|---|---|
| General Infrastructure & Simulation Setup | Which email security/filtering platform(s) protect your mailboxes - and is there a separate secure email gateway (SEG) in front of them (e.g., Microsoft 365 Defender/EOP, Google Workspace, Proofpoint, Mimecast, Barracuda, Cisco Secure Email, Zoho Mail, Zimbra, or other)? | |
| Sending Domain | Has our sending domain been added to your allow-list at the gateway/organization level - not just an individual mailbox’s safe-senders list? | |
| Sending IP Address(es) | Have our sending IP address(es) been added to your allow-list separately from the domain entry, since most gateways require both? | |
| Simulation Links / URLs | Have our simulation links/landing-page URL been excluded from URL rewriting and click-time/time-of-click sandboxing? | |
| Simulation Attachments | If this campaign uses attachments, have they been excluded from attachment sandboxing specifically - a separate exclusion list from spam scoring? |
\n
Part 2 - If an Issue Appears During Your Simulation
If emails are delayed, bouncing, or landing in spam once the campaign is live, the questions below map to each stage of a typical mail security pipeline. Working through them with the IT/email security administrator will help us isolate the cause quickly.
| Stage | Question | Your Response / Notes |
|---|---|---|
| B1. Network DoS Protection (Connection Filtering) | Could our sending IP(s) be hitting a connection-rate or DoS-protection limit on your gateway, and can your team check connection logs for throttling or drops during the send window? | |
| B2. Rate Controls (Throttling Policies) | Does your gateway enforce a sender-based rate limit - max emails per minute or hour from one IP or domain - and do your deferral (soft-bounce/4xx) logs show our traffic being throttled rather than rejected outright? | |
| B3. IP Analysis (Blocklists / Reputation) | Has our sending IP been checked directly against the reputation or blocklist services your gateway consults (e.g., Spamhaus, SORBS, vendor-proprietary lists), and is it on your gateway’s IP allow-list separately from the domain allow-list? | |
| B4. Sender Authentication (SPF / DKIM / DMARC) | Does your gateway enforce SPF/DKIM/DMARC and take action on failure (reject, quarantine, or tag), and is your DMARC policy set to strict alignment (p=quarantine or p=reject) that could be blocking our messages? | |
| B5. Recipient Verification | Does your gateway validate recipient addresses against your directory before accepting mail, and could outdated entries or distribution lists in the target list be causing rejections for a subset of recipients? | |
| B6. Virus / Malware Scanning (Attachment Sandboxing) | Has our domain/IP and templates been excluded from attachment sandboxing specifically - a separate exclusion list from spam scoring - and could automatic pre-opening of attachments be registering false ‘opened/clicked’ results? | |
| B7. Custom Policy / Mail Flow Rules | Are there custom mail flow rules or keyword filters - for example, flagging terms like ‘password’ or ‘urgent action required’ - that could be intercepting our content, and have rule-match audit logs been checked for the campaign window? | |
| B8. Spam Fingerprint Analysis | Does your gateway use fingerprint or hash-based detection against a shared spam/phishing database, and can this be bypassed for allow-listed senders, or does it apply regardless of sender reputation? | |
| B9. Intent Analysis (Phishing Heuristics) | Does your gateway run intent-based or behavioral phishing detection - urgency language, credential-harvesting patterns - and does allow-listing our sender bypass this layer, or does it operate independently of sender trust? | |
| B10. Image Analysis | Does your gateway analyze embedded images for spam indicators, and has this layer specifically been confirmed to permit our templates’ logo and graphic assets, separate from general spam scoring? | |
| B11. Bayesian Analysis (Adaptive Filtering) | Does your gateway use Bayesian or adaptive filtering that learns from prior classifications, and is there a way to exclude our sender/domain from this scoring entirely, in case repeated campaigns are training it to flag our content? | |
| B12. Spam Scoring | What spam score threshold triggers rejection or quarantine on your platform, and is our sending domain/IP fully exempt from spam scoring as a trusted sender, or does it only receive a reduced score that could still cross the threshold? | |
| C. Proxy, URL Rewriting & Sandboxing | Has our tracking/landing-page domain been explicitly excluded from any link-rewriting or time-of-click sandboxing tool you use (e.g., Safe Links, URL Defense, URL Protect), since automated pre-fetching can register false clicks or block genuine access? | |
| D. Delivery Logs & Evidence | Can your team share message trace/mail flow logs - and ideally, full headers for one affected message alongside one successfully delivered message - so we can see exactly where the two diverged? |
Attaching mail flow logs, any NDR/bounce-back messages, and the message headers noted above will usually let us narrow this down in a single round-trip.
\