This question is a close duplicate of What to do with work not on the board?. In my answer to that question, I articulate CodeGnome's Law of Transparency℠: "No invisible work, ever!" The Law of Transparency is just as applicable to your current situation because it argues against creating untracked work in the first place, precisely because that is part of what's generating the pain the Scrum Team is currently experiencing.
The short answer here is that "work is work," and treating certain types of work as second-class citizens makes them harder to track. The fix is for the Scrum Team to make all work visible through the defined Scrum Artifacts (primarily the Product and Sprint backlogs), and through other team-defined processes such as Kanban boards or other information radiators that provide information about available team capacity, iteration objectives, and the Definition of Done for each Sprint.
"Invisible Work" is a Scrum Anti-Pattern
The 2020 Scrum Guide has a section on Scrum Theory that explains the need for transparency, and describes how various Scrum Artifacts can help provide it. Work is work. By deliberately excluding certain classes of work such as:
- release activities
- support work
or any other activities that consume team capacity, you're creating hidden work that can't easily be tracked. That's the problem you're facing, and that's why you have drag on your velocity that can't be properly accounted for.
When Tooling is Part of the Problem
If you're doing this for tooling reasons, there's a related question about Why does Pivotal Tracker discourage estimating points for bugs and chores?. My answer there explains why feature-only velocity is an anti-pattern, and why story spikes, chores, support, and other work all belong on the appropriate backlogs.
When Central Coherence is Part of the Problem
You may also be doing this because your Sprint Backlog lacks the central coherence of a Sprint Goal to ensure that unrelated work doesn't suck up team capacity. If the team if missing its Sprint Goals because of work unrelated to the Product Backlog items selected by the Scrum Team and accepted by the Developers defined during Sprint Planning, that's often caused by untracked work or a lack of a well-defined Sprint Goal that can be estimated with reasonable confidence.
Increasing Transparency is Essential
When my original answer was written, the 2017 edition of the Scrum Guide said:
The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.
At the time of this answer, the 2020 edition now says:
Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.
Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured[.]
In either case, it's incumbent upon the Scrum Master to work with the Scrum Team and the organization to help the team find better ways to make all their work visible, estimable, and trackable. While the Scrum framework has plenty of built-in features to do this when properly leveraged, it really doesn't matter how you do it so long as all work is sufficiently visible to support the process the team wants to build, rather than leaving the root cause unaddressed within the framework's continuous process improvement cycles.