The decision you are actually making
A message request and an existing chat are two different situations, and X documents them with different controls. If you treat them as one inbox, you can end up restricting new senders while an old conversation keeps delivering messages, or deleting a thread thinking you have recalled it.
The table below is a task checklist, not a description of a specific menu. Labels differ by app, platform and version, so find the control that matches the row, not the wording.
| Your situation | What you want | Control to look for | What it does not do |
|---|---|---|---|
| Someone new has sent a request | Stop seeing requests from people you don’t know | The setting that limits messages from anyone | It does not stop messages from an account with an already established conversation |
| Someone new has sent a request | Decide whether to let this person in | Accept or delete the request | Deleting a request is not the same as deleting a DM or conversation |
| An existing conversation keeps arriving | Stop that sender | Block or report, as a separate action | Restricting messages from anyone is not a block |
| An existing conversation is unwanted | Remove it from your view | Delete the conversation | It removes the thread only from the account doing the deletion, not from the other person’s |
| You sent something you regret | Take it back | Nothing in these controls | Deleting is not recall; the other side keeps their copy |
| You want to know who someone is | Confirm identity | Nothing in these controls | A block is not identity verification |
Step 1: Separate requests from established chats
Before changing anything, look at where the message actually sits. A request is an approach from someone you have not been in a conversation with; an established chat is one that already exists. The two are governed by different controls, so the first step is classification, not a settings change.
- If the message is a request, your choices are about accepting or deleting the request.
- If the message is in an existing conversation, your choices are about the conversation itself, or about blocking or reporting the sender.
- If you are unsure, do nothing irreversible until you have identified which case you are in.
X distinguishes accepting or deleting a request from deleting a Direct Message or conversation, which removes it only from the account performing the deletion. Source
This is the most common source of confusion: people delete a request expecting the thread to vanish everywhere, or delete a conversation expecting the other person to lose it. Neither is what the control does.
Step 2: Decide whether to restrict new senders
Limiting messages from anyone is a broad setting. It is useful when the problem is unsolicited approaches from strangers, and it is the wrong tool when the problem is one specific person you already talk to.
X says disabling messages from anyone does not stop messages from an account with an already established conversation; blocking or reporting is a separate action. Source
That sentence is the key limit. If an established conversation already exists, the broad restriction does not close it. To stop that sender, you need the separate action of blocking or reporting. Blocking is a delivery control, not proof of who the person is, and it does not verify identity in either direction.
Step 3: Handle the request itself
When a request arrives, decide on the request, not on the person’s profile. Accepting lets the conversation exist; deleting the request removes it from your pending list. Neither action tells you whether the sender is trustworthy, and neither is a background check.
A practical checklist before accepting:
- Does the request contain a specific, checkable reason for contact?
- Is it asking you to move to another channel, send money, or share a code?
- Does the account’s public presence match what the message claims?
- If you are unsure, leave the request unaccepted rather than replying to test it.
Declining to accept is a legitimate outcome. You do not owe a stranger a conversation.
Step 4: Understand what deletion means
Deleting a Direct Message or conversation removes it only from the account performing the deletion. The other participant keeps their copy. This is why deletion is not recall: if you sent something you regret, deleting your side does not take it back from the recipient.
The same distinction applies to requests. Deleting a request is an inbox action, not an erasure of anything the sender holds. Treat deletion as tidying your own view, not as undoing a message.
Step 5: Blocking, reporting and what they do not prove
Blocking and reporting are separate actions from message restrictions. They are the right response to a specific sender, and they are not a substitute for the broad setting when the problem is unsolicited volume.
Two limits are worth stating plainly:
- A block is not identity verification. It tells the platform to stop the interaction; it does not confirm who the other account belongs to.
- Reporting is a request for review, not a guarantee of an outcome you can see.
Where a username lookup fits, and where it does not
If a message comes from a public username you want to understand better, a username lookup can show where that handle appears publicly. TraceSeek, the app covered by TruthsSeek, checks a known public username across 3,000+ platforms, with a free first scan that takes 20–30 seconds according to the product. It does not require registration or login for that first scan.
What it cannot do matters more here:
- It cannot operate your X account settings, accept requests, block, report or delete anything.
- It cannot access private accounts or private posts.
- It cannot verify a real identity. A public match is a lead, not proof that the person messaging you owns that handle.
- It cannot guarantee erasure of anything.
A lookup is useful for context before you accept a request from a public handle. It is not a substitute for the platform controls above, and a match on several platforms should not be read as confirmation that the sender is who they claim to be.
Common failure paths
| What people do | Why it fails | Better move |
|---|---|---|
| Turn on the broad message restriction and expect an existing chat to stop | The restriction does not stop messages from an account with an already established conversation | Block or report that sender separately |
| Delete a conversation expecting the other person to lose it | Deletion removes it only from the account doing the deletion | Treat it as tidying your view; assume the other side keeps their copy |
| Delete a request and assume the sender can no longer reach out | Deleting a request is not the same as deleting a DM or conversation | Decide on the request, then use block if you want no further contact |
| Accept a request to “check” the sender | Accepting opens the conversation; it does not verify anyone | Check public information first, and leave the request unaccepted if unsure |
| Assume a block proves who someone is | A block is a delivery control, not identity verification | Keep identity claims separate from platform actions |
A short working order
- Classify: request or established chat.
- For requests, decide accept or delete; do not treat either as verification.
- For established chats, use block or report rather than the broad restriction.
- Remember deletion is one-sided and is not recall.
- If a public username is involved and you want context, look it up — then return to the platform controls for any action.
The labels on these controls change between apps and versions, so the durable skill is knowing which situation you are in and what each action can and cannot do.