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
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.
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.
Recommended MTA-STS deployment
- Generate the DNS TXT record and policy file
- Host the policy file 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
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 |
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)
- Google - Email sender guidelines (Gmail requirements)
- Microsoft - Email authentication in Microsoft 365 (Outlook/M365 guide)