DNS records explained
New domains require ownership proof, SPF, DKIM, DMARC and two MX records. The OpenPGP CNAME is optional. Older domains can have a different required set; follow the labels on your domain page.
Verify a sending domain is the setup walkthrough. This page explains the records behind it.
Where the records go
The domain you add and the sending subdomain are separate settings. For a domain added as mail.example.com with the default sending subdomain tix:
| Record | Full hostname |
|---|---|
| Ownership TXT | mail.example.com |
| SPF TXT and both MX records | tix.mail.example.com |
| DKIM TXT | The displayed selector followed by ._domainkey.mail.example.com |
| DMARC TXT | _dmarc.mail.example.com |
DNS providers can accept a full hostname or a name relative to the zone you are editing. In the example.com zone, tix.mail becomes tix.mail.example.com. In a delegated mail.example.com zone, tix creates the same name.
Check the resulting full hostname. Entering tix.mail.example.com into a field that appends example.com can create tix.mail.example.com.example.com instead.
Domain ownership
The ownership TXT value begins with epostix-verification=. Publish the exact value issued for your domain. It proves control before Epostix completes mail verification.
It belongs on the domain you added, independently of the sending subdomain. Existing TXT records can stay. After ownership is confirmed, this proof record can be removed; it is not part of ongoing mail-record health checks.
Choosing the sending subdomain
The label for SPF and bounce MX records defaults to tix. You can change it while the domain is unverified. Changing it reissues those records and restarts verification. The label is fixed after verification because mail already in flight can refer to it.
DKIM and DMARC stay under the domain you added. If you added mail.example.com, DMARC belongs at _dmarc.mail.example.com, even when the SPF and MX host is tix.mail.example.com.
Using the root domain instead
You can publish SPF and MX on the domain itself, but check what already uses that host:
- SPF: a hostname can have only one SPF policy. Merge the Epostix
include:into an existing policy rather than adding a second one. - MX: these records route incoming mail. Replacing the MX records used by your inbox provider can move that mail to Epostix.
A separate sending subdomain avoids those conflicts.
SPF (required on new domains)
SPF is a TXT policy authorizing servers to send using the envelope-sender domain. Publish the include: value shown by Epostix. SPF alone does not authenticate the visible From address; DMARC checks alignment with that address.
The generated policy ends in ~all, a soft fail for sources outside the policy. If you already have SPF at this host, keep one policy and review the combined configuration before changing it.
DKIM (required)
DKIM publishes a public key. Epostix signs messages with the matching private key, and receivers use the DNS key to check the signature and signed content.
The selector is the label before ._domainkey. Copy the full TXT value from the dashboard. It contains a long public key; one missing character can prevent verification.
DMARC (required on new domains)
DMARC connects SPF and DKIM authentication to the visible From domain. A message passes DMARC when SPF or DKIM passes with the required domain alignment. The policy tells receivers how the domain owner wants failures handled.
Epostix generates v=DMARC1; p=none;. This requests no rejection or quarantine based on DMARC. It does not configure aggregate reports by itself; reporting needs a rua destination.
Review all legitimate sending sources before moving to p=quarantine or p=reject. Do not replace an existing stricter policy without understanding its effect.
Bounce reporting (required on new domains)
The two MX records route mail at the configured host to Epostix, including asynchronous bounce reports. Publish both targets and the priority shown in the dashboard.
They sit at the same host as SPF. With the default sending subdomain, that is separate from the MX records your normal inboxes use. Using the root domain changes that separation.
OpenPGP key directory (optional)
The OpenPGP CNAME delegates the domain's key directory to Epostix. Publish the host and target shown on the domain page if you use that feature. It is not required for ordinary sending or domain verification.
Host and value formats by provider
Select your provider in the records panel to get its formatting. Always check which DNS zone the provider is editing.
| Provider | What to check |
|---|---|
| Cloudflare | Keep mail-related CNAME records DNS-only; TXT and MX are always DNS-only |
| Namecheap / GoDaddy | The zone name is appended to relative hosts |
| Squarespace | Enter the name relative to the DNS zone; paste TXT content as one value |
| AWS Route 53 | Use the full record name; TXT content uses quoted strings |
| Other | Check whether the provider appends the zone name and adds TXT quotes |
A trailing dot denotes an absolute DNS name in a zone file. Provider forms handle it differently, so use the expected format for MX and CNAME targets. TXT values are content, not hostnames: do not add a trailing dot to them.
Zone file downloads the mail records in BIND format. Ownership proof is a separate setup step when required.
Changing these later
Keep required mail records in place after verification. Epostix checks them every 24 hours. A failed required record starts a 72-hour repair window with hourly checks; unresolved failures stop sending when the window expires.
Restore the records and run a new check from the domain page. See verification.