NEWRFC 10023 and the _for-sale TXT record: what it means for DNS security Sponsored by

NEWRFC 10023 and the _for-sale TXT record: what it means for DNS security

Missing DMARC Record

Critical email authentication policy missing from DNS

Critical Security Issue

Email Authentication

Anti-Phishing

Critical Security Risk

Your domain lacks DMARC (Domain-based Message Authentication, Reporting & Conformance) records, leaving it vulnerable to email spoofing, phishing attacks, and brand impersonation. Attackers can send emails that appear to come from your domain without authentication.

Understanding DMARC Protection

DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that builds upon SPF and DKIM to provide comprehensive protection against email spoofing. DMARC allows domain owners to publish policies specifying how email receivers should handle messages that fail authentication checks.

Without DMARC, attackers can easily forge emails from your domain to conduct phishing attacks, business email compromise (BEC) scams, and brand impersonation campaigns. Recipients have no reliable way to distinguish legitimate emails from fraudulent ones claiming to be from your organization.

Real-World Attack Impact

Beyond the theoretical risks, the absence of DMARC enables sophisticated email-based attacks in practice. These include executive impersonation for financial fraud, customer phishing campaigns using your brand, vendor impersonation for supply chain attacks, and reputation damage from spam campaigns appearing to originate from your domain. Organizations without DMARC protection report significantly higher rates of successful business email compromise attacks.

With the critical importance of DMARC protection established, implementing comprehensive email authentication becomes essential for preventing domain abuse. The following systematic approach ensures effective DMARC deployment.

DMARC Implementation

Set up DMARC policy to authenticate and protect your email domain

DMARC DNS Record Configuration and Policy Implementation

Implement comprehensive DMARC policy records with progressive enforcement levels, enabling systematic protection against email spoofing while maintaining operational flexibility.

DMARC policy implementation requires careful progression through monitoring, enforcement, and protection phases to ensure legitimate email delivery while blocking authentication failures. Each policy level provides increasing security protection with corresponding operational considerations. Organizations should implement DMARC policies systematically, starting with monitoring to understand email authentication patterns before progressing to enforcement policies that actively protect against domain abuse.

Monitoring Policy Configuration (p=none)

Establish baseline monitoring to understand email authentication patterns:

# DMARC Monitoring Policy - Baseline Data Collection (_dmarc.yourdomain.com)
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

# Monitoring Policy Components:
# _dmarc.yourdomain.com - DNS record name for DMARC policy publication
#   _dmarc: Required DMARC service prefix (identifies DMARC policy record)
#   yourdomain.com: Your domain name (replace with actual domain)
#   DNS record type: TXT (text record containing DMARC policy parameters)

# DMARC Policy Parameters:
# v=DMARC1 - DMARC version identifier (required first parameter)
#   - Specifies DMARC protocol version 1 (current standard)
#   - Must be first parameter in policy record
#   - Required for DMARC validation by email receivers

# p=none - Domain policy: monitoring only, no enforcement action
#   - Allows all emails to pass regardless of authentication status
#   - Collects authentication statistics without affecting email delivery
#   - Essential for understanding legitimate vs illegitimate email sources
#   - Recommended duration: 2-4 weeks for comprehensive baseline data

# rua=mailto:dmarc@yourdomain.com - Aggregate reporting destination
#   - Daily/weekly XML reports containing authentication statistics
#   - Volume data showing passed/failed authentication attempts
#   - Source IP addresses and sending infrastructure analysis
#   - Critical for understanding email authentication landscape

Monitoring policy enables comprehensive data collection about email authentication patterns without affecting legitimate email delivery, providing the foundation for informed enforcement decisions.

Quarantine Policy Implementation (p=quarantine)

Transition to active enforcement with controlled quarantine policies:

# DMARC Quarantine Policy - Controlled Enforcement (_dmarc.yourdomain.com)
_dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100"

