The Final Pieces: DKIM and DMARC Implementation for Access Developers

Moving from Outlook automation in your Access apps? This guide explains DKIM and DMARC implementation for reliable email delivery.

The Final Pieces: DKIM and DMARC Implementation for Access Developers

Email authentication is like a three-legged stool.

In our previous article, we explored SPF—the first leg of that stool. But a one-legged stool can't stand on its own. To build a stable email authentication strategy, we need to implement the remaining two legs: DKIM and DMARC.

As Access developers transitioning away from Outlook automation to services like Mailgun, understanding these protocols isn't just academic—it's essential for ensuring your application's emails actually reach their recipients.

DKIM Implementation: Digital Signatures for Your Messages

DKIM (DomainKeys Identified Mail) is like a wax seal on a medieval letter. It cryptographically signs your messages to prove they haven't been tampered with in transit.

Unlike SPF, which only verifies the sending server, DKIM verifies the message content itself. This distinction is crucial because it means DKIM authentication survives email forwarding—a scenario where SPF often fails.

How DKIM Works

DKIM uses public-key cryptography to sign and verify messages:

selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEKyU1fSma0axspqYK5iAj+54lsAg4qRRCnpKK68hawSd8zpsDz77ntGCR0X2mHVvkf0WEOIqaspaG/A5IGxieiWer+wBX8lW2tE4NHTE0PLhHqL0uD2sif2pKoPR3Wr6n/rbiihGYCIzvuY4/U5GigNUGls/QUbCPRyzho30wIDAQAB;"

Let's break down the components:

  • selector: This is a predetermined value provided by your email service provider (like Mailgun or SendGrid)
  • _domainkey: A fixed string that identifies this as a DKIM record
  • example.com: Your domain name
  • v=DKIM1: The DKIM version
  • k=rsa: The encryption algorithm used
  • p=...: The public key itself (the long string of characters)

For Access developers, you won't need to generate DKIM keys yourself. Email service providers handle this entirely. They generate the key pair, securely store the private key, and provide you with the complete DNS record to add. Your responsibility is simply to add the provided DNS record to your domain's DNS settings exactly as provided.

How DKIM Complements SPF

SPF and DKIM work together to address different aspects of email authentication:

SPF's Limitations

  • Forwarding breaks SPF: When an email is forwarded, it comes from a new sending server that wasn't in your SPF record
  • No content integrity: SPF only verifies the sending server, not the message content

DKIM's Advantages

  • Survives forwarding: The DKIM signature remains valid even when the message is forwarded
  • Verifies content: DKIM ensures the message hasn't been altered in transit
  • Provides cryptographic proof: The mathematical certainty of public-key cryptography is stronger than IP-based verification

Together, they provide a robust foundation for email authentication. But there's still a missing piece: how should receiving mail servers handle messages that fail these checks? That's where DMARC comes in.

DMARC Implementation: Putting It All Together

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy framework that ties SPF and DKIM together.

It serves three critical functions:

  1. Tells receivers what to do with messages that fail authentication
  2. Aligns the "From" header with the domain validated by SPF or DKIM
  3. Provides reporting on authentication results

DMARC DNS Record Format

A DMARC record must be published as a TXT record at exactly _dmarc.yourdomain.com. This specific hostname prefix (_dmarc.) is required—it's not customizable like DKIM selectors.

A properly formatted DMARC record looks like this:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100; sp=none;"

The key components are:

  • v=DMARC1: The DMARC version
  • p=none: The policy for the domain (none, quarantine, or reject)
  • rua=mailto:...: Where to send aggregate reports
  • pct=100: Percentage of messages subject to filtering
  • sp=none: Policy for subdomains

DMARC and Subdomains

For organizations sending email from multiple subdomains, DMARC allows for different policies at the domain and subdomain level. The sp tag in your DMARC record controls what happens with subdomains:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; sp=reject; ..."

This configuration would:

  • Monitor the main domain (p=none)
  • Reject messages from unauthorized subdomains (sp=reject)

This approach is particularly useful since subdomains are often targeted for spoofing.

Policy Options

DMARC offers three policy options that tell receiving mail servers what to do with messages that fail authentication:

  • p=none: Take no action, but send reports (monitoring mode)
  • p=quarantine: Place failing messages in the spam folder
  • p=reject: Reject failing messages entirely

For Access developers implementing email authentication, always start with p=none. This allows you to monitor authentication results without affecting delivery. Once you've reviewed reports and are confident in your configuration, you can move directly to p=quarantine or p=reject.

While DMARC offers additional configuration options like percentage-based rollout (pct), these advanced features add complexity that most Access developers don't need. Stick with the simple approach: monitor first with p=none, then enforce with either p=quarantine or p=reject when ready.

This straightforward path provides the most predictable email delivery behavior and simplifies troubleshooting if issues arise.

Setting Up DMARC Monitoring

DMARC's monitoring capabilities are only valuable if you actually review the reports. Several services offer free options for Access developers sending low volumes of email:

  • Dmarcian: Founded by one of the original DMARC specification authors, their free tier monitors up to 2 domains and processes 1,250 emails monthly with 30-day data retention. They provide specific documentation for Mailgun integration and recommend configuring a subdomain for Mailgun rather than your primary domain.
  • Postmark Free DMARC Monitor: Offers unlimited free monitoring with no volume restrictions. Instead of a dashboard, it sends weekly email digests summarizing your DMARC activity. The setup process is extremely simple, making it ideal for developers who want minimal time investment.
  • PowerDMARC: While not completely free, their service starts at just $8/month and provides comprehensive visualization with 7 distinct viewing formats, AI-powered threat intelligence, and an interactive dashboard. Their Setup Wizard guides you through implementation, including proper alignment settings for Mailgun.

These services convert complex XML reports into readable information showing which messages passed or failed authentication, what IP addresses are sending email claiming to be from your domain, and whether failures are due to SPF, DKIM, or both.

Simply sign up with your chosen service and follow their specific instructions for configuring your DMARC record with their reporting address. This visibility is invaluable for identifying configuration issues before implementing stricter policies.

Gradual Implementation Strategy

Email authentication is best implemented in two phases to minimize disruption:

Phase 1: Monitoring (2-4 weeks)

  • Implement SPF with ~all (soft fail)
  • Implement DKIM with your email service provider
  • Implement DMARC with p=none
  • Collect and analyze reports to identify legitimate senders

Phase 2: Enforcement (ongoing)

  • Update SPF to use -all (hard fail)
  • Move DMARC to p=quarantine or p=reject
  • Continue monitoring reports regularly

This methodical approach ensures you don't accidentally block legitimate email while still achieving strong authentication.

Conclusion

DKIM and DMARC complete the email authentication trifecta, providing a robust framework for ensuring your Access application's emails reach their intended recipients.

While the technical details may seem daunting, remember that most email service providers handle the complex parts for you. Your primary responsibilities are:

  • Adding the provided DNS records to your domain
  • Implementing a gradual rollout strategy
  • Monitoring authentication reports
  • Working with IT departments when necessary

By following the guidance in this article series, you'll be well-equipped to transition from Outlook automation to modern email delivery methods without sacrificing deliverability or security.

Acknowledgments

  • Article title generated with the help of Claude-3.7-Sonnet
  • Article excerpt generated with the help of Claude-3.7-Sonnet
  • Initial draft generated with the help of Claude-3.7-Sonnet
  • Cover image generated by Imagen3

All original code samples by Mike Wolfe are licensed under CC BY 4.0