A PTR record maps an IP address back to a hostname, and it's one of the first things receiving mail servers check. This guide covers how the in-addr.arpa reverse zone works, where to request a PTR and a second IPv4 address in the WeaselCloud client area, and how to confirm the change actually took effect.
The mail server is running, the queue is clear, and the message left the box - but it never reaches the inbox because Gmail quietly filed it under spam. Almost always the cause is the same: the sending IP address has no valid PTR record, the reverse DNS entry that maps an IP back to a hostname. Here's what a PTR record actually does, why it matters the moment you run your own mail server, and how to request one - plus a second IPv4 address if you need it - from the WeaselCloud client area.
Short version. A normal (forward) DNS record answers "this domain points to this IP." A PTR record answers the opposite question: "this IP points to this name." It doesn't live in your domain's DNS zone - it lives in a separate reverse zone called
in-addr.arpa, controlled by whoever owns the IP block, which in your case is WeaselCloud. That's why you can't set a PTR through your own domain's DNS panel; you request it from the hosting provider. Without a matching PTR, mail sent from your own SMTP server routinely lands in spam at Gmail, Yahoo, and Mail.ru - it's one of the first checks a receiving server runs. WeaselCloud has no self-service form for either one - you request a PTR or an additional IPv4 by opening a support ticket in themy.weasel.cloudclient area (Support → Tech support). Confirm the result withdig -x <IP>; expect anywhere from a few minutes up to a day for it to take effect.
What a PTR record is and how it differs from a normal DNS record
A standard A record ties a domain to an IP address: type example.com into a browser, and DNS hands back the server's IP. A PTR record (short for pointer) runs the lookup the other way: you have an IP address and want to know what hostname is registered against it. This is called reverse DNS, or rDNS.
The difference isn't just direction, it's ownership. You control the records for example.com yourself, through your registrar or your own name servers. The reverse record for an IP lives in a zone that belongs to whoever holds that block of addresses - for a WeaselCloud VPS, that's WeaselCloud's own address space. So a PTR change always goes through the hosting provider, never through your domain's DNS panel.
Why unconfigured PTR sends mail from a VPS straight to spam
If you run your own mail server on a VPS - for outbound company mail, for a newsletter, or just so your application can send through a local SMTP relay instead of a third-party service - a PTR record stops being a technicality and becomes a precondition for delivery.
Receiving mail servers such as Gmail, Yahoo, and Mail.ru don't only look at headers and content. Before anything else, they weigh the reputation of the sending IP, and one of the cheapest signals to check is whether that IP even has a PTR record, and whether it roughly matches the hostname the server announced during the SMTP handshake (the HELO/EHLO command). A properly configured mail server usually has a sensible PTR like mail.example.com. IP addresses that spam comes from typically have no PTR at all, or one nobody bothered to set to anything meaningful.
A stricter check called FCrDNS (forward-confirmed reverse DNS) goes one step further: the PTR for your IP resolves to a hostname, and the forward A record for that hostname resolves back to the same IP. That round-trip match reads as a strong signal that the sender is properly set up, not a compromised machine on autopilot. A missing PTR isn't an automatic ban, but for many providers it's enough on its own to knock the score down before SPF and DKIM are even checked.
Who actually needs a PTR - and who can skip this entirely
If your server only handles a website or an API, PTR is irrelevant - inbound HTTP requests don't care about it. It matters the moment something on that server sends mail on its own behalf: a mail daemon like Postfix or Exim, transactional email through a local SMTP relay, a newsletter. From that point on, PTR is what makes SPF, DKIM, and DMARC actually useful - they confirm a sender is authorized, but some receivers never get that far if the IP already looks suspicious at the PTR stage.
Provider | What it checks via reverse DNS | Typical result without a valid PTR |
|---|---|---|
Gmail | presence of a PTR, rough match against the HELO hostname | message accepted but frequently routed to spam |
Yahoo | presence of a PTR, FCrDNS | hard bounce during the SMTP session in a share of cases |
Mail.ru | presence of a PTR, overall IP reputation | message usually lands in the spam folder, especially for bulk sending |
The exact thresholds change without much notice and aren't fully published - treat the table as a general pattern, not a guaranteed rule set for any given date.
How the in-addr.arpa reverse zone works, in plain terms
For IPv4, reverse lookups run through a special domain called in-addr.arpa. The address is written into it backwards: for 203.0.113.10, the reverse zone is 10.113.0.203.in-addr.arpa, and that's where the PTR record actually lives. The zone is delegated down a chain from regional internet registries (RIPE for Europe) to the provider that owns the address block. In practice that means one thing for a WeaselCloud customer: to get a PTR set, go to the client area, not to your domain's DNS zone.
How to order an additional IPv4 address in WeaselCloud
Every WeaselCloud VPS ships with one IPv4 address by default. You need a second one if a single server hosts several sites still relying on per-IP SSL setups, if you're running a dedicated mail server and don't want it sharing reputation with the main site's IP, or if an application needs to bind to more than one address. IPv4 is a limited resource - every provider's free pool is finite - so an additional address is usually a paid add-on rather than something assigned automatically.
The my.weasel.cloud client area has no "order an IP" button on the service page - neither Hosting Information nor Configurable Options carries one. Request it via a ticket instead: Support → Open Ticket, department Tech support. State which server (the weasel-de-...-style hostname from the service card) needs the second IPv4 and why.
Once the address is assigned, it sometimes needs to be added manually to the operating system's network configuration - otherwise the OS simply doesn't know it has a second IP. The exact method depends on the distribution (on Ubuntu 22.04/24.04 that's netplan), and WeaselCloud usually spells out the required step in the ticket reply.
How to request a PTR for your IP address
Once an IPv4 address exists - the default one or a second one - its PTR goes through the same Tech support ticket (WeaselCloud has no self-service PTR form either). State the IP and the hostname the PTR should point to, usually your mail server's domain, for example mail.example.com. Before submitting, make sure that hostname already has its own A record pointing back to the same IP - without it you get a PTR, but not the FCrDNS match that actually produces the benefit.
How to confirm the PTR record took effect
Two standard tools cover this on virtually any operating system. The first is dig with the -x flag, which runs a reverse lookup without making you manually construct the in-addr.arpa address:
dig -x 203.0.113.10 +short
-xswitches dig into reverse-lookup mode - you feed it an IP instead of a name+shorttrims the output down to just the answer, skipping the query headers
If the PTR is set, you'll get one line back, something like mail.example.com. - the trailing dot is normal, it marks a fully qualified name. An empty response means the record hasn't been applied yet, or was never requested.
The second option is nslookup, available even on systems that don't ship dig:
nslookup 203.0.113.10
Look for the line reading name = mail.example.com. in the output - that's the current PTR for the address. If the name server returns something like ** server can't find ... : NXDOMAIN instead, no reverse record exists for that address yet.
How long propagation takes
PTR records are served from WeaselCloud's own name servers - unlike changing regular records at a third-party registrar, there's no need to wait for independent nameservers worldwide to catch up. Changes are usually visible within a few minutes to a couple of hours. If a resolver somewhere had already cached the old, empty answer, it clears later on that particular network - hence the more cautious upper bound providers quote, up to 24 hours. If dig -x still shows nothing after a full day, that's worth a support ticket rather than waiting further.
FAQ
What is a PTR record
A PTR record is a reverse DNS entry that maps an IP address back to a hostname, the mirror image of a regular A record (domain to IP). It lives in the special in-addr.arpa zone, controlled by whoever owns the IP block, not by whoever owns the domain.
Why does mail from my server go to spam
The most common reason is a missing or mismatched PTR record on the sending IP. Receiving servers like Gmail and Yahoo check whether the sending IP has a reverse record and whether it roughly matches the hostname announced during the HELO handshake - without that match, a message loses credibility before SPF and DKIM are even evaluated.
How do I check a PTR record
Run dig -x <IP> +short - it returns the hostname if one is set, or nothing if it isn't. The alternative is nslookup <IP>, where the hostname shows up on the line starting with name =.
How do I get an additional IPv4 address for my VPS
Through a support ticket in the my.weasel.cloud client area (Support → Tech support) - there's no self-service order form. An additional IPv4 is usually a paid add-on, since every provider's available address pool is limited.
How long does a PTR record take to propagate
Usually a few minutes to a couple of hours, since the record is served directly from the provider's own name servers. Up to 24 hours is the cautious upper bound for cases where a resolver somewhere had already cached the previous, empty answer.
Takeaways
- A PTR record (reverse DNS) maps an IP address to a hostname - the reverse of a standard A record.
- It lives in the
in-addr.arpazone controlled by the IP block's owner - for your VPS, that's WeaselCloud, not your domain registrar. - Without a valid PTR, mail from a self-hosted server routinely lands in spam at Gmail, Yahoo, and Mail.ru - it's one of the first checks a receiving server runs.
- Order a PTR or an additional IPv4 only through a support ticket in the my.weasel.cloud client area (Support → Tech support) - there's no self-service form.
- Before requesting a PTR, make sure your mail server's hostname already has an A record pointing back to the same IP - that's what gives you the FCrDNS match.
- Verify the result with
dig -x <IP> +shortornslookup <IP>. - Propagation usually takes minutes to a couple of hours; up to 24 hours only in edge cases involving cached answers.
What's next
- WeaselCloud client area overview - if you're not sure where networking settings even live.
- Billing cycle and auto-renewal - how an add-on like a second IPv4 shows up on your recurring invoice.
- Basic ufw firewall for a VPS - opening the SMTP ports once your mail server is running.