MailBaby SPF, DKIM and DMARC setup, step by step

To authenticate mail relayed through MailBaby, add include:spf-c.mailbaby.net to the appropriate existing SPF policy, authorize the originating server using its IP address or MailBaby's _mailbaby TXT method, and sign your domain's mail before it reaches the relay. MailBaby preserves upstream DKIM signatures and adds its own transport-domain signature. That extra signature does not, by itself, authenticate your visible From domain for DMARC. MailBaby SPF, MailBaby DKIM FAQ

This guide covers MailBaby's outbound SMTP smart host, with cPanel/Exim as the concrete upstream signer. It is not a mailbox migration, a MailBaby customer-domain DKIM dashboard tutorial, or a complete API, WordPress or other-MTA configuration guide. Keep the intended From address unchanged while validating this route.

No customer account, DNS configuration or delivered message was tested for this article. The checks below are an implementation plan, not reported results.

What each authentication layer does

SPF normally authenticates the SMTP MAIL FROM domain, commonly reflected in the received Return-Path. A null reverse-path uses the HELO identity for SPF. Neither a login username nor a visible From address is automatically the SPF identity. DKIM uses d= for its signing domain and s= for its selector. DMARC evaluates authentication and alignment together; a signature from an unrelated domain can pass DKIM without satisfying DMARC. SPF standard, DMARC alignment

Before changing DNS

Have an active MailBaby account, its SMTP credentials, an authorized server administrator and access to the authoritative DNS provider. cPanel's Email Deliverability interface must be enabled by the hosting provider. Generating a key in cPanel requires different access from changing Exim's server-wide transport configuration. MailBaby's reviewed documentation specifies no separate branded-DKIM plan tier because customer-domain signing happens upstream.

Record the following before making a change:

• The exact visible From address and its domain, for example billing@example.com.
• The actual MAIL FROM domain configured by the application or mail server. Do not assume it equals example.com.
• The origin IP that connects to MailBaby, including any outbound NAT translation.
• The authoritative zone containing each required owner name. The registrar is not necessarily the DNS host.
• Existing SPF mechanisms, DKIM selectors, DMARC policies, inherited policy and report recipients, plus the services that depend on them.
• Current routing and signing configuration, with a secure rollback copy. Keep passwords and private keys out of DNS, screenshots and support tickets.

Do not replace MX records to use this outbound relay. Existing mailbox delivery, web hosting and unrelated verification records should remain intact. MailBaby does not provide smart-host installation services; its FAQ directs server configuration to a qualified administrator and warns against sending server login details in tickets. MailBaby FAQ, cPanel prerequisites

1. Configure SPF and choose an origin-authorization method

MailBaby's current SPF instructions use:

include:spf-c.mailbaby.net

Merge that mechanism into the one SPF TXT policy at the domain actually being evaluated. SPF does not inherit from the root domain to a child domain. If the SMTP envelope uses bounce.example.com, inspect that name rather than assuming an SPF update at example.com covers it. Also confirm which sending-domain authorization MailBaby expects for your submission route.

MailBaby requires two related checks: its outbound delivery infrastructure must be authorized, and the server submitting to MailBaby must be authorized. Its current documentation provides two origin-authorization options. Choose the one that matches your controlled setup. Current MailBaby SPF procedure

Option A: retain or add the actual origin IP in SPF

For a new policy used only by this example route, the structure could be:

example.com. IN TXT "v=spf1 ip4:192.0.2.25 include:spf-c.mailbaby.net ~all"

example.com and 192.0.2.25 are documentation examples, not your values. Use the real connecting origin IP. Do not copy a private address or an address merely because it appears in a hosting dashboard. Retain all other legitimate senders in an existing policy, and preserve its deliberate final qualifier rather than automatically replacing it with ~all.

This IP authorizes the submission origin for MailBaby's checks; the recipient normally sees a MailBaby delivery IP. If your server also delivers directly on another route, its SPF authorization may be required independently of this relay.

Option B: use MailBaby's SMTP authorization TXT record

MailBaby documents this alternative to adding the origin IP:

_mailbaby.example.com. IN TXT "v=1 user=YOUR_ACTUAL_MAILBABY_USERNAME"

Replace the placeholder with the actual MailBaby username for the domain. For an example.com zone, the relative owner is _mailbaby; for news.example.com managed within the parent zone, it is _mailbaby.news. In a separately authoritative news.example.com zone, the relative owner is _mailbaby. Confirm that the DNS editor does not append the zone name twice.

