Stop Phishing on Campus: Safe Redirects and Link Scanning for Universities

Phishing has become the most persistent, expensive, and demoralizing threat to higher education. From financial-aid scams and compromised LMS accounts to fake tech-support pages and malicious “scholarship” forms, attackers exploit one thing universities excel at: open, fast-moving collaboration powered by links—everywhere. Emails, LMS announcements, QR codes on posters, library guides, faculty profiles, research pages, and student clubs all circulate links at campus speed. One malicious redirect can compromise a single student or cascade through a department.

This guide gives you a complete, practical blueprint to stop phishing on campus by combining safe redirects, automated link scanning, and measurable governance that respects academic openness and privacy laws (FERPA, GDPR for EU students, PDPA in Singapore, and local equivalents). You’ll learn how to design a safe-redirect architecture, scan links at multiple checkpoints, integrate protections into the LMS and email, use short links to simplify enforcement, and build a culture where reporting and remediation are as frictionless as sharing a link.

Table of Contents

  1. Why Campus Phishing Is Different (and Hard)
  2. Strategy: Safe Redirects + Link Scanning = Defense-in-Depth
  3. Architecture Overview: How the Pieces Fit
  4. Safe Redirects: Design, Patterns, and Caching
  5. Link Scanning: Engines, Signals, and Orchestration
  6. Using Short Links to Enforce Policy at Scale
  7. LMS, Email, and QR Workflows (Canvas/Moodle/Google Workspace/M365)
  8. Privacy and Compliance (FERPA, PDPA, GDPR)
  9. Analytics, KPIs, and Early-Warning Signals
  10. Incident Response: Playbooks for “Click-Time” Crises
  11. Implementation Blueprint (Day 0–30, 30–90, 90+)
  12. Governance: Policies, Roles, and Review Cadence
  13. Campus Communications: Training, Micro-UX, and Interstitials
  14. Reference Configs and Snippets (Nginx/Lua, Cloudflare Worker, API)
  15. Cost, Performance, and Reliability Considerations
  16. Checklist, FAQ, and Glossary

1) Why Campus Phishing Is Different (and Hard)

Open ecosystems: Universities thrive on collaboration with students, faculty, visiting lecturers, alumni, and external partners. Openness means lots of unmanaged devices, personal email accounts, rotating cohorts, and non-standard browsers.

High link velocity: Links flow through syllabi, LMS modules, mass email, calendar invites, student group chats, and QR codes on posters. Attackers love the speed and trust of these channels.

Distributed publishing: Faculty and departments manage their own pages, file shares, and newsletters. Central IT cannot pre-review every link.

Diverse identities: You’ll see tenure-track faculty, adjuncts, student workers, vendors, and alumni with different access levels and lifespans. Identity sprawl creates gaps attackers exploit.

Compliance pressure: Education data is highly regulated. Some defenses (like heavy tracking) may conflict with FERPA or differ across jurisdictions, which complicates security telemetry.

Conclusion: Campus security must be robust yet lightweight, centralized yet respectful of local autonomy. The right control plane is link-centric.

2) Strategy: Safe Redirects + Link Scanning = Defense-in-Depth

Safe redirects funnel every outbound link through a trusted gateway on your domain. This gateway enforces policy, checks risk at click time, and can show an interstitial warning when needed. Result: you control the last step before a user lands on a risky site.

Link scanning evaluates destinations before and after publication, using threat feeds, reputation services, and dynamic analyses. Result: you proactively quarantine malicious links and continuously re-check as reputations change.

Together, they form a defense-in-depth loop:

  1. Creation-time scanning: When a staff member posts a link to the LMS, newsletter, or website, the link is scanned. If risky, block or route to review.
  2. Short link normalization: The link is converted to a campus short URL that always travels through the safe-redirect gateway.
  3. Click-time checks: At the moment of the click, the safe-redirect gateway re-checks risk, device posture, and policy.
  4. Continuous rescans: Background rescans catch delayed detections (e.g., a benign page becomes malicious later).
  5. Feedback: User reports and automated verdict changes trigger takedowns and notifications.

3) Architecture Overview: How the Pieces Fit

