Fake-Dating on Autopilot: The Punctipes Auto-Login Notification Family

Since late 2023, one operator has run a family of fake-dating sites that email fabricated "new message" notifications from personas who do not exist. Every site uses the same script: the subject claims that a woman with an Eastern-European first name has just written to you, the body contains one blurred photo and one line of manufactured longing, and a single button takes the recipient directly to a paywalled chat where every reply costs credits. The estate self-identifies in its footer as a real Cyprus company, Punctipes Limited (HE 408773). The brands are linked not by a shared registrant, but by a persistent infrastructure fingerprint: a t.<brand>[.]com/?r=<base64> auto-login redirect, a message@ / notifications@ sender pair, and a mirror support@<brand>.help apex. When one site is flagged and falls silent, the next is already sending.

Key Takeaways

• A single operator runs a rolling family of self-hosted fake-dating platforms linked by an identical auto-login CTA construction, a two-address notification sender pair, and a mirror .help support apex, rather than any shared WHOIS registrant.
• The lure is a fabricated inbox notification, not a request. Subjects insert the recipient's own email handle and a rotating persona name to imitate platform-level personalization, while the body contains a single one-click call to action.
• Every click passes through a t.<brand>[.]com/?r=<base64> redirect. Its decoded destination contains a login_token= bearer credential that places the recipient in an already-authenticated credit-messaging session without a password step.
• The infrastructure combines fresh and aged domains. The core brands either register through Cloudflare in recent batches or reuse an older dropped domain, while a separate tier of roughly a dozen aged, affiliate-sourced domains feeds the same funnel.
• The mail authenticates cleanly. The self-hosted brands pass SPF, DKIM, and DMARC on operator-owned apexes, so authentication tells a defender only that the operator controls the domain, not that the sender is honest.
• The operator's own footer is the most persistent pivot. The Punctipes corporate identity survives complete apex and CTA rotation and reappears verbatim on every new site.

Background

Fake-dating platforms in this class make money through credit-messaging. A visitor signs up for free, immediately receives a flood of attention from attractive profiles, and then learns that reading or answering each message costs tokens sold in bundles. The profiles sending those messages are fabricated, scripted, or operated by paid staff. This is not a con run by one scammer against one victim. It is an industrialized funnel that harvests lonely and curious users at volume, then bills them through micro-payments for the illusion of a conversation. Consumer dating-review sites such as DatingSpot24 and Scam-Detector describe exactly this model for the named brands here, including credit pricing on the order of a couple of credits to reply and dozens of credits for a photo.

Email sits at the top of the funnel. Rather than waiting for users to discover the site, the operator sends fabricated "someone messaged you" alerts to their inboxes and relies on curiosity to complete the loop. Two design choices help the mail work. First, it resembles a routine product notification rather than a pitch, leaving the content bland enough to pass casual inspection. Second, the call to action provides a one-click auto-login, removing any password friction between curiosity and the paywall.

The corporate veneer deserves some context. Punctipes Limited is a genuine entity in the Cyprus business register, incorporated in April 2020 and described there as a marketing agency. A registered company behind a platform is not proof that the platform is honest. It makes takedown more complicated because the operator can point to a real corporate filing, but the product it fronts is a fabricated-persona lure with a metered paywall.

Several supporting mechanics in this campaign may be unfamiliar to readers who have not seen them used together:

• A ?r=<base64> redirect parameter contains the true destination URL as a base64 blob behind an operator-controlled hop. This conceals the actual landing point from casual inspection and naive link filters, while remaining unremarkable because legitimate systems encode redirect targets in the same way.
• A ULID (Universally Unique Lexicographically Sortable Identifier) is a 128-bit identifier like a UUID, but encoded as a sortable, URL-safe 26-character string with a millisecond timestamp in its leading bits. In these URLs, it identifies a specific fabricated conversation and scales cleanly on the backend.
• An auto-login token (login_token= here, activation_token= on the adjacent variant below) is a bearer credential embedded in the CTA link. The token itself is the credential, so clicking the email opens an authenticated session. Anyone who obtains a forwarded copy of the link inherits that session.
• partner_id and partner_login_id parameters assign an arriving visitor to a specific affiliate for payout. Their presence on every CTA points to a paid affiliate layer beneath the email channel: the commercial machinery that allows a credit-messaging site to buy victim traffic instead of sourcing it organically.
• Postmark is a reputable transactional ESP with the click-tracking domain pstmrk[.]it. Sending "notification" mail through a transactional service provides inbox placement, a warmed sending reputation, and per-recipient click analytics. One brand in this investigation uses that rail; the operator's own brands do not.

