Why Phishing Simulation Emails are Going to Spam (and How to Fix It Without Weakening Security)

If your phishing simulation emails are going to spam or quarantine, your results become hard to trust.

A 2% click rate might mean your users improved. Or it might mean a large part of the company never really saw the message. That is not just a reporting problem. It is a program design problem. This guide is for security engineers, IT admins, CISOs, and compliance leads who need reliable delivery for simulations without punching dangerous holes into mail security.

Safety note: This article is about defensive simulations and awareness measurement. It does not include instructions for real phishing, credential theft, or bypassing security controls for malicious purposes.

The short version

If phishing simulation emails are going to spam, the fix is usually not “relax the filters until everything lands in the inbox.”

The safer approach is:

• use a dedicated simulation domain or subdomain
• make SPF, DKIM, and DMARC alignment intentional
• keep content and redirect chains clean
• distinguish delivery telemetry from user behavior telemetry
• and, where needed, use surgical allowlisting rather than broad bypasses

That last point matters. Broad allowlisting is risky. But narrow, well-documented rules tied to a dedicated sending IP and known sender identities can be a perfectly reasonable long-term control.

Why phishing simulation deliverability breaks

Deliverability failures are rarely random. They are usually the predictable result of how the program was set up.

1) SPF, DKIM, or DMARC are not aligned with the visible sender

This is the most common cause.

If the domain users see in the From field does not line up with the domain authorized by SPF or signed by DKIM, mail systems have a good reason to be suspicious. Microsoft and Google both treat SPF, DKIM, and DMARC as core sender trust signals, and both emphasize alignment with the visible sender domain.

Common failure patterns:

• the visible From domain is not the domain you actually authenticated
• DKIM signing is missing or attached to the wrong domain
• DMARC exists, but alignment with the visible sender was never tested properly
• DNS changes were made, but not fully propagated or validated before the campaign launched

2) The simulation uses the main corporate domain

Using the primary company domain may look realistic, but it often creates unnecessary collisions.

You end up testing against the same anti-spoofing, impersonation, and anti-abuse controls that exist to protect that domain in production. That can be appropriate in some mature programs, but it is rarely the cleanest place to start.

For most teams, a dedicated simulation subdomain is the safer default.

3) The wrong kind of allowlisting was used

Allowlisting can become a security problem, especially when teams do things like:

• bypassing phishing protection globally
• allowlisting huge cloud provider IP ranges
• exempting entire sender infrastructures they do not control
• skipping scanning for broad categories of mail

But that is not the only model.

There is a big difference between broad bypasses and surgical delivery rules. If your provider sends from a dedicated IP and a small, known set of sender addresses or domains, narrowly scoped allowlisting can be acceptable and can even remain in place as part of the standard setup. AutoPhish’s own setup guidance documents exactly that model: campaigns are sent from a dedicated SMTP server/IP and a defined set of sender addresses, which makes precise filtering exceptions feasible without resorting to the kind of oversized bypasses that create real exposure.

4) Content and links trigger the same controls you expect users to trust

Simulation emails often contain:

• tracking links
• redirects
• urgency language
• brand-like phrasing
• login-style calls to action

That is not automatically wrong. But it does mean the mail will be inspected like suspicious mail. If the simulation depends on looking sketchy enough to beat your own controls, you are not really testing users anymore. You are testing whether your security stack catches obviously risky content.

5) Delivery data and behavior data are mixed together

If you cannot clearly separate:

• sent
• delivered
• opened
• clicked
• reported

then your reporting will mislead you. A weak campaign metric may reflect a user problem. Or a routing problem. Or a quarantine policy. Or a mailbox-provider-specific filtering issue. Those are very different remediation paths.

A safer way to improve phishing simulation deliverability

Step 1: Separate simulation sending from normal business email

For most organizations, the best starting point is:

• a dedicated simulation domain or subdomain
• dedicated authentication records
• a clean sending path that is easy to explain and audit
• no impersonation of real internal individuals unless there is a strong, reviewed reason

This reduces blast radius, reduces confusion, and makes troubleshooting much easier.

Step 2: Validate authentication before the first campaign

Before you conclude that “Microsoft is blocking us” or “Google is too aggressive,” verify the basics:

• SPF includes only the infrastructure that should send simulation mail
• DKIM is enabled and signing reliably
• DMARC is published and aligned with the visible sender domain
• test messages actually show the authentication results you expected

For a vendor-neutral refresher, Microsoft’s overview of email authentication is a useful baseline, and Google’s sender guidance makes the same basic point: reliable delivery starts with clean authentication and domain alignment.

If you are using AutoPhish, the help article on campaign email delivery and the DNS check are good starting points during setup.