Control plane components:

  • Safe Redirect Service (SRS): A small service (reverse proxy + logic) at go.university.edu/r/<token> that performs policy checks and forwards using 302/307.
  • Link Scanning Orchestrator: Queues, scans, and records verdicts from multiple engines (reputation APIs, sandboxing, content heuristics).
  • Short Link Platform: Generates managed short URLs, enforces per-domain rules, injects UTM/policy tags, and provides admin dashboards.
  • Policy Store: Allow/deny lists, categorization rules, and interstitial templates (e.g., scholarship warnings, finance warnings).
  • User Reporting Intake: One-click “Report this link” on interstitials and inside the LMS and email footers.
  • Analytics & SIEM Integration: Event stream of click decisions, rescans, escalations, and user reports.

Data flow:

  1. A faculty member submits a link into the LMS.
  2. The LMS plugin converts it into a short link and calls the scanning API.
  3. If clean, publish; if uncertain, publish with interstitial; if malicious, block and notify.
  4. When a user clicks, the SRS runs click-time checks and either forwards, warns, or blocks.
  5. All events flow into your SIEM; rescans run on a schedule.

4) Safe Redirects: Design, Patterns, and Caching

4.1 Why safe redirects

  • Single enforcement point for every outbound click.
  • Late binding: reputations can change between publication and click.
  • User education: interstitials explain risks without breaking academic workflow.
  • Telemetry: see which campaigns and departments are targets.

4.2 Redirect codes and UX

  • 302 or 307 are preferred to keep method semantics intact; SEO impact is minimal because you are not trying to index the destination.
  • Cache behavior: set short TTLs on the redirect response (e.g., Cache-Control: private, max-age=30) so policy updates propagate quickly.

4.3 Interstitial patterns

  • Soft warn: “This page is outside the university. Proceed?”
  • Hard block: “This link is blocked due to phishing risk.”
  • Reason-specific templates: “This resembles a fake scholarship page.”
  • Appeal flow: One-click “request review” sends context to security.

4.4 Allowlist and denylist philosophy

  • Allowlist core academic domains (publishers, government education portals) BUT continue scanning for page-level compromises.
  • Denylist known-bad domains and dynamic patterns (IDN homographs, fast-flux TLDs common in attacks).

4.5 Punycode and homograph defense

Normalize the host, detect mixed-script confusables, and apply stricter interstitials when risk flags are present.

4.6 Device and session signals

  • If your IdP supports device posture (managed vs BYOD), factor into interstitial strength.
  • For SSO-protected university apps, maintain a session ID to avoid nagging when users are clicking between trusted properties.

5) Link Scanning: Engines, Signals, and Orchestration

5.1 Multi-engine approach

Combine:

  • Reputation feeds/APIs (known bad domains, malware/drive-by).
  • HTML/JS heuristics (credential harvest patterns, obfuscated JS, unexpected form posts).
  • Visual similarity (phish pages mimicking campus login).
  • Sandboxing (detonating URLs in a headless browser for redirects, downloads, or geofenced behavior).
  • Certificate and TLS clues (age, issuer anomalies).
  • Hosting intel (bulletproof hosts, sudden ASN switches).

5.2 Verdict taxonomy

  • Clean (no interstitial)
  • Caution (soft interstitial)
  • Suspicious (hard interstitial + report option)
  • Malicious (blocked)
  • Unknown (publish with interstitial + rescan)

5.3 Continuous rescans

Schedule rescans at 1h, 6h, 24h, and then daily for X days (configurable). Any verdict upgrade triggers:

  • Auto-expiration of caches;
  • Retroactive interstitials on existing short links;
  • Owner notifications (faculty who published the link);
  • LMS patching (replace risky link text with warning).

5.4 Human-in-the-loop

Security analysts handle edge cases (e.g., research sites with unconventional certs). Their decisions update the policy store.

6) Using Short Links to Enforce Policy at Scale

Short links are the governance lever that makes universal enforcement feasible.

Benefits:

  • Normalization: All outbound links look like go.university.edu/abc123.
  • Revocability: You can change the destination or block it centrally.
  • Attribution: Each link has an owner, department, and campaign tag.
  • Fast takedown: Block hundreds of messages by disabling the single short link.
  • QR safety: Posters and flyers route through the SRS with interstitials if needed.

