Blog · Dmarc
Why SPF, DKIM, and DMARC Exist as Separate Mechanisms
Every email authentication check is a DNS lookup at its core. Receiving servers query DNS to find out which servers are allowed to send for a domain (SPF), what public key to use to verify a DKIM signature (DKIM), and what policy to apply when both fail (DMARC). But these three mechanisms did not all follow the same path into DNS, and the history explains a great deal about why your DNS zone probably contains both TXT records and some empty record-type slots that seemed like a good idea.
Why SPF Got Its Own DNS Record Type (And Gave It Back)
SPF was the first major email authentication system to get its own dedicated DNS record type. IANA assigned type 99 to SPF, and for a brief period in the mid-2000s, sending domains published SPF data as type 99 records.
The idea was sound in theory: register a proper protocol with IANA, give mailbox providers a clear record type to query, and build email authentication on a more formal footing than a plain text string in a TXT record.
The problem was practical. Type 99 was not universally queryable. Some large DNS operators blocked or rate-limited type 99 queries. Some DNS caches mishandled responses. The ecosystem that email runs on is enormous and slow to change, and many servers simply never queried type 99.
The solution was to move SPF back to TXT records, where it had originally been published as an informal experiment. RFC 7208 (the current SPF specification) defines SPF as a TXT record at the root of the sending domain. Type 99 was formally deprecated.
Today, if you publish an SPF record, it is a single TXT record. There is no type 99 in active use.
Why DKIM Never Got Its Own Record Type
DKIM was designed after the SPF type 99 experience, and the designers learned from it. DKIM does not have a dedicated DNS record type. Its public keys live in TXT records under a selector subdomain.
The selector design is deliberate. When you set up DKIM, you choose a selector name (often something like "default" or "20230601"). Your DKIM public key is published at:
[selector]._domainkey.example.com TXT "v=DKIM1; k=rsa; p=..."
The underscore in _domainkey ensures this subdomain will not collide with any regular DNS record. The selector lets you publish multiple DKIM keys for the same domain, which makes key rotation straightforward: you add a new selector, wait for propagation, then retire the old one, without touching the main domain DNS.
DKIM was never assigned its own record type, and there was no serious proposal to give it one after the SPF type 99 deprecation. The TXT-based selector model works, and the ecosystem settled on it.
Why DMARC Is a TXT Record at a Fixed Prefix
DMARC was designed with the benefit of both prior systems. It lives at a fixed subdomain prefix: _dmarc.example.com. The record type is TXT.
The underscore in _dmarc serves the same collision-avoidance purpose as the underscore in DKIM's _domainkey prefix. A regular subdomain cannot start with an underscore under normal domain registration rules, so _dmarc.example.com is guaranteed not to conflict with any other DNS record at the same domain.
DMARC was never assigned its own record type either. The designers chose TXT at _dmarc and kept things simple. This has proven reliable: _dmarc lookups are fast, well-supported, and universally understood by receivers that implement DMARC.
What About the Record Types That Were Supposed to Happen?
The history of email authentication DNS records is largely a history of proposals that never landed.
SPF type 99 is the clearest example. It was real, it was assigned, and it was deprecated.
ARC (Authenticated Received Chain) was designed to solve a different problem: what happens when a message passes through a forwarding service or mailing list that modifies it, breaking DKIM signatures. ARC is not a DNS record type at all. It is a series of additional email headers (ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal) that each intermediary adds and signs, preserving the authentication chain even when the message is modified in transit. No dedicated DNS record type was ever proposed for ARC.
BIMI (Brand Indicators for Message Identification) uses TXT records under default._domainkey.example.com, following the DKIM model. No BIMI-specific DNS record type exists.
The pattern is consistent: after SPF type 99 was retired, no subsequent email authentication system pursued a dedicated record type. The ecosystem moved toward TXT-based approaches and stayed there.
How SPF, DKIM, and DMARC Work Together
These three mechanisms check different parts of the email transaction and answer different questions.
SPF answers: Is the sending server allowed to send for this domain? It compares the SMTP envelope MAIL FROM domain and the connecting server IP address against the published SPF record.
DKIM answers: Was this message signed by a server that holds the private key for this domain, and was it modified in transit? It verifies the cryptographic DKIM signature against the public key published in DNS.
DMARC answers: Do the domains used by SPF and DKIM match the From header domain that the recipient sees? Alignment is the part that matters for fraud prevention. A message can have valid SPF and valid DKIM but still fail DMARC if the domains do not align.
None of the three is sufficient on its own. SPF and DKIM verify that authentication mechanisms passed; DMARC verifies that the authenticated identity matches what the recipient sees. Together they form a layered email authentication system.
FAQ
Does SPF type 99 still exist anywhere?
Type 99 was deprecated in 2014 when RFC 7208 was published. No major mailbox provider queries it today. If you see type 99 records in your DNS zone or DNS cache logs, they are passive and unused. Publishing SPF data only at type 99 during the transition period would have caused deliverability problems, which is partly why the deprecation was prioritized.
Can I use DKIM with a dedicated record type instead of TXT?
No. There is no DKIM record type assigned by IANA. DKIM always uses TXT records under a selector subdomain. Some early drafts discussed selector record types, but nothing was standardized. The TXT-based approach is the only one supported by any major email receiver.
Why do SPF and DKIM use different approaches to their DNS records?
SPF was designed earlier, when the idea of a dedicated email authentication record type seemed like the right approach. When that caused interoperability problems, the DKIM designers deliberately chose TXT under a selector prefix to avoid DNS operator interference. DMARC followed DKIM's model and has remained stable since. The divergence reflects the ecosystem learning from earlier mistakes, not any fundamental difference in the importance of the mechanisms.
Does DMARC work if SPF or DKIM fails?
DMARC evaluates alignment, not just whether SPF or DKIM passed individually. A message can have both SPF and DKIM pass but still fail DMARC if the From header domain does not align with the domains used by SPF and DKIM. This is the core insight DMARC adds: verifying that the identity in the From header matches the authenticated sending identity.
If SPF and DKIM both pass, why would DMARC fail?
DMARC checks alignment. SPF authenticates the domain in the SMTP envelope (the MAIL FROM domain). DKIM authenticates the domain in the DKIM-Signature header (the d= domain). Neither of these is necessarily the same as the From header domain that recipients see. DMARC fails when neither the SPF-authenticated domain nor the DKIM-authenticated domain matches the From header domain. This is called alignment failure, and it is the primary vector for sender impersonation attacks.
What You Can Do With This
If you manage email for a domain and you are not yet publishing SPF, DKIM, and DMARC records, start with SPF and DKIM. Both are straightforward to set up with your email provider or mail server documentation. DMARC is the layer that makes the other two useful for fraud prevention, because it enforces alignment.
You can monitor your DMARC setup using aggregate reports, which are XML files sent to the rua address you specify in your DMARC record. Reading these reports manually is painful. DMARCFlow parses them and surfaces alignment failures, SPF pass rates, and DKIM verification results in a readable dashboard, making it practical to move from p=none to p=quarantine or p=reject without guessing whether legitimate mail will break.
When you monitor DMARC alignment failures, you are watching the exact attack surface that sender impersonation exploits. DMARC aggregate reports show you how many messages are passing alignment, which specific subdomains are failing, and whether SPF or DKIM is the source of the mismatch. DMARCFlow parses these reports and surfaces the patterns that matter, so you can move from p=none to p=quarantine or p=reject based on actual data instead of guesswork.
The DNS records for email authentication are straightforward to publish and complex to get right at scale. Start with SPF and DKIM, add DMARC with an rua address that actually receives reports, and monitor the alignment data before tightening your policy.