What an incoming request actually is
When someone who is not in your contacts messages you on Signal, the message arrives as a request rather than an ordinary conversation. You are given three options: Block, Delete and Accept. Nothing about the request itself tells you who the person really is, so the useful work happens before you choose.
Signal message requests offer Block, Delete and Accept; accepting allows the sender to see the Signal profile, message or call, and receive read receipts when enabled on both devices. Source
That single sentence carries most of the decision: accepting is the step that opens the door in both directions. Before you tap it, treat the sender’s name and photo as display information, not as identification.
Signal profile names are required while photos and last names are optional; a nickname can be used, so a displayed name or photo does not by itself establish a sender’s identity. Source
A checklist to run before you respond
Work through these in order. Stop at any point where you cannot answer a question, and treat that gap as a reason to wait rather than to accept.
| Check | What to look for | Why it matters |
|---|---|---|
| Sender’s claimed name | Does it match anyone you actually know, in a way you can confirm outside Signal? | A profile name is required but can be a nickname; it is not verified identity |
| Profile photo | Is the photo consistent with other things you know about this person? | Photos are optional, and a matching photo does not prove identity |
| Message content | Does it ask for money, codes, files, or a move to another app? | These are common patterns in unsolicited contact and are a reason to slow down |
| Context | Were you expecting contact from this person or this number? | Unexpected contact deserves more caution than a message you invited |
| Your own exposure | What is on your Signal profile right now? | Accepting lets the sender see your profile |
A useful rule: if you cannot confirm the person through a channel you already trust, you are not ready to accept. Nothing in the request requires an immediate answer.
Accept, delete and block: what each one does
The three buttons are not interchangeable, and the differences matter for both one-to-one and group situations.
| Choice | Effect on the request | What the sender can see or do | When it fits |
|---|---|---|---|
| Accept | Opens the conversation | The sender can see your Signal profile, message or call you, and receive read receipts when read receipts are enabled on both devices | You can identify the sender, or you deliberately want the conversation |
| Delete | Removes the request from your list | The sender is not accepted into a conversation; you have not opened the door | You do not want to engage but do not want to block |
| Block | Refuses the sender | The sender is blocked from contacting you through that route | The message is unwanted, suspicious, or from someone you do not want to hear from |
For individuals
- Accept is the only option that reveals your profile and enables two-way contact, including read receipts when both devices have them on. If you are unsure, this is the option to postpone.
- Delete clears the request without granting that access. It is the middle path when you simply do not want to deal with the message now.
- Block is the clearest signal that you do not want further contact. Use it when the content or the sender is the problem, not just the timing.
For groups
Group invitations and group-related requests raise the same underlying question: do you want this sender to have a route to you? The three options still describe your relationship with the sender rather than with the group’s topic. If you are unsure about a group, decide about the sender first; you can revisit the group question separately.
Common failure paths
- Accepting to “see what they want.” Accepting is what lets the sender see your profile and reach you. If curiosity is the only reason, delete instead and decide later.
- Treating a familiar name or photo as proof. Because profile names can be nicknames and photos are optional, a familiar-looking profile is a lead, not confirmation.
- Assuming delete is the same as block. They are different choices with different consequences for future contact; pick the one that matches what you actually want.
- Answering a request for codes or money to “check” the sender. Verification should happen through a channel you already trust, not inside the conversation you are trying to evaluate.
What this task is not
Reviewing a message request is separate from changing your Signal username or phone number. Those are profile and account settings tasks with their own steps, and nothing in this checklist changes them. Likewise, a profile name is not a verified identity, and no setting on this screen turns it into one.
If you later want to check whether a username you already know appears on public sites, a lookup tool such as TraceSeek can search 3,000+ platforms and return public matches in roughly 20-30 seconds, with a free first scan and no registration or login required. Keep its limits in view: it works from public usernames only, it cannot change your Signal settings, it cannot verify who a person really is, and it is not a way to access private accounts or to guarantee that anything is erased. A public match is a lead, not proof of ownership.
A short next step
If a request is waiting, read it once against the checklist, decide whether you can confirm the sender through a trusted channel, and then choose the option that matches your answer: accept if you can and want to, delete if you are unsure, block if the contact is unwanted. If you have already accepted and regret it, you can still block the sender afterward; the earlier accept does not lock you in.