Campus patterns:

  • LMS resource links (Canvas/Moodle modules).
  • Mass emails (admissions, financial aid, bursar).
  • Library databases (proxy resolvers, off-campus access).
  • Career office (externally hosted application portals).
  • Student clubs (event signups with third-party forms).
  • Research (preprints, data repositories, cloud notebooks).

Governance by tag:

  • Tag links with unit=financial-aid or channel=qr or audience=undergrad. Policy can be stricter for high-risk tags.

7) LMS, Email, and QR Workflows

7.1 LMS (Canvas, Moodle, Google Classroom)

  • Plugin/Button: “Insert Safe Link.” Paste a URL → it becomes a short URL after scanning.
  • Context capture: Course code, term, instructor.
  • Broken-link monitoring: Periodic checks replace dead links with a helpful note.
  • Rich tooltips: Hover shows the normalized destination and trust badges.

7.2 Email (Google Workspace/Microsoft 365)

  • Composer add-on: Converts raw URLs to managed short links before sending.
  • Outbound gateway rule: Optionally rewrite naked URLs to safe redirects for designated senders (bulk mailers).
  • Banner injection: “External link safety check enabled” footer with reporting link.

7.3 QR Codes

  • Generate QR codes only for campus short links. When kiosk operators design posters, the QR is already governed.
  • For events, pair short links with rate limits during the first hour to deter QR-born flood attacks.

8) Privacy and Compliance (FERPA, PDPA, GDPR)

Principles:

  • Data minimization: The SRS does not need to store personal content; store only pseudonymous click events (time, link token, verdict, policy path).
  • Retention: Keep full analytics briefly (e.g., 30 days), retain aggregate stats longer.
  • Purpose limitation: Use click data solely for security and reliability, not to profile students.
  • Opt-out & transparency: Document how the SRS works on a public page with student-friendly explanations.
  • Access controls: Only security and compliance teams can see sensitive telemetry.
  • Cross-border transfers: If scanning uses external APIs, ensure DPAs and regional processing where applicable.

FERPA-specific: Avoid tying link analytics to identifiable education records unless necessary for security investigation. Aggregate and de-identify by default.

9) Analytics, KPIs, and Early-Warning Signals

Operational KPIs:

  • Malicious links blocked (weekly).
  • Suspicious → clean adjudications (model precision indicator).
  • Median time-to-takedown after first detection or user report.
  • Interstitial click-through rate (did users heed warnings?).
  • Top attack themes (financial aid, scholarship, account reset).
  • False positive rate (keep <1–2% to avoid alert fatigue).

Early warning signals:

  • Spikes in newly registered lookalike domains for university brands.
  • Burst of blocks from a specific department campaign.
  • Repeated blocks targeting a cohort (e.g., incoming freshmen).
  • DNS or ASN shifts on sites popular with students (potential compromises).

10) Incident Response: Playbooks for “Click-Time” Crises

Scenario A: Fake campus login page spreads via student group email

  1. IOC discovered by scanning or report.
  2. Elevate verdict to Malicious, block instantly.
  3. Notify email admins to quarantine original message thread and all descendants.
  4. Publish a campus-wide bulletin with a screenshot and “what to do if you clicked.”
  5. Force reset SSO tokens for high-risk cohort (detected via interstitial logs).
  6. Debrief: Add domain pattern to denylist; update training content.

Scenario B: Malicious scholarship forms in multiple languages

  1. Sandbox reveals credential harvest pattern.
  2. Set Suspicious with hard interstitial including scholarship safety tips.
  3. Contact financial-aid office to mass-communicate and replace links.
  4. Enable language-targeted detection rules (multi-script confusables).
  5. Report to relevant registrars or hosting providers.

Scenario C: QR codes on campus posters lead to malware

  1. Populate denylist for the domain; block all clicks.
  2. Ask facilities to remove posters, provide replacement QR templates.
  3. Notify student affairs communications channels; update “poster policy.”

11) Implementation Blueprint

Phase 1: Day 0–30 (MVP)

  • Stand up Safe Redirect Service on a subdomain (go.university.edu).
  • Integrate a basic short link platform (self-hosted or SaaS) with owner attribution.
  • Wire a single reputation provider + basic heuristics.
  • Launch interstitial v1 and a “Report this link” button.
  • Pilot in IT, Security, Financial Aid (high-value targets).
  • Create initial policy store: allowlist key academic/government domains.

