DMARC, SPF and DKIM for mailbox.org

mailbox.org is a mail provider from the Heinlein group. It lets you send and receive mail for your own domain: Business customers add the domain in the Business console, private customers add addresses as an external alias. In both cases you publish SPF, DKIM and DMARC yourself at your DNS host. mailbox.org documents this in a knowledge base article (Business and Private versions), which this guide follows. For the background on each standard, see SPF explained, DKIM explained and DMARC explained.

What mailbox.org sends from

Mail you send as [email protected] leaves through mailbox.org's servers. The visible From address is your own domain.

Before mail flows, the domain must be verified. mailbox.org shows a security key that you publish as a TXT record, and then you point the MX records at its four inbound servers. As of November 2026 the documented MX records are:

example.com MX 10 mxext1.mailbox.org.
example.com MX 10 mxext2.mailbox.org.
example.com MX 10 mxext3.mailbox.org.
example.com MX 10 mxext4.mailbox.org.

The MX records only control inbound mail. They say nothing about which servers may send.

The knowledge base does not state which domain appears as the envelope sender (Return-Path) of outgoing mail. Its example bounce shows Gmail checking "SPF check for [example.com]", which is the customer's domain, and the SPF article says the include authorises mailbox.org servers "to send emails with senders of your domain". That fits mail sent with your own domain in the envelope, so SPF for your domain must list mailbox.org.

The docs also do not print a sample DKIM-Signature header. They do say the DKIM key "is stored in the DNS record of your domain", and the selectors live under _domainkey.example.com. A signature that verifies through those names carries d=example.com.

SPF

Publish one TXT record on the domain itself (host @ at most DNS hosts). As of November 2026 mailbox.org documents this value:

example.com TXT "v=spf1 include:mailbox.org ~all"

include:mailbox.org tells receivers to check mailbox.org's own SPF record as well. The docs explain it authorises "all email servers of mailbox" for your domain.

mailbox.org is explicit that a domain must have only one SPF record: "Multiple SPF entries are not allowed!" If other services also send for your domain, merge them into the same record. A typical setup with mailbox.org plus another service looks like this, where _spf.example.net stands for that other service's include:

example.com TXT "v=spf1 include:mailbox.org include:_spf.example.net ~all"

That record uses 2 DNS lookups itself. Each include then adds the lookups inside its own record. mailbox.org does not document a number for include:mailbox.org. When we counted it with real DNS on 6 November 2026, its record held IP ranges and one mx mechanism, so it cost 2 lookups in total (the include and the mx). mailbox.org can change that record, so check your own tree with the SPF lookup counter. RFC 7208 sets the limit at 10 lookups. Above that, receivers return a permanent error and SPF fails (see too many SPF lookups).

The documented record ends in ~all (softfail). That is fine with DMARC: DMARC decides what happens to failing mail, not the all term.

DKIM

mailbox.org signs outgoing mail and hosts the keys. You point four names in your zone at them. The knowledge base does not describe a switch in the console for DKIM; the setup it documents is the DNS records alone.

As of November 2026 the documented records are four CNAMEs, one per key:

MBO0001._domainkey.example.com CNAME MBO0001._domainkey.mailbox.org.
MBO0002._domainkey.example.com CNAME MBO0002._domainkey.mailbox.org.
MBO0003._domainkey.example.com CNAME MBO0003._domainkey.mailbox.org.
MBO0004._domainkey.example.com CNAME MBO0004._domainkey.mailbox.org.

Steps, based on the docs:

• Open the DNS settings at your domain host.
• Create a record of type CNAME.
• As host name, enter MBO0001._domainkey.example.com. The docs show this full form and note that field names vary between providers. Many DNS hosts expect only the part before your domain and add the domain themselves.
• As target, enter MBO0001._domainkey.mailbox.org.. Some hosts need the trailing dot, others add it for you.
• Repeat for MBO0002, MBO0003 and MBO0004.

The selectors are written in capitals in the docs. DNS names are not case sensitive, so either spelling resolves.

mailbox.org does not state the key length; its troubleshooting example shows an RSA key (k=rsa). The keys are hosted by mailbox.org, and the docs describe no way to choose them.

Before 2021 mailbox.org recommended TXT records that held a copy of the key. Those still work, but if mailbox.org changes its keys, a copied TXT record goes stale and your mail starts to fail DKIM. To switch, the docs say to delete the TXT record first and then add the CNAME.

DMARC alignment

DMARC passes when SPF or DKIM passes and the authenticated domain aligns with the From domain.

