SPF, DKIM, DMARC: The Email Authentication Trinity

Research Summary

Email authentication protocols (SPF, DKIM, and DMARC) represent the foundational security layer that municipal IT teams must implement before advanced M365 security features can reach maximum effectiveness. Current research reveals a critical vulnerability: 93.3% of government domains that suffered email spoofing attacks had not enabled email authentication even in monitoring mode, despite these protocols being free to implement and requiring only DNS configuration changes.

The “authentication trinity” works as interdependent building blocks where SPF validates authorized mail servers, DKIM provides cryptographic message signing, and DMARC enforces domain alignment while providing actionable reporting. Microsoft’s official documentation emphasizes that “anything less than all of the email authentication methods results in substandard protection,” yet implementation rates remain extraordinarily low in government sectors.

For municipal environments specifically, the challenge centers on gradual deployment complexity rather than technical difficulty. Small IT teams (2-10 people) face DNS management challenges including fragile text fields requiring precise syntax, lack of validation or testing capabilities, and propagation delays that complicate timely implementation. Industry data shows approximately 80% of organizations attempting email authentication implementation fail to reach enforcement-level policies, typically getting stuck in monitoring mode indefinitely.

Obsidian Vault Sources

• [[Exchange Online Protection (EOP) Advanced Configuration]] - Municipal-specific DNS authentication configuration
• [[Microsoft Defender for Office 365 Best Practices]] - Authentication integration with M365 Defender capabilities
• [[BEC Email Security Practices]] - JP Morgan Chase recommendations for Business Email Compromise prevention
• [[Evolution of Phishing]] - Historical context showing evolution from simple phishing to sophisticated AiTM attacks
• [[How to protect against BEC in M365 Business]] - Protection strategy overview with authentication as foundation
• [[2025-10-02 Three settings that stop 90% of email-based attacks - LinkedIn]] - Published content on M365 underutilization
• [[2025-09-29 The Email Security Crisis Hiding in Plain Sight - Blog]] - Draft examining confidence-reality gap in municipal email security

External Sources

• Microsoft Learn - Email Authentication About (Defender for Office 365) - Official documentation confirming SPF, DKIM, and DMARC as “interdependent building blocks” (https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about)
• Microsoft 2025 Bulk Sender Requirements - May 5, 2025 mandate for organizations sending 5,000+ emails/day (dmarcian.com, redsift.com)
• DMARCLY/Cisco Best Practices - Industry consensus on implementation order and gradual deployment strategies
• Proofpoint/PowerDMARC Government Research - 3,134 government domains hijacked, 93.3% without authentication (proofpoint.com, powerdmarc.com)
• Valimail/NIST DNS Challenges - Technical research on DNS management complexity, 80% failure rate (valimail.com, NIST SP 1800-6B)
• DMARC Monitoring Tools - Budget-friendly options: DMARCReport (free), EasyDMARC ($35.99/mo), DMARCLY ($17.99/mo)
• VEC Statistics 2024-2025 - 66% increase in Vendor Email Compromise attacks, $12.5B total fraud losses (hoxhunt.com, trustpair.com, gfoa.org)

Municipal Context

Municipal organizations face unique email security challenges due to transparency obligations making staff directories, organizational charts, and vendor relationships publicly accessible. High-trust factor of municipal domains (.ca government domains) creates exceptional value for attackers. Municipal emails frequently authorize significant financial transactions, amplifying impact of successful spoofing attacks.

Small municipal IT teams (2-10 staff) face DNS management complexity without dedicated specialists, multiple email sources (M365, website forms, financial systems, emergency alerts), and coordination with external DNS providers. Email authentication protocols offer rare “free” security improvement requiring only DNS configuration without software purchases.

FOIPPA (Freedom of Information and Protection of Privacy Act) creates legal obligations for municipal email security, with recent amendments (Ontario 2025) introducing enhanced compliance requirements. Email authentication supports these obligations by preventing domain spoofing that could lead to unauthorized disclosure of personal information.

Research Gaps