Phase 2: Day 30–90 (Scale)

  • Add multi-engine scanning, sandboxing, and continuous rescans.
  • Build LMS plugin and email composer add-on.
  • Add punycode/homograph detection and language-aware warnings.
  • Send events to SIEM and publish weekly KPIs.
  • Onboard library, admissions, career office, student services.
  • Launch QR-only pilot for events.

Phase 3: Day 90+ (Optimize)

  • Implement risk-based interstitials (more context for finance vs research).
  • Add device posture signals from EDR or IdP.
  • Expand policy-as-code with unit tests for rules.
  • Run red-team simulations (phishing drills) and measure time-to-takedown.
  • Negotiate DPAs with external scanning providers where needed.

12) Governance: Policies, Roles, and Review Cadence

Policy themes:

  • All public links in official channels must be short links routed through SRS.
  • Departments own their links and respond to verdict upgrades within X hours.
  • Student organizations using official channels must generate short links via the campus tool.
  • Interstitial customization allowed but cannot override a Malicious block.

Roles:

  • Security Operations: Own scanning engines, SIEM, takedowns.
  • Comms/Marketing: Interstitial copy, campus advisories, training.
  • IT Platform: SRS availability, LMS/email integrations.
  • Departments: Link owners and stewards.
  • Faculty champions: Liaison for adoption and feedback.

Cadence:

  • Weekly: KPI review + triage backlog of “Suspicious.”
  • Monthly: Update allow/deny patterns, review false positives.
  • Quarterly: Red-team exercise and tabletop incident rehearsal.
  • Annually: Policy review with legal/compliance and student reps.

13) Campus Communications: Training, Micro-UX, and Interstitials

Training that sticks:

  • Two-minute “micro-modules” embedded in LMS orientation.
  • “Lookalike domain” examples for your brand in multiple scripts.
  • Scholarship and bursar-themed drills—realistic to student life.
  • Positive framing: “You caught it—thanks!” to reinforce reporting.

Interstitial micro-UX:

  • Plain language first (“This link looks risky”).
  • Why we think so (“New domain impersonating bursar patterns”).
  • What to do (verify sender, use official portal).
  • Choices (Go back, Report, Proceed if you’re sure).
  • No shame: Thank users for caution.

Posters and QR etiquette:

  • Official QR templates.
  • Footer text: “QRs on campus should resolve to go.university.edu—report others.”

14) Reference Configs and Snippets

The following snippets illustrate common patterns. Tailor them to your environment and secrets management practices.

14.1 Nginx reverse proxy for Safe Redirect Service

map $http_user_agent $is_bot {
    default 0;
    ~*(googlebot|bingbot|duckduckbot|linkedinbot|twitterbot) 1;
}

server {
    listen 443 ssl http2;
    server_name go.university.edu;

    # TLS and HSTS omitted for brevity

    location /r/ {
        # Token = $arg_t or path segment; normalize as needed
        set $token $arg_t;

        # Call internal app to resolve token to destination + policy
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://srs_backend/resolve?token=$token&ua=$http_user_agent&ip=$remote_addr&bot=$is_bot;
    }

    location /interstitial {
        try_files $uri /interstitial.html;
    }
}

14.2 Lua (OpenResty) pre-check for IDN homographs

local idna = require "idna"
local host = ngx.var.arg_host or ""
local ulabel = idna.to_unicode(host)
if ulabel ~= host then
  ngx.var.homograph = 1
else
  ngx.var.homograph = 0
end

14.3 Cloudflare Worker (click-time decision with interstitial)

export default {
  async fetch(req, env) {
    const url = new URL(req.url);
    const token = url.searchParams.get("t");
    if (!token) return new Response("Missing token", { status: 400 });

    const meta = await env.KV.get(`link:`, { type: "json" });
    if (!meta) return Response.redirect("https://security.university.edu/not-found", 302);

    // Get most recent verdict
    const verdict = await env.KV.get(`verdict:`) || "unknown";

    // Basic policy
    if (verdict === "malicious") {
      return Response.redirect("https://security.university.edu/blocked?t=" + token, 302);
    }

    if (verdict === "suspicious" || verdict === "unknown") {
      return Response.redirect(`https://go.university.edu/interstitial?t=`, 302);
    }

    // Clean: strict caching short-lived
    return new Response(null, {
      status: 302,
      headers: {
        "Location": meta.dest,
        "Cache-Control": "private, max-age=30"
      }
    });
  }
};