You still need the MailBaby SPF include. For an otherwise unused, MailBaby-only envelope domain, the SPF value can have this structure:

v=spf1 include:spf-c.mailbaby.net ~all

Do not delete an existing origin IP simply because this method makes it unnecessary for MailBaby. First check whether another legitimate direct-delivery route still needs it. The _mailbaby value is a public authorization record, not a place for the SMTP password.

The separate API authorization name is _mb, with a different value format. It is not interchangeable with _mailbaby. Follow the API authorization guide if the application uses the API rather than this SMTP workflow.

Preserve the SPF budget and existing senders

Do not publish a second v=spf1 TXT record at the same owner. Merge deliberately, keeping necessary mechanisms before the final all. Avoid adding a or mx merely because a sample contains them; those mechanisms authorize infrastructure and consume lookups whether or not that infrastructure is appropriate for sending.

Evaluate the complete SPF tree for the actual envelope domain. The limit is 10 DNS-query-causing terms during evaluation, including nested include and redirect processing, not 10 top-level includes. a, mx, ptr and exists also count; ip4, ip6 and all do not. Exceeding the limit produces permerror. Also check invalid syntax, duplicate SPF records and excessive empty DNS lookups. RFC 7208, lookup limits

MailBaby says existing users of its older relay.mailbaby.net SPF style need not switch solely because the newer form is documented. Do not confuse the FAQ's _spf-c.mailbaby.net IP-inventory reference with the current instructed include:spf-c.mailbaby.net token.

2. Publish the upstream cPanel DKIM public key

Open cPanel → Email → Email Deliverability, then choose Manage for the actual sending domain. Do not stop at WHM's server-hostname deliverability check: that can validate a different identity from your visible sender domain.

1. Inspect the domain's DKIM section. Use Generate Local DKIM Key only if a key does not already exist.
2. Copy the Name and Value from Suggested “DKIM” (TXT) Record. Copy the public record, not the private key.
3. Publish that TXT record at the authoritative DNS provider. If cPanel does not control public DNS, a local installation or repair alone is insufficient.
4. Preserve other selectors. If the exact owner already contains a different active key or alias, investigate the existing signer before replacing it.
5. Check the returned public key against cPanel's intended key and selector.

cPanel offers Full and Split presentations for DNS providers with different TXT-entry interfaces. Multiple quoted character strings can belong to one TXT resource record and are concatenated without adding spaces. Do not turn the pieces into separate DKIM records, insert line-break text into the key or copy typographic quotation marks. cPanel DKIM procedure

The usual owner pattern is:

SELECTOR._domainkey.SIGNING_DOMAIN

Use the actual selector and signing domain, not the capitals above. For cPanel's documented default selector and d=example.com, the lookup is default._domainkey.example.com. Publishing a key at the server hostname will not validate a signature whose d= is example.com.

For a signing domain of news.example.com, suppose the actual issued selector is represented by issued-selector. The full owner is issued-selector._domainkey.news.example.com. In an editor that appends the example.com zone suffix, enter issued-selector._domainkey.news; in a separately authoritative news.example.com zone, enter issued-selector._domainkey. If the editor expects a full name, use the complete owner instead. Replace issued-selector with the actual selector supplied by the signer, use its matching public key, and verify the final full DNS name before saving.

3. Ensure the MailBaby transport actually signs

A valid public key does not cause a relay transport to sign automatically. In MailBaby's cPanel/Exim instructions, the administrator configures authentication, routing and the SMTP transport in WHM → Service Configuration → Exim Configuration Manager → Advanced Editor. Use the version-specific official configuration and merge it with existing server behavior rather than pasting a global replacement.

The published transport connects the signer to cPanel's domain selection and private key. These are the relevant signing fields to inspect, not a complete transport to install:

dkim_domain = ${perl{get_dkim_domain}}
dkim_selector = default
dkim_private_key = "/var/cpanel/domain_keys/private/${dkim_domain}"

The selected domain, public TXT owner and private key must agree. Keep the private key on the authorized signer with appropriate access controls; never publish its contents. Preserve the documented X-AuthUser header. Verify that the intended outbound messages actually take the mailbaby_smtp route, rather than a bypass, and that the signing settings remain present after a configuration rebuild. A route check alone still does not prove a delivered DKIM pass. MailBaby cPanel/Exim procedure