• Municipal-specific authentication adoption rates and implementation timelines
• DNS management workflows for non-technical municipal teams
• DMARC report analysis approaches for small teams (2-10 people)
• Email authentication integration with FOIPPA/FIPPA compliance requirements
• Vendor communication authentication patterns and procurement requirements
• Emergency communication override requirements during crisis situations
• Post-implementation attack prevention measurement and ROI analysis

Content Strategy

Content Premise Validation

Core Argument Assessment: The core premise is exceptionally sound and strategically brilliant for municipal IT professionals. Positioning email authentication as the prerequisite foundation for M365’s advanced features addresses a genuine technical reality—advanced threat protection cannot effectively distinguish legitimate from spoofed emails without reliable authentication signals. This creates a logical bridge from the previous blog post about M365 underutilization, establishing a “fix the foundation before optimizing the features” narrative.

Audience Relevance Check: This content directly addresses real municipal IT challenges with surgical precision. Municipal IT professionals face constant pressure to “do more with security” while lacking clarity on implementation priorities. By explicitly stating “authentication first, advanced features second,” this content provides actionable prioritization that respects their resource constraints. The focus on DNS-only implementation (no workflow changes, no user retraining) directly addresses municipal change management challenges.

Strategic Coherence: The content strategy demonstrates exceptional alignment with stated objectives: bridges logically from previous blog post about M365 underutilization, positions authentication as enabler for advanced features, maintains m365-security theme consistency while establishing technical depth, addresses municipal constraints (small teams, budget limitations, public transparency risks), and balances technical implementation guidance with strategic context.

Conceptual Issues Identified: None. The fundamental approach is architecturally sound.

Strategic Recommendations

Content Strengths:

• Exceptional premise-audience fit with “authentication as foundation for M365 features” positioning
• Outstanding municipal contextualization throughout
• Excellent technical progression from conceptual to tactical to operational
• Strong implementation guidance with concrete code examples
• Effective risk management approach (gradual deployment)
• Research-backed authority without overwhelming readers

Priority Improvements Identified:

1. CRITICAL - Expand M365 Defender Integration section (Lines 222-233): This is the strategic linchpin connecting authentication to M365 features from previous post. Add concrete example showing authentication data enhancing M365 threat detection.

2. HIGH PRIORITY - Enhance DMARC report analysis guidance (Lines 256-259): 80% of organizations get stuck in monitoring mode—practical report analysis guidance reduces this risk. Expand with report structure explanation and prioritization framework.

3. HIGH PRIORITY - Add FOIPPA compliance connection (Lines 295-313): Legal compliance is powerful motivator for municipal IT directors and CAOs. Add 2-3 sentences connecting authentication to FOIPPA obligations within “The Bottom Line” section.

4. MEDIUM PRIORITY - Add resource allocation guidance: Municipal IT directors need realistic time estimates for each implementation phase to justify staff allocation and project planning.

5. MEDIUM PRIORITY - Enhance CTA with tactical action: Add three-step numbered CTA with specific audit tool link to increase reader-to-implementer conversion.

Human Checkpoint: Review strategy assessment and approve priority improvements before proceeding to implementation.

📧 Municipal Email Security Series

• Part 1: The Email Security Crisis Hiding in Plain Sight - Understanding the problem
• Part 2: SPF, DKIM, DMARC: The Email Authentication Trinity ← You are here
• Part 3: Advanced Threat Protection Beyond Basic Email Filtering - Coming soon

The Foundation Your M365 Security Depends On

In our previous post, we examined how municipalities aren’t using the M365 security features they’re already paying for—leaving protection levels on ‘Built-in’ when ‘Strict’ is available. But before you can maximize those advanced features, you need to get the foundation right: email authentication.

Here’s the problem: even if you upgrade to Strict protection policies tomorrow, those sophisticated anti-phishing engines need trustworthy data to work with. They need to know which emails are legitimately from your domain and which are spoofed attempts. That’s where SPF, DKIM, and DMARC come in.

Think of email authentication as the identity verification system for your municipality’s email. Without it, your M365 anti-phishing policies are like having security guards who can’t check IDs—they might catch obvious threats, but sophisticated impersonation attacks will sail right through.

