Key takeaways

  • In October 2026, four Japanese services that send email on behalf of other organizations disclosed breaches: Arcadia (disaster alerts for local governments), Yumil Link (Cuenote), Blastmail (a Rakus subsidiary) and Y-mail (Igreks). Earlier in the month, the ransomware attack on IDCF Cloud had stopped email delivery for several large companies.
  • The numbers are large. Yumil Link now counts a cumulative 51.63 million records from 49 client systems, the second-largest breach in Japan this year. Blastmail lost the details of every customer and the delivery lists of 345. Hundreds of client organizations have had to send their own notices.
  • In each of the four, the attackers reached the access the vendor itself uses to set up and support the environments it runs for each customer: a secret key, support staff credentials, setup scripts, API servers. In our view, that privileged path is the common weak point.
  • Three of the four were then used to send phishing, from the vendor's systems or under its customers' names. Email authentication does not catch this: mail sent from a hijacked legitimate environment is properly signed, and only the sender can defend against it. Phishing from domains attackers register themselves already passes DMARC more than 90% of the time, according to the Council of Anti-Phishing Japan.
  • If your organization sends mail through such a service, it holds your customers' data and your name. Check what it keeps, delete what you do not need, ask how its staff access the environment it runs for you, and be ready to revoke the signing keys it holds for your domain.

Five cases in one month#

Service What it does Disclosed How the attackers got in What was exposed Misuse so far
SpeeCAN RAIDEN (Arcadia) Disaster alerts by email, voice and fax for local governments Oct 13 A directory traversal flaw exposed a secret key used for logins between its services; account IDs were then brute-forced Up to about 3.14 million email addresses, plus phone and fax numbers (estimates) 1.42 million emails, mostly card-company phishing, sent through its system
Cuenote FC (Yumil Link) Bulk email delivery Oct 19, Oct 26 A library vulnerability gave attackers its support staff's credentials; a planted program read other systems' data, and login sessions were hijacked A cumulative 51.63 million records from 49 client systems; 16 systems still being counted Spam posing as a credit card company, sent from Yumil Link's own domain
Blastmail (Rakus Lite Cloud) Bulk email delivery Oct 21 Attackers got into two API servers, ran commands, and connected to its sales system and service database Details of every customer; delivery lists of 345 contracts None disclosed; the service has been down since October 21
Y-mail (Igreks) Bulk email delivery Oct 24 Setup scripts for customer environments were taken from its portal server and used to get into customers' sending environments Up to 30 addresses per newsletter may have been viewed Phishing may have been sent from some customers' environments
IDCF Cloud (IDC Frontier) Cloud hosting used by several email services Oct 7 Ransomware on the cloud platform IDC Frontier says it found no sign that data was taken Email for JR East, View Card, JR Kyushu, Peach and others stopped or delayed

The fifth is different in kind: IDCF Cloud is a hosting platform, not an email service. But it shows the same dependency from the other side. Several companies learned in one morning that their newsletters, booking confirmations and member emails all ran through a vendor's servers on that platform. JR East, View Card and JR Kyushu warned that up to millions of addresses may have been exposed; JR Kyushu and JR Central later withdrew their warnings after IDC Frontier said it found no leak.

Yumil Link's second report on October 26 changed the scale of its breach. Its first report on October 19 had counted five systems and an estimated 9 million records. Log analysis then found 45 more systems where the attackers had used the planted program to read other systems' data, or had taken session information at login and used it to sign in. In total, data was copied out of 49 systems, each used by a single client company, a cumulative 51,628,280 records. Address books in the service hold email addresses and, depending on the client, names, prefectures, dates of birth and other fields.

The same day, JR Central, JR West and JR Kyushu said Yumil Link had told them that data of some members of EX reservation and smart EX, the online booking services for the Tokaido, Sanyo and Kyushu Shinkansen, had been viewed or taken: email addresses, member IDs, names in katakana and member types, for members who had received certain emails sent through Cuenote FC. When Yumil Link first found the attack on October 16, it had told them EX customers were not affected. The number of members is still being confirmed.

Yumil Link's timeline also shows what was missing. On October 18, two days after it found the attack, it applied IP restrictions to admin screens and APIs "where none had been set."

What a "customer environment" is#