14.4 Example scanning verdict payload

{
  "url": "https://bursar-university.com/login",
  "hash": "f6a9c1...",
  "checks": {
    "reputation": "bad",
    "sandbox": "credential_harvest",
    "punycode": false,
    "tls_age_days": 2,
    "visual_clone": 0.92
  },
  "verdict": "malicious",
  "confidence": 0.97,
  "recommendation": "block",
  "tags": ["bursar-impersonation", "new-domain"]
}

14.5 Minimal queue-driven rescanner (pseudo-Express)

app.post("/scan", async (req, res) => {
  const { url, token, context } = req.body;
  await queue.add({ url, token, context, phase: "initial" });
  res.json({ status: "queued" });
});

worker.process(async job => {
  const { url, token, phase } = job.data;
  const verdict = await multiEngineScan(url);
  await saveVerdict(url, verdict);
  if (verdict === "unknown") {
    await queue.add({ url, token, phase: "rescan6h" }, { delay: 6 * 3600 * 1000 });
  }
});

14.6 Policy-as-code example (YAML)

rules:
  - id: finance_ext_strict
    if:
      tag.audience: "students"
      tag.unit: "financial-aid"
      dest.domain_category: "finance"
    then:
      interstitial: "hard"
      rescan_interval: "1h"
      max_cache_age: "15s"
  - id: research_mirror_soft
    if:
      tag.unit: "research"
      dest.is_repo: true
    then:
      interstitial: "soft"
      rescan_interval: "24h"

15) Cost, Performance, and Reliability Considerations

Availability: The SRS must be highly available; use multiple PoPs or a CDN worker model. Keep the decision logic fast—most clicks should resolve in <100 ms.

Caching: Cache clean decisions briefly (15–30 seconds) at the edge. Cache verdict lookups but invalidate on upgrades to “suspicious” or “malicious.”

Scanning cost: Reputation checks are cheap; sandboxing is costlier. Use tiered scanning: reputation → heuristics → sandbox only for ambiguous/high-risk links.

Storage: Retain raw click logs for 30 days and aggregated counts longer. Consider downsampling to control volume.

Privacy trade-offs: Resist the urge to collect device fingerprints beyond what’s necessary for security. Favor coarse-grained analytics.

False positives: Provide fast self-service appeal; whitelisting should be precise (host + path) and time-bounded.

16) Checklist

Before launch

  • SRS reachable at go.university.edu with TLS and HSTS
  • Short link creation integrated with LMS and email
  • At least one reputation provider enabled
  • Interstitial v1 localized for your languages
  • “Report this link” path wired to ticketing
  • Weekly KPI dashboard

Within 90 days

  • Multi-engine scanning and sandbox
  • Continuous rescans + verdict upgrades
  • Homograph detection and language-aware warnings
  • QR-only policy + official templates
  • Red-team phishing drill + debrief
  • Policy-as-code repo with tests

Frequently Asked Questions (FAQ)

Q1: Will safe redirects break SEO for our public web pages?
No. Safe redirects govern outbound links, not your site’s own page URLs. For internal navigation, keep canonical URLs. For external destinations, a 302/307 via SRS is fine; you are not trying to pass SEO to third-party pages.

Q2: Won’t users get annoyed by interstitials?
Design with risk-based interstitials. Clean links flow seamlessly; only risky/unknown links trigger warnings. Keep copy short and actionable.

Q3: Can attackers just hide behind new shorteners or multiple hops?
Yes, so always expand chains during scanning and at click time. Do not trust chained shorteners; resolve to the final destination before deciding.

Q4: What about accessibility?
Interstitials and reports must be fully accessible (WCAG 2.1 AA). Provide keyboard navigation and screen-reader labels, especially for “Proceed” and “Go back.”

Q5: How do we protect student privacy?
Store minimal, pseudonymous click data. Do not combine with grade or advising records. Publish a clear privacy notice and retention schedule.

Q6: How do we handle false positives for research sites or code repos?
Offer a prominent “Request review” button with a 24–48h SLA. Use granular allowlisting (host + path) and time limits. Record justification.