# Quarantine Policy Enhancement:
# p=quarantine - Domain policy: quarantine authentication-failing emails
#   - Suspicious emails delivered to recipient spam/junk folders
#   - Provides active protection without complete email blocking
#   - Enables monitoring of policy impact on email deliverability
#   - Intermediate step toward full rejection policy

# pct=100 - Percentage of failing emails to apply policy to
#   - pct=100: Apply quarantine to 100% of authentication failures (full enforcement)
#   - pct=25: Apply to 25% of failures (gradual rollout option)
#   - pct=50: Apply to 50% of failures (progressive implementation)
#   - Enables gradual policy testing and validation

# Quarantine Policy Benefits:
# - Active protection against domain spoofing attempts
# - Maintains email deliverability while implementing security controls
# - Provides operational data for optimizing authentication configuration
# - Enables confidence building before implementing rejection policies

# Advanced Quarantine Configuration (optional):
# _dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; pct=25; rua=...; ruf=...; fo=1"
#   pct=25: Start with 25% enforcement for gradual implementation
#   ruf=mailto:address: Forensic reports for individual failure analysis
#   fo=1: Generate forensic reports for alignment failures

Quarantine policy provides active email security enforcement while maintaining controlled risk management through percentage-based rollout and spam folder delivery.

Rejection Policy Configuration (p=reject)

Implement maximum security enforcement with strict authentication requirements:

# DMARC Rejection Policy - Maximum Security Enforcement (_dmarc.yourdomain.com)
_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; aspf=s; adkim=s"

# Maximum Security Policy Configuration:
# p=reject - Domain policy: reject all authentication-failing emails
#   - Complete blocking of emails that fail SPF and DKIM authentication
#   - Provides strongest protection against domain spoofing attacks
#   - Eliminates recipient exposure to potentially fraudulent emails
#   - Requires complete confidence in authentication infrastructure

# aspf=s - SPF alignment mode: strict (exact domain matching)
#   - Return-Path domain must exactly match From: header domain
#   - Prevents subdomain-based SPF authentication bypass
#   - bounce.yourdomain.com cannot validate emails from yourdomain.com
#   - Enhanced security but requires precise email infrastructure configuration

# adkim=s - DKIM alignment mode: strict (exact domain matching)
#   - DKIM signature domain must exactly match From: header domain
#   - Prevents subdomain-based DKIM authentication bypass
#   - mail.yourdomain.com DKIM signature cannot validate yourdomain.com emails
#   - Maximum cryptographic security with exact domain requirements

# Rejection Policy Security Benefits:
# - Complete elimination of spoofed emails reaching recipients
# - Maximum brand protection and recipient security
# - Industry-leading email authentication implementation
# - Zero tolerance for authentication failures

# Production Rejection Configuration (comprehensive):
# _dmarc.yourdomain.com TXT "v=DMARC1; p=reject; sp=reject; rua=...; ruf=...; 
#                            aspf=s; adkim=s; pct=100; ri=86400; fo=1"
#   sp=reject: Subdomain policy (comprehensive domain protection)
#   ri=86400: Daily aggregate reports (86400 seconds = 24 hours)
#   fo=1: Forensic reporting for alignment failures

Rejection policy provides maximum email authentication security through complete blocking of authentication failures with strict alignment requirements for comprehensive domain protection.

DMARC Policy Parameters

Key DMARC configuration options:

• v=DMARC1: Version identifier (required)
• p=none/quarantine/reject: Policy for domain alignment failures
• rua=mailto:address: Aggregate report destination
• ruf=mailto:address: Forensic report destination
• pct=100: Percentage of messages to apply policy to
• aspf=r/s: SPF alignment mode (relaxed/strict)
• adkim=r/s: DKIM alignment mode (relaxed/strict)

DMARC Prerequisites Verification and Authentication Foundation

Establish comprehensive email authentication infrastructure verification to ensure proper SPF and DKIM configuration before DMARC implementation.