Discovery and Infrastructure

The estate first came into focus through a pair of message@ and notifications@ senders on a self-hosted apex. It widened as sibling platforms appeared with the same construction. Attribution across the self-hosted brands depends on their infrastructure shape and operator footer, not a single registrant, because every apex is protected by registrar privacy.

Four core self-hosted brands anchor the operator family, all built from the same pattern. Behind them is a broader tier of roughly a dozen aged and affiliate-sourced dating-brand domains that intermittently feed the same fake-notification funnel. Those domains are lower-confidence, so they are described here as a tier rather than named individually. One additional brand, flirtynlocal[.]com, uses the same genre and funnel shape but differs in its infrastructure and is publicly attributed to another company. We therefore treat it below as an adjacent variant, not part of the Punctipes estate.

Brand	CTA / auto-login host	Notification senders	Affiliate ID	Rail	Registration cohort
placefortalk[.]com (+ placefortalk[.]help)	t.placefortalk[.]com	message@ / notifications@	partner_id=1133	Self-hosted SMTP	Cloudflare, 2023-11-14
amoures[.]com	t.amoures[.]com	message@ / notifications@	not observed	Self-hosted SMTP	GoDaddy, 2005-05-21 (aged)
amourtalks[.]com (+ typo amoutalks[.]com, mirror amourtalks[.]help)	t.amourtalks[.]com	message@ / notifications@	partner_id=718	Self-hosted SMTP	Cloudflare, 2025-06-04
amourwings[.]com	t.amourwings[.]com	message@ / notifications@	not observed	Self-hosted SMTP	Cloudflare, 2025-07-09

The self-hosted brands fall into two registration cohorts. The purpose-built cohort registers through Cloudflare in recent windows with the WHOIS organization redacted, and includes the sites the operator newly establishes. The other cohort reuses a domain first registered years earlier through a different registrar. This is the same aged-domain sourcing used for the broader feeder tier, giving the operator inventory with a longer, more innocuous registration history. The original site, placefortalk[.]com, has since gone dormant after being flagged, while its Cloudflare-registered sister sites continued sending. This behavior is characteristic of the operator: instead of repairing a burned apex, it rotates to the next one.

Each brand also registers a corresponding .help apex used only for the footer support address. This gives the operator a second owned TLD for each brand and a support channel that appears separate from the sending domain.

How It Works

The recipient receives an email with the brand as its display name, for example, PlaceForTalk, sometimes preceded by a bullet. The subject claims that a specific woman has written and inserts the recipient's own email handle to imitate personalization: 💌 [handle], a new message from Olena awaits. Persona names come from a small pool of Eastern-European first names paired with an age, including Olena, Anastasiia, Ruslana, or Iryna. The body is intentionally sparse: one blurred or teasing persona photo, a single line of persona-voiced longing ("Now I'm left thinking about our conversation..."), and one button.

The button links to t.<brand>[.]com/?r=<base64>&did=<delivery_id>. Base64-decoding the r= blob produces a destination on the brand apex in the form https://<brand>[.]com/dialogs/<ULID>?partner_id=<N>&partner_login_id=<N>&login_token=<token>. The login_token performs a password-less auto-login. The recipient arrives inside the platform's chat interface already signed in and viewing the fabricated conversation identified by the ULID. Replying to "Olena" then costs credits, and those credits cost money. The email does not ask for a credential or payment. It only needs to earn one click.

Two supporting endpoints complete the send. A read-receipt beacon calls t.<brand>[.]com/read/?did=<delivery_id>, while the unsubscribe handler is hosted at t.<brand>[.]com/unsubscribe/<list_id>/<delivery_id>. Both use the same per-send delivery identifier that the operator uses to track engagement.

Sample Lures

All samples are defanged and have recipient data removed. They contain attacker-controlled content only; every recipient identifier has been replaced with a placeholder.

Core self-hosted brand, handle-keyed persona notification:

From: "PlaceForTalk" <notifications@placefortalk[.]com>
Subject: 💌 [recipient handle], a new message from Olena awaits
Return-Path: <bounce@mail.placefortalk[.]com>

[recipient handle], Now I'm left thinking about our conversation...

  [ blurred persona photo ]        Read Message

© 2026 Punctipes Limited
Manou Katraki 6, Office 7, Limassol, 3107, Cyprus
Registration No. HE 408773
support@placefortalk[.]help    +1 (833) 588-4911

