SPF, DKIM & DMARC for mailbox.org.
mailbox.org — the privacy-focused German mail provider run by Heinlein Support — authenticates a custom domain with three ingredients you publish at your DNS host: one shared SPF include (include:mailbox.org), four DKIM CNAME records that delegate mailbox.org's signing keys back to it, and a DMARC policy record you add yourself. There is no per-account key generation and no wizard that writes DNS for you: mailbox.org uses a fixed set of shared DKIM selectors (MBO0001 through MBO0004), so every custom-domain customer publishes the same four CNAMEs. Because mailbox.org sends your outbound mail from its own smart hosts using your address as the envelope sender, once these records are live both SPF and DKIM align to your domain, DMARC passes on either mechanism, and mail leaves fully authenticated as you instead of as mailbox.org.
Why authenticate mailbox.org?
Authenticating your mailbox.org domain is what decides whether your mail reaches the inbox. Since February 2024, Gmail and Yahoo require every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft began enforcing the same on high-volume mail into Outlook.com/Hotmail in 2025 — but even for a small business or personal domain, unauthenticated mail is the fastest route to the spam folder. mailbox.org is a real mailbox host rather than a bulk ESP, yet the mechanics are the same: it signs your outbound custom-domain mail as d=yourdomain.com using the MBO selectors, and a receiving server verifies that signature by looking up MBO0001._domainkey.yourdomain.com. If you haven't published the four CNAMEs, that lookup fails, DKIM never verifies for your domain, and DMARC has nothing aligned to lean on. Publishing SPF, the DKIM CNAMEs, and DMARC closes that gap — both mechanisms align to your domain, mail passes DMARC even after forwarding, and the sending reputation you build accrues to your own domain rather than being pooled with unauthenticated senders.
The SPF reality for mailbox.org
mailbox.org is a genuine "include" provider: you add one shared mechanism, include:mailbox.org, to the single SPF TXT record on your root domain — the full record is v=spf1 include:mailbox.org ~all. This is a real shared include that every mailbox.org customer uses, unlike the CNAME-delegation model of bulk ESPs. It matters more here than for a Return-Path-owning ESP because mailbox.org sends with an envelope sender on your own domain, so SPF actually ALIGNS to your organizational domain and contributes a DMARC pass on its own (not just DKIM). One provider-specific detail worth knowing: include:mailbox.org costs roughly TWO of your 10 SPF DNS lookups, not one. The shared record it resolves to is v=spf1 ip4:213.203.238.0/25 ip4:195.10.208.0/24 ip4:91.198.250.0/24 ip4:80.241.56.0/21 ip6:2001:67c:2050::/48 mx ~all — the include itself is one lookup, and the nested mx mechanism inside that record is a second. That's still cheap, but factor it into your budget if you already stack Google Workspace, a marketing tool, or a transactional relay. mailbox.org recommends ending with ~all (softfail), which is what its own record uses; only tighten to -all once you're certain every sender is listed. And keep exactly one SPF TXT record on the domain — if you send from other providers too, merge each mechanism into that single v=spf1 line rather than publishing a second SPF record (two SPF records is a PermError).
Step by step
- 1
Confirm your plan supports a custom domain
Sending from a custom domain requires a paid tier — an individual Standard or Premium account, or a sub-account on a Family plan. The free-tier Lite plan cannot send from a custom domain, so upgrade first if needed.
- 2
Add and verify the domain
Log in to the webmail, click the gear icon (top right) → Settings / All settings → Email addresses, and register your custom domain there. mailbox.org walks you through proving ownership and shows the DNS records it expects. The four DKIM selectors (MBO0001–MBO0004) are mailbox.org's fixed shared keys and are documented in its knowledge base (kb.mailbox.org) — there's no per-account key to generate.
- 3
Point MX to mailbox.org (receiving)
So inbound mail is delivered to your mailbox, remove any existing MX records from a previous provider, then add mailbox.org's custom-domain hosts: mxext1.mailbox.org, mxext2.mailbox.org, and mxext3.mailbox.org (some setups also list mxext4), all at priority 10. MX is about receiving, not authentication, but it's part of the same setup — and leaving stale MX records in place splits your inbound mail.
- 4
Publish the SPF record
Add one TXT record on the root domain (host @ or blank) with v=spf1 include:mailbox.org ~all. If a v=spf1 record already exists for another sender, merge include:mailbox.org into that single record — never add a second SPF TXT. Keep the ~all (softfail) qualifier that mailbox.org recommends.
- 5
Add the four DKIM CNAMEs
Create four CNAME records so mailbox.org's signatures verify on your domain: host MBO0001._domainkey → target MBO0001._domainkey.mailbox.org, and the same pattern for MBO0002, MBO0003, and MBO0004. Publish all four — MBO0001/MBO0002 carry RSA keys and MBO0003/MBO0004 carry Ed25519 keys, and mailbox.org may sign with either algorithm. Keep the type as CNAME (mailbox.org's recommended method); don't switch to A or TXT.
- 6
Add the DMARC record — with an rua
mailbox.org doesn't create DMARC for you. Add a TXT record at host _dmarc with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Start at p=none (monitor-only) so nothing is affected while you confirm alignment. Always include the rua tag: mailbox.org's own guidance warns that some receivers reject mail when the DMARC record has no reporting address, even though that behavior isn't RFC-compliant.
- 7
Grey-cloud the CNAMEs and avoid host doubling
If your DNS is behind Cloudflare, set each DKIM CNAME to 'DNS only' (grey cloud) — an orange-cloud proxied CNAME won't resolve to the mailbox.org host and DKIM verification fails. Many registrars also auto-append your domain, so enter just the label (MBO0001._domainkey, not MBO0001._domainkey.yourdomain.com) to avoid doubling it.
- 8
Send a test and read the headers
After propagation (usually minutes, up to 48 hours), send a message from your mailbox.org custom-domain address to a Gmail account, open it, and choose ⋮ → Show original. You want SPF: PASS, DKIM: PASS with d=yourdomain.com and one of the MBO selectors, and DMARC: PASS — all aligned to your domain. Then run the domain through a health check to confirm every record resolves.
Records to add
mailbox.org generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| TXT | @ | v=spf1 include:mailbox.org ~allRoot SPF — keep exactly one SPF record and merge other senders into this line. Costs ~2 DNS lookups (the include plus a nested mx inside mailbox.org's shared record). |
| CNAME | MBO0001._domainkey | MBO0001._domainkey.mailbox.orgDKIM selector 1 (RSA). Fixed shared value — the same for every mailbox.org custom-domain customer. |
| CNAME | MBO0002._domainkey | MBO0002._domainkey.mailbox.orgDKIM selector 2 (RSA). Publish alongside MBO0001. |
| CNAME | MBO0003._domainkey | MBO0003._domainkey.mailbox.orgDKIM selector 3 (Ed25519). Modern algorithm key — publish it too so Ed25519-signed mail verifies. |
| CNAME | MBO0004._domainkey | MBO0004._domainkey.mailbox.orgDKIM selector 4 (Ed25519). Fourth of the four fixed selectors; CNAME delegation lets mailbox.org rotate keys without you touching DNS. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYou add this yourself — mailbox.org never creates it. One per domain; always include the rua tag; start at p=none, then tighten. |
| MX | @ | mxext1.mailbox.org (priority 10)Receiving, not authentication. Also add mxext2.mailbox.org and mxext3.mailbox.org (some setups list mxext4) at priority 10, and remove any old provider's MX first. |
Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.
The 10-lookup budget
SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what mailbox.org's setup costs against that budget.
mailbox.org adds 2 of your 10 lookups; ip4: and ip6: mechanisms are free.
DKIM
DKIM on mailbox.org works by CNAME delegation to a fixed set of four shared selectors — there is no key to generate or copy. You publish four CNAME records — MBO0001._domainkey, MBO0002._domainkey, MBO0003._domainkey, and MBO0004._domainkey — each pointing to the matching MBO000X._domainkey.mailbox.org host. Because they're CNAMEs rather than TXT records you paste, mailbox.org holds the private keys and can rotate the published public keys behind those selectors without you ever re-editing DNS. Two things make mailbox.org's setup distinctive. First, there are four selectors because mailbox.org publishes two key types: MBO0001 and MBO0002 carry RSA keys, while MBO0003 and MBO0004 carry modern Ed25519 keys. mailbox.org may sign with either algorithm, so you must publish all four — omitting the Ed25519 pair (or any one selector) causes intermittent DKIM failures whenever mail is signed with a key whose selector you didn't publish. Second, mailbox.org explicitly recommends the CNAME method over the legacy TXT approach: with CNAMEs, if mailbox.org needs to change its keys the delegation still resolves, whereas TXT records copied once become invalid the moment mailbox.org rotates. Publish all four CNAMEs exactly as shown (grey-cloud/DNS-only if on Cloudflare), and DKIM signs as d=yourdomain.com and aligns.
DMARC
DMARC is a separate policy TXT record you publish yourself — mailbox.org does not create it. Add a TXT record at _dmarc.yourdomain.com starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only: it changes nothing about delivery while you watch the aggregate (rua) reports to confirm mailbox.org mail is passing SPF and DKIM aligned to your domain. There's a mailbox.org-specific reason never to skip the rua tag: mailbox.org's own knowledge base warns that some receiving servers reject messages when the DMARC record has no rua address — behavior that doesn't actually comply with the DMARC RFC, but happens in the wild — so always include a reporting mailbox. Because mailbox.org aligns both mechanisms (SPF via your own envelope domain, DKIM via the MBO selectors), you should see clean passes quickly. Watch the reports for a week or two, make sure every legitimate sender is authenticating, then tighten to p=quarantine and eventually p=reject. Keep exactly one _dmarc record for the whole domain no matter how many senders you use — mailbox.org's own domain, for reference, runs p=reject.
Check it actually worked
Don't rely on mailbox.org's domain-setup screen alone — confirm authentication on a real message. Send a test from your custom-domain address to a Gmail account, open it, and choose ⋮ → Show original: you want SPF: PASS, DKIM: PASS showing d=yourdomain.com with one of the MBO000X selectors (not mailbox.org as the signing domain), and DMARC: PASS — all aligned to your domain. Prefer a full report? Send a test to check-auth@verifier.port25.com and it emails back a complete SPF/DKIM/DMARC breakdown. You can spot-check the raw records with dig TXT yourdomain.com, dig CNAME MBO0001._domainkey.yourdomain.com, and dig TXT _dmarc.yourdomain.com. Finally, run your domain through Qualisend's domain health check to confirm every record resolves and your SPF stays under the 10-lookup limit, and once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer — mailbox.org should appear as an aligned, passing source.
Common gotchas
- Coverage
A custom domain needs a paid plan. Only Standard and Premium individual accounts (or a sub-account on a Family plan) can send from a custom domain — the free Lite tier can't, so no amount of correct DNS will authenticate mail until you upgrade.
- DNS setup
Publish all four DKIM CNAMEs, not one. MBO0001/MBO0002 are RSA keys and MBO0003/MBO0004 are Ed25519 keys; mailbox.org may sign with either algorithm, so omitting a selector causes DKIM to fail intermittently whenever mail is signed with the key you left unpublished.
- Breaks auth
include:mailbox.org costs about two SPF lookups, not one. mailbox.org's shared SPF record ends with an mx mechanism (v=spf1 ip4:… ip6:… mx ~all), so the include is one lookup and the nested mx is a second — budget accordingly if you also stack Google Workspace, a marketing tool, or a relay under the 10-lookup limit.
- DNS setup
Use CNAME for DKIM, not TXT. mailbox.org recommends CNAME delegation so it can rotate keys transparently; the legacy TXT method breaks the moment mailbox.org changes a key, since your copied public key becomes stale.
- Coverage
Never omit the DMARC rua tag. mailbox.org's own guidance warns that some receivers reject mail when the DMARC record has no reporting address — a non-RFC behavior that still occurs — so always include rua=mailto:… even in monitoring mode.
- Coverage
Remove old MX records first. Before adding mxext1/mxext2/mxext3.mailbox.org (priority 10), delete any MX records left over from a previous provider, or inbound mail will split between the two systems.
- DNS setup
Grey-cloud the CNAMEs and don't double the host. On Cloudflare set each DKIM CNAME to 'DNS only' (an orange-cloud proxy breaks resolution), and enter just the label (MBO0001._domainkey) if your registrar auto-appends the domain — otherwise you get MBO0001._domainkey.yourdomain.com.yourdomain.com.
- Breaks auth
Keep exactly one SPF record and use ~all. If you send through other providers too, merge include:mailbox.org into the single v=spf1 line rather than publishing a second SPF TXT (two is a PermError), and keep the softfail ~all mailbox.org recommends.
Build your SPF record
mailbox.org is pre-selected below. Add any other platforms you send through, then publish the single merged record.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listmailbox.org SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.