NORWEGIAN CRUISE LINE - BOOKING PHISHING

The scam email knew her ship, her sailing date and what she had paid. It still was not from the cruise line.

Guests started posting about it on 10 October: an email that opened with their real name, named the right ship, the right departure date, the right booking number, and in some cases the exact amount already paid, then asked them to confirm a payment card before the reservation was cancelled. Norwegian Cruise Line says it is investigating. The interesting part is what the sending domains prove, because they rule out the explanation most people reached for first.

SB

SafeBrowz Threat Research Security Research · 14 October 2026 · 11 min read

What the email actually contained

Guests began reporting the messages publicly on 10 October 2026. The details in them, as described by the people who received them and by the cruise trade press that collected the reports, were their full name, the ship, the departure date and the booking number, and in a number of cases the total fare and a confirmation that the booking was paid in full. Some versions named family members travelling on the same reservation.

The ask varied, which is normal for a campaign that is testing which wording performs. Some messages asked the guest to complete a security verification. Some asked them to confirm the payment card on the booking. A number added the pressure line that matters: act now or the reservation may be cancelled. For anyone with a cruise leaving in the next few weeks, that is an extremely effective sentence.

Norwegian Cruise Line posted a notice on its own site and sent a letter to travel advisors, saying it would also warn guests sailing within the next 30 days. The letter, which was shared publicly, says the company is "aware of reports of fraudulent emails falsely claiming to be from Norwegian Cruise Line" and is "actively investigating the matter". The notice on its website is shorter and says it is investigating those reports. Its notice gives guests the practical instruction: its email comes from ncl.com, e.ncl.com or nclcorp.com, and reservation questions should go through a travel advisor, the phone number for your region, or the contact page on its own site.

On the question everyone asked first

The obvious conclusion when a stranger emails you your own booking number is that the cruise line was breached. We are not going to tell you that, because nobody has established it. NCL has not confirmed how the senders obtained accurate reservation information, and as of writing there is no published finding either way. Travel bookings are also handled by more parties than the cruise line alone, so "the data was correct" does not identify a source on its own.

What matters for you is narrower and more useful: the accuracy of the details tells you nothing about the legitimacy of the message. We are used to treating correct personal information as proof of identity, because for most of the history of our inboxes only the real company knew our order number. That assumption is now simply wrong, and it is wrong across every industry, which is the same lesson behind the Booking.com messages that quote your real reservation and the Amazon recall texts that cite a real order. Treat accurate details as table stakes, not evidence.

What the sending domains prove

This is the part we can establish ourselves, and it is worth walking through, because it is the strongest practical takeaway in the whole story.

Email has a mechanism for exactly this problem. A domain owner can publish a DNS policy called DMARC telling the world what to do with mail that claims to be from them but fails authentication. The strictest setting is p=reject: throw it away. We checked all three of the domains NCL names, and every one of them publishes it, with an SPF record that ends in a hard fail:

• ncl.com sends through Proofpoint, SPF ends -all, DMARC p=reject
• nclcorp.com sends through Proofpoint, SPF ends -all, DMARC p=reject
• e.ncl.com, their bulk-mail subdomain, runs on Salesforce Marketing Cloud, SPF ends -all, DMARC p=reject

None of them carries an sp= exception, so subdomains inherit the same policy. In plain terms: whoever ran this campaign could not put @ncl.com in the From line and expect an enforcing receiver to deliver it, and the reported messages show they did not try. Two caveats so you are not over-trusting this. Not every mail system checks DMARC, so a forgery can still land somewhere that does not look. And none of it constrains the display name, which is the part most phones show you: a message from an unrelated address can still present itself as "Norwegian Cruise Line", which is precisely what happened here. They came from other domains entirely, and the three that were reported publicly each represent a different trick:

• A defunct business's live domain. joinorderly[.]com serves a Squarespace page reading "Website Expired", but the domain itself is current, renewed as recently as August, and its mail is live on Google Workspace. Its DMARC policy is quarantine rather than reject, so a forgery from it would land in a spam folder rather than be discarded, which means forgery is a live possibility here and not something we can rule out. The address reported as the sender is also the one in its own DMARC reporting record, which tells you about the owner rather than the attacker: a guessable founder address is exactly what someone would pick to look real. We cannot tell from outside which of those happened, and the outlet that published the addresses says so itself, cautioning that they may be spoofed and the businesses behind them may not be involved.
• A real organisation's mailbox. One sender address belonged to a genuine interior-design school on Long Island, New York. Its domain publishes p=reject, so an unauthenticated forgery would fail DMARC and be rejected by an enforcing receiver, which points at mail that left through infrastructure the domain authorises. That is a wider door than it sounds: alongside its own mail provider it authorises two large shared sending platforms, the kind any customer of those services sends through. So the likeliest readings are a compromised mailbox or an abused account on one of those platforms, not somebody inside the school. The school is a victim here, and that is why we are not naming or linking it.