DMARC implementation requires functional SPF and DKIM authentication mechanisms as foundational components for email validation. Organizations must verify proper configuration of both authentication systems before deploying DMARC policies to prevent unintended email blocking and ensure effective domain protection. Prerequisite validation includes DNS record verification, authentication testing, and infrastructure compatibility assessment.

SPF Record Validation and Configuration Assessment

Verify Sender Policy Framework (SPF) record configuration and DNS publication:

# SPF Record Verification - DNS Configuration Validation
dig yourdomain.com TXT | grep "v=spf1"

# SPF Verification Command Analysis:
# dig yourdomain.com TXT - Query all TXT records for domain
#   dig: DNS lookup utility for record retrieval
#   yourdomain.com: Replace with your actual domain name
#   TXT: DNS record type containing SPF policy data

# grep "v=spf1" - Filter output to show only SPF records
#   v=spf1: SPF version identifier (required SPF record prefix)
#   Searches DNS query results for valid SPF record format
#   Confirms SPF record presence and proper version specification

# Expected SPF Record Format:
# yourdomain.com. IN TXT "v=spf1 include:_spf.google.com ~all"
#   v=spf1: SPF version identifier (required first parameter)
#   include: mechanism: Include another domain's SPF policy
#   ~all: Soft fail qualifier (suspicious but allow delivery)
#   -all: Hard fail qualifier (reject unauthorized senders)

# SPF Validation Checks:
# 1. Record exists and contains "v=spf1" identifier
# 2. Authorized sending sources properly included (include:, ip4:, ip6:)
# 3. Appropriate failure policy specified (~all or -all)
# 4. DNS lookup count within RFC limits (10 lookup maximum)

# Advanced SPF Validation:
nslookup -type=TXT yourdomain.com          # Alternative DNS lookup method
host -t TXT yourdomain.com                 # Another verification option
dig +short TXT yourdomain.com | grep spf1  # Simplified SPF record display

SPF record validation ensures proper sender authorization configuration, which DMARC relies upon for authentication alignment and policy enforcement effectiveness.

DKIM Record Verification and Cryptographic Key Validation

Verify DKIM (DomainKeys Identified Mail) record configuration and public key availability:

# DKIM Record Verification - Cryptographic Key Validation
dig default._domainkey.yourdomain.com TXT

# DKIM Verification Command Structure:
# dig default._domainkey.yourdomain.com TXT - Query DKIM selector record
#   default: DKIM selector name (commonly used selector identifier)
#   _domainkey: DKIM service identifier (required DKIM DNS prefix)
#   yourdomain.com: Domain name (replace with your actual domain)
#   TXT: DNS record type containing DKIM public key data

# Expected DKIM Record Format:
# default._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
#   v=DKIM1: DKIM version identifier (required first parameter)
#   k=rsa: Key algorithm (RSA public key cryptography)
#   p=: Public key data (base64 encoded RSA public key)

# DKIM Validation Requirements:
# 1. DNS record exists at correct selector location
# 2. Record contains proper DKIM version identifier (v=DKIM1)
# 3. Public key data present and properly formatted (p= parameter)
# 4. Key algorithm specified (k=rsa for RSA keys)
# 5. Record length within DNS TXT record limits (255 chars per string)

# Multiple Selector Verification (if applicable):
dig google._domainkey.yourdomain.com TXT    # Google Workspace selector
dig s1._domainkey.yourdomain.com TXT        # SendGrid selector  
dig selector1._domainkey.yourdomain.com TXT # Generic selector
dig mail._domainkey.yourdomain.com TXT      # Mail service selector

# DKIM Record Content Validation:
dig +short TXT default._domainkey.yourdomain.com | grep -E "v=DKIM1"
#   +short: Display only record value (simplified output)
#   grep -E "v=DKIM1": Filter for valid DKIM records
#   Confirms proper DKIM record format and version

