RTFM · Networking

Mail DNS: PTR, FCrDNS, MX, SPF, DKIM, DMARC, and BIMI

Deliverable mail needs a coherent identity in both directions: the public IP names the mail host, and the mail host resolves back to that public IP.

PTR and forward-confirmed reverse DNS

For a public mail IP, the owner publishes a PTR such as 203.0.113.25 → mail.example.com. Then public DNS publishes mail.example.com A/AAAA back to the same public sending address. That forward confirmation is commonly called FCrDNS.

PTR and FCrDNS

dig -x 203.0.113.25 +short
dig mail.example.com A +short
dig mail.example.com AAAA +short

# IPv6 reverse lookup: quote the full address
dig -x 2001:db8:1200::25 +short

Domain records

Mail DNS checks

dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT mail._domainkey.example.com
dig +short TXT default._bimi.example.com

What MailDragon does and does not do

MailDragon generates DKIM keys, records, and guidance and tells the operator exactly what to publish. It does not automatically alter the authoritative DNS service. The operator still publishes MX, SPF, DKIM, DMARC, BIMI, A/AAAA, and any required verification records. A future MailDragon-to-dnsDragon integration may automate that boundary; it is not a current dependency.

SPF, DKIM, and DMARC cannot repair a mail server whose public sending IP has unsuitable reverse DNS or whose forward and reverse names disagree.

The record roles

MX says which host receives mail for the domain.
SPF says which senders are authorized by the domain's policy.
DKIM signs a message and publishes the verifier key under selector._domainkey.
DMARC checks alignment and publishes policy and reporting instructions.
BIMI can associate a brand indicator with a domain that meets the required authentication policy.

Publish a coherent first mail domain

The example below uses one mail hostname. It gives a new operator a complete mental model: public DNS tells senders where to deliver, SPF authorises the intended sending path, DKIM publishes the public key for signatures MailDragon creates, and DMARC tells receivers what alignment policy and report mailbox to use. Start conservatively with DMARC p=none while you observe reports; do not publish a reject policy before you know every legitimate sender.

A readable public DNS baseline

# Public DNS records for example.test
mail                 A      203.0.113.25
mail                 AAAA   2001:db8:100::25
@                    MX 10  mail.example.test.
@                    TXT    "v=spf1 mx -all"
_dmarc              TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.test; adkim=s; aspf=s"
mail._domainkey     TXT    "v=DKIM1; k=rsa; p=<MailDragon-generated-public-key>"
default._bimi       TXT    "v=BIMI1; l=https://www.example.test/logo.svg; a="

Publish each record in the right place
Record	Who publishes it	What to verify
A/AAAA and MX	The operator in public authoritative DNS	mail.example.test resolves externally and MX points at it.
PTR	The public-address owner	PTR returns mail.example.test, then forward lookup returns the same IP.
SPF and DMARC	The operator in public authoritative DNS	dig returns the intended TXT policy without conflicting duplicate records.
DKIM	MailDragon generates it; operator publishes it	The selector TXT exactly matches the generated public key.
BIMI	The operator, only after meeting its wider requirements	Do not expect a BIMI TXT record alone to display a logo everywhere.

Generate and verify DKIM with MailDragon

MailDragon's create-dkim.sh generates a 2048-bit key, protects the private key under its DKIM directory, adds the domain/selector mapping to Rspamd configuration, runs rspamadm configtest, and restarts the signing service through its OpenRC/systemd compatibility layer. It prints the DNS TXT record; copy the printed public record, never the private key file.

MailDragon DKIM and domain-health workflow

# Run from the MailDragon scripts directory or its installed management path.
./scripts/create-dkim.sh example.test mail

# The script prints the record name and value. Publish that exact TXT value, then verify.
dig TXT mail._domainkey.example.test +short

# MailDragon's one-shot operational report checks maps, DNS, and key presence.
./scripts/check-domain.sh example.test

MailDragon does not automatically change authoritative DNS. It generates keys, records, and guidance; the operator still publishes the requested public records and waits for DNS propagation. A future MailDragon-to-dnsDragon integration is not a present dependency.

Prove it works: The domain has a coherent public identity

dig shows MX, A, AAAA, SPF, DKIM, and DMARC records; check-reversedns.sh passes for the actual public sending addresses; and a controlled delivered message contains the expected authentication results.

Failure diagnosis in the order receivers experience it

No MX or wrong A/AAAA: remote senders cannot find the receiving service. Fix public DNS and test from outside before touching Postfix.
TCP 25 unavailable: trace provider/router delivery and nftables. A correct MX cannot bypass a filtered port.
PTR or FCrDNS fails: fix the actual public outbound address with its ISP/provider. SPF and DKIM do not replace a coherent reverse identity.
DKIM fails: compare the selector used by MailDragon with the selector TXT name, then run the script's config test rather than hand-editing an unrelated record.
DMARC fails despite SPF/DKIM passing: inspect identifier alignment; the authenticated domain must align with the visible From domain under the published policy.