A third address was reported too, but the two outlets that listed it spell its domain differently and we could not reach the original report to settle which, so we are leaving it out rather than printing a domain we cannot stand behind. The two we can stand behind are both visible to you in the same place: the actual address the mail came from, not the display name sitting in front of it.

Why the familiar advice fails on this one

Most guidance for spotting a phishing email would have cleared this campaign, and it is worth being honest about which parts and why.

"Look for bad spelling and odd grammar." There was none to find. "Check whether they know anything real about you." They knew your ship and your fare. "Be suspicious of a brand-new domain." This is the one that should change how you read these stories: the payment page in this campaign sat at cruise-booking[.]janeye[.]com, and the domain underneath it, janeye[.]com, was registered in December 2022. It was not days old. It had years of history, which is precisely the kind of signal reputation systems reward, and the phishing lived on a subdomain of it. The registry record for it now shows the domain in clientHold, a registrar suspension, with the record last updated on 12 October. The registrar's own record was last touched on 10 October and already showed the hold, so WHOIS cannot actually tell us which day it was applied, only that it has been.

An aged domain inherits a reputation its subdomains have not earned, and that is the whole reason an attacker wants one. We have hit it twice this month, which is why we think it is a pattern rather than a coincidence: it is also how a fake hosting-renewal page ended up on a real Dutch publisher's subdomain, where we walk through the DNS comparison that tells you whether the owner is a victim. A "new domain" check is a weak defence on its own.

The check that does survive is the sender address, and the reason it survives is the DMARC finding above. It is not a matter of opinion or vigilance: a brand that publishes reject has made the forgery of its own name a technical non-event, so a message that is not from its domain is not from them. The small habit is to tap the sender name in your mail app to expand the actual address, and read what is after the @ rather than what is before it.

The thirty-second check, in the order that matters

1. Expand the sender address. Not the display name. Read the part immediately after the @: for NCL it should be ncl.com, a subdomain of it such as e.ncl.com, or nclcorp.com. Two things to hold onto. A domain that merely ends in those letters is not the same thing, because something like secure-ncl[.]com ends in "ncl.com" and belongs to someone else. And NCL owns other domains besides those three, so an unfamiliar one is a reason to check rather than proof of a scam. When you are unsure, do not resolve it from the email at all: go to step 3.
2. Do not use the link, even to look. If you want to know what it is, paste it into a checker. Do not open it to make up your own mind, because the page is built to be convincing and the domain may well be older than your booking.
3. Go to the company the way you normally would. A new tab, ncl.com typed by hand, or the phone number printed on the confirmation you received when you booked. Not a number from the email.
4. Ask a plain question. "Is there anything outstanding on booking number X?" A real outstanding balance will be visible in your own account and your advisor will know about it.
5. Tell your travel advisor if you booked through one. They are being targeted in the same campaign and NCL wrote to them directly about it.

Red flags in a cruise booking email

• A card you already paid with needs "confirming". Cruise lines take payment through your booking, your advisor, or your account. A link that collects a card number to re-validate it is not a process that exists.
• A cancellation deadline attached to a verification step. Urgency is the payload. A genuine balance has a due date you can see in your own account, not a countdown delivered by email.
• The sender domain is not the brand's domain. The one check that holds. Read what comes after the @.
• A link that does not go to the company's own site. Hover it, or long-press it on a phone, and read the host. A cruise booking is managed on the cruise line's domain, not on a "cruise-booking" subdomain of something else.
• Correct details used as the opening move. Counter-intuitive, but a stranger leading with your booking number is establishing trust they have not earned, and these details circulate.

Check a cruise payment link before you type a card number

SafeBrowz is a browser extension and Android app that reads a page before you interact with it, in three layers. Layer 1 runs in the extension itself: URL patterns and homograph checks that catch a lookalike address without a network call. Layer 2 is server-side, and it is where our 550+ brand database, our own block list and the external threat feeds live; this campaign's payment page sits there now, as an entry for that one host. Layer 3 is AI content analysis in over 100 languages, which reads what a page is actually asking for and flags a card-collection form wearing a brand it does not belong to, even on a domain nobody has reported yet. On this campaign Layer 3 is the only one of the three that could have helped, and it is worth saying why: our brand database holds no cruise line at all, and the payment host carried no brand name in it to match even if it did. There was no lookalike address here, just an ordinary-looking subdomain. What was left to judge was the page.

Detection comes from threat-intelligence research and our own brand database, not from user browsing data. SafeBrowz does not store per-user browsing history.

Honest scope: two limits worth stating on this one. First, the sender-address check that matters most here happens in your email, and a browser extension cannot see your inbox: that step is yours, and no scanner replaces it. Second, this campaign's page had already stopped resolving by the time we looked at it, so our verdict on that host today is a block we added on 14 October after verifying the reporting, not a detection we can claim credit for. What we can do is the next one, and the part we are genuinely good at is the moment after the click, when a page asks for a card.

Add to Chrome Add to Firefox Add to Edge Get it on Google Play