CTA: hxxps://t.placefortalk[.]com/?r=<base64>&did=<delivery_id>
  decodes to: hxxps://placefortalk[.]com/dialogs/<ULID>?partner_id=1133&login_token=<token>

Sibling brand, engagement-notification variant (a "liked you" pretext rather than a message):

From: "AmourWings" <notifications@amourwings[.]com>
Subject: 🚀 Anastasiia found your profile!

Someone new is interested. See who liked you back.

  [ blurred persona photo ]        View Profile

CTA: hxxps://t.amourwings[.]com/?r=<base64>&did=<delivery_id>

Adjacent same-genre platform (divergent infrastructure, publicly attributed to a different operator), username-style persona on a transactional-ESP rail:

From: "FlirtyNLocal" <notifications@mails.flirtynlocal[.]com>
Subject: [username] sent you a message
Female | 29

You have 1 unread message waiting.

  [ blurred persona photo ]        Open Message

CTA: hxxps://track.pstmrk[.]it/... -> hxxps://flirtynlocal[.]com/verify?...&activation_token=<token>

Technical Analysis

This family is useful to study because each site carries the same reproducible template. Five signals separate the operator's traffic from legitimate dating-product mail.

Sender and Support-Apex Grammar

Every self-hosted brand uses the same mailbox grammar on its apex. The lure senders are always message@ and notifications@. A small group of lifecycle addresses surrounds them: activate@, confirm@, welcome@, and support@, used for onboarding and account mail. The footer support address never uses the sending apex. Instead, it is always support@<brand>.help, on a separately registered mirror TLD. This one-to-one pairing of a .com sending apex and a .help support apex is a compact, high-signal fingerprint because legitimate operators rarely place support on a parallel TLD registered on the same day as the primary.

The Auto-Login CTA Construction

The click path is identical across the self-hosted brands and provides the strongest infrastructure-level pivot when the footer is truncated. Clicks pass through t.<brand>[.]com, an operator-owned redirect host, with the destination stored as a base64 blob in an r= parameter. The decoded destination uses a /dialogs/<ULID> path on the brand apex and carries a login_token. The exact same construction appears across otherwise unrelated brand names: the redirect host naming, base64 parameter, ULID-keyed dialog path, and embedded auto-login token. That reuse links the estate at the infrastructure layer.

The complete tracking-parameter dictionary observed on the decoded landing URLs:

Parameter	Location	Role
r=	t.<brand>[.]com/?r=...	base64 blob encoding the true destination URL
did / delivery_id	redirect, read-receipt, unsubscribe	per-send delivery identifier
partner_id	decoded landing	affiliate / brand attribution (1133 placefortalk, 718 amourtalks)
partner_login_id	decoded landing	affiliate sub-attribution / traffic-source id
template_id	decoded landing	email-template variant id
chat_request_id	decoded landing	fabricated inbound-message reference
message_id	decoded landing	fabricated message reference
event_data_id	decoded landing	event / campaign tracking id
initial_id	decoded landing	uuid session / initial-contact id
login_token	/dialogs/<ULID> (self-hosted rail)	password-less one-click auto-login
list_id	/unsubscribe/<list_id>/<did>	mailing-list identifier

Brand-Name Generation

The operator draws from a narrow, repetitive naming vocabulary: an amour* cluster (amoures, amourtalks, amourwings) and generic dating-intent tokens across the aged feeder tier. It also creates typo-siblings of active brands by removing a character. One example is amoutalks[.]com, which shadows amourtalks[.]com under the same support apex, captures mistyped traffic, and reserves a spare apex.

Registration Cohorts and Aged Staging

The split between the two cohorts gives defenders another usable signal. The purpose-built brands register through Cloudflare within tight recent windows and use redacted WHOIS records. The aged core brand and the broader feeder tier instead reuse domains first registered years earlier through multiple budget registrars behind privacy proxies. By combining newly created domains with aged, dropped inventory, the operator avoids a newly-registered-domain heuristic across part of the estate. Domain age alone therefore cannot distinguish this traffic from legitimate mail.

The Affiliate Layer

The partner_id values vary by brand (1133 for placefortalk, 718 for amourtalks), but the parameter structure remains the same. A stable affiliate parameter schema combined with per-brand numeric identifiers indicates a shared affiliate-attribution stack beneath the brands and a paid traffic-acquisition funnel beneath the email channel. Identifying who buys traffic under each partner_id is a higher-order attribution lead.

Detection Observations

