Telegram Aggressive Anti-Spam: setup and false-positive checks
Check Telegram's native anti-spam setting, identify who deleted a message and report a false positive without confusing group filters with account restrictions.
A legitimate support question disappears a few seconds after posting. There is a moderation bot in the group, so someone asks its administrator to add the author to an allowlist. Before changing that setting, check who actually removed the message. Telegram's own Aggressive Anti-Spam can act independently of a third-party bot.
Three questions need separate answers: what deleted this message, whether the member can still post in this group, and whether their account has a wider Telegram restriction. Solving one does not establish the other two. Start with the specific deletion rather than disabling every layer of protection.
What Telegram's native setting does
Telegram's native anti-spam reference describes automatic spam deletion in eligible supergroups. Actions use an official Telegram Anti-Spam actor. Administrators do not need to add that account as an ordinary group bot for the native system to work.
This explains why changing another bot's allowlist may leave the symptom unchanged: the setting you edited may belong to a different system. A familiar name in the members list is not enough to identify the actor. Use the actual deletion event.
Availability also depends on the group. The current toggle reference uses a minimum membership value supplied through Telegram's server configuration. Check availability in the intended supergroup; an old article's numeric threshold is not a reliable universal rule for today's client.
Enable or disable it with a monitored change
Use a current official Telegram client and an account with the necessary administrator access. The precise location and wording of the control can vary by client, so the following is a verification sequence rather than a claim that every app has identical menus.
- Open the intended group's information and management settings. Confirm the group name before editing anything, especially if a channel has a separate discussion group.
- Locate the native Aggressive Anti-Spam control, where available. Write down its current state. A similarly named switch in a bot's Mini App belongs to that bot.
- Agree who will review the result and handle complaints. Choose a period when a moderator can respond, rather than enabling it just before leaving the group unattended.
- Change the native switch once, then reopen the settings to check its state. Leave third-party filtering unchanged during this comparison.
- Ask a consenting ordinary member to send a few harmless, representative messages. Include the normal formats your community uses, such as a short question and an allowed documentation link.
- Check the messages and native log. Continue reviewing real reports before deciding whether to keep the change.
A harmless sample can reveal a problem, but passing it does not measure the filter's overall accuracy. Do not post real scams, mass-send repeated messages or deliberately provoke an account restriction to test protection. If a separate test group is ineligible for the native feature, do not inflate its membership just to reveal a switch.
To turn the feature off, use the same native control and verify the saved state. Record why the team chose to disable it and who will cover incoming spam afterward. Treat this as a configuration decision, not a way to restore a missing original or clear an unrelated restriction.
Find the deletion and report a mistake
Open Recent Actions from the group's administrator area promptly. Telegram's group guide describes an admin-only record for the preceding 48 hours. Search the relevant time and message, then inspect the actor. If filters hide the event, clear them before concluding it is absent. The fuller moderation-log investigation guide covers comparing records and handling missing evidence.
For a deletion attributed to Telegram's native filter, inspect the event's available actions. Telegram's false-positive reporting operation refers to the mistakenly deleted message recorded in the native log. It is not a generic appeal against any bot action.
The TDLib reference further limits reporting to an administrator and an eligible deletion event. If your client offers the false-positive action for that event, report the legitimate deletion there. If it does not, verify your role, the actor and your client version; do not choose an unrelated event just to make a report possible.
A report records feedback. These references do not promise restoration, a response deadline or removal of every restriction on the author. Record the report time, then check the member's current situation separately.
A concrete example: an allowed resource link disappears
Imagine a community where links to project documentation are allowed. At 10:15 UTC, an ordinary member posts a short answer with one such link. The message disappears, but a third-party bot sends no explanation.
The moderator finds the matching native deletion and confirms that Telegram Anti-Spam performed it. They read enough context to establish why the answer was legitimate and use the available false-positive report. They leave the unrelated bot's allowlist alone.
Next, they ask whether the member can send an ordinary reply now. If the answer is yes, there is no reason to lift a group restriction that was never established. If the answer is no, they inspect current permissions and the exact error before choosing a recovery step. Where the content is still needed, they can agree with its author how to share it again. A new approved post is not restoration of the original message.
Had the deletion event named a different bot, the moderator would follow that bot's relevant rule and record instead. If no matching event is available, the cause remains unconfirmed. Silence from one bot does not identify another actor.
Coordinate it with Defendy
Keep two separate notes: the native Telegram switch and the group's Defendy configuration. Defendy's text anti-spam guide explains its own filter and consequences. Those settings do not establish an override of Telegram's native decisions.
For a suspected Defendy event, check the configured moderation-log destination, including the relevant event category and any topic routing. Delivery depends on logging being enabled and a valid destination. An empty log chat is therefore insufficient evidence that Defendy took no action.
Change the setting supported by the evidence, then check the result before changing another. This makes a second incident easier to understand. If both systems are loosened at once, you lose the ability to tell which change mattered and may remove protection unnecessarily.
When the symptom points somewhere else
- The switch is missing. Check the account, native administrator role, group type and client version. Ask the owner to verify availability. Do not grant broad rights or add an unfamiliar bot merely to make a menu appear.
- The author cannot post. Inspect current group permissions and restrictions. Use the access-recovery guide if a group moderation action is involved.
- The problem also occurs outside this group. Telegram's Spam FAQ describes account-level restrictions and its official appeal route. A group's native switch is not a substitute for that process.
- Several older messages disappeared together. Check whether group auto-delete or a deliberate cleanup could explain the timing before assigning an anti-spam cause.
Keep a small, useful incident record
Save the group, time with timezone, affected message, observed actor, client version and outcome in a private moderator workspace. Note which setting changed, its previous value and who will check the result. Include only the relevant excerpt or redacted screenshot; a complaint does not require copying the member's entire conversation.
A good closing note is concrete: “Native deletion identified; feedback sent; member can post; native setting unchanged.” If a step was not verified, say so. That gives the next moderator a reliable starting point without promising that one report permanently prevents future false positives.
Sources and scope
Reviewed on 6 October 2026 against the linked Telegram documentation and Defendy's anti-spam settings and log-routing implementation. No live group or current client interface was tested. The procedure is an operational recommendation, not an accuracy claim or a guaranteed appeal outcome.
