What Is ADSP? Understanding Author Domain Signing Practices in DKIM

Email authentication relies on several standards that help receiving mail servers determine whether a message is legitimate. One of the technologies associated with DKIM is Author Domain Signing Practices (ADSP). It was designed to allow a domain owner to publish information about how messages sent from that domain should be signed.

Although ADSP is no longer the primary choice for modern email authentication, understanding how it works provides useful background on the development of email security protocols and explains why newer standards such as DMARC have become more widely adopted.

Key Takeaways

• ADSP, or Author Domain Signing Practices, was created as an extension to DKIM.
• It allows a domain to indicate whether messages using that domain are expected to carry DKIM signatures.
• The visible From: address identifies the author domain used when evaluating the message.
• ADSP supports three signing policies: unknown, all, and discardable.
• An ADSP policy can be published through a dedicated TXT record in DNS.
• ADSP has important limitations, which is one reason DMARC has become the preferred approach for enforcing modern email authentication policies.

What Is ADSP?

Author Domain Signing Practices is an extension associated with DomainKeys Identified Mail (DKIM). Its purpose is to communicate a domain owner’s expectations regarding DKIM signing.

DKIM works by attaching a cryptographic signature to an email. The receiving mail server can retrieve the appropriate public key from DNS and use it to determine whether the signature is valid and whether the message content has been changed after signing.

ADSP was intended to address another question: What should a recipient expect when an email claiming to come from a particular domain does not have a DKIM signature?

A domain could publish an ADSP policy in DNS to describe its expected signing behavior. Mail systems could then use that information when evaluating messages that lacked a valid DKIM signature.

In simple terms, DKIM provides a way to verify a signature, while ADSP was designed to communicate what a domain expected regarding the presence of that signature.

Understanding the Author Address

To understand ADSP, it is important to distinguish the author address from other email addresses found within an email’s headers.

The From: field is the address normally displayed to the recipient. It identifies the domain that appears to be responsible for the message and is therefore commonly referred to as the author address.

For example:

From: user@example.com

Here, example.com represents the author domain.

The author address should not be confused with the Return-Path address. The Return-Path is associated with the envelope sender and is used for handling delivery-related messages such as bounces. It is not the same as the address displayed in the visible From field.

This distinction is important because email authentication technologies evaluate different parts of a message and its headers.

What Is an Author Domain Signature?

A DKIM signature contains several parameters that help a receiving mail server validate the message. One of the most important is the d= tag.

The d= value identifies the domain that generated the DKIM signature.

For example:

d=example.com

If an email contains a DKIM signature associated with example.com, the recipient’s mail server can retrieve the corresponding public key from DNS and verify the signature.

Ideally, the domain used in the DKIM signature should have an appropriate relationship with the domain shown in the From address. When these domains do not correspond as expected, it may indicate that the message was sent through a third-party domain, incorrectly configured, or potentially attempting to impersonate another sender.

DKIM validation alone, however, does not provide the complete policy and reporting framework offered by modern authentication standards.

How Does ADSP Work?

ADSP uses a DNS TXT record to publish the signing expectations for a domain.

When an email claims to originate from a particular author domain, a receiving system can look for the domain’s ADSP record and determine which signing practice has been published.

ADSP defines three primary signing practices:

1. Unknown

The unknown option does not make a firm requirement that messages from the domain must contain DKIM signatures.

This provides flexibility for organizations whose email infrastructure includes multiple sending systems or whose users may send mail through different servers.

With this approach, the domain does not explicitly state that every message must be signed.

2. All

The all policy indicates that messages associated with the author domain are expected to contain a valid DKIM signature.

This creates a stronger expectation than the unknown setting because the domain is declaring that its email should be signed.

Organizations choosing this approach need to make sure that all legitimate sending platforms are properly configured for DKIM. Otherwise, legitimate messages could fail authentication expectations.

3. Discardable

The discardable policy represents the strictest ADSP option.

It indicates that messages associated with the author domain are expected to have valid DKIM signatures and that messages failing to meet this requirement may be rejected or discarded by the receiving system.

This resembles the general enforcement concept found in modern DMARC policies, particularly when DMARC is configured to reject authentication failures. However, ADSP and DMARC are different technologies and should not be treated as interchangeable.

Publishing an ADSP Record in DNS

An ADSP policy is published as a TXT record under the _adsp._domainkey namespace.

A typical record can look like this:

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

Replace example.com with the domain for which you want to publish the policy.

The policy value can be changed depending on the desired signing practice:

dkim=unknown

or:

dkim=all

or:

dkim=discardable

After publishing the record, DNS changes may require some time to propagate. Organizations should also verify that their legitimate email platforms are correctly configured before applying a restrictive policy.

