Some sequencers, deliverability checkers and AI-based audit tools will flag PTR or reverse DNS (rDNS) as "failing" or "missing" for the servers your mailboxes send from. Sometimes this shows up as "none.non" entries or forward-confirmed reverse DNS (FCrDNS) errors. On its own, this warning doesn't mean your setup is broken, and it isn't something you can (or need to) change. Here's why, and what to do if you are also seeing real placement problems.
Why this happens
We don't publish PTR (reverse DNS) records for our sending IPs. This is a deliberate part of how our sending infrastructure is built, not an oversight or a configuration error. Our sending IP addresses also rotate frequently as part of how we manage sender reputation, so the specific IP behind any one of your mailboxes changes often rather than staying fixed. Reverse DNS and PTR records are tied to fixed IPs, so on a rotating pool they will naturally appear missing or unresolved. See One of my sending IPs shows as blacklisted for the same pattern with blacklist checkers. Because a checker tool inspects a single IP at a single moment, and that IP may already have rotated again by the time you look it up, it will reliably report a PTR "fail" or "missing". That's expected given how the infrastructure works.
PTR records, dedicated IPs and custom DNS settings can't be configured per account: sending runs on a centrally managed, shared, rotating pool. If a fixed IP with its own PTR is a hard requirement for your use case, tell us before you scale up so we can be straight about whether Maildoso fits.
If you're also being asked (for example by a deliverability audit) about List-Unsubscribe headers, the same "managed, not configurable" answer applies. See Does Maildoso support List-Unsubscribe (one-click unsubscribe) headers?
What actually matters for deliverability
SPF, DKIM, and DMARC: inbox providers like Gmail, Outlook and Yahoo authenticate mail through SPF, DKIM and DMARC alignment, not reverse DNS. Our sending infrastructure is built around those signals, and we manage these records for your Maildoso domains automatically. rDNS is an older heuristic that modern providers largely don't use as a filtering signal.
Sending reputation and engagement: consistent warmup (see How warmup works and how to start it) and sensible daily volume matter far more than a static reverse DNS entry.
For modern cold email, a fixed PTR/rDNS record is not required for inbox placement. Our internal testing has confirmed that PTR records are not a critical factor for inbox placement.
If a tool also flags DKIM or DMARC
We run our own SMTP infrastructure, handling 80M+ emails per day, so our DKIM and DMARC setup is custom-built for our servers rather than based on standard templates. This is why some audit tools flag them as generic or missing even though both are working correctly. You can verify your records directly on MXToolbox or EasyDMARC. For more detail, see My DKIM or DMARC isn't detected by a third-party checker.
A note on AI-based audits
AI audit tools are trained on older data and standard configurations. At the scale we operate, many of our infrastructure decisions look unconventional to those tools but are correct for high-volume cold email sending. If an AI audit lists missing PTR/rDNS, FCrDNS failures or "generic" DKIM/DMARC as problems, that's the expected result for our setup, not a sign that something is misconfigured.
What you should do
A standalone PTR/rDNS warning from a third-party checker or AI audit doesn't need action: there's nothing to fix on your side.
Keep your warmup running at the recommended volume and your sending volumes reasonable.
Make sure your authentication (SPF, DKIM, DMARC) is passing. For Maildoso-managed domains it already is.
If you are seeing real placement problems
A PTR warning next to an actual problem, such as a measured spam rate on your own sends, bounces, or a drop in replies, is a different situation, and we'd rather look at it than tell you to ignore it. Send us your account email, the affected domains or mailboxes, one full message header (or your placement-test result), and your current warmup settings. The most common real cause we find is warmup volume that's too low or too new, not PTR. You can also book a Deliverability Audit with one of our specialists: log in, click the Deliverability Audit button in the top-right of your dashboard, and pick a time.