A while back I went down the route of messing with geo-location stuff, and to be honest it's a day to day management thing that's not really worth it. For me it was easier to block pretty much everything outside of UK ISPs. Then you have to consider search engines, security review sites (e.g. "Is this site safe?"), and any other site you might not want to block. I didn't care for indexing, so for me, that wasn't a problem. Here's an except from the .htaccess file.
<Limit POST PUT DELETE OPTIONS CONNECT TRACK DEBUG>
order deny,allowdeny from all
allow from [IP Addresses or IP ranges to allow]</Limit>
<Limit GET HEAD>
order allow,denyallow from all
deny from 0.0.0.0/7 126.96.36.199/12 3 188.8.131.52/6 184.108.40.206/5 220.127.116.11/6 18.104.22.168/7 22.214.171.124/5 126.96.36.199/5 41 188.8.131.52/7 184.108.40.206/7 220.127.116.11/12 18.104.22.168/11 22.214.171.124/13 47 126.96.36.199/7 188.8.131.52/7 55 184.108.40.206/6 220.127.116.11/7deny from 18.104.22.168/14 22.214.171.124/13 126.96.36.199/6 188.8.131.52/7 106 184.108.40.206/7 220.127.116.11/4
deny from 175 177 18.104.22.168/19 179 22.214.171.124/6 185 126.96.36.199/7 189 188.8.131.52/7deny from 184.108.40.206/7 220.127.116.11/6 211 18.104.22.168/7 22.214.171.124/6 126.96.36.199/3
In addition to this, I had to manage the smaller IP blocks within the ones not covered above (said list is 2-3 years old, so treat with caution). This was for a Wordpress website setup, and it seemed to work well enough. It served as a content site for adding to a forum's chatter, so people on one site would visit mine. I'd get the occasional "I can't access your site", as some site members were based abroad, or on holiday. It's not a great way to go, unless you want belt and braces.
The smaller IP blocks were managed via the site's iptables rules, and in addition to IP filtering, there were rules for allowing SSH from specific IPs (e.g. my home), and blocking a few common nasties, such as 'w00tw00t blackhats' and so on.
You can google for how to block specific ports via .htaccess, or you can re-direct instead to port 80, or whatever you want to do. Or you could do it at the IPtable level if that's what you want. Here's an IP table example (not tested it, but it will be something like this):
-A INPUT -s 188.8.131.52 -p tcp -m tcp --dport 25 -m comment --comment "Allow SMTP from 184.108.40.206" -j ACCEPT
Presumably that's assuming your webserver handles SMTP requests. If not, probably best to set it up at the .htaccess level.
-A INPUT -s 0.0.0.0/0 -p tcp -m tcp --dport 80 -m comment --comment "Allow HTTP from anywhere" -j ACCEPT
(the only thing changing is the IP CIDR (0.0.0.0/0) and the port (80), and obviously the comment)
Note the "ACCEPT" at the end of each. If creating tables to prevent access, you might use"DROP" or "REJECT". The first basically doesn't respond and black holes requests, while reject responds and acts as a closed port. Some argue that drop is safer, as it acts as if nothing is there to attack, while reject shows a response. Others argue that drop ports can be detected anyway.
Do your own research, and if you write an allow statement, write another to block everything else. And be sure to have one or two remote, trusted testers. You can use a few website testing sites to see if access is working or not. Pick a site, such as GT Metrix, throw your site into its query, and see if it gets a hit. It's an easy way to test access rules, assuming you know the site's server IP. Once you get the rule working, tweak the IPs/ports to suit.
It's probably very easy to whitelist your IP on SMTP via the .htaccess, but the syntax will have to be spot on, and I'm not in the know. In addition, as it's a remote site, you'll be at the mercy of 3rd party policies and practices, so some things might not be possible.