MailBaby SPF Record: spf-c Include vs _mailbaby TXT Guide

MailBaby needs proof that a domain is allowed to send through your account before it will deliver mail from that domain at full reputation. There are two accepted forms of proof and they solve slightly different problems. The SPF include tells receiving servers that MailBaby’s IPs are legitimate senders for the domain; the _mailbaby TXT record tells MailBaby that the domain belongs to a specific account. Most hosting providers end up using both. This guide sets out what each record does, exactly what to publish, and how to confirm it resolved.

Short answer: Every domain that sends through MailBaby needs include:spf-c.mailbaby.net in its single v=spf1 TXT record, with the origin server’s IP still authorised, so recipients pass SPF. The _mailbaby.<domain> TXT record (v=1 user=mbXXXXX) additionally binds the domain to your account and is the right choice when SPF is managed by the customer, is near the ten-lookup limit, or the domain will be used with the REST API. Most providers publish both, and confirm each with dig +short TXT against a public resolver.

The SPF include method

The original and still most common approach is to add MailBaby’s SPF include to the domain’s existing record. A complete record for a domain hosted on a cPanel or DirectAdmin server looks like this:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf-c.mailbaby.net ip4:203.0.113.10 ~all"

Two details are non-negotiable. First, the include must be spf-c.mailbaby.net; the older relay.mailbaby.net includes still resolve but the spf-c name is the maintained one. Second, the sending server’s own IP must remain authorised, shown here as the ip4: mechanism. MailBaby checks that the origin server is permitted by the domain’s SPF before accepting the message into the clean pool, so a record that lists only the MailBaby include will score worse than one that also lists your server.

On cPanel, set the include once for every zone the server manages through WHM » Exim Configuration Manager » Basic Editor » SPF include hosts for all domains, or update a single domain with the API:

uapi --user=USER EmailAuth install_spf_records domain=example.com record='v=spf1 a mx include:spf-c.mailbaby.net ~all'

The a mechanism already covers the server IP when the domain’s A record points at it, so the explicit ip4: is only needed when the website is elsewhere, for example behind a CDN proxy.

The _mailbaby TXT method

Since 15 December 2025 MailBaby also accepts an ownership record that binds a domain to an account without touching SPF:

_mailbaby.example.com.  3600  IN  TXT  "v=1 user=mb12345"

Replace mb12345 with your SMTP username. This is the record to use when the customer’s SPF is managed elsewhere, when the domain is already near the ten-lookup limit, or when you want to authorise a domain for the REST API rather than for SMTP relay. It also stops a different MailBaby customer from sending as your domain, because only the account named in the record is trusted for it.

The TXT method does not replace SPF at the receiving end. Recipients still evaluate the domain’s SPF record, and if MailBaby’s IPs are not in it the result is softfail or fail. So for domains that send real mail, publish both records.

Choosing between them

Use the spf-c include on every domain that sends mail through the relay; it is required for recipients to pass SPF. Add the _mailbaby TXT record when:

• The domain’s DNS is hosted by the customer and you only want them to add one simple record.
• The SPF record already includes several third-party services and another include would exceed ten DNS lookups.
• You have multiple MailBaby accounts and need a domain tied to one specific account.
• The domain will be used with the REST API rather than SMTP.

Watch the lookup limit

SPF permits ten DNS-querying mechanisms per evaluation. include:spf-c.mailbaby.net costs at least one lookup, and a and mx cost one each. A record that already includes a marketing platform, a helpdesk and a CRM can tip over the limit, at which point the result is permerror and the message is treated as unauthenticated everywhere. Count before you add:

dig +short TXT example.com
dig +short TXT spf-c.mailbaby.net

Follow each nested include and add them up. If the total exceeds ten, move a rarely used service to a subdomain with its own record, or rely on the _mailbaby TXT record and keep the SPF include only for the domains that genuinely send through the relay.

Cloudflare and long records

Cloudflare stores TXT records verbatim and handles the 255-character string split for you, but the total record length still matters for some resolvers. cPanel 132 and later handles long TXT records in its own zones. If a domain’s record exceeds roughly 450 characters, shorten it before adding the include. The Cloudflare-specific steps, including DKIM and DMARC, are in our Cloudflare DNS guide.

Verify

Query from outside the server so you see what the world sees:

dig +short TXT example.com @1.1.1.1
dig +short TXT _mailbaby.example.com @1.1.1.1

The first should return a single v=spf1 string containing include:spf-c.mailbaby.net; the second should return "v=1 user=mb12345". Then send a test message and check the received headers for spf=pass with MailBaby’s sending IP listed as the client. In the InterServer portal, the domain should appear as verified within a few minutes of the TXT record propagating. The common pitfall is two SPF records on the same name: a customer adds a second v=spf1 string instead of editing the existing one, and every SPF check returns permerror. There must be exactly one.

MailBaby SPF record at a glance

Official documentation: RFC 7208 (SPF), RFC 5321 (SMTP), Linux man pages.

Related guides: Adding MailBaby SPF, DKIM and DMARC records in Cloudflare DNS · Fixing “classified as rSPAM” and other MailBaby rejections · MailBaby with Postfix on Ubuntu/Debian as an authenticated smarthost.

Frequently asked questions