PTR & Reverse DNS Configuration

There is a deliverability check that happens before SPF, before DKIM, before DMARC — at the moment your server first connects to a receiving server, before a single line of your message is considered. It is reverse DNS, and it is the most overlooked fix in email. Teams will spend thousands on warming tools and rewrite subject lines for weeks while their sending IP has no valid PTR record at all, quietly getting rejected at the door. This page explains what reverse DNS is, why it now gates your mail, the two-way FCrDNS check receivers actually run, and why the fact that you cannot set it yourself is exactly where a host that owns your IP makes the difference.

What is reverse DNS, and what is a PTR record?

Regular DNS — forward DNS — answers the question “what IP address does this hostname have?” by resolving a name like mail.example.com to an IP through an A record. Reverse DNS does the opposite: it answers “what hostname does this IP address belong to?” by resolving an IP back to a name. The record type that makes reverse DNS work is the PTR record (pointer record), which maps an IP address to a hostname — the mirror image of an A record. So while an A record says mail.example.com points to 192.0.2.10, the matching PTR record says 192.0.2.10 points back to mail.example.com.

Reverse DNS is not new — it was defined in the earliest DNS standards in the 1980s — but its role in email has grown from a nicety to a requirement. For mail servers, the PTR record is how a receiving server checks that the machine connecting to it is what it claims to be, which is the first thing a receiver wants to know before trusting anything else.

Why does reverse DNS matter for email?

Because it is the very first identity check, and it runs at the connection level. When your mail server opens an SMTP connection to a receiving server, the receiver immediately performs a reverse DNS lookup on your IP to see whether it has a valid PTR record and whether that record makes sense. This happens in milliseconds, silently, on every connection — and critically, it happens before SPF, DKIM or DMARC are evaluated. If the lookup finds no PTR, or a PTR that does not line up, many receivers reject or defer the connection outright, with an error like 550 5.7.25, before they ever look at your authentication. All the authentication work in the world cannot save mail that is refused at the connection.

The logic is simple and effective: most spam originates from compromised home machines, botnets and throwaway servers spun up for a single campaign, and those almost never have proper reverse DNS. A single fast DNS query filters out a large share of that junk before any deeper analysis. The flip side is that a legitimate sender without proper PTR looks, to the receiver, exactly like that junk. This is why reverse DNS is the most overlooked deliverability fix there is — it is invisible until you look for it, and devastating when it is wrong.

There is a particular cruelty to how this failure presents. Because the rejection happens at the connection, before the message is accepted, it often does not show up the way a content or reputation problem does — you may see a spike in deferrals, a stream that never arrives, or a bounce log full of a single cryptic code, with no obvious cause in your campaign. Teams chase the wrong fix for weeks, tuning subject lines and warming IPs, while the actual problem is a PTR that was never set or quietly broke. Checking reverse DNS first, before anything more elaborate, saves that wasted effort — and it is the first thing a competent deliverability look should rule in or out.

Is reverse DNS actually required now?

Yes. What used to be a best practice is now an enforced requirement at the major providers. Since February 2024, Gmail and Yahoo require senders to have valid reverse DNS as part of their authentication standards, and Microsoft made forward and reverse DNS matching a hard requirement when its enforcement began in May 2025. Unlike DMARC, which is mandated specifically for bulk senders above the 5,000-a-day threshold, a valid PTR is part of the baseline expected of essentially all senders — and for bulk senders it sits alongside SPF, DKIM, DMARC, TLS and one-click unsubscribe as a non-skippable item. Yahoo and Microsoft are especially strict: Microsoft’s filters routinely refuse connections from IPs without reverse DNS, and a generic or missing PTR caps your sender reputation no matter how clean the rest of your setup is. The requirement is not subtle, and the penalty for missing it is connection-level rejection rather than a quiet move to spam.

Where each major provider stands today:

The trend is one-directional: the requirements have only tightened, reverse DNS sits inside the same enforcement cycle as DMARC and TLS, and there is no sign of any provider relaxing it. Treating a valid, confirmed PTR as optional in 2026 is treating connection-level rejection as acceptable.

