Why email authentication is essential
Three building blocks that complement each other
SPF tells which servers have the right to send for your domain. The rule is published in a TXT record at the apex. Well configured, it limits spoofing. Too permissive, it lets abuse through.
DKIM signs your messages. The public key lives in a TXT under selector._domainkey. A valid signature proves the message hasn't been modified and indicates which domain signed it.
DMARC links the visible address to SPF and DKIM. If SPF or DKIM passes and aligns with the sender's domain, the message is considered compliant. The policy then decides the treatment on failure: observation, quarantine or rejection.
What a recipient server sees
Upon reception, the server reads your DNS records then adds an Authentication-Results header. You'll find spf=pass or fail, dkim=pass or fail, dmarc=pass or fail, with the evaluated domain. This header is your ground truth. It confirms the real effect of your settings, beyond theory.
What BIMI changes
BIMI is not a spam filter. It displays a validated logo when DMARC is in place with an enforced policy. The logo is requested via a dedicated DNS record and sometimes a VMC certificate. Result: the recipient better identifies your brand and spots a fake faster.
The most common errors
- Two SPFs at the same name → Merge into a single value
- SPF exceeding 10 lookups → Simplify the includes or use the SPF Flattener
- Misspelled DKIM selector → The key becomes unfindable
- Truncated public key → Verification fails silently
- DMARC without alignment → Message passes but doesn't protect identity
- DMARC reports to unmonitored mailbox → You lose observability. Use DMARC Monitoring to collect and visualize reports automatically
TTL and DNS propagation
The network doesn't "propagate" in the strict sense. It caches according to TTL. A short TTL helps during an update. A TTL that's too short over time overloads unnecessarily. A medium TTL (3600-86400s) stabilizes a validated setting. Reduce before a change, restore afterwards.
How to use the CaptainDNS toolbox
SPF, DKIM, DMARC syntax validators
Validators read your raw records and explain each element:
SPF: mechanism order, include, redirect, presence of all, DNS query counting, non-existent IPs and domains. The goal is to stay under 10 lookups and avoid loops.
DKIM: reading tags v, k, p, t, s. Key length verification, detection of truncation, invalid characters and key rotation best practices.
DMARC: reading tags v, p, sp, adkim, aspf, pct, rua, ruf. Verification of chosen alignment and report address validity.
Live record inspectors
Inspectors resolve DNS and display the response as seen from the Internet:
- SPF Inspector: unfolds the include chain, shows called domains and where the limit would be exceeded
- DKIM Inspector: resolves the selector, extracts the public key and checks format consistency
- DMARC Inspector: reads _dmarc.domain, displays the active policy, rua/ruf addresses and enforcement percentage
These tools verify the present, not theory. Ideal for a support ticket or production deployment.
Email deliverability audit
This check analyzes MX, SPF, DKIM and DMARC simultaneously to answer a simple question: is the domain ready to send? It also points to the most likely cause of failure: SPF too permissive, missing DKIM key, unenforced DMARC policy, strict alignment breaking on a subdomain, MX pointing to a CNAME.
DMARC record generator
The generator helps you create complete, RFC-compliant DMARC records:
- Domain configuration: simple input with automatic _dmarc hostname generation
- Flexible policies: choose between none, quarantine and reject with subdomain handling
- Integrated reporting: rua/ruf addresses with validation and implementation guidance
- Advanced options: DKIM/SPF alignments, percentages, intervals and failure options
The tool generates the complete record ready to publish and guides to the inspector for post-deployment verification.
DMARCbis: preparing for the DMARC v2 transition
DMARCbis succeeds RFC 7489 and elevates DMARC to the status of IETF Proposed Standard. The key change: the Public Suffix List is replaced by a DNS Tree Walk algorithm to identify the organizational domain.
Three tags are added (psd, np, t), three are removed (pct, ri, rf). Reporting is separated into three distinct normative documents.
DMARCbis Checker analyzes the compatibility of your DMARC records with the new standard. It detects obsolete tags, verifies discovery via Tree Walk and recommends the necessary adjustments.
DMARCbis Migration automatically generates a record compliant with the new standard from your current DMARC record, with a before/after comparison.
BIMI in production
The BIMI validator checks record structure, tests the HTTPS logo URL, verifies Tiny-PS constraints and downloads the VMC when provided. Combined with DMARC enforced at quarantine or reject, it secures your logo display in compatible webmail clients.
MTA-STS for transport security
MTA-STS (RFC 8461) adds a critical layer of protection by enforcing TLS encryption for incoming email. Without MTA-STS, opportunistic TLS can be downgraded by attackers. With MTA-STS, sending servers must use TLS or reject delivery.
MTA-STS tools
Syntax Validator: Paste your DNS TXT record and policy file content. The validator checks version, mode, MX patterns and max_age directives before you publish.
Record Inspector: Enter a domain to fetch the live MTA-STS record and policy file. Verifies TLS certificates and cross-checks MX patterns with actual mail servers.
Generator: Create compliant MTA-STS records and policy files. Configure testing or enforce mode, add MX patterns, set cache duration. Copy-ready output with deployment instructions.
MTA-STS Hosting: Let CaptainDNS host your MTA-STS policy file. No web server setup required: create your policy, verify domain ownership, point a CNAME and you're done. Automatic HTTPS, managed certificates, and instant updates when you change your policy.
Recommended MTA-STS deployment
- Generate the DNS TXT record and policy file
- Host the policy file: use MTA-STS Hosting for zero-maintenance hosting, or self-host at
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt - Publish the DNS TXT record at
_mta-sts.yourdomain.com - Start in testing mode to identify issues without breaking delivery
- Switch to enforce once you've verified all MX servers support TLS
- Monitor with TLS-RPT to receive failure reports
TLS-RPT for transport reporting
TLS-RPT (RFC 8460) complements MTA-STS by receiving reports on TLS negotiation failures. Without these reports, you wouldn't know if incoming emails are silently failing due to an expired certificate or misconfiguration.
Syntax Validator: Paste your TLS-RPT DNS TXT record and validate RFC compliance before publishing. Checks mailto and HTTPS report URIs.
Record Inspector: Resolve a domain's TLS-RPT record live. Verify report addresses, including external receiving authorizations.
Generator: Create a valid TLS-RPT record with mailto and/or HTTPS report URIs. Copy-ready output for your DNS zone.
TLS-RPT Monitoring: Track TLS-RPT reports for your domains without leaving CaptainDNS. Visualize TLS negotiation failures, identify problematic certificates and get alerts on anomalies.
DANE/TLSA for certificate authentication
DANE (RFC 6698/7672) binds TLS certificates to domain names via DNSSEC-signed TLSA DNS records. Unlike the traditional CA-based model, DANE lets the domain owner specify exactly which certificate a server must present.
Syntax Validator: Paste a raw TLSA record and verify usage, selector, matching type and certificate data fields before publishing. Detects non-recommended combinations and hex format errors.
Record Inspector: Enter a domain to check the full DANE configuration: MX resolution, TLSA lookup, DNSSEC validation, and matching against the server's TLS certificate.
Generator: Create a TLSA record from your PEM certificate or directly from the server via STARTTLS. Supports DANE-EE, DANE-TA, SHA-256, SHA-512 and SPKI selector.
Recommended DANE deployment
- Enable DNSSEC on your domain (absolute prerequisite)
- Generate the TLSA record with the DANE generator
- Publish the record at
_25._tcp.yourmailhost - Verify with the DANE inspector after propagation
- Enable TLS-RPT to receive DANE failure reports
- Plan rotation: update the TLSA record before each certificate renewal
Record generators
Beyond the DMARC generator, the toolkit covers record creation for every protocol:
SPF Generator: Build a valid SPF record by selecting your preconfigured email providers (Google Workspace, Microsoft 365, etc.). The generator assembles mechanisms, checks the 10-lookup limit and produces a publish-ready record.
SPF Flattener: Flatten your SPF records to eliminate nested includes. The tool resolves each include into direct IP addresses, reducing DNS lookups and preventing permerror failures in production.
DKIM Generator: Generate a DKIM key pair (RSA 1024/2048-bit or Ed25519) and the associated DNS TXT record. The tool produces the private key for your server and the public key for DNS publication.
BIMI Generator: Create a BIMI DNS record with your SVG logo URL and optional VMC certificate. The tool verifies DMARC prerequisites and guides publication.
DKIM Selector Finder
Finding a DKIM selector can be tedious when you don't know its name. The DKIM Selector Finder automatically queries a database of known selectors (Google, Microsoft, Amazon SES, etc.) and tests each one against your domain. Result: a list of active selectors with their public keys, no guessing required.
Reputation and connectivity checks
IP and domain blacklists
Perfect SPF and DKIM are useless if your IP or domain is blacklisted. The IP blacklist checker queries major DNSBLs (Spamhaus, Barracuda, SORBS, etc.) and the domain blacklist checker checks URI lists (SURBL, URIBL, etc.). A blacklisted domain will see its emails rejected or flagged as spam, regardless of authentication.
SMTP/MX Tester
The SMTP tester verifies your MX server connectivity: DNS resolution, SMTP connection, banner, STARTTLS support, TLS certificate validity and open relay detection. It's the last link: DNS authentication is correct, but is the server actually reachable and secure?
Recommended deployment method
- Document initial state: DNS captures and Authentication-Results examples
- Reduce TTL before changes (300-600s)
- Deploy SPF clean and unique, verify with the inspector
- Publish DKIM key on a new selector, test the signature
- Enable DMARC at p=none, analyze reports, fix then enforce
- Add BIMI when DMARC is enforced and logo/VMC pass validation
- Restore comfortable TTL (3600-86400s) when stable
Monitoring and daily operations
Configurations evolve with providers, subdomains, microservices and one-off campaigns. Keep a simple cycle: regular checks, report reading, key rotation, cleanup of obsolete includes and selectors. A change should always leave a trace: date, author, previous value, new value, reason. This shortens each diagnosis.
Complementary tools
| Tool | Purpose |
|---|---|
| DNS Propagation Checker | Confirm your DNS changes are visible worldwide |
| DNS Lookup | Query any DNS record type |
| IP Whois | Identify the owner of an IP address |
| IP Blacklist Checker | Check if your IP is blacklisted |
| Domain Blacklist Checker | Check if your domain is blacklisted |
| DMARC Monitoring | Collect and visualize DMARC aggregate reports for your domains |
| SMTP/MX Tester | Test SMTP connectivity, STARTTLS and TLS certificates |
Useful resources
- RFC 7208 - Sender Policy Framework (SPF) (official specification)
- RFC 6376 - DomainKeys Identified Mail (DKIM) (official specification)
- RFC 7489 - Domain-based Message Authentication (DMARC) (official specification)
- RFC 8461 - MTA Strict Transport Security (MTA-STS) (official specification)
- RFC 8460 - SMTP TLS Reporting (TLS-RPT) (official specification)
- RFC 6698 - DNS-Based Authentication of Named Entities (DANE) (official specification)
- RFC 7672 - SMTP Security via Opportunistic DANE TLS (DANE for SMTP)
- Google - Email sender guidelines (Gmail requirements)
- Microsoft - Email authentication in Microsoft 365 (Outlook/M365 guide)