How can a cybersecurity company safely send malicious files to clients for testing purposes without being blocked?
Matthew Whittaker
Co-founder & CTO, Suped
Published 3 Jul 2025
Updated 19 Aug 2025
6 min read
Cybersecurity companies face a unique challenge when it comes to email deliverability: the need to intentionally send what are, by all standard definitions, malicious files to their clients. This is often part of a contracted service, such as testing the client's defenses for certifications like Cyber Essentials Plus. The irony is, the very systems designed to protect clients often block these legitimate test emails, leading to deliverability issues for the security firm.
The core problem is that email security filters, including anti-malware and anti-phishing solutions, are doing their job correctly by flagging or blocking emails containing known threats. When these emails are blocked, it affects the sender's reputation, leading to increased bounce rates, blacklisting (or blocklisting) of sending IPs or domains, and general deliverability woes for their regular, non-test communications. It's a delicate balance to strike between rigorous security testing and maintaining a healthy sender reputation.
The impact of email security filters on testing
The primary hurdle in sending malicious files for testing is bypassing the very security mechanisms you aim to evaluate. Email filters, including sophisticated anti-virus engines and sandboxing technologies, are designed to detect and quarantine suspicious attachments or links. These systems don't differentiate between a genuinely malicious payload and a test payload sent with explicit permission, at least not automatically.
When your test emails are consistently blocked, your sending domain and IP addresses can quickly acquire a negative reputation. This leads to your legitimate emails, such as invoices, proposals, or marketing communications, being flagged as spam or outright rejected. This can result in your domain being placed on an email blacklist (or blocklist), making it challenging to reach any inbox, not just those of your testing clients. Understanding what happens when your domain is on an email blacklist is crucial for preventing long-term damage.
Furthermore, an email service provider (ESP) might detect this irregular sending behavior. Sending files that trigger their spam or abuse filters can lead to warnings, temporary suspensions, or even termination of your account, especially if these activities cause email deliverability issues for their wider network. It is important to remember that these providers have their own reputation to uphold with internet service providers (ISPs) and email recipients.
Technical strategies for safe delivery
To safely send malicious files for testing, a multi-faceted approach is required, prioritizing isolation and clear communication. The goal is to ensure the test files reach their intended recipients for evaluation without negatively impacting your core email operations.
Dedicated infrastructure
Using separate, dedicated infrastructure for sending test files is a critical first step. This prevents your main company domains and IPs from being flagged. Consider the following options:
Separate domain: Register a new domain specifically for testing purposes (e.g., securitytest-yourcompany.com). This domain will absorb any negative reputation from the test sends, protecting your primary brand.
Dedicated IP addresses: Acquire dedicated IP addresses that are distinct from those used for your regular email communications. You might even consider dynamic IPs from cloud providers for each test, as some cybersecurity vendors do. For instance, some companies use new Azure IP addresses for each client testing scenario to avoid account blocks and minimize long-term reputation damage. Remember to warm up your IP address even for test sends if you plan to reuse them.
Custom mail server: Set up a lightweight mail server (e.g., on an EC2 or Google Cloud VPS) specifically for these test emails. This gives you full control over the sending environment.
Client-side whitelisting and communication
Even with dedicated infrastructure, clear communication and client-side whitelisting are essential.
Pre-notify clients: Inform clients about the exact sender domain, IP addresses, and scheduled time for the test emails. This allows them to prepare their systems and anticipate the incoming test. Share this information with their IT and security teams.
Whitelisting: Instruct clients to whitelist your dedicated sending domain and IP addresses in their email security gateways (e.g., Mimecast, Proofpoint, or Microsoft Defender). This ensures the email itself is delivered, allowing their internal systems to perform the actual malware detection test. You can provide specific instructions for identifying which spam filter a company uses.
Dedicated email addresses: Ask clients to set up specific, isolated email addresses for receiving these test files. This minimizes the risk to their primary inboxes.
For the actual malicious payloads, leverage commonly recognized test files. The EICAR test file is a standard, harmless file that antivirus programs detect as malware. Using such files allows you to verify if the client's security systems are correctly identifying and blocking (or quarantining) malicious content without actually deploying a harmful threat. Another approach for more advanced testing could involve using a malware sandbox to analyze the behavior of suspicious files in a controlled environment.
Reputation management and technical hygiene
Maintaining your overall email sender reputation is paramount, even while conducting these specialized tests. It prevents your primary email channels from being affected by the necessary, but often suspicious, test traffic.
Segment sending: Ensure your normal business communications are sent from completely separate domains and IP addresses. This isolation is crucial to prevent your main domain from being blacklisted (or blocklisted).
DNS records: Properly configure SPF, DKIM, and DMARC records for both your primary and test domains. This validates your sending identity and helps prevent your emails from being flagged as spoofed or fraudulent. Even for throwaway domains, having valid DNS records improves the chances of initial delivery.
Monitoring: Regularly monitor your sending reputation using tools like Google Postmaster Tools for your main domains. For your test domains/IPs, assume they will incur a poor reputation, and be prepared to discard them after use.
It's a continuous process to keep your email streams distinct and to manage the perception of your sending entities, especially when you are intentionally sending content that triggers security alerts. Review NCSC guidance on mitigating malware for broader security insights.
Communication and collaboration with clients
Beyond technical configurations, maintaining strong communication channels with both your clients and relevant email security providers is key.
For clients, ensure they fully understand the nature of the tests, the files involved, and the purpose. Provide them with clear, step-by-step instructions on how to prepare their systems, including any necessary whitelisting of your dedicated sending domains or IP addresses. It helps if you can provide them with a pre-requisite document detailing how to bypass certain types of filtering for your IPs, which some large anti-virus vendors do for their phishing tests. This preemptive communication can prevent unnecessary panic or incident response actions on their end.
Regarding email security providers and ISPs, directly contacting their postmaster teams may be beneficial if you encounter persistent blocking issues with your dedicated test infrastructure. Some providers, upon vetting your legitimate use case as a cybersecurity company, may be willing to offer specific guidance or even partial whitelisting for your designated test IPs. This is often an exceptional circumstance, requiring proof of your operational needs and strict adherence to their guidelines.
Summary
Safely sending malicious files for cybersecurity testing is a balancing act, requiring meticulous planning and execution. By isolating your testing infrastructure, maintaining rigorous sender hygiene, and fostering open communication with your clients, you can fulfill audit requirements without compromising your essential email deliverability. The key is to treat your test sending operations as entirely separate from your regular business communications.
While challenging, mastering this niche aspect of email sending is vital for cybersecurity companies to effectively demonstrate and improve their clients' defensive capabilities.
Views from the trenches
Best practices
Use a completely separate, distinct domain and dedicated IP addresses for all cybersecurity testing emails to isolate reputation.
Always pre-notify clients about the exact sender domain, IPs, and scheduled test times to allow for whitelisting and preparation.
Provide clear, concise instructions to clients on how to whitelist your testing domain and IPs in their specific email security gateways.
Utilize harmless test files like EICAR or similar industry-recognized non-malicious payloads for general detection tests.
Common pitfalls
Sending malicious test files from your primary company domain or shared IP addresses, leading to widespread blocklisting.
Failing to communicate with clients about upcoming tests, causing their security systems to block legitimate assessments.
Not properly configuring SPF, DKIM, and DMARC for your testing domains, making the test emails appear less legitimate.
Reusing test domains or IP addresses that have already accumulated a negative reputation, leading to consistent blocking.
Expert tips
Consider spinning up new, dynamic IP addresses from cloud providers like AWS EC2 or Azure for each client test to ensure a clean slate every time.
Reach out to your client's email security vendor (e.g., Proofpoint, Mimecast) if known, to establish a communication channel for your testing activities.
Advise clients to create specific whitelisting rules that allow the test payload through but still trigger their internal detection mechanisms.
For advanced scenarios, research if the NCSC or similar regulatory bodies provide specific guidelines for conducting such tests without deliverability issues.
Expert view
Expert from Email Geeks says they had a client, an antivirus vendor, who provided prerequisite documentation detailing how to bypass certain filtering types for their IPs for major providers, mainly for phishing tests.
2022-11-09 - Email Geeks
Expert view
Expert from Email Geeks says for actual virus/malicious file testing, the antivirus vendor would spin up a new Azure IP for each client, and Microsoft was aware of their activities, preventing account blocks.
Azure IP addresses for each client testing scenario to avoid account blocks and minimize long-term reputation damage. Remember to warm up your IP address even for test sends if you plan to reuse them.
EC2 or 
Google Cloud VPS) specifically for these test emails. This gives you full control over the sending environment.
Mimecast, 
Proofpoint, or 
Microsoft Defender). This ensures the email itself is delivered, allowing their internal systems to perform the actual malware detection test. You can provide specific instructions for identifying which spam filter a company uses.