What is FCrDNS (forward-confirmed reverse DNS)?

A plain PTR record, on its own, proves less than it appears to, and FCrDNS is the check that fixes that. The problem: anyone who controls an IP can point its PTR record at any hostname they like, including one they do not own. A spammer controlling an IP could set its PTR to mail.google.com and, with only a one-way check, appear to inherit Google’s reputation. Forward-confirmed reverse DNS closes that loophole with a second step. The receiver does the reverse lookup — IP to hostname via the PTR — and then immediately does a forward lookup on that hostname, fetching its A or AAAA record. Only if the forward lookup resolves back to the original IP does FCrDNS pass. It is the email-delivery equivalent of showing two matching pieces of ID: the PTR says who you are, and the forward record independently confirms it.

Why you can’t set reverse DNS yourself — and why that matters

Here is the structural catch that defeats most do-it-yourself attempts: PTR records are controlled by whoever owns the IP address block, not by your domain registrar. Your registrar manages your forward DNS — A, MX, TXT, the records you are used to editing — but it has no authority over the reverse zone for an IP it does not own. The reverse zone belongs to the hosting provider or ISP that holds the IP block. So no matter how much access you have to your own DNS, you cannot publish your own PTR; you have to go to whoever owns the IP. With a typical cloud provider that means a support request, a verification step, and a wait, and with some it means caveats — a sending-limit increase first, or a panel quirk to learn.

This is precisely where a host that owns your IP changes the equation. Because MCSNET provides your dedicated sending IP and hosts the infrastructure, we set the PTR and confirm FCrDNS directly, as part of the build, with no ticket-and-wait loop and no dependency on a third party who does not care about your deliverability. The thing you cannot do yourself becomes something we simply do — and keep correct.

The generic-cloud-PTR trap

A PTR that exists is not the same as a PTR that helps, and the default ones actively hurt. When you spin up an instance on a cloud platform, the provider automatically assigns a default PTR — a long, machine-generated hostname on the provider’s own domain. It is technically valid reverse DNS, so a naive check passes, but mail filters read it for what it is: a generic cloud instance, not a managed mail server. Generic PTRs are heavily associated with spam and abuse precisely because every spammer who spins up a cheap VM inherits one by default, so receivers discount them. For real sending you need a custom PTR that matches your own sending domain — mail.yourdomain.com, not a provider’s auto-assigned string — backed by FCrDNS. The difference between the default and a custom, confirmed PTR is the difference between looking like throwaway infrastructure and looking like an accountable sender, and receivers treat the two very differently.

The IPv6 gap most setups miss

Reverse DNS quietly breaks over IPv6 in a way that catches careful senders off guard. Gmail in particular prefers IPv6 when it is available, so if your server can send over IPv6 but you have only configured a PTR for your IPv4 address, the connection that actually happens — over IPv6 — has no valid reverse DNS, and FCrDNS fails on it even though your IPv4 setup looks perfect. Google explicitly requires proper reverse DNS for IPv6 email connections, which makes this gap a real rejection risk rather than a theoretical one. The fix is to configure PTR records for every address your server actually sends from, IPv4 and IPv6 alike, and to confirm FCrDNS on both. It is the kind of detail that is invisible until a fraction of your mail starts failing for no obvious reason, and exactly the kind we check as a matter of course.

HELO/EHLO alignment

There is one more alignment that strengthens the whole picture: the hostname your mail server announces in its SMTP greeting. When your server connects, it introduces itself with a HELO or EHLO command naming a hostname, and the cleanest configuration is for that name to match the PTR record for the connecting IP. Some receiving servers go further and reject mail when the greeting hostname and the reverse DNS do not agree, treating the mismatch as a sign of a misconfigured or impersonating sender. Lining up the SMTP banner, the PTR hostname and the forward A record into one consistent identity removes any ambiguity for the receiver. It is a small piece, but it is the kind of consistency that separates infrastructure that was set up carefully from infrastructure that was merely set up.

