Classification: Perimeter Defense & Mail Authentication
Status: Implemented & Verified

Executive Summary#

This report covers auditing, remediating, and enforcing cryptographic and domain-level email authentication records (SPF, DKIM, and DMARC) across a multi-service custom domain. The objective was resolving silent delivery failures for automated application notifications, aligning third-party transactional mail providers, and enforcing a strict quarantine policy to protect domain reputation against spoofing and phishing attempts.

Threat Model & Problem Statement#

When operating self-hosted services alongside third-party transactional email relays and professional mail routing, misaligned authentication headers lead to two major failure modes:

  1. Silent Delivery Rejection & Spam Classification: Receiving mail transfer agents (Google Workspace, Proton, Microsoft 365) apply strict scoring algorithms. Automated transactional messages originating without aligned SPF or valid DKIM signatures fail basic reputation checks and get silently dropped or routed to spam folders.
  2. Domain Spoofing & Phishing Vulnerability: Operating a naked or permissive DMARC record (p=none) without cryptographic alignment reporting allows unauthorized threat actors to spoof the envelope From: address, damaging domain reputation without the owner’s knowledge.

Diagnostic & Architectural Analysis#

Initial Audit & Identified Gaps#

  • SPF Sprawl & Syntax Limits: Multiple transactional services were attempting to deliver mail without explicit authorization in the root TXT record, risking DNS lookup limits.
  • DKIM Alignment Mismatches: Transactional notifications lacked public key cryptographic selectors corresponding to the sending subdomain headers.
  • Permissive DMARC Policy: No aggregate (rua) telemetry reporting was configured, meaning delivery anomalies and spoof attempts were invisible.

Remediation & Implementation Steps#

1. SPF Record Consolidation & Strict Failure Enforcement#

The root SPF record was structured to explicitly authorize primary mail relays and transactional infrastructure while strictly dropping all unlisted senders via a hard fail (-all):

v=spf1 include:_spf.mxroute.com include:sendgrid.net -all

2. Cryptographic DKIM Key Generation & Selector Alignment#

Public 2048-bit RSA keys were published as dedicated DNS TXT/CNAME records matching the cryptographic selectors required by active relays, ensuring cryptographic signing for all outgoing envelopes.

3. Progressive DMARC Enforcement & Telemetry Parsing#

To enforce strict boundary protection without causing accidental legitimate mail loss, the DMARC policy was transitioned from monitoring to strict quarantine with automated aggregate reporting:

DNS Zone file
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@ownchain.systems; ruf=mailto:dmarc-forensics@ownchain.systems; pct=100; sp=quarantine;

Verification & Validation#

Header Inspection: Evaluated incoming message headers across major consumer and enterprise MX hosts to verify passing status:

spf=pass

dkim=pass

dmarc=pass (p=QUARANTINE sp=QUARANTINE)

Automated Telemetry Auditing: Reviewed incoming aggregate XML reports to verify zero valid transactional notifications were dropped while unauthorized spoofing attempts were quarantined at the edge.

Key Takeaway#

Email security is not set-and-forget; it requires end-to-end alignment. Strict DMARC enforcement (p=quarantine or p=reject) is only reliable when every internal service and transactional relay has been explicitly mapped, authenticated with SPF, and signed with verified DKIM keys.