# Reverse DNS and email spam: what PTR checks really mean

> Reverse DNS email spam checks use PTR records as one sender signal. Learn what Google requires, what receivers may do, and how to validate it.

Reverse DNS can affect how a receiving mail system evaluates your sending IP address, but a missing or mismatched PTR record does not prove that a message will go to spam. Google has required valid forward and reverse DNS for all senders since February 1, 2024. Microsoft says some mail servers may reject mail without a reverse record or flag it as spam. Reverse DNS is one signal, separate from authentication and receiver-specific filtering decisions.

## Quick takeaways

- Reverse DNS maps an IP address back to a hostname through a PTR record.
- Google requires valid forward and reverse DNS for all senders as of February 1, 2024.
- Microsoft says some email servers may flag mail as spam or reject it when the sending IP lacks a PTR record.
- RFC 5321 says an EHLO name and IP-address mismatch alone MUST NOT cause SMTP rejection.
- Reverse DNS is not an SPF, DKIM, or DMARC authentication record.
- A public PTR lookup shows current DNS data, not a receiver's private spam decision or future inbox placement.

## Who is affected?

Any operator sending email directly from an IP address is affected. That includes teams operating their own SMTP servers and teams using an email service provider whose infrastructure sends mail on the organization's behalf. The relevant IP is the IP that opens the SMTP connection to the receiving server, not necessarily the IP address of the website or corporate network.

