It could be any of three things: a genuine notice from someone who really does need your signature, an outright spoof built to look like HelloSign, or — the case that beats the usual checks — a real email sent from HelloSign's own servers on behalf of a stranger who simply opened a HelloSign account. Dropbox's own domain list verifies app.hellosign.com specifically, not the bare hellosign.com domain, and security researchers have documented attackers using genuine HelloSign accounts to pass SPF, DKIM, and DMARC while running an HR/payroll signing lure. The 2024 Dropbox Sign breach is part of why some of these lures land convincingly at all: it exposed customer and counterparty email addresses tied to real signature activity.
A signature-request email carrying the HelloSign or Dropbox Sign name can be one of three different things, and each calls for a different response. It can be completely genuine — someone you actually do business with really did send a document through Dropbox Sign for you to sign. It can be an outright spoof: a forged sender address or a look-alike domain dressed up to resemble HelloSign, the same kind of fake-login and fake-notification pattern this archive documents elsewhere as a recurring, years-long wave of Dropbox brand impersonation. And it can be the hardest case of the three: a real email, delivered from HelloSign's own production mail infrastructure, that passes every authentication check a person or a filter would normally rely on — because the person who sent it is a stranger who simply registered a HelloSign customer account and used the platform's legitimate signature-request workflow to reach you. That third case is the one ordinary advice like "check the sender" or "look for the padlock" can't catch, because every one of those checks comes back clean.
Dropbox publishes the exact domains it will ever send email from or host content on, specifically so people can check a suspicious message against it. Its official-domains help page states: "All email from employees, support staff, and some service-related email (such as email verification, password reset confirmations, and Dropbox research study invitations) are sent from docsend.com, dropbox.com, dropboxmail.com, em-s.dropbox.com, em.dropbox.com, txn.dropbox.com, or dropbox.zendesk.com." Its list of verified Dropbox domains names "app.hellosign.com" specifically — worth noting precisely because it is not the bare hellosign.com domain a search for "hellosign.com scam" might expect to see; the domain to actually check a signing link against is the app. subdomain. The same page's blanket rule is the one worth keeping in mind for any Dropbox-branded email: "Most of the things you do with Dropbox online happen on www.dropbox.com. This is the only domain where Dropbox will ever ask for private information like the email address and password for your Dropbox account. Be wary of any other domains that look like Dropbox that ask you for your Dropbox email or password."
The harder problem is that a HelloSign email can fail none of those domain checks — because it genuinely is from HelloSign's own infrastructure, just set in motion by someone with no legitimate reason to be contacting you. Security firm Ironscales documented a case in which a phishing campaign "abused the HelloSign (Dropbox Sign) e-signature platform by registering filesignportal.com nine days before the attack, creating a HelloSign customer account under that domain, and using the platform to send an HR payroll e-signature lure," where "SPF, DKIM, and DMARC all passed for mail.hellosign.com" and "[a]ll signing links resolved to legitimate app.hellosign.com." As Ironscales put it, an attacker who "registers a fresh domain and provisions a HelloSign customer account inherits that authentication posture immediately, without DNS aging, without IP reputation building, without waiting for their own domain to stop looking new" — the valid TLS, the known domain, and the familiar interface "validate only that HelloSign delivered the message, not that HR sent it." Email-security vendor Sublime Security ships a detection rule built for exactly this gap, describing its purpose as identifying "messages sent from HelloSign that notify recipients about a shared file and contain suspicious content either in the document or the sender's display name" — its logic explicitly starts from mail already confirmed to be "Legitimate Dropbox sending infrastructure." Cloudflare's 2026 Threat Report names this as a broader pattern too, warning of "stealth attacks via trusted internal tools like Google Calendar, Dropbox, and GitHub" from adversaries "weaponizing trusted cloud tooling to mask attacks" — in Cloudflare's telemetry, one tracked group "[u]sed Google Drive and Dropbox to host XenoRAT payloads," a different technique than a HelloSign signing lure but the same underlying exploit of a trusted platform's reputation.
Part of why a HelloSign-themed lure can land convincingly at all traces back to a real Dropbox Sign security incident. This archive's own entry on that breach records that a threat actor "had accessed a Dropbox Sign automated system configuration tool and used its elevated privileges to reach the customer database," exposing "account holders' emails, usernames, phone numbers, and hashed passwords, along with general account settings and authentication information such as API keys, OAuth tokens, and multi-factor authentication details." Dropbox Sign's own incident post confirms the same scope directly: a threat actor "had accessed data including Dropbox Sign customer information such as email addresses, user names, phone numbers and hashed passwords, in addition to general account settings and certain authentication information such as API keys, OAuth tokens, and multi-factor authentication." It adds a detail relevant to people who never even had an account: "For those who received or signed a document through Dropbox Sign, but never created an account, email addresses and names were also exposed." A breach that exposed real customer and counterparty email addresses tied to real signature activity is exactly the kind of dataset that makes a "you have a pending document to sign" email more believable — it can land in an inbox that has genuinely used Dropbox Sign or HelloSign before.
Dropbox's own guidance for a suspicious message is to report it, not to try to resolve it yourself: "Forward the suspicious email to [email protected] and we'll investigate," and more specifically, "If you received a suspicious email, forward the complete message to [email protected]." Its report-abuse help page describes a parallel, more general route for content — not just email — that breaks its rules: "If you find content on Dropbox that violates our Acceptable Use Policy, you can report it using the Report an issue form or by following the steps below." What Dropbox does not publish is any account of how often its e-signature platform specifically gets used this way, how new HelloSign customer accounts are screened before they can send signature requests, or what share of reported HelloSign abuse gets acted on — this archive found no equivalent transparency reporting for Dropbox Sign to match what Dropbox publishes about its verified domains generally. For the related question of whether a dropbox.com share link itself is safe to click, see this archive's answer at /questions/are-dropbox-links-safe.
Sources
- Dropbox Help — 'What official domains does Dropbox use?'
- Dropbox Help — 'How to protect yourself from phishing and viruses'
- Dropbox Help — 'Report abuse on Dropbox'
- Dropbox Sign — 'A recent security incident involving Dropbox Sign'
- Ironscales — 'HelloSign's Reputation, Attacker's Domain: How a 9-Day-Old HR Portal Hijacked a Trusted E-Signature Platform'
- detection.fyi (Sublime Security) — 'Service Abuse: HelloSign share with suspicious sender or document name'
- Cloudflare — 'Introducing the 2026 Cloudflare Threat Report'
- Dropbox Watchdog archive — the 2024 Dropbox Sign breach
This answer is informational, not legal or security advice. Dropbox Watchdog is independent and not affiliated with Dropbox, Inc.