Project 9: DMARC Policy Engine

Build an engine that evaluates DMARC policy and alignment based on SPF and DKIM results.

Quick Reference

Attribute Value
Difficulty Advanced
Time Estimate 2-3 weeks
Language Python (Alternatives: Go, Rust)
Prerequisites SPF and DKIM basics, DNS TXT parsing
Key Topics Alignment, policy evaluation, reporting

1. Learning Objectives

  1. Parse DMARC records and tags.
  2. Evaluate SPF/DKIM alignment for the From domain.
  3. Apply DMARC policy to decide pass/quarantine/reject.
  4. Generate a human-readable policy decision report.

2. Theoretical Foundation

2.1 Core Concepts

  • DMARC: Policy layer that ties SPF and DKIM to the visible From domain.
  • Alignment: SPF or DKIM domain must align with From domain (strict or relaxed).
  • Policy tags: p= and sp= define action for domain and subdomains.
  • Reporting: Aggregate and forensic reporting via rua and ruf.

2.2 Why This Matters

DMARC is the final decision maker. It determines whether to accept or reject messages when authentication fails.

2.3 Historical Context / Background

DMARC was introduced to stop spoofing by enforcing consistent domain alignment across email authentication methods.

2.4 Common Misconceptions

  • Misconception: DMARC validates SPF and DKIM itself. Reality: It uses their results.
  • Misconception: DMARC is only about policy. Reality: Alignment is the core logic.

3. Project Specification

3.1 What You Will Build

A CLI tool that takes a message, SPF result, DKIM result, and From domain, then outputs a DMARC decision and explanation.

3.2 Functional Requirements

  1. Fetch DMARC record for a domain (_dmarc.example.com).
  2. Parse tags (p, sp, adkim, aspf, rua).
  3. Evaluate alignment and authentication results.
  4. Produce DMARC disposition and reason.

3.3 Non-Functional Requirements

  • Performance: DMARC evaluation under 200 ms after DNS.
  • Reliability: Handle missing or malformed DMARC records.
  • Usability: Explain alignment decisions clearly.

3.4 Example Usage / Output

$ ./dmarc-eval --from example.com --spf pass --spf-domain mail.example.com --dkim fail
DMARC record: v=DMARC1; p=reject; adkim=s; aspf=r
Alignment: SPF aligned (relaxed), DKIM not aligned
Result: DMARC PASS (SPF aligned)
Disposition: accept

3.5 Real World Outcome

You can determine whether a message should be accepted, quarantined, or rejected based on DMARC rules and alignment.

4. Solution Architecture

4.1 High-Level Design

DMARC Parser
  -> Alignment Engine
  -> Policy Evaluator
  -> Decision Reporter

4.2 Key Components

Component Responsibility Key Decisions
Parser Parse DMARC tags Default values if missing
Alignment Compare domains strict vs relaxed logic
Evaluator Apply p/sp policy Based on pass/fail
Reporter Explain outcome Detailed reasons

4.3 Data Structures

class DmarcRecord:
    def __init__(self, p, sp, adkim, aspf):
        self.p = p
        self.sp = sp
        self.adkim = adkim
        self.aspf = aspf

4.4 Algorithm Overview

Key Algorithm: Alignment

  1. Extract organizational domain from From.
  2. For SPF, compare MAIL FROM or HELO domain.
  3. For DKIM, compare d= domain.
  4. Apply strict (exact match) or relaxed (organizational match).

Complexity Analysis:

  • Time: O(n) for tag parsing and domain comparisons
  • Space: O(1)

5. Implementation Guide

5.1 Development Environment Setup

python -m venv .venv
source .venv/bin/activate

5.2 Project Structure

dmarc-engine/
├── dmarc_parser.py
├── alignment.py
├── policy.py
└── report.py

5.3 The Core Question You’re Answering

“Given authentication results, what action should a receiver take for this domain?”

5.4 Concepts You Must Understand First

Stop and research these before coding:

  1. Organizational domain
  2. SPF and DKIM identifiers
  3. Strict vs relaxed alignment
  4. DMARC policy tags

5.5 Questions to Guide Your Design

  1. How will you determine the organizational domain without public suffix list?
  2. What happens if DMARC record is missing?
  3. How do you apply sp= for subdomains?