Reverse DNS needs a dedicated IP

Proper reverse DNS assumes something about your IP: that it is yours to name. On a shared IP, you generally cannot set a custom PTR, because the address is used by many senders and its reverse record is not yours to control — which is one of several reasons serious sending belongs on a dedicated IP. A dedicated, static IP that you control is what lets a custom PTR exist and FCrDNS line up, and it is what ties your reverse DNS to your own reputation rather than a shared pool’s. There is an honest exception worth stating: if you send entirely through a relay or ESP, your mail leaves their IPs, and they handle the reverse DNS on those addresses — you do not need to configure it. Reverse DNS becomes your responsibility precisely when you run your own sending on your own dedicated IP, which is the setup where it matters most and is forgotten most often.

How we configure and verify reverse DNS

Because we host your dedicated sending IP, reverse DNS is something we own rather than advise on. We set a custom PTR record on your sending IP pointing to your mail server’s hostname, publish the matching forward A or AAAA record so the lookup confirms back to the same IP, and verify that FCrDNS passes end to end. We align the SMTP HELO/EHLO greeting to the same hostname, and we configure PTR for both IPv4 and IPv6 wherever your server sends, closing the IPv6 gap. Then we verify the result the way a receiver would — confirming the record exists, points to your domain rather than a generic default, and resolves both directions — and we send test mail to the major providers to confirm it is accepted at the connection.

# mcsnet · reverse dns check · sending ip 192.0.2.10
ptr (reverse)   192.0.2.10  →  mail.brand.example
a (forward)     mail.brand.example  →  192.0.2.10
fcrdns          match  PASS
generic?        no — custom hostname on your domain
helo/ehlo       mail.brand.example  (aligned)
ipv6 ptr        2001:db8::10  →  mail.brand.example  PASS
result          accepted at gmail · outlook · yahoo connection

What breaks reverse DNS, and how we catch it

Reverse DNS is not quite set-and-forget, because the things that break it happen outside your own DNS. A hosting provider can, rarely, change reverse-zone configuration in a way that silently breaks FCrDNS without warning; a server can be reconfigured to send from a new address that has no PTR; an IPv6 path can open up that the IPv4-only setup never covered. Because the failure is silent — mail simply starts being deferred or rejected with no change on your side — the only protection is to check on a schedule rather than assume. We monitor the reverse DNS on your sending IPs and re-verify FCrDNS regularly, so a break is caught as a monitoring alert rather than discovered weeks later in a bounce log. The whole point of treating reverse DNS as managed infrastructure rather than a one-time edit is that the gate which guards every connection stays open.

Why work with us?

Two reasons, and the first is structural. We own the IP, so we own the PTR. Reverse DNS is the one piece of email authentication you cannot configure yourself — it belongs to the IP holder — and because MCSNET hosts your dedicated sending IP in Toronto, we set it, confirm FCrDNS, align the HELO, cover IPv6 and monitor it, with no third-party ticket between you and a working configuration. Second, data and consent: your sending runs on infrastructure resident in Canada under PIPEDA, with a CASL-aware approach, so the reverse DNS that anchors your identity sits inside a sovereign, accountable setup. Reverse DNS is rarely the headline, but it is the gate before every other gate — and owning the IP is what lets us keep it open.

Who this is for, and who it is not

It is for senders running their own outbound mail on a dedicated IP — email platforms, agencies, SaaS and e-commerce businesses on real sending infrastructure — who need the connection-level identity correct and confirmed. It is for anyone seeing 550 5.7.25 or PTR-related rejections, and for teams who have done SPF, DKIM and DMARC but never checked the reverse DNS underneath them. It is not necessary for senders who route entirely through a relay or ESP, whose provider owns the sending IPs and the reverse DNS on them — and we will tell you when that is your situation rather than configure something you do not control. Reverse DNS is the foundation beneath authentication: it pairs with the authentication setup and SPF and DKIM above it, and with the dedicated IP it depends on. Get the PTR right, confirmed both ways, and your mail clears the very first check instead of failing it silently.