These services do not reach into their customers' own networks. A company that uses one uploads its mailing list to the vendor, writes its newsletter in the vendor's web screen, and the vendor's servers send it. What the vendor's reports call a customer environment is the set of systems the vendor runs for that customer, on its own servers: an admin screen, a database of address books and sending history, and sending servers set up to send under the customer's domain.

Some services run one shared system for many customers. Others give each customer, or each large customer, a dedicated environment. Of the 81 Cuenote FC systems the attackers tried, 78 were dedicated to a single company; Y-mail likewise describes "dedicated sending environments" for each customer. The vendor's staff log in to these environments to set them up, troubleshoot and support them. That access is what matters below.

Why email delivery services#

Companies that send newsletters, alerts, booking confirmations and notices hand their mailing lists to specialist services. In our view, that makes those services worth more to an attacker than their size suggests. Each one holds four things:

  • Lists of real, active addresses, often with names and other fields used to personalize mail
  • Sender reputation: years of good sending history that gets mail past spam filters
  • Authentication: the right to send mail that passes SPF, DKIM and DMARC checks for its customers' domains
  • Brands: the names of the companies, cities and services its customers send under

The last three are what turn a data breach into a phishing platform. Arcadia's system sent 869,575 of its 1.42 million malicious emails to addresses it did not hold: the attackers used it to send to their own lists, borrowing its reputation and its customers' names.

They also matter for availability. When IDCF Cloud went down, Peach Aviation's itinerary emails were delayed, and when Arcadia's servers were stopped, Okayama could not send phone warnings about dam water releases. An email service can be part of how an organization warns people.

The common weak point: the vendor's own way in#

Look at the column on how the attackers got in. None of the four began with a single customer's weak password. Each reached something the vendor uses to set up and operate the environments of many customers at once:

  • Arcadia: a secret key for logins between its own services, kept in a config file
  • Yumil Link: the credentials of its support and quality assurance staff, which the attackers then tried on other systems
  • Y-mail: setup scripts for customer environments, kept on its portal server, which it calls "the trigger for the intrusion into customer environments"
  • Blastmail: API servers that connected to both its sales system and the service database

In our view, this is the same problem seen in attacks on managed service providers: a path built for the vendor's convenience, to set up, support and bill many customers, becomes a path to all of them at once. Among the countermeasures Yumil Link lists is deleting its support staff's accounts from other systems, which it began two days after finding the attack.

In our experience, vendor security reviews ask about encryption, certifications and data centers far more often than about how the vendor's own staff access the environment it runs for a customer: which accounts, from where, with what authentication, and whether the customer can see it in its logs. These cases suggest that question deserves a place near the top.

Authentication does not help here#

For years, the advice on phishing has been to authenticate mail: publish SPF, sign with DKIM, set a DMARC policy of reject, and let receivers filter out mail that fails. That advice is still right. It stops attackers from spoofing a domain they do not control. But a DMARC pass shows only that the mail really came from the domain it claims. It says nothing about whether the sender is honest, and phishing now passes it routinely, in two main ways.

1. A domain the attacker owns. The attacker registers a domain and sets up SPF, DKIM and DMARC correctly, so the mail passes. The domain may be a look-alike of a real brand (a typo, an added hyphen, a letter from another alphabet), or have nothing to do with the brand at all, with only the display name, such as a card company's name, doing the deceiving. Many recipients see only the display name.

2. A real domain, with the sending system taken over. The attacker sends from the legitimate domain, either by breaking into the delivery platform, as in the cases above, or by taking over a customer's account on it, or a company's own mailbox. The mail goes out through real servers, signed with real keys.

Between the two, attackers also open their own accounts on legitimate delivery services and send from there. The Council of Anti-Phishing Japan noted in September that hostnames of legitimate services, including the email platform SendGrid's domain, were still widely used in the addresses of reported phishing sites.

The first kind is now the norm#

The Council counts phishing that reaches its research addresses each month. Most now comes from domains the attackers registered themselves, and almost all of that passes DMARC:

Month Share of phishing from attackers' own domains Of those, share passing DMARC
December 2025 75.3% 17.8%
July 2026 73.5% 94.7%
August 2026 67.7% 94.2%
September 2026 62.2% 98.9%