The traffic is most readily recognized at the ecosystem level rather than message by message. Individual sends are intentionally sparse notifications with one photo and one sentence, so each message can look like an ordinary product alert. The useful evidence sits in the structure around it.

• The operator footer is the most persistent behavioral pivot. The Punctipes corporate identity appears verbatim across sends, including the company name, Cyprus registration number, Limassol street address, and toll-free support line. It survives rotation of the apex and the entire CTA estate. A body-content match on the footer identifies new sites before they have any reputation signal.
• The auto-login CTA shape is the strongest infrastructure pivot. A t.<label>[.]com/?r=<base64>&did= redirect that resolves to a /dialogs/<ULID>?...login_token= destination is a narrow construction not reproduced by legitimate senders.
• The .com sending apex paired with a same-owner .help support apex is a high-signal registration tell.
• Clean authentication does not establish legitimacy here. The self-hosted brands pass SPF, DKIM, and DMARC on their own apexes, so an authentication-PASS result should carry no weight toward legitimacy for this family.

Indicators of Compromise

All indicators are defanged. Recipient data has been removed. The list below contains the confirmed operator estate and the single adjacent same-genre platform, with annotations where attribution differs.

Senders

Value	Role	Notes
message@placefortalk[.]com	Sender	Primary lure sender
notifications@placefortalk[.]com	Sender	Sibling lure sender
support@placefortalk[.]help	Support	Footer support mirror apex
message@amoures[.]com	Sender	Sister brand
notifications@amoures[.]com	Sender	Sister brand
support@amourtalks[.]com	Support	Sister brand
support@amourtalks[.]help	Support	Mirror support apex
message@amourwings[.]com	Sender	Sister brand
notifications@amourwings[.]com	Sender	Sister brand
notifications@mails.flirtynlocal[.]com	Sender	Adjacent genre platform (different operator)
info@mail.flirtynlocal[.]com	Sender	Adjacent genre platform (different operator)

Domains

Value	Role	Notes
placefortalk[.]com	Operator apex	Original site, now dormant; Punctipes footer
placefortalk[.]help	Support mirror apex	Operator-owned
amoures[.]com	Operator apex	Aged-cohort sister brand
amourtalks[.]com	Operator apex	Purpose-built sister brand
amoutalks[.]com	Operator apex	Typo-sibling of amourtalks
amourtalks[.]help	Support mirror apex	Operator-owned
amourwings[.]com	Operator apex	Purpose-built sister brand
flirtynlocal[.]com	Platform apex	Adjacent genre platform (different operator)

Hosts

Value	Role	Notes
t.placefortalk[.]com	Auto-login CTA host	base64 r= redirect
mail.placefortalk[.]com	Return-path / bounce host
img2.placefortalk[.]com	Image CDN	Persona thumbnails
images-cdn.placefortalk[.]com	Image CDN	Persona thumbnails
t.amoures[.]com	Auto-login CTA host	Same construction as placefortalk
t.amourtalks[.]com	Auto-login CTA host	Same construction
mails.flirtynlocal[.]com	Sending host	Adjacent genre platform (different operator)

Phone Numbers

Value	Role	Notes
+1 (833) 588-4911	Operator support line	Appears in the Punctipes footer

MITRE Fight Fraud Framework (F3) Mapping

This mapping follows the MITRE Center for Threat-Informed Defense Fight Fraud Framework (F3), the current fraud matrix at ctid.mitre.org/fraud. F3 maps cleanly to the infrastructure and resource-development side of this campaign and provides a serviceable initial-access anchor. It does not include a first-class technique for either the credit-messaging monetization model or the auto-login funnel, so those stages are recorded as coverage gaps rather than assigned an ill-fitting ID.

Tactic	Technique	ID
Resource Development	Acquire Infrastructure: Domains	T1583.001
Resource Development	Create Fake Materials: Fake Website	F1020.002
Resource Development	Establish Accounts (fabricated personas)	T1585
Initial Access	Phishing	T1660
Monetization	Credit / token-messaging paywall	No first-class F3 technique (coverage gap)

Conclusion

The Punctipes estate is designed to withstand exposure. Flagging one apex does not disrupt the funnel because the template, auto-login construction, sender pair, mirror support apex, and affiliate parameters move intact to the next domain. The operator also maintains a mix of fresh and aged inventory for that rotation. The one pivot that remains unchanged is the corporate footer printed on every send. Defenders tracking this family should follow the fingerprint rather than the domain and treat clean authentication on an unfamiliar dating-brand apex as neutral rather than reassuring.