First identify the server that really sends the message
Identify the public IP that actually sends mail, then check its reverse PTR and the PTR hostname's forward address.
Check PTR only for the IP that actually connects to the recipient; a relay may send instead of the VPS. Use a rejection or authorised message header to identify that address and route. The website A, inbound MX and panel IP are not substitutes, and matching reverse DNS alone is no delivery fix.
If Novasean hosts your website but another service sends its mail, that service's operator manages the sending route or can identify its address operator. A DirectAdmin mailbox or forwarding rule may also send through a shared relay; do not request a PTR change on a customer VPS until the actual sender is established. Keep recipient addresses and message contents out of public diagnostic tools.
Understand which DNS zone contains the PTR record
Forward DNS maps a hostname to an address with A or AAAA records. Reverse DNS maps an IP address to a hostname with a PTR record in the address's reverse namespace: in-addr.arpa for IPv4 or ip6.arpa for IPv6. The IP address holder or its delegated reverse-DNS operator normally controls that zone. Adding a PTR-looking record to your ordinary domain zone does not change the reverse answer for an IP you do not control.
Choose a stable mail hostname such as mail.example.com only after the sending operator confirms it is appropriate. The hostname's forward A or AAAA answer should include the corresponding sending address. Gmail's published sender guidelines require valid forward and reverse DNS and say the sending IP must match the address returned for the PTR hostname. This check does not replace SPF, DKIM or DMARC and does not guarantee inbox delivery.
Compare PTR with forward A or AAAA
For an authorised public IPv4 address, run dig -x 192.0.2.25 +short after replacing the reserved documentation address with the actual sender IP. Record the returned hostname. If the short output is empty, repeat the same lookup without +short and record the DNS status and responding server before calling the PTR missing: a timeout or SERVFAIL is a lookup problem, not proof that no record exists. Then run dig A mail.example.com +short after replacing the reserved example name with the PTR result. If that answer is empty, make the same full-response check for the forward query. If the mail leaves over IPv6, repeat the reverse lookup for that IPv6 sending address and query the returned hostname's AAAA records. Test the two address families separately; a working IPv4 PTR says nothing about IPv6.
If the sending IP is 192.0.2.25, an illustrative matching result is PTR mail.example.com and an A answer containing 192.0.2.25; replace both documentation values for a real check.
Compare the forward result with the same sending IP, not merely with a different address belonging to the same provider. A hostname may legitimately have several address records, so check whether the relevant sending IP is present rather than assuming it must be the only answer. Record the query time and resolver used. If a change was recent, query the relevant authoritative servers as well as a recursive resolver and allow for the published TTL before concluding that caches disagree.
Ask the owner of each side to correct a mismatch
If the PTR is missing or names the wrong host, ask the operator responsible for the sending IP to set or correct reverse DNS. Do not assume that Virtualizor, DirectAdmin or a DNS panel exposes this permission. If the PTR hostname does not point forward to the sending IP, the authorised owner of that hostname's forward DNS must correct its A or AAAA record. Plan the forward record first, then request the reverse change through the address provider's supported route. Save the old values and agree how to reverse a failed change.
For a Novasean service, send support the service identifier, public sending IP, intended hostname, exact reverse and forward answers, query time and the relevant rejection code or header excerpt. Ask whether Novasean or an upstream address provider controls PTR for that specific address. Do not send passwords, private keys or full unrelated message contents. The provider may have a controlled request process or may not offer customer-editable PTR; never infer a self-service feature from another host's instructions.
Verify the DNS correction and the original mail failure
After the responsible operator confirms an approved change, repeat the PTR lookup and the hostname's forward A or AAAA lookup from an independent resolver. Compare both with the actual outgoing address. Then send a permitted test message through the same route to the affected recipient and inspect the new delivery result and authentication headers. A correct PTR does not by itself repair a blocked SMTP path, a bad SPF or DKIM setup, a DMARC alignment failure, a recipient policy or an IP reputation problem.
If the original rejection persists, preserve the new diagnostic result and exact error code and continue with the specific mail-delivery investigation. Do not loosen SPF or DMARC, alter MX records or reinstall the VPS merely to change a reverse-DNS result. If the outbound relay is shared, escalate to that relay's operator rather than changing a different machine.
Frequently asked questions
Can I create my VPS PTR record in my domain's DNS panel? Usually no. The reverse zone for the public IP is managed by the address holder or a delegated operator; check who owns that route.
Does the PTR have to be my website name? No. It should be a hostname chosen for the actual sender and have forward DNS that includes the sending IP.
Why does IPv4 pass while IPv6 mail still fails? The two addresses have separate reverse records and forward checks. Identify which address the recipient actually saw.
Does matching PTR and A guarantee mail delivery? No. Recipients still evaluate authentication, policy and reputation.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.