If you (or an audit tool, 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. This page explains each one, what is and isn't configurable, and what we actually want to see if you're having a real placement problem.
1. DNS is managed by Maildoso
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 Custom DNS, nameservers, and tracking domains (managed DNS) and How DNS records work for your Maildoso domains. If you need your website on the same domain, use a separate domain for cold email.
2. SPF includes point at a shared, rotating pool
Your domain's SPF record includes our relay domains, and those resolve to the shared pool of IPs your mail actually leaves from. Two things audits commonly flag:
"The IPs in your SPF don't match smtp.maildoso.com." Correct —
smtp.maildoso.comis the submission endpoint you connect to; delivery to recipients happens from the relay pool, which is what SPF covers. See My SPF/DKIM/DMARC lookup fails when I check it against smtp.maildoso.com."Some pool IPs are on a blocklist." The pool is shared and rotating; we monitor reputation and rotate listed IPs out of the sending path. A snapshot of one IP tells you little about your mail — check your domain, not an IP. See One of my sending IPs shows as blacklisted.
3. DKIM is signed with our own selector
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". Use a tool that scans all selectors, such as the easydmarc DKIM detector with "detect all selectors" — see My DKIM or DMARC isn't detected by a third-party checker. The reliable proof is the DKIM-Signature header and an Authentication-Results: dkim=pass line on a message you sent to a Gmail address; if you're seeing dkim=fail or no signature on real messages, send us that header — that's a case we do investigate.
4. DMARC is managed
We publish and manage the DMARC record for your domain. Custom DMARC policies or your own reporting (rua/ruf) addresses aren't configurable per account 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.
5. No PTR / reverse DNS, no dedicated IP
We don't publish PTR records for the sending pool, and dedicated IPs aren't offered — this is by design for a rotating, centrally managed pool. It isn't a per-account setting that support can turn on. See A checker tool says my PTR or reverse DNS (rDNS) is failing and Can I get a dedicated sending IP for my mailboxes?. If a fixed IP with PTR is a hard requirement for you, tell us before scaling up so we can be honest about fit.
6. SURBL lists our relay domains (and possibly yours)
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.
7. Some headers are set by the relay
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?
What we can't change per account
PTR / reverse DNS, dedicated or fixed sending IPs, moving you to a different relay pool.
Custom DNS records, DMARC policy or rua addresses, your own DKIM key.
Per-account custom tracking domains (a global tracking domain is provided).
What actually decides your placement — and what to send us
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, 35% 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 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. 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.