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 that the message has not been modified and indicates which domain signed it.
DMARC links the visible address to SPF and DKIM. If SPF or DKIM passes and is aligned with the sender's domain, the message is considered compliant. The policy then decides the treatment in case of failure: observation, quarantine or rejection.
What a recipient server sees
Upon reception, the server reads your DNS records then adds an Authentication Results header. We 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 applied policy. The logo is requested via a dedicated DNS record and sometimes a VMC certificate. Simple result: the recipient better identifies your brand and spots a fake faster.
The most common errors
- Two SPFs with the same name. You need to merge into a single value.
- An SPF that exceeds the DNS lookup limit. You need to simplify the includes.
- A misspelled DKIM selector. The key becomes unfindable.
- A truncated public key. Verification fails silently.
- A DMARC without alignment. The message passes in theory but doesn't protect identity.
- DMARC reports sent to an unmonitored mailbox. You lose observability.
TTL and famous 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 unnecessarily overloads and complicates diagnosis. A medium TTL stabilizes a validated setting. Reduce before a change. Restore afterwards.
How to use the CaptainDNS toolbox
SPF DKIM DMARC syntax validators
The validators read your records and explain each element.
SPF useful controls: order of mechanisms, include, redirect, presence of all, count of DNS queries, non-existent IPs and domains. The goal is to stay under the limit of ten lookups and avoid loops.
DKIM reading of tags v, k, p, t, s. Verification of public key length, detection of cuts, invalid characters, and reminder of good key rotation practices.
DMARC reading of tags v, p, sp, adkim, aspf, pct, rua, ruf. Verification of chosen alignment and validity of report addresses. The validators explain the consequence of each tag in real life.
Live record inspectors
The inspectors resolve DNS and display the response as it's seen from the Internet.
SPF inspector: it unfolds the include chain, shows the called domains and where the lookup limit would be exceeded.
DKIM inspector: it resolves the selector, extracts the public key and controls format consistency.
DMARC inspector: it reads _dmarc.domain, displays the active policy, rua and ruf addresses and shows if the application percentage is partial.
These tools serve to verify the present, not theory. Ideal for a ticket or production deployment.
Email deliverability audit
This check reads MX, SPF, DKIM and DMARC at once 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, unapplied DMARC policy, strict alignment that breaks 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 management.
- Integrated reporting: rua/ruf addresses with validation and implementation guidance.
- Advanced options: DKIM/SPF alignment, percentages, intervals and failure options.
The tool generates the complete record ready for publication and guides to the inspector for post-deployment verification.
Validate BIMI with confidence
The BIMI syntax checker verifies the record structure, tests the HTTPS logo endpoint, ensures Tiny-PS requirements are respected and downloads the VMC when available. Combine it with a DMARC policy on quarantine or reject to present a trusted brand logo in supporting inboxes.
Recommended method for production deployment
- Document the initial state. DNS captures and Authentication Results examples.
- Reduce TTL before modification.
- Deploy clean and unique SPF. Verify live with the inspector.
- Publish the DKIM key on a new selector. Test the signature on output.
- Activate DMARC in p=none, monitor reports, adjust alignment and then enforce.
- Enable BIMI once DMARC enforcement is stable and the logo/VMC pass validation.
- Restore a comfortable TTL when everything is stable.
Monitoring and daily life
Configurations evolve with providers, subdomains, microservices and one-off campaigns. Keep a simple cycle: regular control, report reading, key rotation, cleanup of obsolete includes and selectors. A change must always leave a trace: date, author, previous value, new value, reason. This shortens each diagnosis.
To summarize, the email authentication toolbox allows you to validate syntax, verify the real response, prepare a DMARC policy that really applies, and soon activate a clean BIMI. Clear evidence, simple steps, messages that arrive and a protected identity.