• SPF alignment compares the RFC5321.MailFrom (Return-Path) domain with the From domain. The docs do not name the Return-Path domain. Their bounce example shows SPF checked for the customer's domain, which suggests that SPF passes and aligns when the include covers the sending server.
• DKIM alignment compares the d= domain with the From domain. With the four CNAMEs in place, the keys sit under example.com, so a valid signature through them carries d=example.com and aligns.

Relaxed alignment, the default, only needs the same organisational domain, so news.example.com aligns with example.com. Strict alignment needs the exact same name. DKIM through the CNAMEs gives an exact match, so it works in both modes. SPF very likely does too, but the docs do not confirm the envelope domain.

Without the DKIM CNAMEs, alignment rests on SPF alone. SPF breaks on forwarding, as mailbox.org's own overview of mail servers points out. The overview adds that DKIM or ARC "can compensate for this in some cases but not reliably in all situations". DKIM often survives forwarding, so publish both.

Step by step to p=reject

1. Publish SPF. Add one TXT record on example.com with include:mailbox.org, merged with the includes of every other service that sends as your domain. Keep the record at 10 DNS lookups or fewer in total.
2. Publish the DKIM CNAMEs. As of November 2026, add all four records from MBO0001._domainkey to MBO0004._domainkey, each pointing at the same name under mailbox.org. Remove any old DKIM TXT records for those names first.
3. Start DMARC at p=none with reports. Publish a TXT record at _dmarc.example.com with v=DMARC1; p=none; rua=mailto:[email protected]. This policy does not protect the domain yet; it only turns on aggregate reports.
4. Read the reports and fix other senders. For two to four weeks, look at which servers send as your domain. Give every legitimate service SPF and, where it offers it, DKIM for your domain, so that its mail aligns too.
5. Move to quarantine. Change the policy to p=quarantine once reports show only aligned mail from your own services. Failing mail is now usually placed in spam, so a sender you missed is still recoverable.
6. Reject. Change the policy to p=reject when the reports stay clean. Receivers then refuse mail that fails DMARC.

The record for step 3:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

The final record:

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

mailbox.org's own example uses p=none. As of November 2026 it suggests a TTL of 400 seconds for the DMARC record. A short TTL also means that later policy changes reach receivers sooner; that is our reading, not a reason mailbox.org gives. The docs also warn against starting with quarantine or reject.

Common mistakes

• Two SPF records. mailbox.org says multiple SPF entries are not allowed. Receivers return a permanent error when they find more than one (multiple SPF records).
• Only one or two DKIM CNAMEs. As of November 2026 the docs ask for all four keys. If a selector mailbox.org signs with is missing, those messages fail DKIM (DKIM not found).
• An old DKIM TXT record. A TXT record copied before 2021 does not follow key changes. A name cannot hold a CNAME and a TXT record at the same time, so delete the TXT record before you add the CNAME.
• The full domain typed twice. Many DNS hosts append the domain. Entering MBO0001._domainkey.example.com there creates MBO0001._domainkey.example.com.example.com. Check the result with a lookup.
• No rua address. mailbox.org recommends always setting rua. Its stated reason is that "some receiving email servers reject messages if the optional rua parameter is missing", which it calls behaviour that does not follow the RFC. Without rua you also get no reports and cannot see other senders (DMARC without rua).
• Relying on a test flag. Some receivers support a test flag: t=y in RFC 9989 (DMARCbis), which obsoletes RFC 7489, or pct in RFC 7489. Neither is a safety net. RFC 7489 says unknown tags must be ignored, so a receiver that implements only RFC 7489 can treat p=reject; t=y as a full reject, and receivers that follow RFC 9989 no longer use pct. Move from p=none to p=quarantine to p=reject and let the reports decide each step.
• Setting ruf. mailbox.org advises against ruf failure reports because they can contain mail that was not meant for you.

How to check it

Run the email security check on your domain. It reads SPF, DKIM and DMARC in one pass. Use the SPF lookup counter to count every lookup behind include:mailbox.org and your other includes. In the DKIM selector finder, look for the selectors documented as of November 2026: MBO0001, MBO0002, MBO0003 and MBO0004; each should resolve through the CNAME to a key. Build or check your policy with the DMARC record generator.

Sources

• SPF, DKIM, and DMARC - How to improve spam reputation and avoid bounces (Business), mailbox.org documentation, fetched 2026-11-05.
• How to improve spam reputation and avoid delivery errors (Private), mailbox.org documentation, fetched 2026-11-05.
• Using your custom domain with mailbox Business, mailbox.org documentation, fetched 2026-11-05.
• Setting up email addresses with a custom domain, mailbox.org documentation, fetched 2026-11-05.
• Overview about mail servers, mailbox.org documentation, fetched 2026-11-05.
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), RFC Editor, fetched 2026-11-06.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC), RFC Editor, fetched 2026-11-06.