KoltrixEvery DNS record a sending domain needs, in one table
A reference table of the DNS records a domain that sends email should have: MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI, with syntax for each.
On this page(13 sections)
Email authentication is spread across half a dozen DNS records with different names, formats and owners. This is the reference we wish we had the first time: every record a domain that sends email should have, what each one does, and the syntax to publish it.
The summary table
| Record | Name | Type | Purpose | Required? |
|---|---|---|---|---|
| MX | example.com |
MX | Where inbound mail for the domain goes | If you receive mail |
| SPF | example.com (and bounce subdomains) |
TXT | Which servers may use the domain as envelope sender | Yes |
| DKIM | <selector>._domainkey.example.com |
TXT or CNAME | Public key for verifying signatures | Yes |
| DMARC | _dmarc.example.com |
TXT | Policy and reporting for From-domain authentication | Yes for bulk senders, recommended for all |
| PTR | Reverse zone of each sending IP | PTR | Hostname of the sending IP | Yes, for IPs you operate |
| MTA-STS | _mta-sts.example.com + policy file |
TXT + HTTPS | Require TLS for inbound delivery | Recommended |
| TLS-RPT | _smtp._tls.example.com |
TXT | Reports on inbound TLS failures | Recommended |
| BIMI | default._bimi.example.com |
TXT | Logo for authenticated mail | Optional |
| Report authorization | <domain>._report._dmarc.<dest> |
TXT | Lets another domain receive your DMARC reports | When reports go to another domain |
The rest of this article goes through each one with syntax and the mistakes worth avoiding.
MX
example.com. MX 10 mx1.mailhost.example.
example.com. MX 20 mx2.mailhost.example.MX records route mail to your domain, so they matter for replies and bounces rather than for sending authentication. Lower preference numbers are tried first. Targets must be hostnames, not IP addresses. Use exactly the MX records your mailbox provider specifies. A domain that should never receive mail gets a null MX: MX 0 .
SPF
example.com. TXT "v=spf1 include:_spf.mailhost.example include:spf.sender.example ~all"SPF authorizes the IPs allowed to use a domain in the SMTP envelope sender (Return-Path). Key rules from RFC 7208:
- Exactly one record beginning with
v=spf1per name. - At most ten DNS-querying terms (
include,a,mx,ptr,exists,redirect) across the whole evaluation, and at most two lookups that return nothing. ip4,ip6andallcost no lookups.- End with
~allor-all, never+all.
If a sending provider uses a custom bounce domain such as bounce.example.com, that subdomain needs its own SPF record. A domain that never sends gets v=spf1 -all.
DKIM
k2026._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"
s1._domainkey.example.com. CNAME s1.dkim.provider.example.DKIM public keys live at <selector>._domainkey.<domain>. Each sending system uses its own selector. Notes:
- Use RSA keys of at least 2048 bits. They exceed 255 characters, so the TXT value is split into multiple strings within one record.
- Many providers ask for a CNAME pointing to a key they host, which lets them rotate keys without your involvement.
- Revoke a key by publishing an empty
p=value. - The
d=domain in signatures must align with your From domain for DMARC to benefit.
DMARC
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"DMARC ties SPF and DKIM to the visible From domain and tells receivers what to do with failures. Common tags under RFC 9989, the 2026 standards-track version of DMARC:
| Tag | Meaning |
|---|---|
p |
Policy for the domain: none, quarantine, reject |
sp |
Policy for existing subdomains (defaults to p) |
np |
Policy for non-existent subdomains (defaults to sp) |
adkim, aspf |
Alignment mode, r (relaxed, default) or s (strict) |
rua |
Where to send aggregate reports |
ruf |
Where to send failure reports (rarely honored) |
Gmail and Yahoo require bulk senders to publish DMARC; p=none satisfies that requirement, though it provides no protection against spoofing. The older pct, rf and ri tags were removed in RFC 9989.
PTR (reverse DNS)
25.2.0.192.in-addr.arpa. PTR mail1.example.com.
mail1.example.com. A 192.0.2.25Each IP that sends mail directly should have a PTR record whose hostname resolves back to the same IP. You set PTR records through whoever owns the IP, usually your cloud or hosting provider. If you send through an email service provider's shared IPs, they handle this. Gmail and Yahoo list valid forward and reverse DNS as a requirement for all senders.
MTA-STS
_mta-sts.example.com. TXT "v=STSv1; id=20261002"Plus a policy file served at https://mta-sts.example.com/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: mx1.mailhost.example
mx: mx2.mailhost.example
max_age: 604800MTA-STS (RFC 8461) protects mail sent to you by telling supporting senders to require valid TLS. Change the id whenever the policy changes. Start in testing mode.
TLS-RPT
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected]"TLS reporting (RFC 8460) asks senders to send daily JSON reports about TLS successes and failures when delivering to you. Publish it before enforcing MTA-STS.
BIMI
default._bimi.example.com. TXT "v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/mark.pem"BIMI requests that supporting mailbox providers display your logo. It requires DMARC at quarantine or reject, a logo in SVG Tiny PS format, and, for some providers including Gmail, a Verified Mark Certificate or Common Mark Certificate referenced by a=.
DMARC report authorization
example.net._report._dmarc.example.com. TXT "v=DMARC1"Needed only when a domain's rua address is at a different organizational domain. The record goes in the zone of the domain receiving the reports.
Who usually owns each record
Part of keeping these records correct is knowing who is allowed to change them. A common split looks like this: the team that runs DNS owns MX, PTR and the MTA-STS hosting; the email or security owner approves every change to SPF, DKIM and DMARC; marketing or brand owns the BIMI logo and certificate. Vendors never edit your zone directly; they give you values, and someone checks them against what is already published before adding them.
The most common failures map neatly onto that list: a second SPF record added by someone following a vendor guide, a DKIM key truncated by a DNS panel, a DMARC record that still says p=none a year later, a PTR left on a cloud default, and an MTA-STS policy that nobody updated after an MX migration. A short quarterly review of every row in the summary table catches nearly all of them.
Verification commands
dig +short MX example.com
dig +short TXT example.com | grep -i spf1
dig +short TXT k2026._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 192.0.2.25
dig +short TXT _mta-sts.example.com
dig +short TXT _smtp._tls.example.com
dig +short TXT default._bimi.example.comKey takeaways
- Every sending domain needs SPF, DKIM and DMARC; IPs you operate need matching PTR records.
- MTA-STS and TLS-RPT protect and monitor inbound TLS; BIMI is an optional reward for enforced DMARC.
- Each record lives at a specific name, and most mistakes are wrong names, duplicate records or truncated keys.
- Verify the served records with
dig, not only your DNS provider's dashboard.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