The Authentication Problem in Municipal Email

Municipal domains are prime targets for spoofing because:

• High trust factor - Citizens and vendors trust emails from municipal domains
• Payment authority - Municipal emails often authorize significant financial transactions
• Public contact information - Staff directories and email formats are publicly available
• Complex vendor relationships - Multiple departments work with hundreds of vendors

Attackers exploit this trust by sending emails that appear to come from your domain but actually originate from their infrastructure. Without proper authentication, these spoofed emails can bypass even advanced security solutions.

In the United States, the Cybersecurity and Infrastructure Security Agency (CISA) mandates email authentication for federal agencies through Binding Operational Directive 18-01, requiring all US government domains to implement DMARC at enforcement level. While this is a US federal mandate rather than a Canadian requirement, it establishes the security standard that Canadian municipal governments should consider following—the technical threats and authentication solutions are identical across jurisdictions.

Understanding the Authentication Trinity

Email authentication relies on three interdependent protocols—Microsoft’s official documentation is clear that “anything less than all three results in substandard protection.” Here’s what each one does:

SPF (Sender Policy Framework): Specifies which mail servers are authorized to send email from your domain DKIM (DomainKeys Identified Mail): Provides cryptographic signatures that prove emails haven’t been tampered with in transit DMARC (Domain-based Message Authentication): Defines policies for handling emails that fail SPF or DKIM validation

These protocols work together to create a comprehensive authentication framework that makes domain spoofing significantly more difficult. More importantly, they provide the trust signals that M365’s anti-phishing engines need to distinguish legitimate email from sophisticated spoofing attempts.

As of May 2025, Microsoft requires email authentication (SPF, DKIM, and DMARC) for high-volume senders to outlook.com, hotmail.com, and live.com—routing non-compliant messages to junk folders. This enforcement underscores how critical proper authentication has become for reliable email delivery.

SPF: Authorized Sender Lists

SPF works like a guest list for your email domain. You publish a DNS record that lists all the mail servers authorized to send email on behalf of your municipality.

Basic SPF Implementation for M365:

v=spf1 include:spf.protection.outlook.com -all

This record tells receiving servers:

• Check Microsoft’s SPF record for authorized senders
• Reject any email claiming to be from your domain that doesn’t come from those servers

Municipal SPF Considerations:

Most municipalities need more complex SPF records because they send email from multiple sources:

• M365/Exchange Online
• Website contact forms
• Financial systems
• Public works notifications
• Emergency alert systems

Enhanced SPF Example:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:mailgun.org ip4:192.168.1.100 -all

This allows email from M365, Google services, Mailgun (for automated notifications), and a specific IP address (perhaps for internal systems).

DKIM: Digital Signatures for Email

DKIM adds a cryptographic signature to your emails that proves they came from your domain and haven’t been modified in transit. It’s like a tamper-evident seal on your municipal communications.

M365 DKIM Setup:

Microsoft provides DKIM signing automatically for most domains, but you need to activate it:

1. Generate DKIM keys in the M365 Defender portal
2. Publish CNAME records in your DNS
3. Enable DKIM signing for your domain

DKIM DNS Records (Example):

selector1._domainkey.yourmunicipalitydomain.ca CNAME selector1-yourmunicipalitydomain-ca._domainkey.yourdomain.onmicrosoft.com
selector2._domainkey.yourmunicipalitydomain.ca CNAME selector2-yourmunicipalitydomain-ca._domainkey.yourdomain.onmicrosoft.com

DMARC: The Authentication Policy Engine

DMARC is where SPF and DKIM come together to create actionable policies. It tells receiving mail servers what to do when emails fail authentication checks.

DMARC Implementation Phases:

Phase 1: Monitoring (Recommended Start)

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourmunicipalitydomain.ca

This policy:

• Takes no action on failed authentication
• Sends aggregate reports to your specified email address
• Allows you to understand your email ecosystem before enforcement

Phase 2: Quarantine Mode

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourmunicipalitydomain.ca; ruf=mailto:dmarc-failures@yourmunicipalitydomain.ca

