In Artificial Intelligence-Driven Phishing: How Phishing Technique Is Evolving and Implemented (2026-06-08), InfoQ highlighted how phishing is transforming via AI from "manual targeted efforts" into an "automated, scaled attack model." Every stage of the phishing lifecycle—reconnaissance (gathering targets), spoofing generation (creating email copy and spoofed sites), distribution (mass sending), and evasion (bypassing detection)—has been elevated by AI, ushering in an era where "highly convincing impersonations can be dispatched in massive volumes at low cost." Attacks that could previously be spotted by unnatural Japanese or crude fake sites have become indistinguishable and exponentially more numerous—this has become the baseline reality on the ground.
In custom system development and cybersecurity, organizations have repeatedly fallen into the trap of "stopping after deploying a single email security product" or "resting easy just because DMARC was configured." From our position supporting clients in custom development, we view this not as a matter of "whether to install tools," but as a design challenge of "whether we can hand off sender domain authentication, spoofing detection, hardened authentication, employee drills, and incident response as an organizational capability ready for sustained operation." Connecting with the fundamentals that must be defended covered in Web Security Basics (GH Media) and the mindset of "building defenses in from the start" covered in Security by Design (GH Media), this article organizes "phishing defense (email authentication and spoofing resilience) implementation support" as a custom development package. Note that this article focuses exclusively on defensive offerings and does not cover attack procedures.
Why rebuild phishing defenses now
| Dimension | Conventional phishing | AI-driven phishing (2026) |
|---|---|---|
| Reconnaissance | Attackers research targets manually | Automated harvesting and profiling of public data |
| Impersonation fidelity | Unnatural phrasing, crude fake websites | Automated generation of natural copy and sophisticated fake websites |
| Distribution volume | Low-volume dispatches targeting specific individuals | High-volume, continuous, multilingual rollouts |
| Detection evasion | Often filterable via known patterns | Varies phrasing to slip past existing filters |
| Cost | Labor-intensive | Automation drives down marginal costs |
| Defensive baseline | The premise that humans "can notice" holds true | Cannot rely solely on human observation |
In short, "installing a single product" and "maintaining organizational phishing resilience" are two entirely different things. In custom development as well, "introducing sender domain authentication in phases, detecting and reporting spoofing, hardening authentication, and training staff through drills" has become a fundamental baseline for quality. This enables us to guarantee "defense-in-depth across technology, operations, and drills" as our deliverable.
Pillars of defense-in-depth implemented in custom development
1. Sender domain authentication (SPF / DKIM / DMARC, BIMI)
SPF declares which servers are authorized to send email for your domain, DKIM verifies that emails have not been tampered with and carry a legitimate signature, and DMARC declares how to handle emails that fail SPF or DKIM (instructing receiving servers on actions to take). DMARC policies have three progressive tiers: p=none (monitoring only, no rejection), p=quarantine (treat as spam), and p=reject (reject messages). Because jumping straight to reject risks dropping legitimate emails, the standard approach is to collect reports under none to understand actual sending patterns before gradually tightening enforcement. BIMI operates on the prerequisite that DMARC is enforced at quarantine or higher, displaying your official logo on authenticated emails to visually distinguish them from impostors.
; DMARC レコード例（まずは監視から始める段階）
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1; adkim=s; aspf=s"The standard playbook is to designate an aggregate report destination in rua, visualize sending realities, and then graduate from p=none to quarantine and finally reject.
2. Detection and reporting of spoofing and fake sites
Continuously monitor for unauthorized mail sent under your domain using DMARC aggregate reports, and establish contact channels and procedures to initiate takedowns as soon as phishing sites are discovered. In tandem, establish channels for employees to report suspicious emails with a single click (via report buttons or dedicated desks) to feed frontline detections back into defense operations. Detection is meaningless without an operational reporting workflow to act on it.
3. Web and authentication spoofing resilience (passkeys, etc.)
Enforce official domain discipline (avoid proliferating confusing domains and publicize canonical URLs) while strengthening authentication for logins and critical transactions. Because passwords alone are easily stolen via phishing, design transitions to phishing-resistant passwordless authentication such as passkeys (GH Media). Across forms and inquiry workflows, establish clear policies for handling attachments and links so users can reliably differentiate official sites from impostors.
4. Employee drills and education
When emails slip past technical defenses, people form the final line of defense. Through regular phishing drills (simulations) and education, ingrain the habit of reporting suspicious messages, integrating drill metrics (click rates and reporting rates) into ongoing operational reviews. Design these exercises not to punish mistakes, but to foster an active reporting culture.
Five phases of "phishing defense (email authentication and spoofing resilience) implementation support" provided in custom development
Phase 1: Assessment (1–2 weeks)
- Inventorying sending domains and auditing current SPF / DKIM / DMARC status
- Reviewing spoofing and fake site monitoring status, and checking for reporting workflows
- Evaluating authentication mechanisms (passwords / MFA / passkeys) and current training drills
- Deliverables: Phishing resilience assessment report + prioritized remediation plan
Phase 2: Design (1–2 weeks)
- Formulating a phased DMARC rollout roadmap (
none→quarantine→reject) - Designing operational workflows for spoofing detection, reporting, and takedowns
- Designing authentication hardening (passkeys, etc.) and attachment/link policies
- Deliverables: Defense-in-depth architecture design + DMARC migration plan
Phase 3: Implementation (2–4 weeks)
- Cleaning up SPF (addressing the 10-lookup limit detailed below) and setting up DKIM signatures
- Deploying DMARC at
p=noneand establishing an aggregate report intake pipeline - Implementing reporting buttons/desks and notification routes for detected fake sites
- Preparing authentication hardening and drill platforms
- Deliverables: Configured settings + operational runbooks
Phase 4: Verification & handover (1–2 weeks)
- Auditing actual sending traffic via reports and evaluating readiness to upgrade from
quarantinetoreject - Upgrading policy enforcement only after confirming legitimate email delivery is unaffected
- Handing over incident response procedures and conducting initial employee drills
- Deliverables: Verification report + incident response runbook + drill results
Phase 5: Ongoing operations (continuous)
- Ongoing monitoring of DMARC reports and tracking spoofed transmissions
- Assisting with takedown requests when fake sites are detected
- Executing recurring drills and improving metrics (click rates / reporting rates)
Standard defense sets for custom development
| Area | Recommendation | Avoid |
|---|---|---|
| Sender domain authentication | Full alignment of SPF, DKIM, and DMARC | DMARC unconfigured / left abandoned at p=none |
| DMARC migration | Phased rollout: none → quarantine → reject | Jumping directly to p=reject |
| SPF | Optimized within the 10-lookup limit | Uncontrolled addition of include mechanisms |
| Spoofing visibility | Active DMARC management + BIMI | Abandoned without active monitoring |
| Authentication | Phishing-resistant authentication such as passkeys | Standalone passwords |
| Human countermeasures | Regular drills + reporting workflows | Education only / no reporting channels |
Which organizations need this / for whom priority is low
| Organizations that need this | Organizations where priority is low |
|---|---|
| Sends high volumes of email under corporate domains | Sends virtually no email |
| Communicates regularly with clients and partners via email | External touchpoints are very limited |
| Faces risks of brand impersonation | Low brand visibility and minimal targeting risk |
| Handles critical actions like logins and financial transactions | Has no features requiring user authentication |
| Has past experience or near-misses with spoofing incidents | Existing operations experience zero issues |
Six clauses to include in custom development contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Target scope | Scope of target domains and systems | Handling of subsidiaries and secondary domains |
| DMARC migration | Phased rollout approach and progression criteria | Target timeline to reach reject |
| Impact on legitimate email | Guaranteeing zero delivery drops via phased rollout | Prior inventory of all sending sources |
| Detection & reporting | Spoofing detection and reporting workflows | Demarcation of responsibilities for initial response |
| Incident response | Procedures upon detecting fake sites | Scope of takedown support |
| Continuous operations | Frequency of report monitoring and drills | Operating costs and KPIs |
Client ROI estimates (assuming an organization sending high email volume)
| Item | Before implementation | After implementation | Difference |
|---|---|---|---|
| Spoofed transmissions | Corporate domain impersonated | Disabling animations with reject | Reduced risk of brand damage |
| Damage risk | Employees and clients deceived | Dramatically reduced via defense-in-depth | Suppression of breach and incident costs |
| Email deliverability | Risk of spam tagging due to auth flaws | Improved via proper authentication | Higher deliverability for legitimate emails |
| Human response | Attacks go unnoticed and unreported | Established reporting culture | Early detection and faster initial response |
| Annual benefit | — | — | Halt spoofing + reduce damage + improve deliverability |
Even completing just the Phase 1 assessment delivers immediate value by using DMARC reports to visualize how exposed your current sending domains are to spoofing. Impersonation attacks typically erode brand equity and customer trust quietly long before they are noticed.
Five common pitfalls to avoid
Pitfall 1: Leaving DMARC permanently at p=none
Collecting reports alone will not stop spoofing unless you graduate to an enforcement policy. Build the progression from quarantine to reject into your project plan.
Pitfall 2: Exceeding the 10-lookup SPF limit
SPF evaluation fails if DNS lookups exceed 10. Clean up include mechanisms to keep queries within limits.
Pitfall 3: Jumping straight to p=reject and dropping legitimate email
Enforcing rejection without inventorying mail sources means critical business emails and third-party delivery services will fail to reach recipients. Understand sending realities through reports before gradually tightening policies.
Pitfall 4: Running drills without technical safeguards
Training and drills alone leave defenses full of holes without sender domain authentication and hardened logins. Design technical and human countermeasures as twin pillars.
Pitfall 5: Wasting detections due to lack of reporting workflows
Even if employees spot suspicious messages, security teams will never receive the intelligence without a clear reporting channel. Establish one-click reporting workflows first.
90-day action plan
| Week | Action |
|---|---|
| Week 1〜2 | Sending domain inventory + current SPF/DKIM/DMARC assessment |
| Week 3〜4 | Deploying DMARC at p=none + initiating aggregate report ingestion |
| Week 5〜7 | SPF cleanup (under 10 lookups) + DKIM configuration + building reporting workflows |
| Week 8〜9 | Report auditing + upgrading policy to p=quarantine |
| Week 10〜11 | Designing authentication hardening (passkeys, etc.) + conducting initial drill |
| Week 12〜13 | Confirming zero impact on legitimate email + reaching p=reject + establishing runbooks |
Conclusion — from installing products to handing off resilience
Now that AI has automated and scaled phishing, defensive strategy must move beyond "installing a single tool" toward "operating sender domain authentication, spoofing detection, hardened authentication, drills, and incident handling as organizational resilience." From our position supporting security in custom development, structuring projects to introduce SPF/DKIM/DMARC in phases, detect and report spoofing, harden authentication, and train personnel via drills is the path to delivering deliverables that unite technology and operations. If you are also looking to overhaul internal SecOps and automated detection, please also read SecOps MCP Integration (GH Media).
This initiative cannot be treated as a one-size-fits-all package. Whether you already have p=none records or none at all, whether your senders are limited to in-house servers or scattered across third-party marketing tools and subsidiary domains, and whether your goal stops at reaching reject or extends to embedding drills and reporting habits—the required steps and timeline depend entirely on where your organization stands among the options outlined in this article. First, let us know the current state of your sending domains and your desired scope of delivery via our contact form. We will work backward from your goals to design the optimal rollout.
