RFC 5617: ADSP — Author Domain Signing Practices

DMARC Email Authentication Published August 2009

ELI5: Imagine you run a company and stamp every letter you send with a wax seal. ADSP was a way to announce to the world: “Every letter from us has a seal. If you get one without it, it’s a forgery.” Good idea, but the announcement mechanism was too rigid — it couldn’t handle mailing lists, forwarding, or third-party senders gracefully. DMARC eventually solved the same problem with a more flexible approach, and ADSP was retired.

Why This Exists

DKIM (RFC 6376) lets a domain sign its outgoing messages, but it doesn't tell receivers what to do when a message lacks a valid signature. Without a policy layer, a receiver has no way to know if an unsigned message from bank.example.com is legitimate (maybe their outbound path doesn't always sign) or fraudulent (a phisher spoofing the bank).

ADSP was the first attempt to fill this gap. It let domain owners publish a DNS record declaring their signing practice:

"unknown" — the domain may or may not sign all messages (the default if no ADSP record exists).
"all" — the domain signs all messages with an Author Signature (the DKIM d= matches the From: domain).
"discardable" — the domain signs all messages, and unsigned messages should be discarded.

Published in August 2009, ADSP saw limited adoption and was moved to "Historic" status in November 2013 by RFC 5863. Its successor, DMARC, addressed ADSP's shortcomings and became the standard email authentication policy mechanism.

How It Works

The DNS Lookup

ADSP records are published as DNS TXT records at _adsp._domainkey.<domain>. When a receiver gets a message with a From: header of alice@example.com, it looks up:

_adsp._domainkey.example.com. IN TXT "dkim=all"

Policy Values

Policy	DNS Record	Meaning
Unknown	`dkim=unknown` (or no record)	The domain may sign some or all mail. No assertion about unsigned messages.
All	`dkim=all`	All mail from this domain is signed with an Author Signature. Unsigned messages are suspicious but not necessarily forgeries.
Discardable	`dkim=discardable`	All mail is signed. Unsigned messages should be silently discarded. The strongest policy.

Author Signature vs. Third-Party Signature

A key concept in ADSP is the Author Signature — a DKIM signature where the d= tag in the DKIM-Signature header exactly matches the domain in the From: header. This is stricter than general DKIM, which allows any domain to sign:

; Author Signature (ADSP cares about this) From: alice@example.com DKIM-Signature: v=1; a=rsa-sha256; d=example.com; ... ; d=example.com matches From domain → Author Signature: YES ; Third-party Signature (ADSP ignores this) From: alice@example.com DKIM-Signature: v=1; a=rsa-sha256; d=esp-provider.com; ... ; d=esp-provider.com does not match From domain → Author Signature: NO

This meant that if you used an ESP (Email Service Provider) that signed mail as d=esp.com rather than d=yourdomain.com, ADSP would treat those messages as unsigned — even though they had a perfectly valid DKIM signature.

The Verification Flow

Receive the message and extract the From: header domain.
Look for DKIM-Signature headers where d= matches the From domain (Author Signatures).
If an Author Signature is present and validates, accept the message normally.
If no valid Author Signature exists, query DNS for _adsp._domainkey.<domain>.
Apply the policy: unknown means take no action, all means treat with suspicion, discardable means reject or silently drop.

Key Technical Details

Why ADSP Failed

ADSP's design had fundamental limitations that prevented meaningful adoption:

Mailing lists break Author Signatures. When a mailing list modifies the message (adds a footer, changes the Subject), the DKIM signature breaks. Under dkim=discardable, the receiver would drop the message. Domains that use mailing lists could never safely deploy a strict policy.
No subdomain coverage. ADSP only applied to the exact domain queried. There was no way to set a policy for *.example.com without publishing records for every subdomain individually.
No reporting mechanism. ADSP had no way for receivers to send feedback to domain owners about authentication results. Without data, domain owners couldn't assess the impact of a stricter policy before deploying it.
No gradual rollout. The only options were "unknown" (no protection), "all" (ambiguous), or "discardable" (nuclear). There was no equivalent to DMARC's percentage (pct=) tag for gradual enforcement.
SPF was not considered. ADSP only evaluated DKIM. A message that passed SPF but lacked DKIM was treated the same as a completely unauthenticated forgery.

ADSP vs. DMARC: Key Differences

Feature	ADSP (RFC 5617)	DMARC (RFC 7489)
Authentication methods	DKIM only	DKIM or SPF (either can pass)
Alignment mode	Strict only (exact From match)	Strict or relaxed (subdomains allowed)
Subdomain policy	None	`sp=` tag for subdomains
Aggregate reporting	None	`rua=` tag for daily XML reports
Forensic reporting	None	`ruf=` tag for per-failure reports
Gradual rollout	None	`pct=` tag to apply policy to a percentage of mail
Policy actions	unknown, all, discardable	none, quarantine, reject
DNS location	`_adsp._domainkey.<d>`	`_dmarc.<d>`
Status	Historic (retired 2013)	Active, widely deployed

The DNS Record in Detail

; ADSP record syntax _adsp._domainkey.example.com. IN TXT "dkim=discardable" ; The only recognized tag is "dkim=" with values: ; unknown - default, no assertion ; all - all mail is Author Signed ; discardable - all mail is Author Signed; discard if not

Common Mistakes

Deploying ADSP in 2024+. ADSP is historic. No major receiver checks ADSP records. If you still have one published, it does nothing. Deploy DMARC instead.
Confusing ADSP with DMARC. Both are policy mechanisms for DKIM, but DMARC is the current standard. If you encounter documentation referencing _adsp._domainkey records, it is outdated.
Leaving stale ADSP records in DNS. Old ADSP records consume DNS query time and add confusion during debugging. If you find _adsp._domainkey TXT records in your zone, clean them up.
Thinking "discardable" was the strongest possible policy. Even at its peak, ADSP's "discardable" was respected by very few receivers. The adoption was too low to provide meaningful protection against spoofing.
Not learning the lesson. ADSP failed because it was all-or-nothing with no visibility. DMARC succeeded because it added reporting (rua=) and gradual rollout (pct=). Always start with monitoring before enforcement.

Deliverability Impact

No current impact. ADSP records are not checked by modern receivers. Publishing one has no effect on delivery, authentication results, or spam filtering.
Historical lesson for DMARC deployment. ADSP's failure directly informed DMARC's design. The reporting and gradual rollout features that make DMARC deployable exist because ADSP proved that a binary policy without feedback is impractical.
Stale records as a signal. An old ADSP record in DNS is a mild signal that a domain's email infrastructure is not actively maintained. While no receiver penalizes this, it can cause confusion during authentication debugging.
Migrate to DMARC. If your domain has an ADSP record but no DMARC record, deploy DMARC immediately. Start with p=none and a rua= reporting address to gain visibility, then tighten the policy based on data.