This policy:

• Quarantines 25% of emails that fail authentication
• Gradually increases enforcement while monitoring impact
• Provides both aggregate and forensic reports

Phase 3: Enforcement Mode

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourmunicipalitydomain.ca; ruf=mailto:dmarc-failures@yourmunicipalitydomain.ca

This policy:

• Rejects emails that fail authentication
• Provides maximum protection against domain spoofing
• Should only be implemented after thorough testing

Email Authentication Implementation Guide for Municipal IT Teams

Realistic Resource Requirements:

Before diving into implementation, here’s what you should expect in terms of time investment for a typical municipality:

• Initial audit and planning: 4-6 hours (one-time)
• SPF implementation: 4-8 hours spread over 1-2 weeks (one-time)
• DKIM setup: 2-4 hours (one-time)
• DMARC monitoring phase: 2 hours weekly for 2-3 months (ongoing)
• DMARC enforcement transition: 4-6 hours spread over 1-2 months (one-time)
• Ongoing maintenance: 2-4 hours monthly once stable (ongoing)

For a municipality with 2-3 people handling IT, this represents a manageable project that can run in parallel with other responsibilities. The work comes in small chunks rather than requiring dedicated weeks of focus.

Step 1: Audit Your Current State (Time: 4-6 hours)

Check your existing authentication:

• Use tools like MXToolbox or DMARC Analyzer to assess current SPF, DKIM, and DMARC records (30 minutes)
• Identify all systems that send email from your domain (2-3 hours)
• Document your current email infrastructure (1-2 hours)
• Coordinate with any external DNS providers or web hosting companies (1 hour)

Step 2: Implement SPF (Time: 4-8 hours over 1-2 weeks)

1. Inventory email sources - List all systems that send email from your domain (2-3 hours)
2. Create SPF record - Start with M365 and add other authorized sources (1-2 hours)
3. Test gradually - Use soft fail (~all) initially, then move to hard fail (-all) (1 week monitoring)
4. Monitor for issues - Watch for legitimate emails being blocked (1-2 hours)

Step 3: Enable DKIM (Time: 2-4 hours)

1. Access M365 Defender portal - Navigate to Email & Collaboration > Policies & Rules > Threat policies (15 minutes)
2. Configure DKIM - Generate keys for your domain (15 minutes)
3. Update DNS - Add required CNAME records (30 minutes)
4. Enable signing - Activate DKIM for your domain (15 minutes)
5. Verify operation - Test that emails include DKIM signatures (1-2 hours including testing and troubleshooting)

Step 4: Deploy DMARC Gradually (Time: 2 hours weekly for 2-3 months, then 4-6 hours for enforcement transition)

1. Start with monitoring - Deploy p=none policy with reporting (30 minutes)
2. Analyze reports - Review DMARC reports to understand email patterns (2 hours weekly for 2-3 months)
3. Identify legitimate sources - Ensure all authorized senders pass authentication (included in report analysis time)
4. Implement quarantine - Move to p=quarantine with low percentage (2 hours including testing)
5. Progress to enforcement - Gradually increase to p=reject (2-4 hours over 1-2 months)

Integration with M365 Defender

Proper email authentication enhances M365’s security capabilities by providing trustworthy signals that advanced threat detection engines need to make accurate decisions.

How Authentication Data Strengthens M365 Detection:

Consider this scenario: Your Finance Director receives an email requesting urgent payment to a new vendor account. The email looks legitimate—correct signature, familiar language, appropriate urgency. M365 Defender analyzes multiple signals:

Without authentication, M365 sees:

• Suspicious payment request (content analysis)
• Unusual link pattern (Safe Links analysis)
• No previous communication history (threat intelligence)

Risk score: Medium to High (requires human judgment)

With proper authentication, M365 sees:

• DMARC fail (sender domain doesn’t match authenticated source)
• Suspicious payment request (content analysis)
• Unusual link pattern (Safe Links analysis)
• No previous communication history (threat intelligence)

Risk score: Critical (automatic quarantine or block)

