Reverse DNS and A records for email: what senders must set

If you send from your own mail server or a dedicated IP, your sending IP needs valid forward-confirmed reverse DNS: a PTR record naming a hostname, and an A record for that hostname pointing back to the same IP. Google states this as a requirement for senders, and a mismatch produces rejections rather than spam-folder placement. If you send only through a provider's shared infrastructure, this is their job — but you should still know how to check it.

The records that matter for email

Two frequent misconceptions: your MX record has nothing to do with whether your outbound mail is accepted, and a PTR record is not something you add in your domain's DNS panel. Reverse DNS lives in the in-addr.arpa zone, which is controlled by whoever was allocated the IP — your host, cloud provider or ISP.

Verify forward-confirmed rDNS in two commands

Start with the IP your mail actually leaves from. Find it in the Received header of a message you sent to an external mailbox, then:

$ dig -x 203.0.113.10 +short
mail.yourdomain.com.

$ dig +short mail.yourdomain.com
203.0.113.10

Both must succeed and the IPs must match. Failure modes and what they mean:

• No PTR at all — the IP owner never set one. Request it.
• PTR is a generic hostname like 203-0-113-10.static.examplehost.net — technically present, but it identifies the host, not you. Receivers treat generic PTRs as a weak signal and some reject on patterns that look like dynamic residential space.
• PTR resolves to a hostname with no A record — the forward confirmation fails. This is as bad as no PTR.
• PTR hostname resolves to a different IP — a stale record after a migration. Very common, and invisible until you look.

If you send over IPv6, do the same for the AAAA and the IPv6 PTR. Receivers are typically stricter on IPv6 than IPv4, and a server that prefers IPv6 with no PTR will fail checks that its IPv4 path passes.

Pick a sensible hostname

The PTR hostname should be one you control, under a domain that is recognisably yours, and it should match the HELO/EHLO name your server announces. The chain that receivers like to see is simple and self-consistent:

EHLO mail.yourdomain.com
PTR for 203.0.113.10        -> mail.yourdomain.com
A for mail.yourdomain.com   -> 203.0.113.10
SPF for yourdomain.com      -> includes 203.0.113.10

A HELO name that disagrees with the PTR is a long-standing spam heuristic. It costs nothing to align them.

What you can and cannot control on hosted platforms

If you send through Google Workspace, Microsoft 365, SendGrid, Amazon SES, Mailgun or Postmark, the sending IPs are theirs and the PTR records are theirs. You do not need to set anything, and you cannot. What you own in that case is the domain side: SPF including their mechanism, DKIM signing with alignment to your From domain, and DMARC.

On a dedicated IP from one of those providers, rDNS is usually configurable through a support request or a console setting — and it is worth doing, because a dedicated IP with a generic PTR gets the worst of both worlds.

Why this is not the first thing to fix

Reverse DNS is a gate, not a lever. Passing it does not earn you placement; failing it blocks you. Once dig -x and dig agree, move on to the things that actually move placement: authentication alignment, spam rate against Google's 0.30% threshold (aim under 0.10%), volume ramp, and list quality. And remember what you can no longer check: Google's domain and IP reputation dashboards retired with Postmaster Tools v1 — senders were redirected from 30 September 2025 and v1 was gone by the end of 2025 — so v2 gives you spam rate, authentication, delivery errors and compliance status, plus the Deliverability analysis report added in June 2026, and no reputation grade.

What not to do

• Do not try to create a PTR record in your domain's DNS editor. It will have no effect; reverse DNS is delegated to the IP holder.
• Do not point the PTR at a hostname you do not control. You will fail forward confirmation the moment that hostname's A record changes.
• Do not forget the PTR after migrating servers. Changing the A record is the obvious step; the stale PTR is the one that lingers.
• Do not add every IP you have ever used to SPF to be safe. An over-broad SPF record authorises senders you no longer control, and deep include chains risk the DNS lookup limit.
• Do not assume one working test covers all your paths. Transactional mail, campaign mail and your mail server may leave from three different IPs.

How MailPilot helps

MailPilot checks SPF, DKIM and DMARC on the domains your connected mailboxes send from, and surfaces alignment problems rather than just record presence — which is where most authentication failures actually live. It warms mailboxes over OAuth or SMTP/IMAP and measures real per-provider placement, so once the DNS gates are passed you can see whether anything downstream is still costing you the inbox.