DMARC Implementation: From p=none to p=reject in 90 Days
A practical guide to implementing DMARC for email authentication. Stop email spoofing without breaking legitimate mail flow.
Email spoofing remains one of the most effective attack vectors. Attackers impersonate your domain to phish customers, partners, and employees-damaging your reputation and potentially causing direct financial harm. DMARC (Domain-based Message Authentication, Reporting & Conformance) solves this problem by telling receiving mail servers what to do with messages that fail authentication.
Yet most organizations either haven't implemented DMARC or are stuck at p=none-monitoring without enforcement. After implementing DMARC across hundreds of domains, I've developed a systematic approach that reaches full enforcement (p=reject) without disrupting legitimate email.
Understanding the Email Authentication Stack
DMARC doesn't work in isolation. It builds on two underlying authentication mechanisms: SPF and DKIM. Understanding all three is essential for successful implementation.
┌─────────────────────────────────────────────────────────────────────────┐
│ EMAIL AUTHENTICATION FLOW │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ Sender Domain: example.com │
│ ══════════════════════════ │
│ │
│ ┌─────────────┐ ┌─────────────────────┐ │
│ │ Sender │ ──── Email Message ────────► │ Receiving MTA │ │
│ │ (MTA) │ │ (Gmail, O365...) │ │
│ └─────────────┘ └──────────┬──────────┘ │
│ │ │
│ ┌──────────▼──────────┐ │
│ │ DNS LOOKUPS │ │
│ │ │ │
│ │ 1. SPF Record │ │
│ │ ↓ Pass/Fail │ │
│ │ 2. DKIM Signature │ │
│ │ ↓ Pass/Fail │ │
│ │ 3. DMARC Policy │ │
│ │ ↓ Alignment? │ │
│ └──────────┬──────────┘ │
│ │ │
│ ┌──────────▼──────────┐ │
│ │ POLICY ACTION │ │
│ │ │ │
│ │ p=none → Deliver │ │
│ │ p=quarantine → Spam│ │
│ │ p=reject → Bounce │ │
│ └─────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
SPF (Sender Policy Framework) publishes a DNS TXT record listing IP addresses authorized to send mail for your domain. When a server receives mail claiming to be from your domain, it checks if the sending IP is in your SPF record.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to email headers. The receiving server retrieves your public key from DNS and verifies the signature, confirming the message wasn't modified in transit and originated from your domain.
DMARC ties SPF and DKIM together with a policy. It requires that at least one mechanism passes AND aligns with the From header domain. DMARC also requests aggregate and forensic reports, giving you visibility into who's sending mail as your domain.
The Alignment Problem
Here's where many implementations fail. DMARC requires domain alignment-the domain in SPF or DKIM must match the From header domain. This sounds simple but creates complications.
Consider a typical scenario: Your marketing team uses Mailchimp. Mailchimp sends email with a From address of newsletter@yourcompany.com. The sending IP is Mailchimp's infrastructure (not in your SPF). The DKIM signature is from mailchimp.com (not your domain).
Without proper configuration, these legitimate emails fail DMARC alignment. Your options:
- SPF alignment: Add Mailchimp's servers to your SPF record
- DKIM alignment: Configure custom DKIM with your domain
- Subdomain separation: Use
mail.yourcompany.comwith dedicated authentication
The third approach is cleanest for complex sending environments. Each sender gets a subdomain with isolated SPF and DKIM records.
Phase 1: Discovery and Inventory (Weeks 1-2)
Before touching DNS, inventory everything sending email as your domain. This is where most projects fail-they break legitimate mail flow because they didn't know about a legacy system or third-party sender.
Deploy DMARC in Monitoring Mode
Start with a p=none policy that requests reports without affecting delivery:
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; fo=1"
| Tag | Value | Purpose |
|---|---|---|
v | DMARC1 | Protocol version |
p | none | Policy (none/quarantine/reject) |
rua | mailto:... | Aggregate report destination |
ruf | mailto:... | Forensic report destination |
fo | 1 | Failure reporting options |
Aggregate Report Analysis
DMARC aggregate reports (RUA) arrive as XML files-typically daily from major providers. They're not human-readable, so you'll need tooling.
Free options:
- Postmark's DMARC tool (free for low volume)
- dmarcian Free tier (basic analysis)
- Manual XML parsing with scripts
Commercial platforms (recommended for business domains):
- Valimail
- dmarcian
- Agari
- Proofpoint
After 2-4 weeks of data collection, you'll have visibility into:
- All IP addresses sending as your domain
- SPF/DKIM pass rates by source
- Unauthorized senders (potential spoofing)
- Misconfigured legitimate senders
Common Senders to Investigate
Your reports will likely reveal these sources:
| Source Type | Examples | Action Required |
|---|---|---|
| Marketing platforms | Mailchimp, HubSpot, Marketo | Configure DKIM alignment |
| Transactional email | SendGrid, Mailgun, SES | Configure DKIM + SPF |
| CRM systems | Salesforce, Zendesk | Enable DKIM signing |
| Support ticketing | Freshdesk, Intercom | Configure sender authentication |
| Legacy applications | On-prem servers, custom apps | Migrate to authenticated relay |
| Scanning/alerting | Security tools, monitoring | Authenticate or use subdomains |
Phase 2: Authentication Configuration (Weeks 3-6)
With your sender inventory complete, configure authentication for each source.
SPF Record Construction
SPF has a 10 DNS lookup limit. Exceeding this limit causes SPF to fail entirely. Plan your record carefully.
v=spf1 include:_spf.google.com include:sendgrid.net include:spf.mailchimp.com -all
Lookup counting:
- Each
include:= 1+ lookups (recursive) - Each
a:ormx:= 1 lookup - Each
ptr:= 1 lookup (avoid-deprecated) ip4:andip6:= 0 lookups
For complex environments exceeding the limit, use SPF flattening services (e.g., dmarcian, AutoSPF) that resolve includes to IP addresses and maintain automated updates.
DKIM Configuration by Provider
Each third-party sender requires DKIM configuration. The process varies but follows a pattern:
- Generate DKIM keys in the provider's dashboard
- Add CNAME or TXT records to your DNS
- Verify configuration in the provider
- Test with email sent to check service
Example: Mailchimp DKIM Setup
Mailchimp provides two CNAME records:
k1._domainkey.example.com CNAME dkim.mcsv.net
k2._domainkey.example.com CNAME dkim2.mcsv.net
After adding these records, verify in Mailchimp's domain settings and send a test email.
Verification Testing
Use these tools to validate configuration:
# Check SPF record
dig TXT example.com +short | grep spf
# Check DKIM record
dig TXT selector._domainkey.example.com +short
# Check DMARC record
dig TXT _dmarc.example.com +short
Or use online validators:
- MXToolbox (mxtoolbox.com)
- DMARC Analyzer (dmarcanalyzer.com)
- Google Admin Toolbox
Phase 3: Gradual Enforcement (Weeks 7-10)
With authentication configured and pass rates high, begin enforcement gradually.
Move to Quarantine
Update your DMARC policy to quarantine with a percentage:
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com
The pct=10 tag tells receivers to apply the policy to only 10% of failing messages. The rest are treated as p=none. This limits blast radius if something's misconfigured.
Ramp-up schedule:
| Week | pct Value | Policy | Expected Impact |
|---|---|---|---|
| 7 | 10 | quarantine | 10% of failures go to spam |
| 8 | 25 | quarantine | 25% of failures go to spam |
| 9 | 50 | quarantine | 50% of failures go to spam |
| 10 | 100 | quarantine | All failures go to spam |
Monitor reports closely during this phase. Any legitimate sender showing failures needs immediate attention.
Phase 4: Full Rejection (Weeks 11-12)
Once quarantine at 100% runs without issues, move to rejection:
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com
With p=reject, failing emails are bounced-never delivered. This is the goal state. Spoofed emails impersonating your domain are now blocked at receiving mail servers worldwide.
Subdomain Policy
By default, subdomains inherit the parent policy. For tighter control, add explicit subdomain policy:
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com
The sp=reject ensures subdomains are also protected. Without this, attackers might spoof random.example.com if you only protect example.com.
Maintaining DMARC Long-Term
DMARC isn't set-and-forget. Your email ecosystem changes over time.
Ongoing monitoring:
- Review aggregate reports weekly
- Investigate any unexpected sources
- Update SPF/DKIM when adding senders
- Test authentication after DNS changes
Common maintenance issues:
| Issue | Symptom | Solution |
|---|---|---|
| New sender not authenticated | Failures in reports | Configure SPF/DKIM |
| SPF lookup limit exceeded | All SPF checks fail | Flatten or use subdomains |
| DKIM key rotation | Signature failures | Update DNS with new keys |
| Subdomain spoofing | Phishing from subdomains | Add sp=reject policy |
Handling Edge Cases
Forwarding and Mailing Lists
Email forwarding breaks SPF (the forwarding server's IP isn't in your SPF). Mailing lists often modify messages (breaking DKIM). Both cause legitimate DMARC failures.
Mitigations:
- ARC (Authenticated Received Chain) preserves authentication through forwards-major providers support this
- DKIM typically survives if lists don't modify the body
- Accept some failure rate from forwarding (usually < 5%)
Legacy Systems
Some legacy applications can't support modern authentication. Options:
- SMTP relay: Route through an authenticated gateway
- Subdomain isolation: Use legacy.example.com with p=none
- Migration: Replace with modern alternatives
For subdomains that can't be authenticated, explicitly set a relaxed policy:
_dmarc.legacy.example.com TXT "v=DMARC1; p=none"
This prevents the subdomain from inheriting the parent's strict policy while you work on remediation.
Real-World Implementation
A fintech client (B2B payments, 200 employees) needed DMARC at p=reject for vendor security requirements. Starting state: no DMARC, basic SPF, no DKIM on third-party senders.
Discovery findings:
- 14 unique sources sending as their domain
- 3 sources they didn't recognize (legacy apps)
- Marketing emails failing DKIM alignment
- Support system using deprecated sending method
Implementation timeline:
- Week 1-2: Deployed monitoring, analyzed reports
- Week 3-4: Configured DKIM for Mailchimp, SendGrid, Zendesk
- Week 5: Migrated legacy apps to SES with DKIM
- Week 6: SPF consolidation (was at 12 lookups)
- Week 7-9: Quarantine at 25% → 50% → 100%
- Week 10-12: Reject at 25% → 50% → 100%
Results:
- 100% DMARC compliance at p=reject
- 847 spoofing attempts blocked in first month
- Zero legitimate email delivery issues
- Passed vendor security assessment
Next Steps
DMARC implementation protects your domain from impersonation but doesn't protect you from receiving spoofed mail from other domains. Consider complementary controls:
- Inbound filtering: Evaluate sender reputation and authentication
- MTA-STS: Enforce TLS for mail transport
- BIMI: Display verified brand logo in supporting clients
We provide DMARC implementation services with ongoing monitoring. Request an assessment to evaluate your current email authentication posture.
Need help with a complex email environment? We've handled domains with 50+ sending sources and intricate forwarding requirements. Get in touch.