The authentication failure transforms ambiguous indicators into clear evidence of spoofing. This is why email authentication is the foundation—it provides the one signal that attackers can’t easily fake.

Specific M365 Integration Points:

Anti-Phishing Policies: DMARC failures automatically trigger additional scrutiny from M365’s anti-phishing engines. When your anti-phishing policy is set to Strict (as discussed in our previous post), authentication failures combined with content-based indicators result in immediate quarantine rather than just warning banners. (For step-by-step guidance on configuring these policies, see our guide on the three M365 settings that stop 90% of email-based attacks.)

Impersonation Protection: M365’s impersonation protection uses authentication data to distinguish between legitimate emails from known contacts and sophisticated display name spoofing. A DMARC-passing email from your actual Finance Director gets trusted; a DMARC-failing email with the same display name gets blocked.

Safe Links: M365 provides comprehensive URL protection for all email, with options to exclude specific trusted URLs from rewriting if needed. This maintains security vigilance while allowing administrators to customize the user experience for known-safe destinations.

Threat Intelligence: Authentication data feeds into M365’s machine learning algorithms for better threat detection. When M365 sees patterns of DMARC failures combined with specific attack indicators, it applies those learnings across all protected tenants, improving detection for everyone.

Common Municipal Implementation Challenges

Multiple Email Sources Many municipalities send email from various systems. Document everything:

• Municipal website contact forms
• Financial software notifications
• Emergency alert systems
• Third-party services (newsletter platforms, payment processors)

DNS Management Authentication requires DNS changes that might involve multiple teams:

• Work with your DNS provider or web hosting company
• Coordinate with any third-party services that manage DNS
• Plan for DNS propagation delays

Gradual Deployment Don’t implement all three protocols simultaneously:

• Start with SPF to establish authorized senders
• Add DKIM for message integrity
• Deploy DMARC gradually to avoid blocking legitimate email

Report Analysis DMARC reports can be overwhelming, but understanding them is critical to avoiding the trap where 80% of organizations get stuck in monitoring mode indefinitely. Here’s how to make sense of them:

What DMARC Reports Tell You:

DMARC aggregate reports (RUA) arrive daily via email in XML format. Each report shows:

• Which IP addresses sent email claiming to be from your domain
• Whether those emails passed SPF authentication
• Whether those emails passed DKIM authentication
• How many emails came from each source
• How recipient mail servers handled them

Your Three-Step Analysis Process:

Step 1: Identify High-Volume Sources (Week 1-2) Focus first on sources sending more than 100 emails per day. These are typically:

• Your M365 tenant (should pass both SPF and DKIM)
• Newsletter platforms or marketing automation (may need SPF includes)
• Website contact forms (may need configuration)
• Financial systems sending invoices or statements

Step 2: Investigate Authentication Failures (Week 3-4) For any source with DMARC failures:

• Is this a legitimate service you use? If yes, work with vendor to fix authentication
• Is this an unauthorized sender? If yes, this is exactly what DMARC is designed to catch
• Is this email forwarding? Forwarded emails often fail SPF (this is expected)

Step 3: Calculate Compliance Rate (Week 4+) Before moving from monitoring (p=none) to quarantine (p=quarantine), you want:

• 95%+ of legitimate email passing DMARC
• All high-volume sources properly authenticated
• Clear understanding of any remaining failures

Free Tools for Report Analysis:

For small municipal IT teams, these budget-friendly options parse XML reports into readable dashboards:

• DMARCReport (free tier): Basic report parsing and visualization
• Postmark DMARC Digests (free): Email summaries of DMARC reports
• MXToolbox DMARC (free monitoring): Basic compliance tracking

When to Move from Monitoring to Enforcement:

You’re ready to progress from p=none to p=quarantine when:

• You’ve monitored for at least 2-4 weeks
• You can explain every major email source in your reports
• Your legitimate email consistently passes DMARC (95%+ compliance)
• You’ve addressed authentication issues with third-party services
• You have a process for reviewing reports weekly

