Dedicated Server Networking, IPs, and rDNS

Each dedicated service includes at least one usable IPv4 address shown in the Nexelya panel. Configure netplan, NetworkManager, or /etc/network/interfaces with the provided gateway and netmask—incorrect gateway is the most common cause of no outbound internet after OS install.

Test with ping 1.1.1.1 and dig example.com @1.1.1.1 to separate L3 from DNS issues.

Additional IPs may be available for SSL termination, legacy applications, or multi-tenant hosting. Request allocations through support or self-service where enabled. Configure secondary addresses as /32 or routed subnets per the assignment sheet—provider conventions vary.

Avoid ARP flux: only announce IPs assigned to your machine on the connected interface.

Mail deliverability depends on forward and reverse DNS alignment. Set PTR records to match the HELO/EHLO hostname used by your MTA. Nexelya support may be required for PTR updates depending on IP block policies.

Forward DNS A/AAAA records should resolve back to the same IP for consistency.

• Use meaningful hostnames: mail.example.com, not generic defaults.
• Wait for DNS TTL propagation before mail tests.
• Include SPF, DKIM, and DMARC for domains sending mail.

If IPv6 is allocated, configure slaac or static addresses per documentation and verify firewall rules for both families. Many application stacks still default to IPv4-only—explicitly test IPv6 listeners if you enable them.

Nexelya exposes bandwidth visibility for capacity planning. Sudden spikes may indicate compromise, backup misconfiguration, or legitimate traffic growth. Rate-limit internal backup traffic during peak hours if commit billing applies to your plan.

Additional IPs may require justification for ARIN/RIPE policies when providers enforce utilization audits.

BGP sessions for your own ASN are a different product tier—contact sales via the quote page for routing discussions.

SMTP port 25 is often restricted; use transactional email APIs for applications.