Why the Unknown Policy Can Be Safer

A strict signing requirement can create problems when an organization does not have complete control over every system capable of sending email on its behalf.

For example, a company might use:

• Its primary corporate email platform
• Marketing automation software
• Customer support systems
• CRM applications
• Transactional email providers
• Website notification systems
• External business applications

If some of these services send messages without the expected DKIM configuration, a strict ADSP policy could cause legitimate messages to fail authentication expectations.

For this reason, a less restrictive approach may be more appropriate in environments where the organization cannot guarantee that every legitimate message will be DKIM-signed.

Before enforcing any email authentication policy, administrators should identify all legitimate sending sources and confirm their authentication configuration.

ADSP vs. DKIM

ADSP and DKIM are related, but they perform different functions.

DKIM adds a cryptographic signature to an email. The receiving server can validate that signature using a public key published in DNS.

ADSP, on the other hand, communicates the domain’s expectations concerning DKIM signing.

A simplified way to understand the difference is:

• DKIM: “This message has been signed.”
• ADSP: “This is how my domain expects messages to be signed.”

DKIM therefore provides message-level authentication, while ADSP was intended to provide an additional policy layer.

Limitations of ADSP

Although ADSP was designed to strengthen DKIM-based authentication, it has several limitations.

One major challenge is that modern email ecosystems are highly distributed. Businesses frequently rely on multiple cloud platforms and third-party services to send email. Maintaining a strict requirement that every message carry an appropriate DKIM signature can therefore become difficult.

ADSP also lacks several capabilities that organizations now expect from an effective email authentication framework.

For example, ADSP does not provide the comprehensive reporting and alignment mechanisms associated with DMARC*.* It also does not offer the same flexibility for defining how receiving systems should handle authentication failures.

These limitations have significantly reduced the practical importance of ADSP in modern email security.

ADSP vs. DMARC

DMARC (Domain-based Message Authentication, Reporting, and Conformance**)** was developed to address many of the shortcomings found in earlier email authentication approaches.

Rather than relying only on DKIM signing expectations, DMARC combines authentication results with domain alignment and a published policy.

A DMARC policy can tell receiving mail servers what to do when messages fail authentication requirements.

Common DMARC policy options include:

p=none

This allows organizations to monitor authentication results without asking receiving servers to reject or quarantine messages.

p=quarantine

This instructs receiving systems to treat authentication failures as suspicious, often by placing them in a spam or quarantine location.

p=reject

This provides the strongest enforcement and tells receiving servers to reject messages that fail the applicable DMARC requirements.

DMARC also supports reporting, giving domain owners visibility into authentication activity and potential sources of unauthorized email.

Why DMARC Is More Relevant Today

Modern organizations rarely rely on a single mail server. Email can originate from numerous internal systems, SaaS platforms, marketing tools, support applications, and third-party providers.

DMARC is better suited to this environment because it combines:

• SPF authentication
• DKIM authentication
• Domain alignment
• Policy enforcement
• Aggregate reporting
• Failure reporting
• Visibility into unauthorized email sources

This gives organizations a broader framework for protecting their domains against spoofing, phishing, and unauthorized email use.

Instead of simply stating that messages should carry DKIM signatures, DMARC provides a mechanism for determining whether authentication results align with the domain shown to recipients and what should happen when those requirements are not satisfied.

ADSP and Modern Email Authentication

ADSP remains useful as a concept for understanding how email authentication policies evolved, particularly the relationship between DKIM signatures and domain-level signing expectations.

However, organizations implementing email authentication today should generally focus their efforts on modern standards such as SPF, DKIM, and DMARC.

A strong email authentication strategy should begin by identifying every legitimate source that sends messages using the organization’s domains. DKIM should then be configured for supported sending services, SPF should identify authorized infrastructure, and DMARC should be introduced to establish alignment, monitoring, and enforcement.

Final Thoughts

Author Domain Signing Practices was created to extend DKIM by allowing domains to communicate their expectations about email signing. Its three policy choices—unknown, all, and discardable—provide different levels of requirements for DKIM-signed messages.

However, the modern email environment has become significantly more complex than when ADSP was introduced. Organizations now need authentication, domain alignment, policy enforcement, and reporting capabilities that go beyond simply requiring DKIM signatures.

That is where DMARC provides a more comprehensive solution. By bringing SPF and DKIM together with alignment, enforcement, and reporting, DMARC gives domain owners greater visibility and control over messages claiming to originate from their domains.

Understanding ADSP is still valuable for learning the history of email authentication, but organizations looking to strengthen their current email security posture should prioritize modern authentication standards and maintain accurate SPF, DKIM, and DMARC configurations.