Don’t rush this phase. The monitoring period is your opportunity to understand your email ecosystem without risking legitimate email delivery. Taking 2-3 months in monitoring mode is better than blocking citizen communications because you moved to enforcement too quickly.

Monitoring and Maintenance

Regular DMARC Report Review

• Weekly analysis during initial deployment
• Monthly review once policies are stable
• Investigate any new unauthorized senders

SPF Record Updates

• Add new email sources to SPF records
• Remove discontinued services
• Monitor for SPF record length limits (DNS has practical limits)

DKIM Key Rotation

• Plan for periodic DKIM key rotation (recommended annually)
• Coordinate with M365 key rotation schedules
• Test new keys before switching

Measuring Success

Authentication Metrics:

• SPF pass rate (target: >95% for legitimate email)
• DKIM signature validation rate (target: >98%)
• DMARC compliance rate (target: >90% before enforcement)

Security Improvements:

• Reduced domain spoofing incidents
• Improved email deliverability
• Enhanced M365 threat detection accuracy

Operational Benefits:

• Better email deliverability to external recipients
• Reduced false positives in security systems
• Improved confidence in email communications

The Bottom Line

Email authentication isn’t just about stopping spoofing—it’s about creating a foundation that makes all your other email security investments more effective. Remember those underutilized M365 Defender capabilities we discussed in the previous post? They work best when they can trust the authentication signals from SPF, DKIM, and DMARC.

For municipalities, proper email authentication is essential because:

• Citizens and vendors trust your domain
• Financial transactions depend on email authenticity
• Public sector targeting makes spoofing attractive to criminals
• Authentication failures can indicate compromise

FOIPPA Compliance Connection:

For BC municipalities, email authentication also supports your FOIPPA compliance obligations in M365. Domain spoofing that leads to unauthorized disclosure of personal information creates legal liability. By implementing SPF, DKIM, and DMARC, you’re establishing technical safeguards that prevent attackers from using your domain to trick recipients into disclosing protected information. When you can demonstrate that your municipality has implemented industry-standard email authentication protocols, you’re showing due diligence in protecting personal information under your control. Understanding the shared responsibility model helps clarify where Microsoft’s security obligations end and yours begin.

Here’s the good news: unlike the M365 features that require policy configuration and change management, email authentication is a DNS-only implementation. You’re not changing workflows, retraining users, or disrupting operations. You’re building the foundation that makes everything else work better.

Don’t let missing email authentication undermine your M365 security investments. SPF, DKIM, and DMARC form the trinity that makes modern email security possible.

Implement them properly, and your municipality’s email will be protected by both authentication and advanced threat detection. Skip them, and even the most sophisticated security policies—including those Strict protection levels—will have blindspots that attackers can exploit.

The choice is clear: authentication first, advanced features second. Your municipality’s email security depends on getting this order right.

Your Next Steps:

1. Audit your current authentication (takes 5 minutes): Use MXToolbox’s Domain Health checker to see your current SPF, DKIM, and DMARC status. Enter your municipality’s domain and look for the authentication section. You might be surprised what’s missing.

2. Document your email sources (takes 1-2 hours): Before you can implement SPF properly, you need to know where your municipality sends email from. Create a spreadsheet listing every system that sends email on your behalf:

• M365/Exchange Online (your primary email system)
• Website contact forms (check with your web hosting provider)
• Financial systems (utility billing, tax notices, etc.)
• Emergency alert systems (if applicable)
• Third-party services (newsletter platforms, payment processors, vendor portals)

3. Plan your implementation timeline: Based on the resource requirements outlined above, schedule the implementation phases:

• Week 1-2: SPF implementation and testing
• Week 3: DKIM setup
• Week 4-16: DMARC monitoring phase (2 hours weekly)
• Month 4-5: DMARC enforcement transition

4. Read our next post: Once you have email authentication properly configured, you’ll be ready to maximize M365’s advanced threat protection capabilities. Our upcoming post will cover how to leverage Safe Attachments, Safe Links, and advanced anti-phishing beyond basic filtering ().

Remember: authentication first, advanced features second. Start with that 5-minute audit today.