DMARC enforcement with Symantec Email Security: from p=none to p=reject

Domain-based Message Authentication, Reporting and Conformance (DMARC) is the email authentication standard that lets a domain owner tell receivers what to do with mail that fails authentication. Published as a DNS TXT record at _dmarc.yourdomain.com, it consolidates SPF (sender policy framework) and DKIM (domainkeys identified mail) into a policy receivers can enforce. Properly deployed, DMARC makes domain spoofing - the technique behind most Business Email Compromise fraud - essentially impossible.

Most organizations publish DMARC at p=none ("monitor, don't enforce") within an hour. Most never move past it. The journey to p=reject is where the actual security benefit lives, and it is a 6-12 week project most teams underestimate. This article is the playbook for that journey, using Symantec Email Security as the analytics and enforcement layer. For the product overview, see our Email Security implementation page.

Why p=none isn't enough

DMARC at p=none gives you two things: visibility (you receive reports about who is sending mail claiming to be from your domain) and signal to receivers (we know about DMARC, we just haven't hardened yet). It gives you zero protection against spoofing - receivers continue to deliver fraudulent mail to your customers, partners, and employees because your policy says "don't act."

The economic argument: average Business Email Compromise wire fraud is $130K-$5M per incident. A typical enterprise sees 2-5 successful BEC events per year. Moving to p=reject reduces external-spoofing-based BEC by 80-95% (some attackers shift to lookalike domains, which DMARC can't prevent - but the wire-fraud volume drops dramatically). The 6-12 week project pays for itself with one prevented incident.

Phase 1: Publish p=none and start collecting (Week 1)

If you haven't already, publish the basic DMARC record:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

This says: DMARC version 1, policy none (don't enforce), send aggregate reports to dmarc-rua, send forensic reports to dmarc-ruf, generate reports on any auth failure. The rua address gets daily aggregate XML from every major receiver (Google, Microsoft, Yahoo, etc.). The ruf address gets per-message forensic reports (when supported).

You will get hundreds to thousands of report files per week. You cannot read these manually - they are XML, structured, and dense. Feed them to Symantec Email Security's DMARC analytics, or to a third-party DMARC aggregator (Valimail, Dmarcian, EasyDMARC). Symantec Email Security's analytics are good and integrated.

Phase 2: Sender discovery (Weeks 2-4)

The aggregate reports show every IP / service sending mail claiming to be from your domain. Categorize each one:

• Legitimate, authenticated: Your primary mail platform (M365, Google Workspace). Already passing SPF/DKIM. No work needed.
• Legitimate, not authenticated: Marketing platforms (Mailchimp, Marketo, HubSpot), HR systems (Workday notifications), IT alerts (PagerDuty, Splunk), customer support (Zendesk, Salesforce Service Cloud). These need to be fixed.
• Unknown: Services you don't recognize. Investigate - often shadow IT or forgotten integrations.
• Malicious: Actual spoofing attempts. Your DMARC reports show these but you can't stop them yet (p=none).

For a typical mid-sized enterprise, this discovery surfaces 20-50 legitimate-but-unauthenticated senders. Each one needs to be configured with proper SPF and/or DKIM alignment.

Phase 3: Authenticate every legitimate sender (Weeks 3-8)

For each legitimate sender:

1. SPF alignment. Add the sender's IP / domain to your SPF record. Stay within the 10 DNS lookup limit (flatten if needed).
2. DKIM alignment. Configure the sender to sign with your domain (or a subdomain you control). Publish the DKIM public key in DNS.
3. Validate. Send a test message, check the headers for "spf=pass" and "dkim=pass" with d= matching your domain.
4. Monitor reports. Confirm the sender now shows as "DMARC pass" in your DMARC analytics.

This is the slow part. Each sender involves a different vendor's UI, different DNS process, sometimes a vendor support ticket. For SaaS senders, expect 1-3 days per service to get authenticated and verified.

Phase 4: Move to p=quarantine (Weeks 8-10)

After 90%+ of your inbound DMARC reports show pass for legitimate senders, move to quarantine:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]; ..."

Note pct=10 - this tells receivers to apply quarantine policy to 10% of failing mail. Use this to ramp up gradually. After a week of stable pct=10, move to pct=50, then pct=100.

What happens: receivers send unauthenticated mail to spam / quarantine folders. Legitimate senders that you missed start surfacing as user complaints ("my newsletter went to spam"). Fix those, then continue ramping.

Phase 5: Move to p=reject (Weeks 10-12)

Once p=quarantine pct=100 has been stable for 2-3 weeks with minimal legitimate complaints, move to reject:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; ..."

Receivers now drop failing mail entirely. Spoofing of your domain is effectively stopped. Continue monitoring reports - new legitimate senders (acquired companies, new SaaS subscriptions, contractor email systems) will surface and need to be authenticated.

Subdomains and the sp= directive

DMARC's p= directive applies to the organizational domain. Subdomains get a separate directive: sp=. Most organizations start with sp=none even at p=reject, then tighten:

"v=DMARC1; p=reject; sp=none; rua=mailto:..."  // initial
"v=DMARC1; p=reject; sp=quarantine; rua=mailto:..."  // after subdomain audit
"v=DMARC1; p=reject; sp=reject; rua=mailto:..."  // hardened

Marketing subdomains (mail.company.com, newsletter.company.com) often need separate DMARC policies because they have entirely different sender ecosystems. Publish dedicated _dmarc.subdomain.company.com records.

What Symantec Email Security adds

You can do DMARC without Symantec - many free and paid tools exist for report aggregation. But Symantec Email Security integrates the inbound enforcement and the outbound analytics in one place:

• Inbound enforcement. Symantec evaluates DMARC on every inbound email and applies block / quarantine / allow according to your domain's published policy.
• Outbound visibility. The DMARC analytics dashboard shows authentication results per sender, alignment failures, and recommendations.
• Sender categorization. Automatic grouping of senders by category (marketing, transactional, IT, shadow).
• Compliance reporting. Reports for audit teams showing DMARC enforcement coverage and progression.
• Forensic analysis. Per-message detail for failed authentication, useful for incident investigation.

Common pitfalls we have walked into

Moving too fast. Going from p=none to p=reject in a week breaks every legitimate sender you haven't authenticated yet. Marketing teams discover their email "stopped working." Avoid this by progressing gradually.

Missing the forwarders. Many SaaS services forward mail through their own infrastructure (Mailman lists, calendar invite forwarders, ticket systems). Forwarding breaks SPF alignment. DMARC handles this via DKIM alignment - make sure your DKIM signing covers forwarded mail paths.

Ignoring subdomains. A wildcard DMARC record can be tightened on the organizational domain but missed on sub-domains. Audit all subdomains, especially marketing.

Stale SPF. Old SPF records accumulate include directives for services no longer used. Periodically audit and clean. Stale SPF wastes the 10-lookup budget.

BIMI ambition. Brand Indicators for Message Identification (BIMI) requires DMARC p=quarantine or p=reject to deploy. Many organizations start the DMARC journey because they want BIMI; that's fine, but DMARC enforcement itself is the actual security benefit.

What this looks like with CyberKIS

CyberKIS runs DMARC enforcement as a defined engagement: 8-12 weeks from baseline to p=reject. We bring the sender discovery playbook, the SPF / DKIM remediation runbooks, and the Symantec Email Security configuration templates. You bring the DNS access and the SaaS vendor relationships. Output: domain spoofing of your brand is effectively dead, BEC fraud volume drops substantially, and your email authentication posture is at industry best practice.

Want help with DMARC? Talk to a CyberKIS engineer or read the Email Security services page.