Step 3: Use surgical allowlisting when needed, not blanket bypasses

This is the part many teams actually need.

A good exception is:

• specific
• documented
• reviewable
• easy to explain to auditors
• tied to a known sender identity or dedicated sending IP
• narrow enough that it does not accidentally trust unrelated traffic

A bad exception is “anything from this provider is fine.” A better exception is “simulation mail from this dedicated IP and this defined sender set should be delivered consistently for this awareness program.” That distinction matters.

In practice, the most defensible posture is often:

• keep normal scanning in place where possible
• avoid global “skip filtering” rules
• prefer narrow sender/IP-based rules over infrastructure-wide trust
• document exactly why the rule exists and what it covers
• review it periodically, but do not assume it must be temporary if it remains tightly scoped and still fits your control model

With AutoPhish, that model is achievable because campaigns are sent from a dedicated IP and a known sender footprint rather than from a giant shared mail pool.

Step 4: Design simulations to teach recognition, not to fight the gateway

The best phishing simulations do not need to “win” against every security control.

They need to help you measure whether people:

• notice suspicious cues
• avoid risky actions
• report suspicious messages quickly
• improve over time

That is a healthier design goal than trying to make every email look indistinguishable from a live attack at the filtering layer.

Step 5: Build reporting that can tell mail problems from people problems

A mature program should be able to answer:

• How many messages were actually delivered?
• Which provider or policy filtered them?
• Which departments saw lower visibility?
• Did users report the message?
• Did the same users improve over time?

That is what turns simulations from “a bunch of fake emails” into something operationally useful.

If you want that kind of structure, reporting matters just as much as content. See: Phishing Simulation Reporting: 12 Features Security Teams Should Compare.

What “good” allowlisting looks like

A good rule should be narrow enough that your security team can live with it and your auditors can understand it.

That usually means:

• it is limited to simulation sending infrastructure
• it is tied to known domains, sender identities, or a dedicated IP
• it does not trust unrelated mail from the same broader provider
• it does not create a blanket “always deliver, never scan” condition unless there is a very strong reason
• it is tracked as part of the awareness program design, not as a hidden workaround

This is also where provider architecture matters. If a platform sends from a shared pool used by many customers, long-term allowlisting gets harder to justify. If it sends from a dedicated IP with a small, documented sender surface, narrow allowlisting becomes much easier to defend.

A quick checklist when phishing simulation emails go to spam

Use this checklist when your results look suspicious.

Authentication and sender identity

• Is the visible From domain the one you intended to use?
• Are SPF, DKIM, and DMARC aligned with that domain?
• Did anything change recently in DNS or sending configuration?
• Are test headers showing the results you expected?

Sending architecture

• Are you using a dedicated simulation subdomain?
• Is the sending infrastructure isolated from production mail?
• Is the sender reputation history stable?
• Are you relying on a shared sender pool, or a dedicated IP?

Rules and exceptions

• Did someone create a broad bypass to “just make it work”?
• Could the rule be narrowed to exact sender identities or a dedicated IP?
• Is the exception documented and reviewable?
• Are you still scanning wherever practical?

Content and measurement

• Are the URLs clean and predictable?
• Are there unnecessary redirect chains?
• Are you measuring delivery separately from engagement?
• Are you tracking report rate and time-to-report, not just clicks?

FAQ

Should we whitelist phishing simulation emails?

Sometimes yes.

What you want to avoid is broad trust. What is often acceptable is narrow trust: a dedicated sending IP, known sender identities, a clearly documented purpose, and no oversized bypass that weakens the rest of your mail security.

Should those rules be temporary?

Not necessarily.

Broad emergency exceptions should be temporary. But surgical, well-scoped rules can remain in place if they are part of the approved operating model, still appropriately narrow, and periodically reviewed.

Can we run simulations from our main corporate domain?

You can, but it is usually higher-friction and higher-risk.

A dedicated simulation subdomain is easier to authenticate, easier to explain, and less likely to collide with your production anti-spoofing and impersonation controls.

Does better deliverability reduce realism?

No.

Good simulations measure recognition and reporting behavior. They do not need sloppy infrastructure or unsafe bypasses to be useful.

How do we prove results are trustworthy?

Document both sides of the system:

1. what was supposed to be delivered
2. what users actually did after delivery

That is far more defensible than showing a click-rate chart without delivery context.

Ready to run simulations that measure resilience instead of mail flow accidents?

AutoPhish is built for teams that want safe simulations, privacy-aware reporting, and audit-friendly evidence without heavy operational overhead.

If you need precise setup guidance, see our help article on how to make sure campaign e-mails are received well.

Sign Up

Image credit: Photo by Krsto Jevtic on Unsplash.