DNS Setup

The MX and TXT records BurnerByte verifies before a domain can receive mail, plus SPF, DKIM and DMARC — with the exact matching rules the verifier applies.

What Gates What

Worth being precise about, because people spend evenings on records that gate nothing.

Record	Stops mail arriving?
MX	Yes. Must resolve, and its target must match your configured SMTP hostname exactly.
TXT	Yes. Must contain the domain's verification token.
SPF	No. Checked and shown on the domain page, but it gates nothing. A red SPF indicator does not stop a single message arriving.
DKIM, DMARC, PTR	No. These affect what you send, and how much of it lands.

Note

If your instance only receives — the common case for disposable inboxes — MX and TXT are the whole job. Route the handful of outbound messages (invites, password resets) through a relay that already has its reputation sorted, and none of SPF, DKIM, DMARC or PTR is your problem.

Required Records

MX Record

Points email delivery to your SMTP server:

text

test.example.com.  IN  MX  10  mail.yourserver.com.

The MX target must equal the API process's smtp.hostname (BB_SMTP_HOSTNAME) exactly — a case-insensitive comparison with the trailing dot stripped, and no suffix or subdomain fallback. mail.yourserver.com in DNS against a smtp.hostname of yourserver.com, or against the localhost default, will never verify. Note it is the API that runs the check, not smtpd.

TXT Verification Record

BurnerByte generates a unique token for each domain:

text

test.example.com.  IN  TXT  "burnerbyte-verify=<your-token>"

The token is the domain's UUID, shown on the domain detail page. Matching is a substring test against every TXT record on the name, so the value may sit inside a longer record. Deleting and re-adding a domain mints a new token.

The Exact-Match Rule

The MX target is compared to BB_SMTP_HOSTNAME case-insensitively with the trailing dot stripped — and that is the entire comparison. No suffix match, no subdomain fallback.

An MX of mail.yourserver.com against a configured hostname of yourserver.com will never verify.
Neither will anything against whatever the variable falls back to when you do not set it. Running the binaries directly that is localhost; under Docker Compose it is mail.burnerbyte.local, from the fallback in docker-compose.yml. Both are values no real MX record points at, which is the point — but if you are checking with printenv, know which one you are expecting to see.

Careful

It is the API that runs the check, not the SMTP daemon. Setting BB_SMTP_HOSTNAME only on smtpd — which looks like the obvious place — leaves the API on its default, and then no domain can ever verify no matter how correct your DNS is. Set it on both.

Additional Records

SPF

SPF is checked on every verification pass and shown on the domain page, but it gates nothing — only MX and TXT decide the verified state. The check is satisfied only by a v=spf1 record that contains the configured smtp.hostname as a literal substring; a mechanism like mx that merely resolves to your host does not count:

text

test.example.com.  IN  TXT  "v=spf1 a:mail.yourserver.com mx -all"

A bare "v=spf1 mx -all" is perfectly valid SPF but leaves BurnerByte's SPF indicator red, because the hostname string is absent.

DKIM

If you sign outbound mail, publish the DKIM public key your signer generates:

text

<selector>._domainkey.test.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=<public-key>"

DMARC

Publish a DMARC policy so receivers know how to handle unauthenticated mail:

text

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

Note

BurnerByte verifies MX and TXT to receive mail. SPF, DKIM, and DMARC affect deliverability and how other servers treat mail from your domain; configure them on any domain that also sends.

Use a Subdomain

Pointing your apex domain's MX at a disposable-inbox platform routes every address at your organization there. Almost always you want a subdomain:

text

; Disposable inboxes live here, and only here.test.example.com.    IN  MX   10  mail.yourserver.com.test.example.com.    IN  TXT  "burnerbyte-verify=<token>" ; Real company mail is untouched.example.com.         IN  MX   10  aspmx.l.google.com.

Addresses then read [email protected], which is also clearer to whoever reads the bug report. Each subdomain is added and verified in BurnerByte as its own domain.

Careful

On Cloudflare DNS the proxy must be off — grey cloud — for the MX target and its A record. The orange cloud proxies HTTP and HTTPS only, so a proxied mail host resolves to an address that does not speak SMTP. Disable Cloudflare Email Routing on any domain BurnerByte handles; it adds its own MX records.

Verification

After adding DNS records:

Wait for DNS propagation (usually 5–30 minutes)
Click Re-verify DNS on the domain detail page
Or wait for the background DNS recheck worker (runs every hour)

Both MX and TXT records must be verified before the domain can receive emails.

Reverse DNS and Sending

If your instance sends as well as receives, the sending IP needs a PTR record resolving to the same hostname the A record points at. Receivers check it, and its absence is one of the strongest spam signals there is.

bash

dig +short -x 203.0.113.10mail.yourserver.com.

PTR is set by whoever owns the IP — your VPS provider's control panel, not your DNS provider. Residential connections cannot set one, which is why mail sent from home is rejected almost universally. Receiving is unaffected.

Testing

bash

# Check MXdig MX test.example.com # Check TXTdig TXT test.example.com # Send a test emailswaks --to [email protected] --server mail.yourserver.com:2525

Note

A failed DNS lookup — timeout, SERVFAIL, resolver outage — never downgrades an already-verified record: the previous value is kept when the lookup itself errored, so a transient blip cannot flip a domain to unverified. It also means a record you deleted stays green until a lookup succeeds and returns no match. The one exception is the automatic check right after adding a domain: it has no previous value, so a lookup error there records "not verified" and you should re-verify once DNS is answering.

When It Does Not Work

Domain Never Verifies and Emails Not Being Received walk through the checks in order.