DKIM record validation ensures cryptographic email signing infrastructure is properly configured, enabling DMARC to verify message integrity and sender authenticity.

Email Authentication Testing and Infrastructure Validation

Perform comprehensive email authentication testing to validate SPF and DKIM functionality:

# Email Authentication Testing - Infrastructure Validation
echo "Test email content" | mail -s "Authentication Test" test@example.com

# Email Testing Command Structure:
# echo "Test email content" - Generate test email body content
#   Simple text message for authentication testing purposes
#   Can be replaced with more detailed test content if needed

# mail -s "Authentication Test" test@example.com - Send test email
#   mail: Command-line email sending utility
#   -s "Authentication Test": Email subject line for identification
#   test@example.com: Destination email address (replace with test address)

# Authentication Testing Process:
# 1. Email sent through local mail server infrastructure
# 2. SPF authentication applied based on sending IP address
# 3. DKIM signature added using configured private key
# 4. Receiving server validates authentication mechanisms
# 5. DMARC alignment checked against From: header domain

# Advanced Authentication Testing Methods:
# swaks --to test@example.com --from you@yourdomain.com --server smtp.yourdomain.com
#   swaks: Swiss Army Knife SMTP tool for detailed testing
#   --from: Specify sender address for authentication testing
#   --server: Use specific SMTP server for controlled testing

# OpenSSL SMTP Testing (advanced):
# openssl s_client -starttls smtp -connect smtp.yourdomain.com:587
#   Direct SMTP connection testing with TLS support
#   Enables manual SMTP command testing and authentication verification

# Authentication Result Analysis:
# Check email headers at destination for authentication results:
#   Authentication-Results: SPF and DKIM validation outcomes
#   DKIM-Signature: Presence of DKIM signature header
#   Received-SPF: SPF validation result and policy evaluation

Comprehensive email authentication testing validates the complete email security infrastructure, ensuring DMARC policies can effectively evaluate and enforce authentication requirements.

Policy Deployment Strategy

Implement DMARC gradually to avoid blocking legitimate emails

Phase 1: Monitoring (p=none)

Start with monitoring-only policy to collect data:

# Phase 1: Monitoring-only DMARC policy (p=none)
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; sp=none; adkim=r; aspf=r"
# v=DMARC1 - DMARC version identifier (required first parameter)
# p=none - main domain policy: monitor only, no enforcement action taken
# rua=mailto:address - aggregate reports destination (daily/weekly XML reports)
# sp=none - subdomain policy: inherit main domain policy (monitoring mode)
# adkim=r - DKIM alignment mode: relaxed (allows organizational domain matches)
# aspf=r - SPF alignment mode: relaxed (allows subdomain matches)
# No percentage specified = applies to 100% of messages

• Monitor for 2-4 weeks to identify all legitimate email sources
• Analyze aggregate reports to understand email authentication status
• Identify and fix any SPF or DKIM configuration issues
• Document all authorized email sending sources

Phase 2: Quarantine (p=quarantine)

Move to quarantine policy for suspicious emails:

# Phase 2: Gradual quarantine enforcement with percentage control
_dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com; fo=1"
# v=DMARC1 - DMARC version identifier (required)
# p=quarantine - policy action: send failing messages to spam/quarantine folder
# pct=25 - percentage of messages to apply policy to (start small, increase gradually)
# rua=mailto:address - aggregate reports for daily analysis (XML format)
# fo=1 - forensic options: generate forensic report if either SPF or DKIM fails
# Gradually increase pct from 25% → 50% → 75% → 100% over weeks

• Start with 25% policy application, increase gradually
• Monitor for any legitimate emails being quarantined
• Adjust SPF/DKIM configurations if needed
• Increase percentage to 100% once confident

Phase 3: Reject (p=reject)

Final phase with strict rejection policy:

