If you (or an audit tool, a sequencer's check, or an AI-generated report) run a full check on a domain that sends through Maildoso, you'll see a few things that look wrong against a generic "self-hosted mail server" checklist but are how our infrastructure is designed. We run our own SMTP infrastructure, handling 80M+ emails per day, so our setup is custom-built rather than based on standard templates. This page explains each finding, how to verify things correctly, and what we want to see if you have a real placement problem.

Your sending domains are delegated to our nameservers, and we publish MX, SPF, DKIM and DMARC for you. You don't add or edit these records yourself, and DNS for a sending domain can't be moved to your own provider (for example Cloudflare) while it sends through Maildoso — see How DNS works on your Maildoso domains. If you need your website on the same domain, use a separate domain for cold email.

Your domain's SPF record includes our relay domains, and those resolve to the shared pool of IPs your mail actually leaves from. Because this is a custom SPF configuration, some third-party checkers (for example the test inside Instantly) misread it and show a softfail or "sender does not match SPF record" warning. In most cases you can safely ignore it — confirm with a standard lookup such as easydmarc.com SPF lookup; if it shows valid there, you're fine.

Outbound mail is DKIM-signed on our infrastructure using our own selector, published on the DNS we manage for your domain. Checkers that only look for a default selector (or ask you to type one) report DKIM as "missing", and some audit tools call our DKIM/DMARC "generic". This is expected, and our setup follows Google's guidelines. To confirm your records, use:

We publish and manage the DMARC record for your domain; custom DMARC policies or your own reporting (rua/ruf) addresses aren't configurable on managed DNS. A brand-new domain can have a short window where DMARC is live before DKIM has fully published — see Why was my email accepted but never delivered, with no bounce? if a new domain's mail is going nowhere.

The reliable proof is a real message, not a DNS lookup against a hostname:

If a real message from your mailbox shows spf=fail, dkim=fail or dmarc=fail, or has no DKIM signature, that's a genuine issue — send us the full message headers (or the mail-tester.com report link) and the mailbox involved, and we'll investigate the specific sending host. A missing DKIM signature together with an SPF softfail usually means your sequencer is sending through the wrong SMTP host — see DKIM selectors and a common Instantly misconfiguration.

Some sequencers, checkers and AI audit tools flag PTR or reverse DNS as failing or missing — sometimes as "none.non" entries or forward-confirmed reverse DNS (FCrDNS) errors. We don't publish PTR records for the sending pool, and dedicated IPs aren't offered: this is a deliberate part of how the infrastructure is built. Our sending IPs rotate frequently to manage reputation, and PTR records are tied to fixed IPs, so a checker inspecting one IP at one moment will reliably report a PTR "fail". It isn't a per-account setting that support can turn on.

It also doesn't matter for placement: Gmail, Outlook and Yahoo authenticate mail through SPF, DKIM and DMARC alignment, not reverse DNS, and our internal testing confirms PTR isn't a critical factor for inbox placement. A standalone PTR warning needs no action. 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 — see also Can I get a dedicated sending IP for my mailboxes?

URL-reputation lists such as SURBL and SpamRATS list domains, not IPs, and at our volume our infrastructure domains accumulate listings. They have no practical effect on inbox placement in 2026, and we don't file delisting requests for them. See SURBL Listings and Deliverability Impact.

Because mail is relayed through our infrastructure (and, if enabled, rotated across your domains), headers such as Return-Path, Message-ID and sequencer-added headers like List-Unsubscribe can be set by the relay rather than passed through unchanged, and the visible sender can be another of your domains. Rotation is an account setting we can switch off; the relay behaviour is not. See Why does the recipient see a different sender or domain? (mailbox rotation) and Does Maildoso support List-Unsubscribe headers?

AI audit tools are trained on older data and standard configurations. At our scale, many infrastructure decisions look unconventional to those tools but are correct for high-volume cold email. If an AI audit lists missing PTR/rDNS, FCrDNS failures, an SPF mismatch with smtp.maildoso.com or "generic" DKIM/DMARC as problems, that's the expected result for our setup, not a sign of misconfiguration.

In the cases we investigate, the real cause is almost always one of: warmup volume too low or too new (we recommend 80/day from day one, 45% reply rate, slow ramp-up off, 14 days before campaigns), campaign volume above 15/day per mailbox, list quality (unknown or catch-all addresses, high bounce rates), or message content. See What's the daily email limit per email account?

If you're seeing spam placement, rejections or a drop in replies, send us: your account email, the affected domains or mailboxes, one full message header from a real send (ideally to a Gmail address, showing the Authentication-Results line), your latest placement-test result, and your current warmup settings and start date. You can also book a free Deliverability audit with one of our specialists: log in, click Deliverability audit in the top bar of your dashboard, and pick a time. Please send the finding you're worried about rather than the whole automated report — most generic checks above don't apply to managed infrastructure, and we'd rather look at the one that matters.