Fake dating profiles: how the farm runs and where to stop it

A fake dating profile costs its operator one browser profile, a slice of residential-proxy bandwidth and a mailbox that receives. It costs you the real user it matches with; the same kit produces marketplace listings that exist only until a deposit clears. Photo verification, email confirmation and IP rules stand in the way, and the farm passes them by design: a face at the phone, an address that gets the mail, a home IP behind every profile. What it cannot change is that its profiles share a machine. This playbook follows one farm from setup to payout, then puts a device-linking check between profile creation and the moment it is shown.

How a dating profile farm is run

1. The machine. One laptop, one antidetect browser, one profile per account. Multilogin's Pro 50 plan is $19.17 a month billed annually ($29 monthly) for 50 profiles; GoLogin sells its Professional tier up to 100 (Multilogin pricing, GoLogin pricing, both checked 2026-08-29). Each profile is its own cookies, storage and fabricated device identity: fifty devices where there is one. Tool pages: Multilogin, GoLogin; the wider write-up is how antidetect browsers spoof the fingerprint.
2. The network. A residential proxy pool billed by the gigabyte: Oxylabs lists its Starter tier at $6/GB and Decodo lists $4/GB pay as you go (Oxylabs, Decodo, both checked 2026-08-29). To the app the exit is home broadband: network.residential is true when neither the cloud-server nor the proxy check fired. The residential-proxy pillar covers which signals survive a rented home IP; this post is the device half.
3. The identity. A photo set, a bio, an age, and a mailbox that receives: a burner domain (the community-maintained disposable-email-domains blocklist held 8,368 domains on 2026-08-29) or a relay. Apple's Hide My Email issues random @privaterelay.appleid.com addresses that forward to the real inbox (Apple Support, checked 2026-08-29).
4. The signup. Done by hand for the profiles that will earn, scripted for the ones that will not; the scripted ones trip device.automation. Where the app asks for a selfie, a real face is supplied.
5. The payout. Romance: the conversation moves to a messaging app and the money follows; the FBI's Internet Crime Complaint Center logged 17,910 Confidence/Romance complaints and $672,009,052 in reported losses for 2024 (IC3 2024 Internet Crime Report, checked 2026-08-29). Redirection: the profile pushes a link to a paid site or a wallet. Neither earns before the profile is shown and matched, which is why the check goes there.

The same farm, selling instead of dating

Swap the bio for a listing and nothing else changes. The FTC describes the rental version: a listing copied from a real one or invented at "surprisingly low rent", an owner who "will usually claim to be out of the country", and a deposit by wire, gift card or cryptocurrency (FTC, Rental Listing Scams, checked 2026-08-30). About half of those who reported a rental scam in the 12 months to June 2025 said it began with a fake Facebook ad (FTC press release, 22 December 2025, checked 2026-08-30). One deposit is the whole return, so the operator wants many listings live from many "sellers". Read the rest with listing published in place of profile shown.

Why photo verification and email confirmation miss it

Photo verification checks a face, not a count. Tinder's process: "A member takes 2 selfies mirroring the poses shown" (Tinder Safety Center, checked 2026-08-29). Bumble assigns one of "a hundred random photo poses" and has a person review the selfie (Bumble, checked 2026-08-29). Both ask whether the person in the photos holds the phone; neither asks how many verified profiles that face, or that device, now owns.

Email confirmation checks that a mailbox receives. A burner domain receives; a relay receives and belongs to a real Apple ID. Deduplicating on the address fails both ways: the farm has unlimited addresses, and a real user on a relay looks like the farm. We wrote up why burner-domain lists are an escalation signal, not a gate.

IP rules see a fresh home address on every profile. Per-IP limits and geo rules never fire against a pool priced by the gigabyte.

Phone verification proves a number received a text, and can bill you for the privilege; the SMS pumping playbook covers the invoice side.

None of these ask the two questions that matter: how many profiles came from this machine, and is it telling the truth about itself. Our multi-accounting pillar covers device linking as the general counter; here it is applied to the one action a dating app or a marketplace sells, being shown. The other fraud playbooks follow the same shape.

The tells

Every row is a field from the evaluate response. Device rows need fingerprintEventId; device.linked_accounts also needs your accountId — on a dating app, the profile id.

The first two rows need each other. Early in that run each spoofed profile had its own stable visitor id, so linking alone did not join them; after some thirty sightings the matcher stopped splitting them, but the flag had caught every full profile spoof from the first request. A plain browser is caught by the count, an antidetect browser by the flag; together, neither has to be perfect.

We chose the linked-accounts threshold; nothing measured it. Two profiles on one device is a couple sharing a tablet, a reinstall, or a profile after a breakup. Three is not a household. Our post on separating a shared family login from a resold one draws the same line.

Where the check goes