Reverse DNS uses the DNS `PTR` record type. [RFC 1035 defines the reverse lookup tree](https://datatracker.ietf.org/doc/html/rfc1035#section-3.5) under `IN-ADDR.ARPA` for IPv4 addresses, while [RFC 1035's PTR record definition](https://datatracker.ietf.org/doc/html/rfc1035#section-3.3.12) describes the record that points from an address to a domain name. For record anatomy and lookup direction, see [what a PTR record is](/learning/email-reverse-dns-check).

The sender normally cannot set a PTR record in an ordinary domain DNS zone. The organization that controls the IP address allocation, often a hosting provider, cloud provider, or email platform, must publish it.

A PTR record is relevant to sender identity checks, but it is not a complete spam-prevention control. Google's sender guidelines list valid forward and reverse DNS separately from SPF or DKIM, and separately from DMARC requirements for bulk senders. That distinction matters: a plausible PTR name does not authenticate the visible From domain or establish DMARC alignment.

## What are the requirements?

### Google requires valid forward and reverse DNS

[Google's email sender guidelines](https://support.google.com/a/answer/81126) require all senders to have valid forward and reverse DNS records. The requirement applies independently of whether the sender is classified as a bulk sender.

For a sending IP, the reverse lookup should return a hostname. That hostname should then resolve forward to the same sending IP. This is commonly called forward-confirmed reverse DNS.

```text
Illustrative only. Publish the actual PTR value through the organization that controls the sending IP.

198.51.100.24 -> mail1.yourdomain.com
mail1.yourdomain.com -> 198.51.100.24
```

Do not publish a PTR target that belongs to another tenant or copy a provider's example hostname. The IP owner generates or configures the real reverse record.

### A receiver may treat missing reverse DNS as an anti-spam signal

Microsoft's [Remote Connectivity Analyzer guidance on missing PTR records](https://learn.microsoft.com/en-us/connectivity-analyzer/ip-address-does-not-have-ptr-record-dns) states: "Some e-mail servers check for a reverse record as a basic anti-spam check procedure. These e-mail servers may reject messages from your domain, or they may flag messages as spam."

"May" is the important word. The statement confirms that reverse DNS can affect filtering or acceptance, but it does not establish a universal spam-folder outcome, a score, or a numeric threshold. No published source in this guidance shows that reverse DNS alone is sufficient to cause spam placement.

A receiver can combine connection data with message authentication, sending reputation, content, complaint history, and local policy. The practical consequence is that fixing a PTR record can remove one avoidable negative signal, while leaving other delivery problems untouched. For related operational checks, see [email reverse DNS best practices](/learning/email-reverse-dns-best-practices).

### An EHLO mismatch alone cannot justify rejection

The SMTP standard limits one common assumption about reverse DNS. [RFC 5321 section 4.1.4](https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.4) says that the EHLO or HELO argument contains the client's domain name, but a mismatch between that name and the connecting IP address "MUST NOT" be the sole basis for refusing the connection.

```text
EHLO mail1.yourdomain.com
```

This does not mean receivers must ignore reverse DNS. It means an EHLO-to-IP mismatch by itself is not enough for rejection under the SMTP specification. A receiver can use other policy evidence, and an operator should investigate a specific SMTP rejection from its exact message and connection evidence. [Reverse DNS does not match SMTP banner](/learning/reverse-dns-does-not-match-smtp-banner) covers that narrower failure case.

### Reverse DNS is not email authentication

[RFC 8601 section 3](https://datatracker.ietf.org/doc/html/rfc8601#section-3) describes the `iprev` authentication-results method and notes that referenced guidance recommends applications avoid using this test as a means of authentication or security. A PTR record identifies a DNS name associated with an IP address. It does not prove authority to use the visible From domain.

A receiver can record an IP reverse result in the `Authentication-Results` header:

```text
Authentication-Results: mx.example;
  iprev=pass policy.iprev=mail1.yourdomain.com
```

The example is illustrative only. [RFC 8601 section 2.7.3](https://datatracker.ietf.org/doc/html/rfc8601#section-2.7.3) registers `pass`, `fail`, `temperror`, and `permerror` values for `iprev`.

SPF, DKIM, and DMARC address different questions. SPF authorizes sending IP addresses for an envelope domain, DKIM verifies a signed message, and DMARC evaluates alignment against the visible From domain. Google's sender guidance identifies SPF or DKIM for all senders and DMARC for bulk senders. Reverse DNS does not replace any of them.

![Decision flow showing how a receiving server can use a PTR record as one signal without treating it as standalone authentication](/images/editorial/reverse-dns-email-spam/reverse-dns-email-spam-decision-flow.webp "1200x738")

*Source: Palisade.*

## When does the requirement take effect?

Google's valid forward and reverse DNS requirement took effect on February 1, 2024, according to its [email sender guidelines](https://support.google.com/a/answer/81126). The requirement is a Google sender policy, not a new DNS protocol.

RFC 1035 defines DNS and PTR records. RFC 5321 is a Standards Track SMTP specification published in October 2008, and its EHLO mismatch rule has no receiver-enforcement date. RFC 8601, published in May 2019, defines the `Authentication-Results` header field and the `iprev` result method. Neither RFC makes a missing PTR record a universal spam trigger.

Microsoft's published guidance does not name an operative date or a uniform enforcement threshold. It says receivers may flag or reject messages, so treat that statement as receiver-policy guidance rather than a guarantee about a particular mailbox provider.

## How do I implement the requirement?

### 1. Identify the actual outbound SMTP IP

Find the public IP address that establishes the SMTP connection for the mail stream in question. For a third-party email platform, use the platform's delivered-message headers or support documentation instead of assuming that the visible From domain's web-server IP sends mail.

If several IPs send mail, check each one. A valid PTR record on one marketing IP does not validate an unrelated transactional or corporate mail path.

### 2. Request or configure the PTR record with the IP owner

Set the PTR target through the provider that owns the IP address range. Use a hostname under a domain you control when the provider supports that arrangement, then ensure the hostname resolves forward to the same IP.

> Do not change a production PTR record until you know which services share the IP address. A careless reverse-DNS change can affect mail systems beyond the stream you are investigating.

### 3. Confirm the forward mapping

Look up the PTR name, then query its A or AAAA record to confirm it leads back to the sending IP. The [DNS lookup tool](/tools/dns-lookup) can inspect the forward record after you have the hostname.

A matching PTR and A or AAAA record satisfies the DNS portion of the check. It does not prove that the mail application sends from that IP, signs messages correctly, or meets a receiver's filtering policy.

### 4. Inspect a delivered message

Send a message through the exact production path and inspect its raw headers. Look for an `Authentication-Results` field added by the receiving system. If it includes `iprev`, record its result and compare it with the current PTR lookup.

Also inspect SPF, DKIM, and DMARC results. Reverse DNS can be sound while authentication fails, and authentication can pass while a receiver still uses other spam signals.

## How do I validate compliance?

Start with a public check of the sending IP. Palisade's [IP reputation checker](/tools/ip-reputation) reports the PTR name returned for an IP and checks blocklist status. It can time out after 3,500 milliseconds and return no PTR result, and it does not perform forward confirmation for you.

Use the result as a starting point, then query the reported hostname's A or AAAA record. Confirm the forward record maps to the same outbound IP. Check DNS through the authoritative provider and at least one public resolver if a recent change has not appeared consistently.

Next, validate the vendor layer. If an email provider owns the sending infrastructure, confirm its current authentication or sender-verification status through that provider. A provider indicator is useful evidence, but it is not proof of a delivered message path.

Then validate the message layer with a real delivered message from the production sender. Inspect `Authentication-Results`, SMTP connection information where available, and the exact IP used. A public PTR lookup cannot reveal a receiver's private spam score, inbox decision, or later infrastructure change.

Finally, use DMARC aggregate reports after enough mail has flowed to identify authenticated sending sources and alignment failures across the domain. Reverse DNS checks do not replace DMARC monitoring. For broader DNS and SMTP context, visit the [infrastructure learning hub](/learning/infrastructure).

## Check the PTR record behind the sending IP

Check the outbound IP with the [IP reputation checker](/tools/ip-reputation), then compare the returned PTR name with its forward DNS record. This follows from the evidence above because a receiver evaluates the connecting IP, not an assumed hostname.

A public lookup cannot prove why a particular receiver placed a message in spam, repair a missing record, monitor later DNS changes, or guarantee inbox placement.

## Sources and further reading

- [RFC 1035: Domain names, implementation and specification](https://datatracker.ietf.org/doc/html/rfc1035)
- [RFC 5321: Simple Mail Transfer Protocol](https://datatracker.ietf.org/doc/html/rfc5321)
- [RFC 8601: Authentication-Results header field](https://datatracker.ietf.org/doc/html/rfc8601)
- [Google email sender guidelines](https://support.google.com/a/answer/81126)
- [Microsoft guidance for an IP address without a PTR record](https://learn.microsoft.com/en-us/connectivity-analyzer/ip-address-does-not-have-ptr-record-dns)

## Frequently asked questions

### What is reverse DNS in email?

Reverse DNS maps an email server's IP address to a hostname through a PTR record. [RFC 1035 defines the reverse DNS tree](https://datatracker.ietf.org/doc/html/rfc1035#section-3.5); see [email reverse DNS checks](/learning/email-reverse-dns-check) for the lookup process.

### Does missing reverse DNS send my email to spam?

Missing reverse DNS does not send mail to spam on its own, but it does raise the risk. Microsoft says some email servers may flag messages as spam or reject them when the sending IP has no PTR record, and Google requires valid forward and reverse DNS from all senders. Neither says missing reverse DNS is by itself the reason a message lands in spam.

### Why would someone use a reverse email lookup?

People use a reverse email lookup to find out what information is associated with an email address, usually to work out who an unfamiliar sender is. That is a different job from reverse DNS, which maps an IP address to a hostname and tells you nothing about a mailbox.

### Which DNS records are commonly used to stop email spoofing and spam?

SPF, DKIM, and DMARC are the DNS-based email authentication controls commonly used for spoofing resistance. Reverse DNS is a connection identity signal, not an authentication record, and [RFC 8601 advises against treating `iprev` as authentication or security](https://datatracker.ietf.org/doc/html/rfc8601#section-3).

### How would I see whether a receiver failed my reverse DNS?

Inspect the delivered message's `Authentication-Results` header for an `iprev` result such as `pass`, `fail`, `temperror`, or `permerror`. A missing `iprev` result does not prove the receiver ignored reverse DNS, because receivers decide which checks to record.