5.6 Thinking Exercise

If SPF passes but is not aligned, and DKIM fails, what is the DMARC result? How does policy affect disposition?

5.7 The Interview Questions They’ll Ask

  1. “What is DMARC alignment and why is it needed?”
  2. “What does p=reject mean for a receiver?”
  3. “What is the difference between p and sp?”

5.8 Hints in Layers

Hint 1: Normalize domains

  • Lowercase and remove trailing dots.

Hint 2: Treat missing records as none

  • DMARC none means monitor-only.

Hint 3: Separate alignment from policy

  • Compute pass/fail first, then apply p/sp.

5.9 Books That Will Help

Topic Book Chapter
DMARC spec RFC 7489 Sections 3-6
DNS TXT RFC 1035 Sections 3-5
Email authentication DDIA Ch. 8

5.10 Implementation Phases

Phase 1: Foundation (4-5 days)

Goals:

  • Parse DMARC record

Tasks:

  1. TXT lookup for _dmarc domain.
  2. Parse tag list.

Checkpoint: Print parsed tags.

Phase 2: Core Functionality (1 week)

Goals:

  • Alignment evaluation

Tasks:

  1. Implement strict and relaxed alignment.
  2. Determine DMARC pass/fail.

Checkpoint: Correct output for test scenarios.

Phase 3: Polish and Edge Cases (4-5 days)

Goals:

  • Reporting and policy actions

Tasks:

  1. Apply p/sp and pct.
  2. Provide explanation output.

Checkpoint: Clear report for each outcome.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
Domain alignment strict vs relaxed support both Required by spec
PSL usage include list vs naive include PSL Correct org domain
Output text vs JSON both Integrations

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Unit Tests Tag parsing p=reject, adkim=s
Integration Tests Known domains google.com, yahoo.com
Edge Case Tests No DMARC record default none

6.2 Critical Test Cases

  1. SPF pass aligned -> DMARC pass.
  2. DKIM pass aligned -> DMARC pass.
  3. Neither aligned -> DMARC fail and policy applied.

6.3 Test Data

From: user@example.com
SPF: pass (mail.example.com)
DKIM: fail

7. Common Pitfalls and Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
Wrong alignment logic incorrect fail separate relaxed vs strict
Ignoring sp= wrong subdomain policy apply sp for subdomains
No PSL usage bad org domain use public suffix list

7.2 Debugging Strategies

  • Print alignment comparisons.
  • Test with known DMARC analyzers.

7.3 Performance Traps

  • Re-fetching PSL each run. Cache it locally.

8. Extensions and Challenges

8.1 Beginner Extensions

  • Add pct handling for partial enforcement.
  • Support rua parsing.

8.2 Intermediate Extensions

  • Generate aggregate report samples.
  • Add policy simulation mode.

8.3 Advanced Extensions

  • Integrate with ARC chain evaluation.
  • Build a DMARC policy monitor dashboard.

9. Real-World Connections

9.1 Industry Applications

  • Mail gateways apply DMARC decisions for inbound mail.
  • Deliverability teams monitor DMARC alignment.
  • OpenDMARC: https://github.com/trusteddomainproject/OpenDMARC
  • dmarc-cat: https://github.com/tuck1s/dmarc-cat

9.3 Interview Relevance

  • Alignment and policy logic are core for email security roles.

10. Resources

10.1 Essential Reading

  • RFC 7489 - DMARC spec
  • Public Suffix List - org domain logic

10.2 Video Resources

  • DMARC alignment tutorials

10.3 Tools and Documentation

  • dmarcian for comparison

11. Self-Assessment Checklist

11.1 Understanding

  • I can explain alignment
  • I understand p vs sp
  • I can interpret DMARC outcomes

11.2 Implementation

  • Parses DMARC correctly
  • Applies alignment rules
  • Outputs clear decisions

11.3 Growth

  • I can explain DMARC limitations without ARC
  • I can use DMARC to improve deliverability

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Parse DMARC and compute pass/fail

Full Completion:

  • Apply policy and explain disposition

Excellence (Going Above and Beyond):

  • Add reporting and simulation features

This guide was generated from EMAIL_SYSTEMS_DEEP_DIVE_PROJECTS.md. For the complete learning path, see the parent directory.