Signup creates a row; nothing is at stake until it enters discovery or the listing goes live. The evaluation goes there: after the profile exists, before it is shown, with accountId set to the profile id so the count arrives in the same response. A signup-form check runs before a profile id exists to link.

The handler below is the decision point; SENTINEL_KEY keeps the env-var name from the product's first release — the product is Maskbreak.

// After the profile row exists, before it enters discovery.
// SENTINEL_KEY is your sk_test_ key in CI and staging.
app.post('/profiles/:id/publish', async (req, res) => {
  const profile = await db.profiles.get(req.params.id, req.user.id);

  const r = await fetch('https://maskbreak.com/v1/evaluate', {
    method: 'POST',
    headers: {
      'Authorization': 'Bearer ' + process.env.SENTINEL_KEY,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      token: req.body.token,                            // network layer
      fingerprintEventId: req.body.fingerprintEventId,  // device layer
      accountId: profile.id,                            // unlocks linked_accounts
      email: req.user.email,
      tz: req.body.tz                                   // Intl.DateTimeFormat().resolvedOptions().timeZone
    })
  });
  const v = await r.json();
  const linked = (v.device && v.device.linked_accounts) || 0;

  await db.profiles.setVerdict(profile.id, {
    decision: v.decision, reasons: v.reasons,
    linked, visitorHash: v.device ? hash(v.device.visitor_id) : null
  });

  if (v.decision === 'block' || linked >= 3) {
    // Same body as the review branch on purpose.
    return res.json({ status: 'pending' });
  }
  if (v.decision === 'review' || linked === 2) {
    await queue.add('profile-review', { id: profile.id, reasons: v.reasons });
    return res.json({ status: 'pending' });
  }
  await db.profiles.setVisible(profile.id, true);
  return res.json({ status: 'live' });
});

Two things are deliberate. Block and review return the same body, so the operator learns nothing about which rule fired. And the verdict is written before any routing, because a profile reported in six weeks is worth nothing unless you can pull its siblings by device; the aged-account playbook makes the same point.

The escalation paths run from a terminal with the public sandbox key.

curl -s -X POST https://maskbreak.com/v1/evaluate \
  -H "Authorization: Bearer sk_test_sandbox" \
  -H "Content-Type: application/json" \
  -d '{"token":"test_clean","email":"someone@mailinator.com"}'

That is the production response on 2026-08-30, minus status, isSuspicious, ip, the legacy details mirror and evaluated_in_ms. A clean home connection plus a burner mailbox lands in review. Send test_proxy instead: decision: block, network.proxy and network.datacenter true, datacenter_asn among the reasons. Device fields need a real fingerprintEventId: use your own sk_test_ key on a staging page with the SDK.

Response ladder

Three rungs. Apps skip the middle one: a held profile is invisible to everyone but its owner, which costs a real user one verification prompt and a farm the only thing it came for.

A VPN on its own never moves a profile off the allow rung. Travelers and expatriates sign up on VPNs; the API's timezone check stays quiet on a VPN exit for that reason (timezone.checked: false). The guide on routing on the decision and sorting on the score explains the split.

When a user reports a profile, pull every profile sharing its device hash and review them together; otherwise the farm is removed one profile at a time. Linking is per API key and hash-only on both sides; our note on where device fingerprinting stands under GDPR and ePrivacy covers the privacy-policy disclosure you still owe.

What it costs you

The platforms that publish figures publish moderation volume, not losses. Match Group says "80% of harmful accounts are proactively removed before a user ever reports them" (Match Group Trust and Safety, checked 2026-08-29). One operator's numbers, but the bill has the same shape at any size: a review queue, and profiles a real user meets before a reviewer does.

The check is one call per publish action on the free tier's 1,000 requests an hour (rate limits). It buys the fact the farm cannot change: profiles 2 through 50 share the hardware, and the hardware, or the tool hiding it, is visible before the profile is shown.

Checklist

• Evaluate at the publish action (profile shown, listing live), not only at the signup form.
• Send fingerprintEventId, accountId (the profile id), email and tz; no device fields without the first, no linked_accounts without the second.
• Route on decision. Block on block; never on network.vpn alone.
• Your own rule: linked_accounts of 2 is a step-up, 3 or more a hold. Keep a 24-hour counter per device.visitor_id hash; the API counts accounts, you count attempts.
• No rule on tampering_score. Use device.antidetect.
• Return the same "pending" body for review and block; store decision, reasons and the visitor-id hash, and pull the siblings on a report.
• Prove the paths in CI with sk_test_sandbox: test_clean plus a burner address returns review; test_proxy returns block.
• For marketplaces, add the listing price against the category median as your own evidence row; the farm's listings are cheap by design.

The product page for stopping fake signups covers the call and the free tier; this post is the reasoning for where it goes.