Detailed DNS Guidance setting up an Exchange 2019 On-premise e-mail server as, this is my first Exchange Server deployment and is a learning experience

ok

1) You would never multi-home exchange - you're just creating pain for yourself there
2) Best practice is to utilise the same DNS that is configured within your domain.... i.e. your domain controllers will take care of local DNS and have forwarders configured to resolve public addresses... that way you get consistency across your entire environment
3) you would reverse publish your exchange server on ports 25 and 443 from your router and/or reverse publishing device (such as an F5)
4) external DNS will require a name for client access services (commonly webmail.domain.com), mail delivery (e.g. mail.domain.com) and a mail exchanger (MX) record - that would point to the A record mail.domain.com. This is vital, as it allows mail delivery, but also DNS reverse lookups to occur, which is one common anti-spam mechanism. You may also wish to setup SPF or DKIM records... but thats going a bit too deep for now i think.
5) I dont understand question 3.... you havent told us where your WAN IP is coming into.... exchange (bad idea), router? router with a reverse publishing device behind it? whats your external segment network topology ?

Hayes, thanks for taking the time to respond to my question.  It's much appreciated.
So Hayes, when you refer to "1) You would never multi-home exchange", I've read just about everywhere online that, joining a 2nd Win server to a DC as a member server then, installing Exchange on the member server is fairly common.  This is to avoid repeating what SBS was or used to be and therefore, separating Exchange from a DC by joining the Exchange server on a Windows server as a member server to the DC is better.  
BTW, I'm working with virtual servers in a 2019 Hyper-V environment so, there isn't a 2nd physical box.

With regards to your response 5), my Q3, the WAN IP is coming from an ISP's modem and into a Cisco router then, into the Exchange server via port forwarding from the Cisco.  Ports 25 and 443 are forwarded from the Cisco into the Exchange server.  The Exchange server will not be part of a chain, backup, cluster, etc... It would be a stand-alone mail server.

My goal is to learn more about the DNS settings required to have the Exchange working properly without outgoing e-mails being rejected or flagged as spam due to incorrect DNS settings..
1.  A record?
2. MX record?
3. Txt record?
4. *Published DNS reverse lookup has been taken care of with the ISP who provided the static IP.

This is the example Exchange member server IP network information:
Exchange Server Static WAN IP assigned to the Cisco router from the ISP's modem - 123.456.789.321
Exchange Server Static LAN IP:  10.0.0.5
Exchange Server (computer name): mailserver
Exchange Server e-mail domain:  mydomain.com

ok, cool., so your exchange is not multi-homed and you have the ports forwarded for your external router directly to exchange.

As far as SPAM, there are 3 related things that i believe your question is about

1) Reverse DNS lookup. This is where the receiving end of and email checks if the email has come from the sender that claims to have sent it.
e.g. compnay.com.au sends an email to CompanyX.co.uk..... CompanyX.co.uk looks up in DNS if the public IP that sent the message (your mail server) is actually associated by looking up the MX records for company.com.au..... if they match... passed - all good... if not, reverse DNS lookup failure - rejected as SPAM.
This method is somewhat commonly used - so getting your MX records correct for this is vital.
In your case, you would get your external DNS provider to
- Create an A record called mail.mydomain.com pointing to 123.456.789.321
- Create an MX record which points to the A record of mail.mydomain.com

it is worth noting that you need these two records for mail to function at all.... so if you are receiving email from the outside world... you must already have these

Sounds like you already have the ports forwarded.... so you are all good there.

you can read more about this method here - https://en.wikipedia.org/wiki/Anti-spam_techniques#PTR/reverse_DNS_checks


2) Sender Policy Framework (SPF) - https://en.wikipedia.org/wiki/Sender_Policy_Framework
SPF is very widely used... however, in many cases (at least currently) SPF is not required....
At this point i would strongly suggest you get up and going by configuring the above - and worry about this at a later date

3) DKIM/DMARC - https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
Similar to SPF - i would suggest you get the basics going before delving into this

4) you mention a TXT record.... no TXT record is required for basic mail functionality.

it sounds like you are relatively new to this - so i strongly suggest using https://mxtoolbox.com/ to verify your work... the tests they provide are awesome.... and give good feedback if there is an issue. In particular, use their MX lookup test and open relay test.
in the future, once you have this nailed and go down the SPF and DKIM path, they also have tests to verify your DNS records for them too.

Based on the tests I'm receiving from mxtoolbox.com, the results are looking positive.  However, I'd prefer some confirmation re: the DNS settings currently in place if you wouldn't mind...

This is the example Exchange member server IP network information:
Exchange Server Static WAN IP assigned to the Cisco router from the ISP's modem - 123.456.789.321
Exchange Server Static LAN IP:  10.0.0.5
Exchange Server (computer name): mailsrv
DC FQDN Exchange is a member of:  comp.mydomain.com
Exchange FQDN as a DC member = mailsrv.comp.mydomain.com

***E-mail will primarily come from examplename@mydomain.com (not examplename@mailsrv.comp.mydomain.com nor examplename@comp.mydomain.com) --Only @mydomain.com

Will the following DNS settings setup on the domain's registrar suffice?

1.  A record?
hostname = @  
target = 123.456.789.321
2. MX record?
mailsrv.comp.mydomain.com
3. Txt record?
?

Sorry mate --was just looking for the meat and missed it in the previous explanation.  Thank you.