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](https://help.autophish.io/en/article/how-to-make-sure-campaign-e-mails-are-received-well-h4fd7a/) 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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about) is a useful baseline, and [Google’s sender guidance](https://support.google.com/a/answer/81126?hl=en) 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](https://help.autophish.io/en/article/how-to-make-sure-campaign-e-mails-are-received-well-h4fd7a/) and the [DNS check](https://autophish.io/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](https://autophish.io/blog/phishing-simulation-reporting-12-features-security-teams-should-compare-dashboards-metrics-and-audit-evidence).

## 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](https://help.autophish.io/en/article/how-to-make-sure-campaign-e-mails-are-received-well-h4fd7a/).

[Sign Up](https://autophish.io/register)

_Image credit: Photo by [Krsto Jevtic](https://unsplash.com/@krstoj) on [Unsplash](https://unsplash.com/photos/g4Ry1F4AZ5Q)._

If you are considering **ad hoc phishing testing**, you are usually trying to answer one practical question:

> **Do we need a full phishing simulation program yet, or do we just need one well-scoped test right now?**

That is a fair question. A one-off campaign can be useful.

But it can also create false confidence, messy reporting, and unnecessary employee friction if you use it as a substitute for a real awareness workflow.

This is the difference security teams should keep in mind:

- **Ad hoc phishing testing** is useful for a specific decision, validation step, or baseline.
- **A phishing simulation program** is useful for ongoing behavior change, trend tracking, and governance.

Those are not the same thing.

> Safety note: this article is about defensive phishing simulations and awareness measurement. It does not include instructions for real phishing, credential theft, or attack operations.

## What ad hoc phishing testing actually means

In practice, ad hoc phishing testing usually means a campaign that is launched for a narrow reason rather than as part of a fixed monthly or quarterly cadence.

Examples include:

- validating whether employees recognize a specific lure pattern
- checking whether a new reporting workflow is being used
- running a baseline before buying a platform
- testing a newly onboarded business unit after a merger or restructuring
- gathering evidence for a specific internal review

That can be perfectly reasonable.

The mistake is assuming that one-off testing gives you the same value as a repeatable awareness program.

It does not.

A single campaign can show you a moment in time. It usually cannot show whether behavior is improving, whether one result was distorted by deliverability, or whether the organization has built stronger reporting habits.

## When one-off phishing simulations make sense

### 1) You need a fast baseline before selecting a platform

Sometimes a security team is early in its phishing-awareness journey and needs a quick read on current risk.

A tightly scoped one-off campaign can help answer questions like:

- Are users reporting suspicious mail at all?
- Which teams need follow-up first?
- Is there obvious confusion around common lure types?
- Does leadership need more evidence before approving a broader rollout?

In that situation, ad hoc phishing testing can be a useful diagnostic tool.

It is especially helpful if you are still comparing operating models, such as the tradeoff between manual campaigns and automation. AutoPhish’s guide to [automated phishing testing vs. manual campaigns](https://autophish.io/blog/automated-phishing-testing-vs-manual-campaigns-which-is-best-for-your-business) covers that decision in more detail.

### 2) You are validating a specific control change

One-off tests can also make sense after a meaningful change, for example:

- a new suspicious-mail reporting button
- updated internal finance approval procedures
- a rewritten employee security policy
- a post-incident remediation cycle

Here, the goal is not “run awareness forever with ad hoc sends.”

The goal is to verify whether a recent change actually improved behavior.

That is a good use case — as long as the campaign has a clearly stated purpose and success criteria.

### 3) You need a low-drama starting point

Some organizations are not ready for a full recurring program yet.

Maybe legal, HR, compliance, or a works council wants to see how the process will be governed first. Maybe the security team is small. Maybe leadership wants a pilot before committing to a broader program.

In those cases, one carefully designed campaign can be the least disruptive way to start.

The key phrase is **carefully designed**.

If the first experience feels punitive, confusing, or sloppy, your ad hoc test does not just produce weak data — it can also make a future recurring program harder to launch.

## When ad hoc phishing testing becomes a bad habit

### 1) When every campaign starts from scratch

If every one-off test requires fresh stakeholder debates, manual audience cleanup, manual reporting, and a custom explanation afterwards, the process will not scale.

The security team ends up doing repeated admin work without getting the benefits of a true program:

- trend data
- cleaner governance
- reusable reporting
- predictable employee communications
- easier leadership updates

At that point, “ad hoc” is often just another word for “we have not operationalized this yet.”

### 2) When the result gets over-interpreted

One campaign can tell you something.

It cannot tell you everything.

For example, a single test might be skewed by:

- messages landing in junk or quarantine
- timing issues during a holiday or busy finance window
- unusual organizational context
- a lure theme that was either too obvious or too niche

This is why reporting quality matters so much. If you want a cleaner evaluation framework, AutoPhish’s article on [phishing simulation reporting features](https://autophish.io/blog/phishing-simulation-reporting-12-features-security-teams-should-compare-dashboards-metrics-and-audit-evidence) is the right checklist.

### 3) When it is used as a compliance shortcut

A one-off phishing test can support a compliance conversation.

It is not the compliance program.

If you need to show governance, consistency, and evidence over time, one isolated campaign is rarely enough. High-authority guidance like [NIST SP 800-53 Rev. 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) treats awareness and training as ongoing control activity, not a one-time stunt.

That matters because many teams accidentally create a brittle story:

- one test was run
- one dashboard screenshot was saved
- nobody can explain what changed afterwards

That is weak evidence.

### 4) When it undermines employee trust

One-off campaigns can be more politically sensitive than recurring programs because employees have no stable frame for what is happening.

Without clear guardrails, an ad hoc test can feel random or personal.

That is one reason privacy posture matters from day one. If your environment includes strong employee representation or strict internal review, AutoPhish’s guide to [privacy-friendly phishing training](https://autophish.io/blog/privacy-friendly-phishing-training-works-councils-consent-and-gdpr-essentials) is worth building into the rollout plan.

## What to compare if you may only need occasional testing

If you are buying for ad hoc phishing testing now, but may expand later, do not evaluate platforms like a one-day-only tool.

Evaluate them as a possible path from **one-off validation** to **repeatable program**.

### 1) Setup speed without long-term lock-in

For occasional testing, you do want fast setup.

But “fast setup” should not mean:

- confusing sender setup
- fragile user imports
- manual data cleanup every time
- no reusable approval workflow

A good platform should let you launch a one-off campaign quickly **and** keep the foundation in place if you decide to run again.

### 2) Reporting that explains context, not just clicks

For ad hoc phishing testing, reporting needs to answer:

- who was in scope
- what was actually delivered
- what users did
- what follow-up happened
- what caveats affected the result

If the only output is a click chart, you will struggle to use the result with leadership, compliance, or even your own future self.

### 3) Guardrails that keep the test boring in the best way

Security teams sometimes underestimate how much operational pain comes from “creative” one-off tests.

The better approach is duller and safer:

- clear exclusions for sensitive groups
- non-punitive defaults
- no risky data collection
- defined approval before launch
- immediate training or reporting guidance after the interaction

A good platform should make the safe version of the campaign easier than the reckless version.

### 4) A clear path from ad hoc to recurring

This is the most important buying question.

Ask vendors:

- Can this one-off campaign become a recurring workflow later?
- Will our reporting stay comparable over time?
- Can we reuse templates, audiences, and approvals?
- Can we shift from named to anonymized reporting if internal expectations change?
- How much extra admin work appears when we move from one campaign to twelve?

If the answer is vague, you may be buying a short-term convenience that becomes a long-term migration project.

## A practical decision rule for security teams

If your need sounds like this, ad hoc phishing testing is usually enough for now:

- “We need a baseline.”
- “We need to validate one process change.”
- “We need a pilot before broader rollout.”
- “We need to check one newly added business unit.”

If your need sounds like this, you probably need a real phishing simulation program instead:

- “We need evidence over time.”
- “We want behavior change, not just one campaign result.”
- “We want less manual admin every quarter.”
- “We need predictable reporting for leadership or compliance.”
- “We want awareness to survive staff turnover and busy periods.”

That line matters because the wrong operating model creates waste in both directions:

- a full-blown program may be too much if you only need one decision-supporting test right now
- a one-off tool or process may be too weak if you already know this needs to become an ongoing control

## The best ad hoc test is designed like the first step of a program

This is the simplest way to avoid rework.

Even if you are only launching one campaign today, treat it like the beginning of a mature process:

1. define the purpose
2. define success criteria
3. agree on privacy and approval rules
4. capture context in the report
5. decide what happens next if the result is weak

That way, the campaign is still useful whether you stop after one test or scale into a recurring program.

## FAQ

### Is ad hoc phishing testing a good replacement for regular awareness training?

Usually no.

It can be useful for a baseline, pilot, or control check, but it rarely delivers the consistency, evidence trail, and behavior-change loop of a recurring phishing simulation program.

### What is the biggest risk with one-off phishing simulations?

Overconfidence.

Teams often treat one campaign as a definitive measure, even though the result may be distorted by timing, deliverability, or scenario choice.

### Are self-service phishing test platforms a good fit for occasional use?

They can be — if setup, reporting, and guardrails are strong.

The key question is whether the platform can support a one-off campaign without forcing you into messy manual work, and whether it can grow into a recurring workflow later.

### Can ad hoc phishing testing help with compliance evidence?

It can contribute evidence, but it should not be presented as a complete compliance answer.

A stronger compliance story usually requires repeatability, approvals, reporting consistency, and documented follow-up over time.

### What should we measure in a one-off campaign?

At minimum:

- delivery quality
- report rate
- click or interaction behavior in context
- follow-up actions
- any caveats that make the result less reliable than it looks

## Want one-off phishing testing that can grow into a real program?

AutoPhish helps security teams run safe phishing simulations with low admin overhead, privacy-aware reporting, and a clear path from pilot campaigns to repeatable awareness workflows.

[Sign Up](https://autophish.io/register)

Mid-sized companies (roughly 100–5,000 employees) sit in an awkward place for security awareness and phishing simulations:

- You’re **too big** for ad-hoc “send a few tests and call it training.”
- You’re **too small** to run an internal phishing tooling stack like a mini security lab.
- You still have enterprise-grade constraints: compliance reviews, works councils, privacy requirements, and a very real risk of breaking email security controls.

This guide is a vendor-neutral evaluation framework for **phishing simulation platforms for mid-sized companies**. It’s written for security engineers, IT admins, CISOs, and compliance leads who want measurable risk reduction *and* an audit-friendly story.

## The mid-market reality: “We need results” + “We can’t afford surprises”

In mid-sized environments, the failure modes are predictable:

- A “quick test” triggers HR escalation (“Are we being tricked at work?”).
- An overly realistic simulation creates helpdesk load and loss of trust.
- The email/security team gets pressured into broad allowlisting “just so it delivers.”
- Reporting becomes a spreadsheet exercise that doesn’t stand up in an audit.

A platform that works in practice is one that makes it easy to run **repeatable, controlled, and explainable** simulations.

If you want an authoritative reference on building a structured awareness program (governance, lifecycle, roles, outcomes), NIST’s learning program guidance is a solid baseline: [NIST SP 800-50 Rev. 1: Building a Cybersecurity and Privacy Learning Program](https://csrc.nist.gov/pubs/sp/800/50/r1/final).

## What to compare (beyond “templates” and “click rate”)

Here’s the checklist that tends to matter most in mid-sized deployments.

### 1) Guardrails: can you run simulations without creating new risk?

Ask how the platform prevents common “training became an incident” outcomes.

Look for capabilities such as:

- **Safe landing pages** and coaching flows (instead of high-friction, high-risk “gotcha” patterns)
- **Controlled realism** (enough to teach recognition, not enough to mimic an attack end-to-end)
- **Built-in guardrails** against collecting sensitive data (e.g., avoiding capture of passwords or personal data during training)
- **Role-based segmentation** that avoids targeting individuals in a way that feels punitive

A useful gut check question:

> “If Legal, HR, and Works Council asked us to explain this program, could we do it confidently in 5 minutes?”

### 2) Privacy and employee trust: can you measure behavior without a surveillance program?

Mid-sized companies often have EU/privacy constraints even when they’re not “big enterprise.” You’ll want a platform that supports:

- clear participant notices and transparent program messaging
- **data minimization** (collect only what you truly need)
- retention controls (how long events and identifiers are stored)
- optional anonymization/pseudonymization depending on your governance model

If this is a frequent internal discussion where you are, see: [Privacy-Friendly Phishing Training: Works Councils, Consent, and GDPR Essentials](https://autophish.io/blog/privacy-friendly-phishing-training-works-councils-consent-and-gdpr-essentials).

### 3) Reporting: can you produce evidence that a CISO and an auditor will accept?

For mid-sized companies, reporting is not “nice to have.” It’s what keeps the program funded.

At minimum, you want reporting that cleanly separates:

- **delivery reality** (did users receive the simulation?)
- **behavior signals** (open/click/report, depending on your model)
- **learning loop** (follow-up coaching completion, repeat patterns, improvement over time)

Practical evaluation questions:

- Can you export results in a format your org can retain as audit evidence?
- Can you show *trends* by department/location without turning it into public shaming?
- Can you prove that “low clicks” wasn’t just “mail went to quarantine”?

### 4) Operational fit: can IT run it without becoming the bottleneck?

A mid-sized program fails when it depends on one person’s heroics.

Look for:

- straightforward onboarding (domains/senders, user import/sync)
- stable integrations with your identity provider and email stack
- predictable admin workflows (campaign scheduling, exclusions, segmentation)
- low helpdesk overhead (clear user-facing guidance and internal comms support)

Also evaluate the *ongoing* workload, not just initial setup:

- How many hours per month does it take to run?
- Who needs access, and what roles/permissions exist?
- Can you standardize campaigns so they don’t become bespoke one-offs?

### 5) Program design support: does the platform help you avoid “random testing”?

The goal is not to “catch people.” The goal is to build resilient behavior.

A mature platform should support a repeatable loop:

1) baseline measurement
2) targeted coaching
3) reporting and governance review
4) iteration

If you want a reference architecture for a program-first approach (not an attack-toolkit mindset), the [training platform](https://autophish.io/training-platform) framing is a good place to start.

## A simple scoring rubric for mid-sized evaluations

When you shortlist platforms, use a scoring rubric that reflects *your* constraints.

Example weighting (adjust as needed):

- **Safety + guardrails (30%)**: reduces the chance of harm, confusion, or risky configurations
- **Reporting + evidence (25%)**: supports governance, budgeting, and audits
- **Privacy + trust (20%)**: prevents escalation and long-term resistance
- **Operational workload (15%)**: minimizes ongoing admin and helpdesk cost
- **Coverage + extensibility (10%)**: email-first today, other channels and integrations as needed

This avoids the classic trap where “template count” becomes the procurement decision.

## Common mid-market mistakes (and how to avoid them)

### Mistake 1: treating click rate as the only success metric

Click rate is easy to measure, but it’s not the whole story.

Even for a simple program, mid-sized orgs do better by tracking at least:

- reporting rate (how often users report suspicious messages)
- time-to-report (how quickly issues surface)
- repeat patterns (do the same themes cause repeated failures?)

### Mistake 2: optimizing for realism instead of learning

If the simulation feels like a trick, you may get “engagement,” but you’ll lose trust.

Mid-sized programs win by being:

- realistic enough to teach recognition and reporting
- safe enough to be explainable to non-security stakeholders
- consistent enough to show improvement over time

### Mistake 3: broad allowlisting to force deliverability

“Just bypass the filters” is the fastest way to create a real security gap.

Prefer platforms and setups where you can achieve reliable measurement **without** weakening phishing protections for real mail.

## A pragmatic 30-day pilot plan (mid-sized friendly)

If you’re evaluating platforms right now, here’s a pilot structure that usually works without drama.

### Week 1: align stakeholders and define guardrails

- Confirm scope: who is in/out (contractors, shared mailboxes, executives, etc.)
- Write down program guardrails (what you will *not* simulate)
- Decide how results will be used (individual coaching vs team-level reporting)

### Weeks 2–3: run a baseline simulation + reporting workflow

- Run a single, low-risk baseline campaign
- Validate deliverability and reporting accuracy
- Test the “human workflow”: comms, support, escalation handling

### Week 4: produce a governance-ready summary

Your pilot deliverable should be something you can take to leadership:

- what you ran (high level)
- what you measured
- what improved (or what the baseline implies)
- what you’ll do next (repeatable plan)

## FAQ

### Are phishing simulations “required for compliance”?

Some frameworks and standards expect organizations to run security awareness and training programs, and many audits ask for evidence that the program is active and improving.

But don’t treat any platform as a magic “compliance checkbox.” Focus on building an explainable program with measurable outcomes and defensible reporting.

### How often should mid-sized companies run phishing simulations?

It depends on risk and maturity, but consistency matters more than intensity.

Many mid-sized organizations succeed with a predictable cadence (e.g., monthly or quarterly) plus targeted follow-ups after major changes (new tooling, new attack patterns, incident learnings).

### Can we run simulations without collecting sensitive personal data?

Yes — and you generally should.

Look for platforms that support data minimization, clear retention controls, and reporting models that don’t require storing more personal data than necessary to improve outcomes.

### What should we do if HR or a works council pushes back?

Treat that as normal governance, not an obstacle.

Bring them in early, explain guardrails, show what data is (and isn’t) collected, and align on how results are used. Programs that prioritize transparency tend to scale better.

## Ready to run a mid-market friendly phishing simulation program?

AutoPhish is built for teams that want **safe simulations**, **audit-friendly reporting**, and **low operational overhead** — without turning awareness into a surveillance program.

[Sign Up](https://autophish.io/register)

_Image credit: [Computer locked](https://commons.wikimedia.org/wiki/File:Computer_locked.jpg) by [Juan Pablo Olmo](https://www.flickr.com/people/41999914@N00), licensed under [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/), via [Wikimedia Commons](https://commons.wikimedia.org/)._

Many organizations discover phishing simulations the same way they discover DLP or device management: it’s already “included” in something they pay for. Email security suites and productivity platforms increasingly ship a built-in phishing simulation feature. On paper, this sounds perfect—one vendor, one portal, one invoice.

In practice, bundled simulation tools can be a great starting point, but they’re not always the best long-term choice. Security engineers and CISOs eventually run into constraints around guardrails, reporting evidence, privacy expectations, and the operational reality of running frequent campaigns.

This article explains how to evaluate **phishing simulation tools bundled into an email platform** versus dedicated platforms, so you can make a decision you’ll still be happy with after the first quarter of “let’s do this properly.”

## What counts as “bundled” vs “dedicated”?

**Bundled** usually means phishing simulation is a feature inside a broader suite (email security, productivity, endpoint, or security platform). You manage simulations in the same ecosystem as mail protection and user administration.

**Dedicated** means phishing simulations and awareness workflows are the core product. The platform is built for recurring campaigns, targeted follow-ups, privacy controls, and reporting as a first-class output.

Some suites are more capable than others. For example, Microsoft documents its approach as “Attack simulation training” in Defender for Office 365: [Get started using Attack simulation training](https://learn.microsoft.com/en-us/defender-office-365/attack-simulation-training-get-started).

## The decision framework: 6 questions that reveal the right answer

### 1) What is your real goal: “run a test” or “change behavior at scale”?
If your goal is a one-off baseline, bundled can be enough.

If your goal is continuous improvement—measurable reporting habits, reduced repeat susceptibility, and audit-friendly evidence—dedicated platforms tend to win because they’re designed for frequency, segmentation, and consistent reporting.

If you’re still deciding how automated you want your program to be, this overview can help: [Automated phishing testing vs. manual campaigns](https://autophish.io/blog/automated-phishing-testing-vs-manual-campaigns-which-is-best-for-your-business).

### 2) Can you measure the outcomes that matter (not just clicks)?
Click rate is easy to produce and easy to misinterpret.

A platform is only useful for risk reduction if it helps you track:

- **Report rate** (do users report suspicious messages?)
- **Time-to-report** (how quickly do they escalate?)
- **Repeat susceptibility** (who needs targeted coaching?)
- **Trends over time** (rolling improvements, not one month’s noise) 

> [See how AutoPhish does reporting here](https://help.autophish.io/en/article/phishing-campaign-reports-analytics-ymehoj/)

If you want a concrete checklist for what reporting should look like in practice, use: [Phishing simulation reporting: 12 features security teams should compare](https://autophish.io/blog/phishing-simulation-reporting-12-features-security-teams-should-compare-dashboards-metrics-and-audit-evidence).

### 3) Do you have guardrails that keep simulations ethical and safe?
The most expensive awareness program is the one that creates internal backlash.

Bundled tools sometimes optimize for “quick launch” rather than program governance. Evaluate whether the platform supports guardrails such as:

- Avoiding sensitive themes that can trigger HR escalation
- Limiting data collection to what you actually need
- Clear training moments (without humiliation)
- Controls for cohort targeting and difficulty ramping

Guardrails aren’t just culture. They’re also risk management.

### 4) How hard is it to operate monthly (or quarterly) campaigns?
The tool you choose determines whether your program becomes routine or a recurring fire drill.

Ask:

- Can you schedule recurring simulations?
- Can you target cohorts by role/business unit and rotate scenarios?
- Can you export consistent reports for leadership and audit evidence?
- How much manual work is required per campaign?

Bundled tools often work well for “run a campaign now.” Dedicated platforms are often better at “run a program continuously.”

### 5) Can you meet privacy expectations (GDPR accountability, works councils, and internal policy)?
Avoid claiming that a tool “makes you compliant.” It doesn’t.

What matters is whether you can run a program aligned to your organization’s privacy expectations:

- Minimal personal data collection
- Clear retention periods
- Role-based access for administrators
- Options to anonymize or aggregate reporting when appropriate

If privacy governance is a core constraint, start with: [Privacy-Friendly Phishing Training: Works Councils, Consent, and GDPR Essentials](https://autophish.io/blog/privacy-friendly-phishing-training-works-councils-consent-and-gdpr-essentials).

### 6) What happens if you change your email platform or security stack?
Bundled tooling can create hidden lock-in:

- Metrics and historical baselines live inside the suite
- Export formats may not be designed for long-term trending
- You may be forced to re-baseline after a platform change

Dedicated platforms can make the awareness program more portable and stable across infrastructure changes.

## Common scenarios (and which choice usually fits)

### “We already have a suite. We just need something quickly.”
Start bundled. Run a safe baseline and validate your internal comms, reporting workflow, and escalation paths.

### “We need audit-friendly evidence and trend reporting every month.”
Lean dedicated. Reporting consistency, segmentation, and repeatable workflows matter more than “included licensing.”

### “We have strict privacy expectations (works council / employee monitoring concerns).”
Choose the product that gives you the most control over data minimization, retention, and reporting granularity. In many orgs, that pushes toward dedicated platforms. See how [AutoPhish handles Anonymization and Privacy](https://autophish.io/anonymization)

## FAQ

### Is a bundled phishing simulation tool ‘good enough’?
It can be—especially for a pilot or a baseline. The gap appears when you need higher-frequency campaigns, cohort targeting, and evidence-grade reporting over time.

### Will a dedicated platform reduce risk more than a bundled tool?
Not automatically. Risk reduction comes from program design: frequency, guardrails, measurement, and follow-up. Dedicated platforms often make those practices easier to sustain.

### Can we use both?
Yes. Some teams start bundled to prove the program internally, then standardize on a dedicated platform for consistent reporting and broader coverage.

## Next step

If you want phishing simulations that are designed as a repeatable program—segmented, automated, and measurable with reporting your stakeholders can trust—AutoPhish is built for that operational reality.

[Sign Up](https://autophish.io/register)

Security teams search for a “GoPhish alternative” for a good reason: GoPhish is well-known, easy to find, and (for many orgs) tempting as a quick way to start phishing simulations.

But most teams don’t actually want “a phishing toolkit.” They want a repeatable awareness program that runs with **minimal operational overhead**: predictable scheduling, deliverability visibility, clean reporting, and governance that doesn’t depend on a single hero admin.

This article breaks down what to evaluate when you’re replacing (or choosing not to run) GoPhish—so you can deliver measurable awareness outcomes **and** make day‑2 operations boring (in the best way).

## When an “open-source phishing tool” is the wrong fit

Open-source phishing simulation tools can be useful in a lab or for a very narrowly scoped awareness exercise. The problem is not that they’re “bad”; it’s that most organizations need the *program* around the tool.

If you run a self-hosted phishing framework, you’re taking responsibility for:

- **Infrastructure and deliverability:** domains, mail routing, reputation, and troubleshooting.
- **Access control and auditability:** who can launch what, who can see results, and how changes are tracked.
- **Data handling:** what user data is stored, for how long, and how it’s anonymized or minimized.
- **Governance:** approvals, guardrails, and documented “what we do / what we don’t do.”

That’s why many teams move from “tooling” to a managed simulation and awareness platform.

If you want a deeper technical/business comparison of open-source vs managed approaches, start with this guide: [Open-source phishing simulation tools vs managed solutions](https://autophish.io/blog/open-source-phishing-simulation-tools-vs-managed-solutions-a-technical-and-business-comparison).

## What a strong GoPhish alternative should deliver

A good alternative isn’t just a UI with templates. It’s a system that makes safe, repeatable training the easiest path.

### 1) Operational simplicity (the real reason most teams move on from GoPhish)

GoPhish is easy to spin up. What’s hard is everything after that: deliverability issues, domain reputation problems, template drift, inconsistent reporting, and knowledge that lives in one person’s head.

A strong GoPhish alternative should make the *program* easy to run over months and years:

- **Automations:** recurring campaigns, reminders, and follow‑up training.
- **Template management:** consistent branding and localization without fragile copy‑paste workflows.
- **Multi‑tenant / multi‑company support:** for MSPs, groups, or subsidiaries.
- **Clear change management:** audit logs and predictable configuration.

If your awareness program relies on heroics, it won’t scale.

### 2) Reporting that security engineers actually trust

Awareness metrics are notoriously easy to game. The goal isn’t perfect numbers; it’s reliable signals that help you decide what to do next.

A strong platform should provide:

- **Cohort-based analysis:** departments, roles, locations, and risk groups—without turning the program into a blame machine.
- **Trend visibility:** outcomes over time, so you can tell whether changes are real.
- **Actionable breakdowns:** which scenarios, cues, and channels (email vs mobile) are driving outcomes.
- **Exportable evidence:** reports you can share with leadership and auditors.

If you’re building an internal risk narrative, tie your program to recognized guidance on training and awareness. For example, [NIST SP 800-50](https://csrc.nist.gov/publications/detail/sp/800-50/final) is a longstanding reference on building a security awareness and training program.

### 3) Privacy and data minimization (especially in the EU)

Simulations involve employee data. Even if your intent is defensive, you still need to handle personal data responsibly.

Evaluate:

- **Data minimization:** can you run useful campaigns without storing more than you need?
- **Retention controls:** can you automatically delete or anonymize historical data on a schedule?
- **Aggregated views:** can you coach teams without unnecessarily exposing individual-level data?
- **Transparency support:** does the platform help you communicate what’s being measured and why?

If privacy is a key requirement for your organization, you may also want to review AutoPhish’s approach to privacy-preserving training: [Privacy-friendly phishing training](https://autophish.io/blog/privacy-friendly-phishing-training-works-councils-consent-and-gdpr-essentials).

### 4) Guardrails (important, but they shouldn’t be your whole story)

You still want a platform that prevents obvious foot‑guns: reckless lure categories, accidental credential harvesting, or overly broad access to individual results.

Look for:

- **Policy-friendly defaults:** training-first outcomes instead of “gotcha” culture.
- **Role-based access control:** separation between campaign creators, approvers, and report viewers.
- **Scenario constraints:** the ability to block sensitive themes (payroll, layoffs, medical, legal threats) if your policy requires it.

The practical vendor question: *“Can we enforce our policy by default, or do we have to rely on trust and tribal knowledge?”*

## A pragmatic evaluation checklist (use this in vendor calls)

Use these questions to quickly determine whether a “GoPhish alternative” is actually built for awareness training (not just campaign sending):

1. **What’s your default stance on credential prompts?** (And can we enforce a policy, not just “trust admins”?)
2. **Can we require approvals before a campaign goes live?**
3. **How do you prevent sensitive lure categories?** (Payroll, layoffs, medical, legal threats.)
4. **Do you support mobile-first scenarios?** 
5. **Can we segment results without overexposing personal data?**
6. **What evidence can we export for internal governance?**
7. **How do you handle data retention and deletion?**
8. **How do you measure learning—not just clicks?**

This is also where an awareness platform can align with broader security and compliance efforts. You’re not “becoming compliant” by buying tooling—but you *can* build defensible, repeatable processes and records that support your security management system.

## How AutoPhish approaches phishing simulations (operationally simple by default)

AutoPhish is designed for teams that want the outcome of phishing simulations—measurable learning—without inheriting the day‑2 operational load of running a toolkit.

The core idea is simple: make the safe, repeatable program the path of least resistance.

- **Automation-first:** recurring campaigns and follow-up training without constant manual work.
- **Clear reporting:** evidence and trend visibility you can share with stakeholders.
- **Policy support:** guardrails exist, but they’re not the headline—they’re there so the program stays within boundaries.

Learn more about how the platform is structured here: [AutoPhish Features](https://autophish.io/about).

If you’re currently comparing approaches, it can help to start from the strategic question: do you want to own infrastructure and risk, or do you want to own outcomes? Many teams begin with an open-source tool and later migrate once they feel the operational and governance weight.

## Implementation tips (safe, non-technical)

You don’t need a “clever” simulation to get better outcomes. Consistency and clarity beat novelty.

- **Start with transparent guardrails:** define what scenarios are allowed, what’s off-limits, and how results are used.
- **Run small, frequent exercises:** shorter cycles produce faster learning and cleaner trend data.
- **Coach managers, not just individuals:** team-level patterns are usually where process fixes live.
- **Close the loop:** each campaign should lead to a concrete action (training module, process fix, comms update).

Two paragraphs of policy can save you months of internal friction.

## FAQ

### Will a managed platform make simulations less realistic?
Not necessarily. The point of realism is to teach recognition and safe behavior, not to demonstrate how far an attacker could go. The best programs balance realism with clear ethical and operational boundaries.

### What should we measure besides click rate?
Click rate is a weak proxy. Consider report ratio, completion of follow-up training, repeated exposure improvements, and scenario-specific outcomes. The best metric is the one that changes your next decision.

### Can phishing simulations help with ISO 27001, NIS2, or GDPR accountability?
Training and awareness programs often support security governance expectations, but they’re not a shortcut to compliance. Focus on building a documented process: roles, approvals, retention, reporting, and continuous improvement. That’s what makes the program defensible.

## Ready to run safer phishing simulations?

If you’re evaluating a GoPhish alternative because you want *less overhead and more measurable learning*, AutoPhish is built for that.

[Sign Up](https://autophish.io/register) to start your first controlled, automation-driven phishing simulation.

Image Credit: Stomchak, CC BY-SA 3.0, source: [Wikimedia Commons – File:Phishing.JPG](https://commons.wikimedia.org/wiki/File:Phishing.JPG)

Phishing simulations live or die on **reporting**.

Not “pretty charts”—but reporting that helps you:

- prove improvement over time (without blaming individuals),
- identify where training needs to change,
- and produce evidence that stands up in security reviews and audits.

If you’re evaluating a phishing simulation / awareness training solution, this guide breaks down the **phishing simulation reporting features** that matter most to security engineers, IT admins, CISOs, and compliance teams.

You’ll also see what “good” looks like for each feature—so you can compare tools consistently.

## What phishing simulation reporting is for (and what it’s not)

A mature phishing simulation program uses reporting to answer three questions:

1. **Risk & behavior:** Are users recognizing and reporting suspicious messages faster?
2. **Program quality:** Are we training the right things (by role, region, and threat pattern)?
3. **Governance & evidence:** Can we show what we ran, why we ran it, and what we changed based on results?

What reporting should *not* become:

- A “gotcha” leaderboard
- A punishment mechanism
- A vanity metric (e.g., obsessing over click rate without looking at reporting rate or follow-up training)

When reporting is used correctly, it becomes the link between security, IT operations, and compliance.

> Click here if you want to see how AutoPhish does Reporting: [AutoPhish Reporting](https://help.autophish.io/en/article/phishing-campaign-reports-analytics-ymehoj/)

## The 12 phishing simulation reporting features to compare

### 1) Clear campaign-level KPIs (not just user-level events)

At minimum, your reporting should make it easy to see—per campaign:

- delivery rate (sent vs delivered vs bounced)
- open rate (optional, depending on mail clients and privacy limitations)
- click rate
- report rate (how many users reported the simulation as suspicious)
- completion rate for follow-up training

Why it matters: campaign-level KPIs let you compare **like-for-like** runs (e.g., “invoice theme” in Q1 vs Q3) and avoid chasing noise.

### 2) Segmentation by role, department, and location (with guardrails)

Security teams need segmentation to tailor training:

- finance vs HR vs IT vs executives
- regions/languages
- office vs remote workers

But segmentation also creates privacy risk. Look for:

- configurable visibility (who can see what)
- aggregated views by default
- the ability to minimize or anonymize individual results where appropriate

If privacy is a priority in your org, review AutoPhish’s approach here: https://autophish.io/anonymization

### 3) Deliverability and email health reporting

Many programs “fail silently” due to deliverability:

- messages land in spam/quarantine
- domains or sending infrastructure get blocked
- tracking gets stripped

Strong reporting includes:

- bounce classification and trends
- domain/sender reputation signals (where available)
- per-recipient-domain results (e.g., Microsoft 365 vs Google Workspace)

Tip: before you blame users or templates, validate your DNS and alignment. AutoPhish provides a quick pre-check: https://autophish.io/dns-check

### 4) Evidence-friendly exports (PDF) with consistent definitions

Compliance and leadership reporting often requires offline artifacts.

Look for:

- PDF exports for board / audit packs
- consistent metric definitions across time (e.g., what exactly counts as a “click”)
- stable identifiers for campaigns and templates

If you can’t export consistently, you can’t show improvement credibly.

### 5) Trend views that support continuous improvement

A single campaign is a snapshot. Good reporting shows trends across:

- quarters and years
- role-based cohorts
- template themes (credential lure vs delivery notice vs document share)

Look for:

- rolling averages
- cohort comparisons
- seasonality-aware views (avoid comparing holiday periods to normal operations)

### 7) Training workflow reporting (what happens *after* the event)

A phishing simulation shouldn’t end at “clicked.”

Better programs track what happens next:

- auto-assigned micro-training
- completion monitoring
- repeated patterns (e.g., users repeatedly missing the same red flags)

If your platform includes a training experience, it should be reportable end-to-end. See: https://autophish.io/training-platform

### 8) Scoring and risk signals (careful, but useful)

Some tools create a “risk score.” This can be useful if:

- it’s transparent (how the score is calculated)
- it’s not used punitively
- it’s supported by behavior improvements and training completion

Avoid black-box scoring that can’t be explained to leadership or works councils.

### 9) Integration signals (ticketing, SIEM/SOAR, identity)

Even if you don’t integrate on day one, reporting should make integration plausible:

- webhook / API availability (for pulling campaign results)
- identity mapping (so you can segment accurately)
- evidence that the platform can fit your incident reporting workflow

Reporting that can’t leave the tool becomes a dead-end. Contact us to get API access for AutoPhish!

### 10) Privacy controls and retention reporting

Security awareness data can be sensitive.

Look for features that support responsible handling:

- configurable retention periods
- role-based access control
- aggregated-by-default reporting
- anonymization or data minimization options

If you need a privacy-first baseline, start here: https://autophish.io/anonymization

### 11) “Explainability” for non-security stakeholders

CISOs and compliance leaders often need to answer:

- What did we do?
- What changed?
- Is the program improving risk?

Reporting should include a narrative-ready view:

- campaign summary
- key changes since last campaign
- recommended next steps driven by results

This is one of the biggest gaps in DIY and early-stage programs.

### 12) Benchmarking (internal > external)

External benchmarks can be misleading because organizations differ in:

- industry threat profile
- mail security posture
- workforce composition

Prefer internal benchmarking:

- “Our reporting rate improved from X% to Y% after policy + training changes”
- “Time-to-report p90 dropped by Z days”

That’s defensible and actually actionable.

## A practical scoring checklist (copy/paste)

Score each item 0–2 (0 = missing, 1 = partial, 2 = strong):

- Campaign KPIs include report rate + time-to-report
- Segmentation exists with access controls
- Deliverability reporting is usable (bounces, trends)
- Export formats support audits (CSV/PDF)
- Audit trail exists (changes + approvals)
- Trend views support comparisons over time
- Follow-up training reporting exists
- Risk/scoring is explainable (or absent by choice)
- Integration path exists (API/webhooks)
- Privacy + retention controls are configurable
- Executive summary view exists
- Internal benchmarking is easy

A tool with a lower click rate but a higher report rate, better governance, and better evidence is often the better real-world choice.

## FAQ

### What is the most important metric in phishing simulation reporting?
There isn’t a single metric, but **report rate** and **time-to-report** often correlate better with organizational resilience than click rate alone.

### Should we track open rates?
Open rates can be unreliable due to mail client privacy protections and image blocking. Use them cautiously; focus on delivery, clicks (where measurable), reporting behavior, and training completion.

### Can phishing simulation reporting help with ISO 27001, NIS2, or GDPR accountability?
Reporting can support evidence collection and continuous improvement, but it does not “make you compliant.” Compliance depends on your policies, governance, lawful basis, access controls, and how you operate the program.

### How do we keep reporting from becoming a blame tool?
Default to aggregated reporting, keep access limited, focus on training outcomes, and avoid individual public rankings.

## Next step

If you’re comparing platforms and want reporting that’s operationally useful, privacy-aware, and easy to turn into audit-ready evidence, AutoPhish is built for security teams that need a repeatable program.

- Explore the platform: https://autophish.io/about
- See pricing: https://autophish.io/pricing
- **Sign up:** [Sign Up](https://autophish.io/register)

This post explains the **risks and theory** behind **SPF**, **DKIM**, and **DMARC**, and why **domain permutations (look-alike domains)** are the silent amplifier that turns “one spoofed email” into a brand, finance, and credential-theft disaster.

## The core problem: email was built for delivery, not identity

SMTP (the protocol that moves email around) was designed in an era where *trust* was implicit. By default:

- The **“From:”** header is just text.
- Anyone can attempt to send mail claiming to be `ceo@yourcompany.com`.
- Many mail systems historically accepted messages as long as they could be delivered.

Modern defenses add **domain-level authentication** on top of SMTP. That’s what SPF, DKIM, and DMARC do.

---

## SPF: “Which servers are allowed to send mail for my domain?”

**SPF (Sender Policy Framework)** is a DNS record that lists the mail servers (or sending services) allowed to send email *using your domain in the envelope-from / return-path*.

### How SPF works (theory)
When a receiving mail server gets a message, it checks:

1. What domain is used in the **envelope sender** (Return-Path).
2. Does that domain publish an SPF record in DNS?
3. Is the **connecting IP** allowed by that SPF record?

If yes → SPF passes. If not → SPF fails (or softfails/neutral depending on policy).

### Example SPF record
```txt
example.com. TXT "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"
```

### Common SPF failure modes (where attackers win)
- **Too permissive**: `v=spf1 +all` (basically “anyone can send”).
- **Softfail forever**: `~all` without DMARC enforcement, leading to “shrug” handling.
- **Missing includes**: your CRM, ticketing system, newsletter tool not listed → legitimate mail fails.
- **DNS lookup limit**: SPF has a **10 DNS-lookup limit**; complex `include:` chains can break delivery.
- **SPF only protects the envelope domain**: attackers can still make the *visible* From look like you unless DMARC is enforcing alignment.

**Bottom line:** SPF is necessary, but **not sufficient** for stopping spoofing.

---

## DKIM: “Was this email really sent by someone with the domain’s private key?”

**DKIM (DomainKeys Identified Mail)** adds a cryptographic signature to outgoing messages. The sender signs selected headers (and sometimes body) with a **private key**. The receiver fetches the **public key** from DNS and verifies the signature.

### How DKIM works (theory)
- Outbound mail server adds a header like:
  - `DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...`
- Receiver queries DNS:
  - `selector1._domainkey.example.com` → public key
- If signature matches → DKIM passes.

### Example DKIM DNS record
```txt
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
```

### DKIM failure modes (where attackers win)
- **No DKIM at all**: lots of domains still don’t sign mail consistently.
- **Selective signing**: only some systems sign (e.g., Microsoft 365 does, your marketing tool doesn’t).
- **Broken signatures**: forwarders/mailing lists can modify content/headers and break DKIM.
- **Weak/old keys**: short keys or long-lived keys increase risk (if compromised, impersonation becomes trivial).
- **Misaligned domain**: DKIM passes for a different domain than what users see in “From”.

**Bottom line:** DKIM is powerful because it’s cryptographic, but it needs **alignment and policy**—that’s DMARC’s job.

---

## DMARC: “What should receivers do if SPF/DKIM fails—and does it match my visible From?”

**DMARC (Domain-based Message Authentication, Reporting & Conformance)** ties everything together:

1. It requires that **SPF and/or DKIM pass**, and
2. They must be **aligned** with the **From:** domain users actually see.

Then it tells receivers what to do if authentication fails:  
- `p=none` (monitor only)  
- `p=quarantine` (send suspicious mail to spam/junk)  
- `p=reject` (block outright)

### DMARC alignment (the key concept)
Attackers love this gap:

- SPF passes for `random-sender.com`
- “From:” shows `ceo@yourcompany.com`

Without DMARC alignment, a message can look like it’s from you even if the authenticated domain is unrelated.

DMARC says: **the authenticated identity must match the visible From**, not just “something passed somewhere”.

### Example DMARC record (monitoring)
```txt
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"
```

### Example DMARC record (enforced)
```txt
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; fo=1; adkim=s; aspf=s"
```

### DMARC failure modes (where attackers win)
- **Stuck at `p=none` forever**: you get reports, but spoofing still lands.
- **No reporting address / ignored reports**: you’re blind to who’s abusing your domain.
- **Misconfigured alignment**: legitimate services fail and you roll back enforcement.
- **Subdomain gaps**: without a subdomain policy, attackers spoof `anything.yourcompany.com`.
- **No external monitoring**: DMARC is not “set and forget” when tooling changes.

**Bottom line:** DMARC is the enforcement layer that turns SPF/DKIM from “signals” into “protection.”

---

## What attackers actually do with weak email authentication

Here are the high-impact abuse paths SPF/DKIM/DMARC help prevent:

### 1) CEO fraud / invoice redirection (BEC)
Attackers send emails that appear to be from leadership or finance to change IBANs, approve payments, or request gift cards. Even one successful spoof can cost more than a year of security tooling.

### 2) Credential harvesting
A perfect-looking email “from IT” pushes a fake Microsoft 365 login page. The moment credentials are captured, the attacker can pivot to real internal mailboxes and send *legitimate* phishing from inside your tenant.

### 3) Brand impersonation against customers/partners
Even if your internal team is trained, your customers aren’t. Spoofed messages can damage your reputation, trigger fraud, and create support nightmares.

---

## Domain permutations: the “look-alike domain” multiplier

Even with perfect DMARC enforcement, attackers can simply register **a different domain that looks like yours** and send from that.

Examples:
- `examp1e.com` (1 instead of l)
- `exarnple.com` (rn instead of m)
- `example-support.com`
- `example.com-security.net`
- `exämple.com` (IDN / homograph tricks)
- Different TLD: `example.co`, `example.net`, `example.io`

This is called **domain permutation / typosquatting** (and includes homograph attacks, combo-squatting, bitsquatting, and more).

### Why permutations are dangerous
- **Users read “shapes,” not strings**: a quick glance at a sender address is unreliable.
- **Mobile clients hide details**: many interfaces collapse or truncate sender info.
- **SPF/DKIM/DMARC won’t help**: those protect *your domain*, not look-alikes.
- **Attackers can build “legit-looking” infrastructure**: TLS certs, branded landing pages, realistic reply flows.

### Typical attack flow with a look-alike domain
1. Register a domain close to yours.
2. Set up SPF/DKIM/DMARC correctly (yes, attackers do this).
3. Send “urgent” messages to finance, HR, customers, or vendors.
4. Harvest credentials or redirect payments.
5. If a reply happens, keep the conversation going (thread hijacking style).

**Takeaway:** you need **both** authentication monitoring **and** look-alike detection.

---

## What “good” looks like: a practical baseline

If you want a clean, modern posture:

### SPF
- Exactly **one** SPF TXT record per domain.
- Only include the senders you actually use.
- End with `-all` once you’ve validated all sources.

### DKIM
- Ensure **every** sending platform signs mail.
- Rotate keys periodically.
- Use sufficiently strong keys (and don’t reuse keys forever).

### DMARC
- Start with `p=none` briefly to observe legitimate senders.
- Move to `p=quarantine`, then `p=reject`.
- Use strict alignment where possible (`aspf=s; adkim=s`).
- Consider subdomain policy (`sp=`) so subdomains aren’t a loophole.

### Domain permutations
- Monitor for look-alikes across common TLDs and obvious typo patterns.
- Prioritize ones that:
  - have MX records (can send/receive email),
  - host phishing pages,
  - are newly registered,
  - resemble brand + “billing / login / support”.

---

## Why continuous monitoring matters (even if you “set it up once”)

DNS changes for boring reasons—migrations, vendor switches, “quick fixes,” expired domains—and those boring changes can quietly break authentication.

Continuous monitoring catches:
- SPF lookup blowups after someone adds a new tool
- DKIM selectors removed or rotated incorrectly
- DMARC downgraded to `p=none`
- A suddenly-appearing look-alike domain that starts emailing your staff

That’s why AutoPhish now includes an **Email Security / DNS Scanner** for quick checks, and **continuous monitoring with alerts** for logged-in orgs.

---

## Quick checklist you can copy into your internal runbook

- [ ] SPF exists, is unique, and ends in `-all` (after validation)
- [ ] All mail sources are accounted for (M365/Google + marketing + support + transactional)
- [ ] DKIM enabled across all sources, keys not stale
- [ ] DMARC exists with reporting enabled
- [ ] DMARC enforced (`quarantine` or `reject`) with alignment configured
- [ ] Subdomains covered (`sp=` or explicit DMARC on subdomains)
- [ ] Look-alike domain monitoring enabled (typos + TLD swaps + combos)
- [ ] Alerting hooked to a real channel (email/Slack/Teams/ticketing)

---

## Check your domain in seconds (free)

Want a quick sanity check right now? Use the **AutoPhish DNS Checker** to instantly analyze your **SPF, DKIM, and DMARC** records:

- AutoPhish DNS Checker: https://autophish.io/dns-check

If you want ongoing protection, you can also set up **continuous monitoring** with an AutoPhish subscription—so you’ll get alerts when DNS records change or when look-alike domains are detected.


## Final thoughts

Email authentication (SPF/DKIM/DMARC) is one of the rare security moves that improves **both** protection **and** deliverability. Add look-alike monitoring, and you cover the two biggest impersonation vectors: **spoofing your domain** and **spoofing your brand**.


**Why mobile phishing matters in 2025**

*   **Smishing (SMS phishing) surged** and is a top vector for fraud in Europe; QR-based “quishing” is **rising fast**. [ENISA](https://www.enisa.europa.eu/sites/default/files/2025-02/Finance%20TL%202024_Final.pdf)
*   **WhatsApp/linked-device abuse:** state-aligned actors have shifted from email to messenger takeovers, often by tricking targets into scanning **WhatsApp Web QR codes**. Treat scans like passwords. [Microsoft+1](https://www.microsoft.com/en-us/security/blog/2025/01/16/new-star-blizzard-spear-phishing-campaign-targets-whatsapp-accounts/)
*   **MFA fatigue** forced a rethink of push approvals; Microsoft moved tenants to **number-matching** to blunt push-spam approvals. [Microsoft Learn+1](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-default-enablement)
*   **FBI/IC3** warn of QR-based fraud—including scams where unsolicited packages contain a QR that leads to credential theft or malware. [Internet Crime Complaint Center+1](https://www.ic3.gov/PSA/2025/PSA250731)

For incident color and “what went wrong”, skim our **[10 Wild Phishing Stories (2024–2025)](https://autophish.io/blog/10-wild-phishing-and-phish-adjacent-stories-from-2024-2025-including-important-lessons-learned)**—we highlight QR-assisted account takeovers and messaging-app pivots with concrete guardrails.

* * *

**The mobile-first phishing playbook (how attacks work)**

1.  **Smishing & messaging lures**  
    Short messages spoof delivery firms, toll fees, or IT resets. Links open credential pages, payment forms, or drive users to install rogue apps.
2.  **QR codes as login tokens**  
    WhatsApp/other apps use **QR to link devices**. A coerced scan = session takeover—even without a password. Policy should treat **“Scan to link” = sensitive auth step**.
3.  **MFA push abuse**  
    Attackers spam prompts until a tired user taps “Approve”. **Number-matching** (enter the on-screen code) and **geolocation/tenant context** reduce these approvals.
4.  **Malware on mobile**  
    Links typically **steal credentials**, but can also push malicious installs—more feasible on Android via sideloaded APKs; iOS is harder (App Store gate) but **risky profiles/0-click vulns** exist. Mobile protections like **Play Protect** reduce but don’t erase risk.

* * *

**What policies SMEs actually need (ready to adapt)**

Below are concise clauses you can drop into your **Acceptable Use**, **BYOD**, and **Messaging** policies. Each includes a control and a short “why”.

**1) BYOD: minimum security baseline**

*   **OS & patch level:** Personal devices used for work must run a **vendor-supported OS** and auto-update enabled. (Android, iOS, iPadOS).
*   **Device security controls:** Screen lock, encrypted storage, and the ability to **remote wipe work data** via MDM/Work Profile (COPE/COSU or Android Work Profile/iOS User Enrollment).
*   **App sources:** **No sideloaded apps** for work use; business apps must come from managed stores. (Android unknown-sources increase risk; Play Protect mitigates but isn’t a policy substitute.) [NCSC+2NCSC+2](https://www.ncsc.gov.uk/collection/device-security-guidance)

**Why:** NCSC’s device guidance stresses balancing usability with controls in BYOD; you want managed data separation and revocation. [NCSC+1](https://www.ncsc.gov.uk/collection/device-security-guidance/bring-your-own-device)

**2) Messaging & social apps (WhatsApp, Signal, iMessage, etc.)**

*   **Business use boundaries:** If messaging apps are used for business, restrict to **managed devices**; **no linking via QR** on unmanaged desktops.
*   **Linked devices monitoring:** Alert on **new linked devices**; require re-verification every 30 days.
*   **No sensitive approvals over chat:** Payments, bank detail changes, or SSO resets **must use ticket + callback** to a number from the directory.

**Why:** Threat actors are actively abusing messenger **linking** and QR. Treat a QR scan like an SSO login. [Microsoft](https://www.microsoft.com/en-us/security/blog/2025/01/16/new-star-blizzard-spear-phishing-campaign-targets-whatsapp-accounts/)

**3) QR code handling**

*   **Treat QR as credentials:** Scanning QR for login or device-linking equals entering a password; only scan **from trusted sources** on **managed devices**.
*   **Preview before open:** Staff must **preview the URL** (mobile browser/app supports this) and verify domain before opening.
*   **Block risky shorteners:** Filter common shorteners (except allowlisted business uses).

**Why:** FBI/IC3 documented QR fraud; attackers hide destinations and piggyback trust. [Internet Crime Complaint Center](https://www.ic3.gov/PSA/2025/PSA250731)

**4) MFA hardening (stop push fatigue)**

*   **Enforce number-matching** for push approvals across the tenant.
*   **Prefer phishing-resistant methods** (FIDO2/passkeys) and **disable SMS fallback** after enrollment. [Microsoft Learn+1](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-default-enablement)

**Why:** Push spam works; number-matching and passkeys meaningfully reduce abuse.

**5) Mobile browser & app controls**

*   **Safe browsing & app vetting:** Keep **Play Protect** on; block app installs from unknown sources; require managed app stores. [Google Help](https://support.google.com/android/answer/2812853?hl=en&utm_source=chatgpt.com)
*   **Profiles/configs:** Ban installation of **unapproved configuration profiles** on iOS; profiles can alter trust roots, VPN/DNS, or MDM—serious risk. [TechTarget](https://www.techtarget.com/searchmobilecomputing/tip/How-to-ensure-iPhone-configuration-profiles-are-safe)

**6) Payments & approvals over mobile**

*   **Dual-control + callback:** Any payment, supplier bank change, or gift card purchase requires **two approvers + callback** using a **known** number (not from the message).
*   **No “approve via link in SMS”** for finance/HR workflows.

**Why:** Classic BEC remains costly; process guardrails beat human judgment under time pressure.

**7) Reporting & response (fast lane)**

*   **Single tap to report:** Add a **Report SMS/Message** action in MDM help app; route to SecOps + vendor for takedown.
*   **Preserve evidence:** Staff should keep the message, screenshot the **full URL**, and note the time before deleting.
*   **Automated blocks:** Add sender and destination domains/hosts to mobile and email gateways; watch for newly linked devices.

* * *

**Rollout checklist**

1.  **Turn on number-matching** (Microsoft Entra ID) and review MFA methods; **prefer passkeys/FIDO2**.
2.  **Update BYOD policy** with the clauses above; require **managed app stores** & **no QR-linking on unmanaged desktops**.
3.  **Set MDM rules**: block unknown sources on Android, block unapproved **iOS profiles**, alert on new WhatsApp/Signal **linked devices**.
4.  **Run a bite-size training** using AutoPhish. For a Works-Council-friendly approach, use anonymized metrics—our [guide](https://autophish.io/blog/privacy-friendly-phishing-training-works-councils-consent-and-gdpr-essentials) explains how.

* * *

**FAQ**

**Q1) Can phishing be done by phone?**

Yes. **Smishing** (SMS) and **messenger DMs** are common phishing channels. Messages link to fake login pages, payment sites, or app installs; they may also attempt **voice phishing (vishing)** callbacks. CISA defines smishing as SMS-based social engineering and details how links can trigger actions on mobile. [CISA](https://www.cisa.gov/news-events/news/avoiding-social-engineering-and-phishing-attacks)

**Q2) Can phishing be used for identity theft?**

Absolutely. The goal is often **credential theft** (email, bank, cloud apps) or collection of personal data that enables account takeover and financial fraud. FBI/IC3 PSAs have repeatedly warned that QR/smishing campaigns harvest personal and financial data for fraud. [Internet Crime Complaint Center](https://www.ic3.gov/PSA/2025/PSA250731)

**Q3) Can a phishing link install malware on my phone?**  


Sometimes—**but** it usually needs extra steps.

*   On **Android**, a site might try to get you to **sideload an APK**; Play Protect reduces risk but allowlisting sources in policy is key. [Google Help](https://support.google.com/android/answer/2812853?hl=en&utm_source=chatgpt.com)
*   On **iOS**, direct installs are restricted; attackers may push **malicious configuration profiles** or exploit rare **zero-click** vulnerabilities. (Recent WhatsApp advisories highlight targeted zero-click issues that were patched; keep apps updated.) [TechTarget+1](https://www.techtarget.com/searchmobilecomputing/tip/How-to-ensure-iPhone-configuration-profiles-are-safe)Most of the time, the **bigger risk is credential harvesting and session theft**—which leads to identity fraud even without malware. [CISA](https://www.cisa.gov/news-events/news/avoiding-social-engineering-and-phishing-attacks)

**Q4) Are QR codes safe to scan?**

Treat QR codes like a **link**: only scan from trusted sources, prefer managed devices, and **preview the URL** before opening. FBI/IC3 specifically warned about QR-based schemes (including unsolicited items with embedded QR). [Internet Crime Complaint Center](https://www.ic3.gov/PSA/2025/PSA250731)

**Q5) Is WhatsApp phishing real if I have 2FA?**


Yes. Attackers can trick users into **linking a new device via QR**, bypassing passwords by stealing **session access**. Enable WhatsApp’s **two-step verification PIN**, monitor **linked devices**, and never link from an untrusted desktop. [Microsoft](https://www.microsoft.com/en-us/security/blog/2025/01/16/new-star-blizzard-spear-phishing-campaign-targets-whatsapp-accounts/)

**Q6) What should finance/HR do differently on mobile?**  


No approvals or bank changes via links or chat. Use **ticket + dual-control + callback** to a known number, every time. Our [incident recap](https://autophish.io/blog/10-wild-phishing-and-phish-adjacent-stories-from-2024-2025-including-important-lessons-learned) explains why this stops even slick deepfake/DM stunts.

* * *

**Further reading & resources**

*   **CISA mobile best practices** and why **FIDO/phishing-resistant MFA** beats SMS/app codes. [CISA](https://www.cisa.gov/sites/default/files/2024-12/joint-guidance-mobile-communications-best-practices_v2.pdf)
*   **NCSC BYOD guidance** to structure a sane, workable personal-device policy. [NCSC+1](https://www.ncsc.gov.uk/collection/device-security-guidance/bring-your-own-device)
*   **Microsoft on evolving identity attacks** (push fatigue → number-matching → passkeys). [Microsoft Learn+1](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-default-enablement)
*   **IC3 PSA on QR fraud** (current scams, reporting). [Internet Crime Complaint Center](https://www.ic3.gov/PSA)

* * *

**How AutoPhish can help**

*   **Mobile-aware simulations:** Safe **smishing**, **QR**, and **messenger-style** scenarios with instant coaching (coming soon)
*   **Policy-driven training:** Our [privacy-friendly training approach](https://autophish.io/blog/privacy-friendly-phishing-training-works-councils-consent-and-gdpr-essentials) keeps Works Councils onside while changing behavior.

Blog

Perché le e-mail di simulazione di phishing finiscono nello spam (e come risolvere il problema senza compromettere la sicurezza)

Test di phishing ad hoc: quando le simulazioni una tantum sono utili — e quando serve un vero e proprio programma

Servizi di phishing simulato: cosa dovrebbero richiedere i team di sicurezza (sicurezza, privacy e prove)

Piattaforme di simulazione di phishing per aziende di medie dimensioni: cosa confrontare nel 2026 (senza creare rischi)

Strumenti di simulazione di phishing in bundle vs piattaforme dedicate: cosa dovrebbero scegliere i team di sicurezza

L'alternativa a GoPhish nel 2026: simulazioni di phishing più sicure senza dover utilizzare un toolkit di attacco

Reportistica sulla simulazione di phishing: 12 caratteristiche che i team di sicurezza dovrebbero confrontare (dashboard, metriche e prove di audit)

SPF, DKIM, DMARC e permutazioni di dominio: le basi della sicurezza e-mail che gli hacker sfruttano

Tendenze del phishing nel 2026: cosa sta davvero cambiando (e cosa no)

Phishing su dispositivi mobili: SMS, WhatsApp e QR - Di quali politiche hanno effettivamente bisogno le PMI

Avvia il tuo primo test di phishing in 10 minuti.