performing-dmarc-policy-enforcement-rollout
Execute a phased DMARC rollout from p=none monitoring through p=quarantine to p=reject enforcement, ensuring all legitimate email sources are authenticated before blocking unauthorized senders.
Best use case
performing-dmarc-policy-enforcement-rollout is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Execute a phased DMARC rollout from p=none monitoring through p=quarantine to p=reject enforcement, ensuring all legitimate email sources are authenticated before blocking unauthorized senders.
Teams using performing-dmarc-policy-enforcement-rollout should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/performing-dmarc-policy-enforcement-rollout/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How performing-dmarc-policy-enforcement-rollout Compares
| Feature / Agent | performing-dmarc-policy-enforcement-rollout | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Execute a phased DMARC rollout from p=none monitoring through p=quarantine to p=reject enforcement, ensuring all legitimate email sources are authenticated before blocking unauthorized senders.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Performing DMARC Policy Enforcement Rollout ## Overview Domain-based Message Authentication, Reporting and Conformance (DMARC) is the cornerstone of email anti-spoofing protection. A DMARC rollout progresses through three phases: monitoring (p=none), quarantine (p=quarantine), and full enforcement (p=reject). When configured at p=reject, any email that fails both SPF and DKIM checks is outright rejected. Google and Yahoo now require DMARC for bulk senders (5,000+ emails), driving a 65% reduction in unauthenticated messages. The rollout typically takes 3-6 months for safe deployment. ## When to Use - When conducting security assessments that involve performing dmarc policy enforcement rollout - When following incident response procedures for related security events - When performing scheduled security testing or auditing activities - When validating security controls through hands-on testing ## Prerequisites - Administrative access to DNS management for the domain - Understanding of SPF, DKIM, and DMARC protocols (RFC 7208, 6376, 7489) - Complete inventory of all legitimate email sending sources - DMARC reporting analysis tool (EasyDMARC, DMARCLY, Valimail, or dmarcian) - Email gateway with DMARC enforcement capability ## Key Concepts ### DMARC Policy Levels | Policy | Behavior | Use Case | |---|---|---| | p=none | Monitor only, no action on failures | Discovery phase | | p=quarantine | Send failing messages to spam/junk | Transition phase | | p=reject | Block failing messages entirely | Full enforcement | ### DMARC Record Anatomy ``` v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-agg@company.com; ruf=mailto:dmarc-forensic@company.com; adkim=r; aspf=r; fo=1 ``` - **p**: Policy for organizational domain - **sp**: Policy for subdomains - **pct**: Percentage of messages subject to policy (for gradual rollout) - **rua**: Aggregate report destination (daily XML reports) - **ruf**: Forensic report destination (per-failure reports) - **adkim**: DKIM alignment mode (r=relaxed, s=strict) - **aspf**: SPF alignment mode (r=relaxed, s=strict) - **fo**: Failure reporting options (0=both fail, 1=either fails) ### SPF and DKIM Alignment - **SPF Alignment**: The domain in the Return-Path (envelope sender) must match the From header domain - **DKIM Alignment**: The d= domain in the DKIM signature must match the From header domain - **Relaxed**: Organizational domain match (sub.example.com matches example.com) - **Strict**: Exact domain match required ## Workflow ### Step 1: Inventory All Sending Sources (Week 1-2) - Audit all systems sending email as your domain (marketing, CRM, ticketing, transactional) - Document third-party services: Salesforce, Mailchimp, SendGrid, Zendesk, etc. - Identify internal mail servers, applications, and relay hosts - Check for shadow IT email sending (departments using unauthorized services) ### Step 2: Configure SPF and DKIM (Week 2-4) - Consolidate SPF record with all legitimate sending IPs and includes - Ensure SPF record stays under 10 DNS lookup limit - Generate and publish DKIM keys for each sending source - Verify DKIM signing works for all outbound mail paths - Test with MX Toolbox or dmarcian SPF/DKIM validators ### Step 3: Deploy DMARC in Monitoring Mode (Week 4-6) - Publish initial DMARC record: `v=DMARC1; p=none; rua=mailto:dmarc@company.com; fo=1` - Wait 1-2 weeks to collect representative aggregate reports - Analyze reports to identify unauthorized senders and alignment failures - Fix SPF/DKIM for all legitimate sources showing failures - Iterate until all legitimate mail passes DMARC ### Step 4: Move to Quarantine with pct Tag (Week 6-12) - Update to quarantine at 10%: `v=DMARC1; p=quarantine; pct=10; rua=...` - Monitor for false positives (legitimate mail being quarantined) - Increase pct gradually: 10% -> 25% -> 50% -> 75% -> 100% - Each increase: wait 1-2 weeks and review reports before advancing - Fix any remaining alignment issues discovered at each stage ### Step 5: Advance to Reject Policy (Week 12-20) - After stable quarantine at 100%, move to reject at 10%: `v=DMARC1; p=reject; pct=10; rua=...` - Gradually increase pct: 10% -> 25% -> 50% -> 100% - Monitor closely for legitimate mail being rejected - Establish emergency rollback procedure (revert to quarantine) - Apply subdomain policy: `sp=reject` for subdomains ### Step 6: Ongoing Monitoring and Maintenance - Continuously monitor DMARC aggregate reports - Add new sending sources before they start sending - Review forensic reports for spoofing attempts - Maintain SPF record as sending infrastructure changes - Rotate DKIM keys annually ## Tools & Resources - **EasyDMARC**: DMARC monitoring dashboard with aggregate/forensic report analysis - **DMARCLY**: SPF, DKIM, DMARC monitoring with auto-DNS updates - **dmarcian**: DMARC deployment and management platform - **Valimail**: Automated DMARC enforcement with hosted authentication - **MX Toolbox**: DNS record lookup and DMARC validator - **Google Admin Toolbox**: DMARC check and diagnostic tools ## Validation - DMARC record published and resolving correctly at _dmarc.domain.com - All legitimate sending sources pass SPF and/or DKIM alignment - Aggregate reports show >99% legitimate mail passing DMARC - Spoofed messages from unauthorized senders are rejected - No legitimate mail blocked after full p=reject enforcement - Subdomain policy (sp=) also set to reject
Related Skills
smack-policy-generator
Generates SMACK policy files from app requirements. Creates mandatory access control rules for process isolation and resource access.
smack-policy-auditor
Analyzes SMACK policy files for correctness, label conflicts, and access control issues. Verifies mandatory access control rules.
performing-yara-rule-development-for-detection
Develop precise YARA rules for malware detection by identifying unique byte patterns, strings, and behavioral indicators in executable files while minimizing false positives.
performing-wireless-security-assessment-with-kismet
Conduct wireless network security assessments using Kismet to detect rogue access points, hidden SSIDs, weak encryption, and unauthorized clients through passive RF monitoring.
performing-wireless-network-penetration-test
Execute a wireless network penetration test to assess WiFi security by capturing handshakes, cracking WPA2/WPA3 keys, detecting rogue access points, and testing wireless segmentation using Aircrack-ng and related tools.
performing-windows-artifact-analysis-with-eric-zimmerman-tools
Perform comprehensive Windows forensic artifact analysis using Eric Zimmerman's open-source EZ Tools suite including KAPE, MFTECmd, PECmd, LECmd, JLECmd, and Timeline Explorer for parsing registry hives, prefetch files, event logs, and file system metadata.
performing-wifi-password-cracking-with-aircrack
Captures WPA/WPA2 handshakes and performs offline password cracking using aircrack-ng, hashcat, and dictionary attacks during authorized wireless security assessments to evaluate passphrase strength and wireless network security posture.
performing-web-cache-poisoning-attack
Exploiting web cache mechanisms to serve malicious content to other users by poisoning cached responses through unkeyed headers and parameters during authorized security tests.
performing-web-cache-deception-attack
Execute web cache deception attacks by exploiting path normalization discrepancies between CDN caching layers and origin servers to cache and retrieve sensitive authenticated content.
performing-web-application-vulnerability-triage
Triage web application vulnerability findings from DAST/SAST scanners using OWASP risk rating methodology to separate true positives from false positives and prioritize remediation.
performing-web-application-scanning-with-nikto
Nikto is an open-source web server and web application scanner that tests against over 7,000 potentially dangerous files/programs, checks for outdated versions of over 1,250 servers, and identifies ve
performing-web-application-penetration-test
Performs systematic security testing of web applications following the OWASP Web Security Testing Guide (WSTG) methodology to identify vulnerabilities in authentication, authorization, input validation, session management, and business logic. The tester uses Burp Suite as the primary interception proxy alongside manual testing techniques to find flaws that automated scanners miss. Activates for requests involving web app pentest, OWASP testing, application security assessment, or web vulnerability testing.