eM Client does not recognize it is default email app in windows 10

eM Client does not recognize that it is the default email program as define in windows 10.  I have actived .NET 3.5 Framework, but still eM Client does still says it is not default email app in Menu>Settings>General?  How do I fix this?

Gary Curtin posted the solution a few weeks ago, but I cannot find it right now to link to it.
So I just paraphrase it without claiming the merit:
Go to windows reistry editor. Under HKEY_CURRENT_USER>SOFTWARE>CLIENTS>MAIL set the Standard to eM Client. Do the same under HKEY_LOCAL_MACHINE>SOFTWARE>CLIENTS>MAIL.

That was at https://forum.emclient.com/emclient/topics/unable-to-send-file-as-attachment-from-within-microsoft-o…

Thanks for the input.  I changed both registry entries to eM Client, but problem persists.  eM Client
still does not know that it is default?  Any other ideas?

It might be the case, that eM Client is the default without knowing it. Just test right-clicking on a file and choose “send to>email recipient”, or try to send a document from within Word, PDF-viewer, etc, or click on an email address. Does em Client open a new message? For me it works (V 7.2.334030.0, Win10 pro V1809).
I take for granted, that you set eM Client as standard in Win10>Settings>Apps>Standard Apps. You cannnot do that from inside eM Client. You should also (in Win10-settings>Apps>Standard Apps) go to the bottom of the screen and select “set standard per App” go to em Client and set all formats to eM Client. It might help to restart Windows after  changing these settings.
Terminology may be different. I only have the German OS and translate loosely.
If all that doesn’t work, I am at my wisdom’s end.

That sounds about right pefunk. I have noticed that in the eM Client settings, it sometimes says this application is not the default mail handler, but in fact it is. 

One thing that can also help is in the Windows App Settings, you can select another app as the default for email, then change it back to eM Client.

Looks like you both are right.  I tried doing a mailTo from Word and it brought up an eM Client window and it worked.  I also tried selecting another app to be default and then changed back to eM Client. eM Client still did not realize that it is default.  I have done multiple restarts, but again eM Client still refuses to recognize that it IS default.  So, it looks like it really is default, but does not recognize it.

I have the same problem - just rebuilt a machine to a new hard drive - totally vanilla install of Windows 10 Pro - added eMclient 7 latest build  from the web site and it refuses to believe it is the default eMail client.  AND … in spite of the updated install from the announcements the notifications still do not work. :-/

Just go to Start / Settings / Apps / Default Apps / “Set Defaults by Apps”  and click “EMClient / Manage”. Then set EMClient to default MAILTO as per below and reboot PC.

If that doesn’t work then i would either setup a “New Win 10 Profile” or failing that “Do a Clean install”. Ive just installed a brand new Win 10 pc (Build 1809) and worked fine as the default mailer.

My windows is 1803 - Clean install too - tried all the other bits no difference so I am downloading and updating to 1809 - let’s see how that goes.

No luck, 1809 did not rectify the problem. Still no notifications at all anywhere.

What version of EMClient do you have ?

Latest version should be for Windows 7.2.34711.0 Wednesday, February 13, 2019


Thanks for your reply - this is a clean Windows 10 install and a brand new install of eMclient hence my disappointment. I am using Windows 10 Pro which is at build 1803 and it says I am fully up to date ???  I don’t even get an envelope in the systray. My eMclient version 7.2.34711.0

Windows 10 does not simply let programs set themselves as a default app as a handler.  When using the Default Apps dialog, setting a default app results in adding a hash key to the registry entry.  This was to prevent malware from casually changing a handler to themself.    A program assigning itself as the default handler is not as simple as back in Windows 7 (I never used Windows 8 to look in its registry for the definition of default handlers).  

If you look in the registry at (using the .pdf filetype as an example for its handler association):


Notice there is a hash value saved there.  Windows 10 creates that hash to make sure the user made that choice, not some malware.  Yep, although under the FileExts subkey, there is a subkey named “mailto” at:


Since I’ve installed em Client, and since I’ve tried to use its option to make it the default, I cannot say if the UserChoice menu existed before (when I was using the Mail app that comes bundled in Windows 10) or not.  There is a subkey there named OpenWithProgids with a data value named of “URL:MailTo Protocol” which is also the name of the mailto class defined at:


The default data value for that key is “URL:MailTo Protocol”.  Microsoft is using its IE libs to decide what is the handler for a protocol.  This sucks.  I ran into this problem when I decided to select Google Chrome as the URL handler (instead of “Internet Browser” which, at the time, I read as “Internet Explorer”).  After that, shortcuts for .url links stopped working.  Google Chrome would load but show the page code instead of rendering it.  Took awhile to remember that I switched the default handler for URLs away from “Internet Browser” (which I found was some IE lib).  Once I switched it back, shortcut to .url worked again to load the web page (i.e., render it). 

You’ll notice the open/command subkey here says to run:

  “C:\Windows\system32\rundll32.exe” “C:\Windows\system32\url.dll”,
  MailToProtocolHandler %l

So, Microsoft is using its url.dll lib to decide what to load as the handler for the mailto protocol.  The actual default mail handler is not listed.  They are using the rundll32.exe program to call the MailToProtocolHandler method (aka function) inside the url.dll library.  Geez, can we get any more obtuse with many-layered dependent definitions.  

