This is a big and complicated question, but I'll try to explain the basics. There are really two questions here: how to get your server to receive mail for a domain name, and how to allow clients to send outgoing mail through it ("relaying").
Receiving mail: The mail server's own name is often different from the domain(s) it receives mail for, and doesn't necessarily have anything to do with them. For example, email@example.com might be handled by mail.example.com, or it could be handled by a gmail server under google.com.
There are two critical pieces here: in order for mail addressed to @example.com be sent to yourserver.example.net, you need an MX record in the DNS entry for example.com. Here's the relevant info for stackexchange.com:
$ dig -t mx stackexchange.com
;; ANSWER SECTION:
stackexchange.com. 300 IN MX 5 alt2.aspmx.l.google.com.
stackexchange.com. 300 IN MX 1 aspmx.l.google.com.
stackexchange.com. 300 IN MX 10 alt3.aspmx.l.google.com.
stackexchange.com. 300 IN MX 10 alt4.aspmx.l.google.com.
stackexchange.com. 300 IN MX 5 alt1.aspmx.l.google.com.
...so mail addressed to @stackexchange.com will be sent to any of those google.com servers (the number just before the server name is a priority, so aspmx.l.google.com will be tried first, then alt1 and alt2, then alt3 and alt4).
The other part of receiving mail is that your server must realize that it should accept messages addressed to those domains, and put them in mailboxes (rather than trying to forward them to another server). In postfix, this can be done by adding them to the
mydestination list in main.cf, or by setting them up as virtual domains. See here.
Relaying outgoing mail: The really critical thing here is to prevent spammers from using you as an "open relay" to sent their junk through. The simplest option here is: don't provide relay service. Depending on your situation, your clients may already have perfectly good ways to send outgoing email, in which case you can just skip the headache and risk. If you do need to allow relaying, you need some way to distinguish trustworthy clients from spammers. You can have clients authenticate and/or trust senders based on the IP address they're coming from. Client authentication is generally better (but please don't let them send passwords in plaintext!). Trusted IPs should be used only when necessary, because if a spammer can subvert a device on the trusted network (or even just bounce SMTP traffic off one), they can use you as an open relay.
There's lots more to it of course, but hopefully that'll give you the basics.
Oh, one more thing: while the email domain can be different from the server name, clients will use the actual server name in their send/receive configs.