# Phase 3: Strict rejection policy with maximum security
_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; adkim=s; aspf=s; pct=100; ri=86400"
# v=DMARC1 - DMARC version identifier (required)
# p=reject - policy action: reject/block all failing authentication messages
# rua=mailto:address - aggregate reports destination (XML format, daily/weekly)
# ruf=mailto:address - forensic reports destination (individual failure reports)
# adkim=s - DKIM alignment mode: strict (exact domain match required)
# aspf=s - SPF alignment mode: strict (exact domain match required)  
# pct=100 - apply policy to 100% of messages (maximum enforcement)
# ri=86400 - report interval: request daily aggregate reports (86400 seconds = 24 hours)

• Blocks all unauthenticated emails claiming to be from your domain
• Provides maximum protection against email spoofing
• Monitor forensic reports for attack attempts
• Maintain ongoing monitoring of aggregate reports

Ongoing Management

Maintain and optimize DMARC implementation for continued protection

DNS Server DMARC Implementation

Platform-specific DMARC configuration examples:

BIND DNS Server Configuration and Zone File Management

Configure DMARC records in BIND zone files with comprehensive policy parameters:

; BIND Zone File Configuration - DMARC Policy Implementation
; /var/named/example.com.zone

; Primary DMARC Policy Record - Comprehensive Security Configuration
_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com; pct=100; adkim=s; aspf=s"

; BIND Zone File Configuration Components:
; _dmarc.example.com. - DMARC policy record name (note trailing dot for FQDN)
; IN - Internet class (standard DNS record class)
; TXT - DNS record type for DMARC policy data
; "policy_string" - DMARC policy parameters in quoted string format

; DMARC Policy Parameters Breakdown:
; v=DMARC1: DMARC version identifier (required first parameter)
; p=quarantine: Domain policy for authentication failures
; rua=mailto:dmarc@example.com: Aggregate reports email destination
; ruf=mailto:dmarc-forensic@example.com: Forensic reports email destination
; pct=100: Apply policy to 100% of failing messages
; adkim=s: DKIM alignment strict mode (exact domain matching)
; aspf=s: SPF alignment strict mode (exact domain matching)

; Subdomain-Specific DMARC Policy (optional)
_dmarc.mail.example.com.    IN    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
; Subdomain policy for mail.example.com subdomain
; p=reject: Stricter policy for mail infrastructure subdomain
; Inherits aggregate reporting from main domain configuration

; Zone File Reload Commands:
; systemctl reload named     # Reload BIND configuration
; rndc reload example.com    # Reload specific zone file
; named-checkzone example.com /var/named/example.com.zone  # Validate zone syntax

BIND zone file configuration enables comprehensive DMARC policy management with full parameter control and subdomain-specific policy customization.

PowerDNS Database Configuration and SQL Management

Configure DMARC records in PowerDNS database with proper SQL record insertion:

-- PowerDNS Database Configuration - DMARC Record Management
-- INSERT DMARC policy record into PowerDNS records table

INSERT INTO records (domain_id, name, type, content, ttl, prio, disabled)
VALUES (1, '_dmarc.example.com', 'TXT', 
        'v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=s', 
        3600, 0, 0);

-- PowerDNS SQL Parameters:
-- domain_id: Foreign key reference to domains table (replace 1 with actual domain ID)
-- name: Full DNS record name (_dmarc.example.com)
-- type: DNS record type (TXT for DMARC policies)
-- content: DMARC policy string with all required parameters
-- ttl: Time To Live in seconds (3600 = 1 hour, recommended for DMARC)
-- prio: Priority field (0 for TXT records, not used for DMARC)
-- disabled: Record status (0 = enabled, 1 = disabled)

-- Query Domain ID for Reference:
SELECT id FROM domains WHERE name = 'example.com';
-- Use result as domain_id in records table INSERT statement

