Solution 1:

In addition to @Matthew Wetmore's correct answer, the usual thing that happens, is that it registers all COM components in that dll.

Specifically it creates two keys (+subkeys) in the Windows registry.

E.g. consider a dll: dao360.dll, which has multiple COM objects inside it. For each the first key is something like:

HKLM\SOFTWARE\Classes\DAO.TableDef.36

for the DAO Table Defintion object, the name of the Key is the ProgID of the COM object that programmers would refer to in their code.

Under the key is usually a single key with a default value:

HKLM\SOFTWARE\Classes\DAO.TableDef.36\CLSID

in this case:

{00000103-0000-0010-8000-00AA006D2EA4}

this is the Class ID or CLSID for the COM object, it tells us where the second key is located:

HKLM\SOFTWARE\Classes\CLSID{00000103-0000-0010-8000-00AA006D2EA4}

This key with its subkeys and values has additional information about the COM object.

One value to notice is the default value under:

HKLM\SOFTWARE\Classes\Wow6432Node\CLSID{00000103-0000-0010-8000-00AA006D2EA4}\InprocServer32

it has the file path of the exe/dll that hosts the COM object, in our example:

%CommonProgramFiles%\Microsoft Shared\DAO\dao360.dll

This is the correct file path when regsvr32.exe was used to register this COM object. If you move the file manually, the COM object will no longer work because this registry value now references a missing file.

So before using regsvr32.exe on a DLL, move it to its final location and don't move the DLL after registering it.

Solution 2:

RegSvr32 calls an exported method DllRegisterServer in the DLL. What specifically happens next is up to the implementation. Often registry keys for COM are written based on the file location. The registration should not, generally, be considered an installer that does much beyond that.

Unless there is something specific to the app, it can be registered from anywhere, but you shouldn't move/remove it after that. SysInternal's SysMon can watch file and registry access when you call the registration if you really want to see the details - though nothing prevents the code from doing either nothing or really anything code can do like access the internet, write or remove other files, et cetera. Like any executable, only register code you trust.

There is also DllInstall that can be called with regsvr32 /i which is meant to be an installer according to the regsvr32 documentation:

Regsvr32
This command-line tool registers .dll files as command components in the registry.
Syntax
regsvr32 [/u] [/s] [/n] [/i[:cmdline]] dllname
Parameters
/u : Unregisters server.
/s : Specifies regsvr32 to run silently and to not display any message boxes.
/n : Specifies not to call DllRegisterServer. You must use this option with /i.
/i :cmdline : Calls DllInstall passing it an optional [cmdline]. When used with /u, it calls dll uninstall.
dllname : Specifies the name of the dll file that will be registered.
/? : Displays help at the command prompt.

There is also DllUnregisterServer, but from practical experience implementations of this are usually of lower quality than the registration.

One of the goals of the Windows Installer (MSI) was to decouple installation from code like this.