Defaults.Exposed › Fixes › Reverse DNS (PTR)

How to fix Reverse DNS (PTR)

Reverse DNS is the ID badge for the server that sends your business email. When a receiving provider like Gmail or Microsoft 365 looks up who's behind the sending address and gets a name that checks out, your mail looks legitimate. When there's no badge — or the name and number don't agree — your perfectly real invoices and quotes get treated as suspicious and quietly junked or rejected.

Bottom line for your business: Your invoices, quotes and customer replies silently land in spam or never arrive at all — so deals stall, payments come in late, and customers think you ignored them, none of which shows up as an error you'd notice.

What this can cost you

• You send a quote to a hot prospect, it drops into their spam, and they go with the competitor who 'actually replied' — and you never even knew the email didn't land.
• Invoices to customers vanish into junk, payments arrive weeks late, and your cash flow takes the hit because nobody ever saw the email.
• A customer complains you never got back to them — but you did; their mail provider quietly binned your reply because your sending server couldn't prove who it was.
• Your domain sails through a new client's security review on everything else, then gets flagged because your mail server has no proper identity — a small thing that makes you look careless.
• You moved to a cheap VPS or a new app to send your newsletters and invoices, and overnight your delivery rate drops — because that new sending server has no reverse-DNS badge and the big providers no longer trust it.

Why it matters. Every major email provider checks the identity of the server that sends your mail, and they check it on every message. If that server can't prove who it is — or if its name and its number contradict each other — your genuine business email gets handled as if it might be spam. You lose replies, payments, and trust, and because nothing bounces, you usually never find out why.

The short version

When your business sends an email, it leaves from a mail server, and every server on the internet has a numeric address — its IP. Reverse DNS (a “PTR” record) is that server’s name badge: it lets anyone who sees the number look up the proper name behind it, like mail.yourcompany.com.

The big receiving providers — Gmail, Microsoft 365, Yahoo — check that badge on every message you send. A server that can name itself, and where the name and the number agree with each other, looks like a legitimate mail server. A server with no badge, or a badge that doesn’t match, looks exactly like the anonymous, throwaway machines spammers use. So your genuine invoices and quotes start every conversation under suspicion — and a lot of them lose.

The frustrating part is that nothing tells you it’s happening. There’s no bounce, no error. Your email just quietly underperforms.

What this can cost you

These are the everyday ways a missing or mismatched reverse-DNS record turns into money and trust walking out the door. We never name a real business — these are patterns we see across the data.

• The quote that never landed. You email a detailed quote to a prospect who asked for it that morning. Their provider can’t verify your sending server, so it drops the message in spam. They don’t dig through junk. By the afternoon they’ve taken the competitor’s quote — the one that “actually showed up.” You chalk it up to a slow lead; in reality your email was never seen.
• The invoice in the void. You invoice a good customer. It lands in their junk folder. Thirty days later you’re chasing a payment that’s overdue through no fault of theirs — and now there’s an awkward conversation, a strained relationship, and a cash-flow gap that was entirely avoidable.
• “You never replied.” A customer is annoyed that you ignored their question. You didn’t — you replied the same day. Their mail provider silently binned your response because your sending server looked untrustworthy. You look unprofessional for something you actually did right.
• The DIY sending server that quietly poisoned everything. To save money, your mail (or just your newsletters and automated invoices) started going out through a cheap VPS or a new sending app. That server never got a reverse-DNS badge. Overnight, your delivery rate sagged across the board — and because there’s no error message, it took months to even suspect the cause.
• The security-review flag. A bigger client’s IT team runs a routine check on your domain during onboarding. Everything else is fine, but your mail server has no proper identity. It’s a minor technical point, but it reads as carelessness — and now you’re fixing it under deadline pressure, or explaining it away, when a competitor’s domain just sailed through.

The thread through all of these: the cost lands on you, it’s invisible while it’s happening, and the fix is free.

What it actually is

Normal DNS turns a name into a number: you type yourcompany.com, and DNS hands back the IP address to connect to. Reverse DNS does the opposite — it turns a number back into a name. Given the IP 203.0.113.10, a reverse lookup (a “PTR record”) answers mail.yourcompany.com.

Why receivers care: when your mail server connects to Gmail to deliver a message, Gmail sees the connecting IP. The first thing a serious mail filter does is ask “who is this machine?” — by doing a reverse lookup on that IP. A real business mail server has an answer (mail.yourcompany.com). A disposable spam machine usually doesn’t, or has a generic provider-assigned name like host-203-0-113-10.someisp.net. So the presence and quality of the badge is one of the very first trust signals applied to your mail — before SPF, DKIM, or the message content even get a look.

It checks the mail server, not your website. This trips people up. Your website’s address is often behind a CDN or proxy (like Cloudflare) and will never have a matching badge — and that’s fine, because reverse DNS for email is about the MX mail server’s IP, a completely separate machine. This check correctly looks up your domain’s primary mail server (the lowest-priority MX record), resolves it to its IP, and checks the badge on that IP.

The half that most setups get wrong: it has to match both ways. Having a name isn’t enough on its own. Gmail and the other big filters do something stricter, called forward-confirmed reverse DNS (FCrDNS):

1. Look up the IP → get a name (e.g. mail.yourcompany.com).
2. Now look that name back up → it must resolve to the same IP you started from.

