DARA Records setup guide

DARA (DKIM Authorized Resigners for Authentication) is a new proposed protocol that helps you with a problem. Sometimes emails get forwarded or modified (by mailing lists or auto-responders), which breaks the original DKIM signature.

DARA allows trusted third parties, the forwarders, to re-sign the email with their DKIM signature.

The main difference between DARA and DKIM is that DKIM is about the original sender proving the email is legitimate.

DARA is mainly about trusted intermediaries that fix broken DKIM signatures by re-signing emails with your permission.

Why Was DARA Introduced?

Email forwarding, mailing lists, and automated responses often modify original emails and change headers, body content, or encoding. These changes invalidate the original DKIM signature, which then causes DMARC failures.

DARA does this with a DNS-based mechanism. It allows senders to explicitly authorize third parties, like forwarders or list servers. They re-sign emails with their own DKIM keys. It helps to maintain trust and improves deliverability. Also this way you can avoid false spam flags.

How DARA Works?

DKIM (DomainKeys Identified Mail) works by verifying the authenticity of an email message. It uses public key cryptography to create a digital signature on the email header.

1. Sender Authorizes Intermediaries

Domain owners publish DARA records in DNS. They list the domains of authorized responders. These responders can re-sign messages using DKIM. The receiving server will treat the new signature as valid if it matches the DARA policy.

2. Receiver Verification Logic

When a receiving server checks an incoming message:

• If the original DKIM signature fails, it checks whether any resigning domain (forwarder, list, etc.) is listed in the sender’s DARA record.

• If the responder is authorized, the server accepts the DKIM signature from that responder.

This simple DNS-based logic reduces the complexity of validating intermediary involvement in the email’s path.

3. DARA Relies on DNS TXT Records

DARA does not rely on headers (unlike ARC) and keeps all authorization information in a TXT record under a subdomain prefixed by _dara.

DARA Record Syntax and Example

Here's how a DARA DNS record is structured:

_dara.example.com. 3600 IN TXT "v=DARA1; auth=forwarder.com:selector; auth=mlist.org:*"

Breakdown:

• v=DARA1 indicates version 1 of the DARA protocol.

• auth= specifies the authorized responder domain and selector.

• forwarder.com:selector means only that specific selector is valid.

• mlist.org:* allows any selector from that domain.

DARA vs ARC (Authenticated Received Chain)

Feature	DARA	ARC
Purpose	Authorize resigning by intermediaries	Track authentication chain across intermediaries
Mechanism	DNS-based TXT records	Header-based trust chain
Complexity	Low (simple DNS lookup)	High (Multi-stage header validation)
Adoption	Experimental	More widely deployed

ARC provides transparency in multi-hop message delivery, but it lacks DNS-based authorization and adds processing complexity.

DARA offers a simpler, focused solution for maintaining DKIM integrity during forwarding.

Use Cases for DARA

DARA is exceptionally useful in environments where legitimate intermediaries have to alter email content:

• Email forwarding services 

• Mailing lists and discussion groups

• Customer support platforms 

• Digest and newsletter reformatting tools

In these use cases, DARA helps to reduce false DMARC rejections and ensures authenticated delivery.

Benefits of Using DARA

• Preserves DKIM alignment even after message alterations

• Increases DMARC pass rate for forwarded or relayed emails

• Enhances deliverability by reducing false positives

• Clarifies sender intent through DNS-authorized intermediaries

• Simplifies infrastructure without relying on header chains or reputation scores

Limitations in DARA

• Not yet standardized: DARA is not in working, it’s in draft and not supported by most mail servers.

• Requires dual configuration: Both sender and intermediary must publish or configure DARA and DKIM records correctly.

• Verifier support is limited: Mail receivers must be updated to support DARA logic.

• Scalability concerns: Complex intermediary chains may make policy management cumbersome.

DARA is like a practical solution to a long-term gap in email authentication.

Integration with Existing Email Authentication Protocols

Here is how DARA interacts with other email authentication mechanisms: 

• DARA and DMARC: DARA complements DMARC and allows authorized intermediaries to re-sign emails. This helps to maintain DMARC alignment even after message modifications.​

• DARA and ARC: ARC (Authenticated Received Chain) provides a header-based trust chain to preserve authentication results through intermediaries. DARA offers a DNS-based approach to authorize specific intermediaries to re-sign messages.​

• DARA and SPF: DARA does not directly interact with SPF (Sender Policy Framework), but together, they contribute to a comprehensive email authentication strategy.​

DARA in the Future for Email Security

DARA is actively being discussed within IETF circles and may eventually be incorporated into future versions of DMARC (e.g., DMARC2). Its lightweight, DNS-native approach makes it appealing for real-world implementation, especially in ecosystems with multiple email hops.

As phishing threats increase and email authentication becomes mission-critical, protocols like DARA will help in modern email infrastructure.

FAQs

What does DARA stand for in email authentication? DARA stands for DKIM Authorized Responders for Authentication. It allows domain owners to list trusted third parties who can re-sign messages without breaking DKIM and DMARC authentication.

How does DARA improve email forwarding? By authorizing specific forwarders or mailing lists to re-sign messages, DARA maintains DKIM validity and helps ensure DMARC passes, even after content modification.

What’s the difference between DARA and ARC? DARA uses DNS-based authorization to allow resigning, while ARC relies on header-based chains to preserve authentication information. DARA is simpler and offers explicit trust management.

Is DARA widely adopted? No, DARA is currently a proposed protocol under development. While promising, it has not yet been standardized or widely implemented.

What happens if DKIM is not authenticated? If DKIM (DomainKeys Identified Mail) is not authenticated, it means the email's digital signature is either missing, invalid, or has been tampered with during transmission.

Conclusion

DARA fills the gap in email authentication and solves a real and persistent problem. It helps to solve legitimate DKIM failures during forwarding. Its DNS-based model is intuitive, efficient, and transparent.

DARA, as for now, is not mainstream. Organizations handling sensitive or high-volume email should monitor DARA developments and prepare for potential implementation.