-- Verify DMARC Record Creation:
SELECT name, type, content, ttl FROM records 
WHERE name LIKE '%_dmarc%' AND type = 'TXT';
-- Confirms DMARC record properly inserted and configured

-- Update Existing DMARC Record:
UPDATE records 
SET content = 'v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s'
WHERE name = '_dmarc.example.com' AND type = 'TXT';
-- Modify DMARC policy from quarantine to reject enforcement

-- PowerDNS Service Management:
-- systemctl restart pdns          # Restart PowerDNS service
-- pdns_control reload             # Reload PowerDNS configuration
-- pdns_control list-zones         # List configured DNS zones

PowerDNS database configuration enables dynamic DMARC policy management through SQL operations with comprehensive record tracking and modification capabilities.

Cloudflare API Configuration and Automated Management

Configure DMARC records via Cloudflare API with comprehensive automation support:

# Cloudflare API Configuration - DMARC Record Automation
# Create DMARC policy record via Cloudflare REST API

curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records" \
     -H "X-Auth-Email: email@example.com" \
     -H "X-Auth-Key: API_KEY" \
     -H "Content-Type: application/json" \
     --data '{
       "type": "TXT",
       "name": "_dmarc",
       "content": "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=s",
       "ttl": 3600,
       "comment": "DMARC email authentication policy"
     }'

# Cloudflare API Configuration Parameters:
# X-Auth-Email: Cloudflare account email address
# X-Auth-Key: Global API key from Cloudflare dashboard
# ZONE_ID: DNS zone identifier (found in domain overview)
# Content-Type: JSON content type for API request body

# DNS Record Parameters:
# type: "TXT" - DNS record type for DMARC policies
# name: "_dmarc" - Record name (Cloudflare automatically appends domain)
# content: DMARC policy string with comprehensive security parameters
# ttl: 3600 - Time To Live in seconds (1 hour recommended)
# comment: Optional description for record identification

# Alternative Authentication (API Token - Recommended):
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records" \
     -H "Authorization: Bearer API_TOKEN" \
     -H "Content-Type: application/json" \
     --data '{"type":"TXT","name":"_dmarc","content":"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"}'
# API Token: Scoped token with Zone:DNS:Edit permissions (more secure)

# Retrieve Zone ID:
curl -X GET "https://api.cloudflare.com/client/v4/zones?name=example.com" \
     -H "X-Auth-Email: email@example.com" \
     -H "X-Auth-Key: API_KEY"
# Extract zone_id from response for use in DNS record operations

# Update Existing DMARC Record:
curl -X PUT "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records/RECORD_ID" \
     -H "Authorization: Bearer API_TOKEN" \
     -H "Content-Type: application/json" \
     --data '{"type":"TXT","name":"_dmarc","content":"v=DMARC1; p=reject; rua=mailto:dmarc@example.com"}'
# RECORD_ID: DNS record identifier from initial creation or list operation

Cloudflare API configuration enables automated DMARC policy management with comprehensive record control, authentication options, and integration capabilities for DevOps workflows.

Report Analysis and Monitoring

Regularly analyze DMARC reports for security insights:

• Set up automated processing of XML aggregate reports
• Monitor for new unauthorized email sources
• Track authentication success rates and failure patterns
• Identify potential spoofing attempts and attack campaigns
• Use DMARC analyzer tools for report visualization

Advanced Configuration

Optimize DMARC for specific use cases:

• Configure subdomain policies (sp=) for different subdomain handling
• Implement forensic reporting (ruf=) for detailed attack analysis
• Set appropriate report intervals (ri=) for aggregate reports
• Use failure reporting options (fo=) for specific failure types
• Consider third-party DMARC management services for complex environments

Best Practices

• Regular review and update of email authentication records
• Coordination with email service providers for proper configuration
• Staff training on email security and DMARC benefits
• Integration with security incident response procedures
• Periodic testing of email authentication effectiveness
• Documentation of authorized email sending infrastructure

Last updated: January 8, 2026