If the two directions agree, the server is confirmed and fully trusted. If there’s a name but it points somewhere else (or nowhere), the server is only half-trusted — a badge that doesn’t survive a second glance is treated as weaker than you’d hope. A PTR that points to a hostname an attacker controls, and which doesn’t resolve back, is in some ways worse than no PTR at all.

That’s exactly how this check scores it:

• Forward-confirmed (FCrDNS): the IP names a host, and that host points back to the same IP. Full marks — this is correct configuration, and it’s what receivers trust.
• Badge exists but doesn’t confirm: there’s a PTR record, but the name doesn’t resolve back to the mail server’s IP. Partial credit only — it looks configured but the big filters won’t fully trust it.
• No badge at all: no PTR record on the mail server’s IP. No credit, and the deliverability cost is real.

A note on weight: in the methodology this is a scored email-security check (worth 25 points, a P2-priority item). It’s not the single heaviest email check — that’s SPF and DMARC, which stop outright impersonation — but it’s a genuine, graded part of your email standing, and one of the few that depends on your provider getting something right rather than you. If you send through Google Workspace or Microsoft 365 only, you almost certainly already pass it; the businesses that fail are the ones sending through their own or a third-party server.

What “good” looks like: your primary mail server’s IP has a PTR record pointing to a real hostname you own, and that hostname resolves straight back to the same IP — the two directions agree (FCrDNS confirmed).

How to fix it (free, ~10 minutes of someone’s time)

Hand this section to whoever owns the IP address of your mail server — usually your email or hosting provider, or your data-centre for a self-hosted box — and note that the fix is free. This is the one email setting you almost certainly cannot change yourself in your normal DNS panel, because reverse DNS is controlled by whoever owns the IP, not by whoever owns the domain. We only charge to monitor that it stays correct, never to make the change.

Step 1 — Find the sending mail server’s IP. Identify the domain’s primary MX host (the mail server with the lowest priority number) and resolve it to its IP address:

dig MX yourcompany.com        # find the primary (lowest-priority) MX host
dig A mail.yourcompany.com    # resolve that host to its IP

That IP is the one that needs the badge. Do not use the website’s IP — it’s a different machine and often behind a CDN that will never match.

Step 2 — Ask the IP owner to set the PTR record. Reverse DNS lives with whoever controls the IP block, so the request goes to:

• Google Workspace / Gmail: managed automatically for Google’s own mail servers — if a domain sending only through Google somehow shows as failing, raise it with Google support. (In practice these pass.)
• Microsoft 365: likewise managed automatically for Microsoft’s servers.
• A self-hosted or VPS mail server: open a ticket with your hosting provider or data-centre asking them to set the PTR (reverse DNS) for your IP to your mail hostname. Most providers expose this in their control panel under “Reverse DNS,” “rDNS,” or “PTR.” On the big clouds it’s a one-field setting (e.g. AWS requires a short request form to enable rDNS on an Elastic IP; most VPS hosts let you set it instantly).
• A third-party sending app (newsletter / invoicing / CRM tool): if it sends from its own shared servers, the provider handles reverse DNS — there’s nothing for you to set, and you can ignore this for that traffic. If it sends from a dedicated IP you bought from them, ask them to set the PTR on it.

Tell them the record you want, for example: 203.0.113.10 → mail.yourcompany.com.

Step 3 — Make it forward-confirm (this is the step most people miss). The hostname in the PTR must also resolve back to the same IP via a normal A record that you control in your own DNS. So:

• The PTR says 203.0.113.10 → mail.yourcompany.com (your provider sets this).
• The A record says mail.yourcompany.com → 203.0.113.10 (you set this in your DNS, e.g. Cloudflare → DNS → add an A record, Name mail, content 203.0.113.10).

Both directions must point at each other. Only then is it forward-confirmed and fully trusted.

Step 4 — Re-check your domain. Confirm the mail server now shows forward-confirmed reverse DNS and the check passes. DNS changes propagate within minutes to a few hours.

Common mistakes

• Setting the badge on the website’s IP instead of the mail server’s. Reverse DNS for email is about the MX server. Putting a PTR on your web/CDN address does nothing for deliverability — the wrong machine gets the badge.
• Stopping at “the PTR exists.” A name on its own only earns partial trust. If it doesn’t resolve back to the same IP, the strict filters (Gmail, M365, Yahoo) won’t fully trust it. Always complete the forward-confirmation (Step 3).
• Forgetting the A record after the provider sets the PTR. The provider sets the reverse half; you must set the forward half in your own DNS. People do one and assume they’re done.
• Asking the wrong party. Sending the request to your domain registrar or DNS host instead of the IP owner gets you “we can’t do that” — because they genuinely can’t. It has to go to whoever owns the IP.
• Generic provider hostnames. A PTR like host-203-0-113-10.someisp.net technically exists but does nothing for your brand or trust. Use a real hostname on your own domain that forward-confirms.

Where this fits

Reverse DNS is the server’s identity; SPF, DKIM and DMARC are the domain’s authorisation and anti-impersonation layer. They answer different questions, and the big providers check all of them. SPF lists which services may send as you; DKIM cryptographically signs your messages so they can’t be tampered with; DMARC ties the two together and tells receivers what to do with mail that fails — and protects the visible “from” name your customers actually see. Reverse DNS sits underneath all of that, vouching that the machine doing the sending is a real, named mail server in the first place. Get SPF, DKIM and DMARC right for the strongest impersonation defence; get reverse DNS right so a new or self-hosted sending server isn’t quietly distrusted before the rest even gets a chance. Every one of these fixes is free.

FAQ