The Council does not say how many of these domains imitate a brand and how many are unrelated.

The second kind is what these breaches add#

Mail sent from a hijacked customer environment comes from the customer's real domain, through the service's real servers, signed with the DKIM key the service holds for the customer's domain. It passes every check, because it is, technically, genuine. After phishing went out from customer environments, Y-mail is regenerating every customer's DKIM private key as a precaution and setting their DMARC policy to reject. In Arcadia's case, Shizuoka saw a fake card-company email from the alert service's own sender domain. The spam Yumil Link has seen mixes the two kinds: the address is on Yumil Link's own domain, and only the display name claims to be a card company. Yumil Link has not said how those emails were sent.

Different defenses#

In our view, the two kinds call for different defenses:

  • Against attacker-owned domains, the receiving side still has a chance, because the domain is wrong. Checking the actual address, not the display name, helps. So does BIMI, which the Council recommends: it shows a verified brand logo only next to mail from the brand's own authenticated domain. Above all, reaching a service through its app or a bookmark rather than a link in an email defeats it.
  • Against a hijacked platform or account, the receiving side has almost nothing to go on: the domain, the signature and, in principle, even a BIMI logo would all be genuine. The defenses are on the sending side: how the delivery vendor protects its own access, multi-factor authentication on your accounts with it, and being ready to revoke the keys it holds for your domain.

For recipients, the lesson covers both: do not log in from a link in an email, however genuine it looks. Use the app, a bookmark or a password manager.

Hundreds of notices, and joint reports#

Each breach at a vendor becomes a breach for its customers. Under Japan's Act on the Protection of Personal Information, the organizations whose data it is usually have to report to the Personal Information Protection Commission and notify the people affected. innovaTopia's tracker lists 290 organizations that had published notices about Blastmail as of October 27, and 22 about Y-mail. The Ministry of Internal Affairs and Communications counted 111 local governments and other bodies that had reported possible leaks through Arcadia by October 14.

The vendors have tried to absorb some of that work. Blastmail offers joint reports to the regulator in its customers' names together with its own, and Arcadia filed reports on behalf of its municipal customers. In our view, that is the right response and should become standard. It also shows that a vendor's breach is a regulatory event for every customer, which is worth agreeing on in the contract before it happens.

The EX case shows another reason to plan ahead: a vendor's first assessment can change. JR Central and its partners were told on day one that their customers were not affected, and ten days later that they were.

What this means for practitioners#

If your organization sends email through a delivery service:

  • Know every service that sends in your name. Marketing, alerts, transactional mail and surveys often use different vendors, chosen by different departments.
  • Keep less there. Delete old lists, and avoid uploading fields such as dates of birth unless you use them in mail. Yumil Link's address books held whatever each client chose to put in.
  • Ask how the vendor's staff access the environment it runs for you. Which support accounts exist, whether they are limited by IP address and protected by multi-factor authentication, and whether you can see their activity.
  • Restrict your own admin and API access by IP address where the service allows it, and turn on multi-factor authentication.
  • Give each vendor its own DKIM selector, so you can revoke one vendor's key without touching your other mail, and know how to do it quickly.
  • Agree on incident terms in advance: how fast the vendor will tell you, whether it supports joint reporting, and what it will tell you about scope.
  • Have a second channel. If your alerts or booking confirmations depend on one email service, decide how you would reach people if it stopped for a week.

If you receive a notice that your address leaked through one of these services, expect phishing that uses the name of the company you dealt with, possibly sent from its real domain. Go to the company's site or app directly rather than following links.

Japanese terms at a glance#

Japanese Reading Meaning
メール配信サービス mēru haishin sābisu Email delivery service
メルマガ（メールマガジン） merumaga (mēru magajin) Email newsletter
配信先リスト haishinsaki risuto Delivery (recipient) list
送信ドメイン認証 sōshin domein ninshō Sender domain authentication (SPF, DKIM, DMARC)
なりすまし送信 narisumashi sōshin Spoofed sending
サポート・品質管理担当者 sapōto hinshitsu kanri tantōsha Support and quality assurance staff
連名報告 renmei hōkoku Joint report (to the privacy regulator)
委託先 itakusaki Contractor, vendor