Use relay.mailbaby.net with the account's credentials. MailBaby documents STARTTLS on ports 25, 587 and 2500, or implicit TLS on 465. Match the port to the TLS mode. Do not weaken encryption to work around a blocked port or copy cleartext-fallback settings from a broader configuration example. Optional server-wide allowlists, spam controls and routing changes are not authentication prerequisites to apply indiscriminately. Getting started with MailBaby

MailBaby's own transport DKIM signature remains even when your upstream signature is present. A “via” label disappearing is not the acceptance test; inspect the intended branded signature. Transport signing

4. Preserve the applicable DMARC policy

DMARC uses the visible From domain. Before adding a record, inspect _dmarc at that domain and the applicable parent/organizational policy under DMARC discovery. Preserve existing enforcement, alignment settings and approved report destinations. Do not replace p=reject or p=quarantine with p=none just to make onboarding appear easier, and do not create a child policy that silently overrides inherited protection.

Only when no direct or inherited policy applies, and the domain owner approves an initial non-enforcing policy, a minimal first record for the example author domain is:

_dmarc.example.com. IN TXT "v=DMARC1; p=none"

In an editor that appends the example.com zone suffix, the full owner _dmarc.example.com is entered as _dmarc. For an author domain of news.example.com, the full owner is _dmarc.news.example.com: enter _dmarc.news in the parent example.com zone, or _dmarc in a separately authoritative news.example.com zone. Use the complete owner instead if the editor expects a full name, and make the change only at the responsible authority. These owner mappings do not authorize overriding an existing direct or inherited policy.

This does not request aggregate reports because it has no rua. If reports are wanted, use the owner's approved collection destination. External destinations whose organizational domain differs require the report receiver's DNS authorization. Review access, retention and privacy before sharing aggregate source-IP and domain data; do not paste an arbitrary example reporting address. DMARC policy, External report authorization

Under relaxed alignment, authenticated subdomains can align when they share the same Organizational Domain. Strict adkim=s or aspf=s requires exact domain equality for that mechanism. Keep the intended From address and existing policy, then fix the authorized signing or envelope configuration as appropriate. A generic DMARC pass is insufficient evidence that a newly configured branded DKIM signature works.

5. Validate public DNS and an actual delivered message

First check DNS

Replace the example names with your actual identities. These are read-only diagnostic examples, not recorded outputs:

dig example.com NS
dig example.com TXT
dig _mailbaby.example.com TXT
dig default._domainkey.example.com TXT
dig _dmarc.example.com TXT

Query the real MAIL FROM owner if it differs from the example. Query _mailbaby only for that selected authorization method. Check the authoritative answers as well as a recursive resolver, retaining timestamps, TTLs and response status. An empty short answer is not enough to distinguish absence from a timeout or DNS error. Wrong-zone changes and cached negative answers require diagnosis, not repeated record additions.

Expected observations are one applicable SPF policy with the intended authorizations, the correct public DKIM key at the exact selector owner, the selected origin-authorization method and the deliberately retained DMARC policy. A DNS lookup cannot prove that Exim has used the matching private key.

Then check the sending route

With authorization to test, send a fresh message through the same application, server and MailBaby route used in production. Deliver it directly to a mailbox you control or trust before investigating forwarding. Save the raw message and relevant trace securely.

Use Authentication-Results from the trusted receiving infrastructure, which must remove or distinguish forged upstream results. An attacker can prepend a field claiming dkim=pass; a familiar authserv-id string alone is not proof. If the receiver's trust boundary is unclear, use an independent trusted mailbox or receiver trace. Authentication-Results trust

Accept this branded-signing setup only when:

• The visible From is the intended, unchanged address.
• The intended upstream customer-domain signature passes, its d= aligns with From under the effective policy, and its s= selects the published key.
• DMARC passes at the trusted receiver.
• The actual envelope identity and SPF result are recorded. Investigate fail, softfail, temperror and permerror independently, even if DKIM makes DMARC pass.
• The message demonstrably used MailBaby, and other legitimate senders still work after shared SPF changes.

An unrelated provider envelope can pass SPF without aligning; adding an include to your From domain does not change that envelope. Resolve the actual route rather than inventing a MailBaby custom Return-Path control. Authentication also does not guarantee inbox placement. If a Microsoft 365 recipient's delivery decision differs from the authentication result, see EmailAuth's guide to inbound DMARC handling and receiver decisions.

Troubleshooting MailBaby authentication

MailBaby requires SRS for supported forwarding and filters that traffic more strictly. Test forwarding separately from original mail: a rewritten SRS envelope can pass SPF without aligning with the original author's From domain. MailBaby FAQ