Q7: Is this only for official departments?
Require official channels (newsletters, LMS, portals, posters) to use short links. Encourage student orgs to adopt the same tool for safety and convenience.

Q8: Our campus already uses an email security gateway. Why add SRS?
Email gateways don’t control LMS, QR, or web flows, and they cannot re-evaluate links weeks after sending. SRS adds click-time governance across all channels.

Q9: Do we need machine learning from day one?
No. Start with reputation and heuristics. Add ML later for visual similarity and language-aware patterns.

Q10: How do we measure success?
Track malicious blocks, median time-to-takedown, interstitial CTR, false positive rate, and department adoption. Survey users twice a year.

Glossary

  • Safe Redirect Service (SRS): A controlled gateway that checks policy before forwarding to external sites.
  • Interstitial: A warning or info page shown between a click and the destination.
  • Punycode/Homograph: Tricks using lookalike characters in domain names to trick users.
  • Verdict: A scanning outcome (clean, suspicious, malicious, unknown).
  • Short Link: A normalized campus link (e.g., go.university.edu/abc123) that points to a managed destination.
  • Sandboxing: Running a URL in a controlled browser to observe behavior.
  • SIEM: Security Information and Event Management—your logging and alerting hub.

Closing Thoughts

Universities can stop phishing without sacrificing openness. The key is to make links themselves the security control: normalize them through short links, route them through a safe redirect that makes a fast decision, and continuously scan destinations as reputations evolve. When you add student-friendly interstitials, transparent privacy practices, and clear reporting, safety becomes part of everyday campus life.

Links power campus learning. With safe redirects and link scanning, links can power campus safety, too.

Bonus: Copy-Paste Interstitial Template (HTML)

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Safety Check • University</title>
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <style>
    body { font-family: system-ui, -apple-system, Segoe UI, Roboto, Arial, sans-serif; margin: 0; }
    .wrap { max-width: 720px; margin: 0 auto; padding: 24px; }
    .card { background: #fff; border-radius: 12px; padding: 24px; box-shadow: 0 4px 20px rgba(0,0,0,.08); }
    .risk { display: inline-block; padding: 4px 10px; border-radius: 999px; background: #fff3cd; color: #8a6d3b; font-size: 12px; font-weight: 600; }
    .actions a { display: inline-block; margin-right: 12px; padding: 10px 16px; border-radius: 10px; text-decoration: none; border: 1px solid #ddd; }
    .primary { background: #0b5fff; color: #fff; border: none; }
    .help { font-size: 13px; color: #555; margin-top: 12px; }
  </style>
</head>
<body>
  <div class="wrap">
    <div class="card">
      <div class="risk">Safety Check</div>
      <h1>We’re not sure about this link</h1>
      <p>This destination isn’t hosted by the university and resembles pages used in past scams.
         If this link is for financial aid or scholarship information, verify through the official portal.</p>
      <div class="actions">
        <a class="primary" href="#" id="proceed">Proceed anyway</a>
        <a href="#" id="back">Go back</a>
        <a href="https://security.university.edu/report?token={{t}}">Report this link</a>
      </div>
      <p class="help">Tips: Check the address bar for spelling, avoid entering your NetID on non-university sites.</p>
    </div>
  </div>
  <script>
    document.getElementById('back').onclick = () => history.back();
    document.getElementById('proceed').onclick = (e) => {
      e.preventDefault();
      window.location = "{{dest}}";
    };
  </script>
</body>
</html>

Bonus: Department Memo Template

Subject: New Link Safety Standard for [Department]
Effective [Date], all external links in [department newsletters/LMS modules/posters] must use our campus short links (go.university.edu). This routes clicks through a quick safety check and allows us to remove malicious content instantly if it’s discovered later.

  • Use the “Insert Safe Link” button in [Canvas/Moodle] or the “Safe Link” button in your email composer.
  • If you see a yellow interstitial, pause and verify the destination.
  • Report suspicious links using the “Report this link” button.

Questions? Contact [[email protected]]. Thank you for helping keep our campus safe.

By deploying safe redirects and link scanning as shared infrastructure—and by shaping small, respectful UX touches around every click—you make phishing harder on attackers and easier on everyone else.