Could be url.dll’s MailToProtocolHandler method is using the FileExts registry keys to decide which are the defaults for the various protocols, and under FileExts/mailto there is no UserChoice subkey which Windows 10 doesn’t see the /user/ made the choice of what is the default handler.

which has a link to:

Note that when defining policies, and although they are all registry entries, some will associate a hash with them.  For example, if you define a Software Restriction Policy on whether a program can load or not using a Path rule pointing to the .exe, you have to use the GPO editor.  You cannot go into the registry to add it yourself or use a .reg file because you won’t be able to define the correct hash on the registry entry.  For the UserChoice key, users don’t have permissions to edit that key’s data value, not even admins.  Windows has to generate the hash value.  The handler that is assigned as the default is specified by the ProgID under the UserChoice key that cannot be directly edited.  The other progids in the other subkeys are not the default handler.

I suspect when em Client issues an API call to check if it is the default app for the mailto protocol that the OS returns a false – because there is no UserChoice subkey under the mailto protocol definition where its ProgID specifies MailClient.exe (em Client’s program).  I’ve gone into the Windows 10 Default Apps settings and elected em Client as the handler for E-mail.  Yet still no UserChoice subkey shows up under the mailto protocol definition.

  “Microsoft decided in Windows 8 (probably for security reasons) that users should be able
  to set default programs  only  via the built in GUI. I.e. by design, you are not supposed to be
  able to set default handlers in a script or programmatically.
  The Hash value is used to prove that the UserChoice ProgId value was set by the user, and not
  by any other  means. This works as long as Microsoft keeps the algorithm which generates the
  Hash, and the mechanism for verifying the ProgId using the Hash, a secret.”

I have not checked if the hash value remains constant between updates to Windows 10.  Microsoft has gotten very tricky about getting around the hacks to disable the Windows Update service (you disable it but scheduled events in Task Scheduler and other services will change the WU service from Disabled back to Manual).  They could get just as tricky with the UserChoice hashing algorithm to thwart malware (or hacker tools) from reverse engineering the old hashes but recomputing them using a different algorithm in an update.  That is, Microsoft could keep moving the hashes to new values using new algorithms that show up in new updates.  So tools to crack the hash (to set an app or malware as the default handler by modifying the UserChoice key’s data values, assuming they get past the permissions issue) might be short-lived: the hashes get validated under the old algorithm and then replaced with new hash values computed using a new algorithm.  Microsoft could keep changing the “secret”.

  In Pre-Win 8, apps could set the default handler for a file type/protocol by manipulating the
  registry, this means you could easily have a script or a group policy manipulating the
  registry. However In Win 8, the registry changes are verified by a hash (unique per user and
  app)  that detects tampering by apps. In the  absence of a valid hash, we ignore the default
  in the registry.

The SetFTA tool might solve the problem, but Microsoft could pull out the rug and move to something else.  I don’t know if the devs of em Client would bother getting their product working with the hashing of FileExts or if they’ll avoid that baskets of asps and have their customers just use the Default Apps wizard in Windows 10 to make sure em Client is selected as the E-mail handler.

Setting the default handler is not easy anymore.  Not even using the Default Apps wizard ensures a UserChoice subkey gets created.  If a program requests the OS to indicate if it is the default app, the OS probably wants to see a UserChoice subkey.

I recently installed Windows 10 on my new laptop, and after completing the Windows update to 17134.829 (next to last update) I installed eM Client.

Using the option to set eM Client as the default during install simply opens the Windows 10 default apps config. I selected eM Client from there and that is all that needs to be done.

In all respects, eM Client is now the default.

I think the complaint is em Client doesn’t see em Client is the default e-mail handler.  I don’t know what the code would be to query the OS for what is defined the default handler for a protocol, but it seems the OS reports to em Client that it is not the default mailto handler, and I’m guessing that is due to the lack of the UserChoice registry key for that protocol.

Even when you use the Default Apps wizard to set em Client as the default mailto handler, em Client still doesn’t see itself as the default handler.  There appears something broken between you using Default Apps that lets the OS know which handler to use and a program that wants to query what is the handler for a protocol; i.e., set and query seem to be disconnected.

Windows correctly sees it as default, so how does this affect use?

The original/starter post in this discussion was about em Client not recognizing it is the default handler for e-mail.

GeorgeC: “eM Client does not recognize that it is the default email program”
Me: “the complaint is em Client doesn’t see em Client is the default e-mail handler”

No one said em Client was not getting used as the default e-mail handler, only that em Client _ reports _ it is not the default e-mail handler.  What em Client reports is misleading, and when configuring em Client that is what users are likely to use to determine if em Client is the default handler or not.  The issue wasn’t about use, but about an erroneous status reported by em Client.  It’s like putting the same red lens over all 3 lights of a stoplight, so drivers won’t know if the stoplight is telling them to stop or to proceed.

I’m guessing em Client issues a Win32 API, a system call, using wmic, or some programming method  to request Windows to tell em Client what is the current default mailto handler (or get a list of all handlers and parses the returned string to see if em Client was listed and for which handler).  What is the method you use to query Windows to report who is the default handler for the mailto protocol?  Whatever it is, it isn’t working.  The car is usable, but the stoplight still shows red for every light.

LOL! The car is usable, and the light is red, but the car goes anyway. That would be more appropriate analogy as eM Client functions as the default regardless of what some buried indicator says in settings.

If you require technical details of how this works, or doesn’t work, it would be better to open a support ticket with eM Client. They do not regularly comment in this forum.