A server has one main address and usually several others. Which account uses which decides how mail is attributed, what a certificate can cover, and what happens to your neighbours when one site misbehaves.
Most of the time the defaults are right. The cases where they are not are worth recognising.
Shared and dedicated addresses
By default every account answers on the server's shared address. That works because modern clients tell the server which site they want during the connection.
A dedicated address assigns one to a single account. It is genuinely required in only a few situations now, and it is sold as though it were required generally.
Where it does matter: when an account needs its own sending reputation for mail, when a legacy client must reach the site over HTTPS without announcing the hostname, or when something external allows access by address.
Where it does not: for certificates. Free automatic certificates work perfectly on a shared address, and the old advice that HTTPS needs a dedicated IP has not been true for years. How to Install an SSL Certificate in cPanel walks through issuing one.
Assigning one
In WHM, addresses are added to the server first, then assigned to an account. Two separate steps, and the second is where people stop.
After assigning, check three things instead of assuming the change is complete.
The site actually answers on the new address. The certificate still covers the domain. And the DNS A record points at the new address instead of the old one, assigning an address in WHM does not update DNS, and a site assigned an address that nothing points at is reachable only by the old route. Understanding A Records and AAAA Records deals with the record.
Mail is why this usually comes up
Outbound mail leaves from an address, and that address carries the reputation.
On a shared address, one account's spam affects everyone's delivery. A dedicated address separates that, which cuts both ways, because a small sender on their own address has no established reputation and starts from nothing.
So a dedicated address is worth it for a real sender with volume, and often worse than the shared one for a site that sends a few messages a week. What to Do When Your IP or Domain Is Blocklisted goes into what happens when the shared one is listed.
If you do assign one for mail, ask for the reverse DNS record to match the hostname the mail server announces. Without that the change achieves little. Understanding PTR and Reverse DNS sets out requesting it.
The main shared address is special
It is what accounts use unless told otherwise, and it is what the server itself uses.
Changing it affects every account still on the default, which is most of them. It is not a routine change and it is not one to make without a maintenance window and a list of what will move. There is more on doing it deliberately in How to Plan and Run Server Maintenance Windows.
Removing an address properly
Before removing one, find out what is still using it.
Accounts assigned to it, DNS records pointing at it, certificates issued for it, and anything external that allows it. Another server's firewall rule, a payment gateway's allow list, a partner's SPF record.
That last category is the one that breaks weeks later, because nothing on your server knows about it. Write down where your addresses appear off the machine, and check the list before releasing one.
IPv6
If the server has IPv6, accounts may answer on it whether or not you intended.
Two consequences worth knowing. A firewall configured for IPv4 only leaves the same ports open over IPv6, which is a real and common gap. Configuring a Firewall on a Dedicated Server deals with checking both.
And mail over IPv6 needs its own reverse DNS record. Major providers check it, so a server with a correct IPv4 setup and no IPv6 reverse record has mail rejected only by the receivers that prefer IPv6. A confusing pattern until you know to look.
Do not sell one as an SEO product
Worth stating plainly for anyone reselling.
A dedicated address does not improve search rankings, and it has not for a long time. Selling it on that basis is a claim you cannot support and a customer who will eventually find out.
Sell it for what it does: separated mail reputation, and compatibility with a small number of things that need an address of their own.
Check it from outside after any change
dig example.com A +short curl -I https://example.com/
The first says what the world resolves; the second says what answers. A mismatch between them and what WHM shows is the whole diagnosis, and it is usually the DNS half that was forgotten.
Find out which address a site actually answers on
An account can hold several addresses and each domain answers on one of them, which is not always the one anybody expects.
dig example.com A +short curl -sI https://example.com/ | head -1 grep -E '^example.com' /etc/userdatadomains 2>/dev/null
Compare what the domain resolves to against what the account is configured with. A mismatch means the domain is pointing at an address the account no longer uses, which produces a site that works from one direction and not another.
This is the usual finding after an address is reassigned. The configuration is updated and the DNS record is not, or the reverse, and the two are maintained by different people.
Releasing an address has consequences elsewhere
An address returned to the provider is reassigned to somebody else, usually quickly.
dig -x 203.0.113.10 +short grep -rn '203.0.113.10' ~/public_html --include='*.php' 2>/dev/null | head
Anything still referencing it then points at a stranger's server: a DNS record nobody updated, an allow list at a payment provider, a monitoring check, a firewall rule at a client's office.
Search for the address before releasing it rather than after. The DNS record is the obvious one and the references held by other people are the ones that cause the problem, since you cannot search those and have to remember them.
Reputation attaches to the address
An address carries a sending history, and receiving that history is part of what you get with a new one.
An address previously used by somebody sending badly arrives with a poor reputation that has nothing to do with you, and the effect is mail that is delivered to spam from the first message.
dig -x 203.0.113.10 +short exim -bp 2>/dev/null | wc -l
Check a newly assigned address against the public reputation services before relying on it for mail, and ask for a different one if it arrives with a history. That request is normal and much easier than repairing a reputation you did not create.
