SMB Security

Email Security Best Practices: SPF, DKIM, and DMARC Explained

Email authentication protocols protect your business from spoofing and phishing. Learn how SPF, DKIM, and DMARC work and why they're essential for email security.

SimplCyber TeamDecember 8, 202410 min read

Why Email Authentication Matters

Email's fundamental design flaw is that anyone can claim to send from any address. Without authentication, attackers easily impersonate your business to scam customers, vendors, or employees. Three email authentication protocols—SPF, DKIM, and DMARC—work together to prove that emails claiming to be from your domain are actually legitimate.

Beyond security, these protocols improve email deliverability. Major email providers increasingly reject or filter unauthenticated emails, meaning messages from your business may never reach recipients without proper authentication.

The Three Pillars of Email Authentication

Think of email authentication like verifying someone's identity with multiple forms of ID:

  • SPF (Sender Policy Framework): Verifies the sender's IP address against an approved list
  • DKIM (DomainKeys Identified Mail): Provides a cryptographic signature proving the email wasn't modified
  • DMARC (Domain-based Message Authentication, Reporting and Conformance): Tells receiving servers what to do if SPF or DKIM checks fail, and provides reporting

All three work together to provide comprehensive email authentication.

SPF: Sender Policy Framework

What SPF Does

SPF allows you to publish a list of IP addresses and servers authorized to send email on behalf of your domain. When someone receives an email claiming to be from your domain, their email server checks whether it came from an approved source.

How SPF Works

  1. You publish an SPF record in your domain's DNS
  2. The SPF record lists all servers/IPs authorized to send email for your domain
  3. When receiving servers get email from your domain, they check the sender's IP against your SPF record
  4. Emails from unauthorized IPs can be rejected or flagged as suspicious

Creating an SPF Record

An SPF record is a TXT record in your DNS that looks like this:

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

Breaking this down:

  • v=spf1: This is an SPF version 1 record
  • include:_spf.google.com: Authorizes Google Workspace to send email for your domain
  • include:spf.protection.outlook.com: Authorizes Microsoft 365 to send email
  • -all: Reject emails from any other source (alternative: ~all for soft fail)

Common SPF Mechanisms

  • ip4:192.0.2.0/24: Authorize a specific IP address or range
  • include:domain.com: Include another domain's SPF policy
  • a: Authorize the domain's A record IP
  • mx: Authorize IPs of the domain's MX records

SPF Best Practices

Be Comprehensive: Include all legitimate email sources:

  • Email service provider (Google, Microsoft, etc.)
  • Marketing platforms (Mailchimp, Constant Contact, etc.)
  • CRM systems (Salesforce, HubSpot, etc.)
  • Ticketing systems (Zendesk, Freshdesk, etc.)
  • Any other service that sends email as your domain

Don't Exceed DNS Lookup Limits: SPF has a 10 DNS lookup limit. Too many include: statements can break your SPF record.

Use -all for Strict Policy: The -all mechanism tells receiving servers to reject emails from unauthorized sources. Use ~all (soft fail) only during initial testing.

Monitor and Update: When adding new email services, update your SPF record immediately.

Testing Your SPF Record

Use online tools to validate:

  • MXToolbox SPF Checker
  • dmarcian SPF Inspector
  • Google Admin Toolbox Messageheader

DKIM: DomainKeys Identified Mail

What DKIM Does

DKIM adds a digital signature to every email sent from your domain. This signature proves:

  • The email actually came from your domain
  • The message wasn't altered in transit

How DKIM Works

  1. Your email server generates a public/private key pair
  2. The private key signs outgoing emails
  3. The public key is published in your DNS
  4. Receiving servers use the public key to verify the signature
  5. If the signature matches, the email is authentic and unmodified

Setting Up DKIM

DKIM setup is typically handled by your email provider:

Google Workspace:

  1. Generate DKIM key in Google Admin Console
  2. Add provided TXT record to your DNS
  3. Enable DKIM signing in Google Admin

Microsoft 365:

  1. Enable DKIM signing in Microsoft 365 Admin Center
  2. Copy provided CNAME records
  3. Add CNAME records to your DNS

Other Providers: Follow provider-specific instructions for key generation and DNS record creation.

DKIM Record Example

A DKIM DNS record looks like:

default._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."

Where:

  • default._domainkey: The selector (can be customized)
  • v=DKIM1: DKIM version
  • k=rsa: Key type (RSA)
  • p=...: The public key

DKIM Best Practices

Use 2048-bit Keys: Provides strong cryptographic protection (1024-bit is becoming deprecated)

Rotate Keys Periodically: Change DKIM keys annually for security

Use Multiple Selectors: Different keys for different mail streams enable granular troubleshooting

Sign All Outgoing Email: Ensure DKIM signing is enabled for all email types

Testing DKIM

Send test emails to:

  • Gmail account (check original message headers)
  • Mail-tester.com
  • DKIM validator tools

Look for DKIM=PASS in authentication results.

DMARC: Bringing It All Together

What DMARC Does

DMARC builds on SPF and DKIM to:

  • Specify what receiving servers should do with emails that fail authentication
  • Provide reports showing who's sending email using your domain
  • Prevent domain spoofing in phishing attacks

How DMARC Works

  1. You publish a DMARC policy in your DNS
  2. The policy specifies actions for failed authentication (none, quarantine, reject)
  3. Receiving servers check SPF and DKIM
  4. If checks fail, they follow your DMARC policy
  5. Receiving servers send reports about email authentication results

Creating a DMARC Record

A DMARC record is a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; aspf=s; adkim=s

Breaking this down:

  • v=DMARC1: DMARC version
  • p=reject: Policy for failed authentication (none, quarantine, reject)
  • pct=100: Percentage of emails to apply policy to (100%)
  • rua=mailto:...: Address for aggregate reports
  • ruf=mailto:...: Address for forensic reports
  • aspf=s: Strict SPF alignment
  • adkim=s: Strict DKIM alignment

DMARC Policies Explained

p=none (Monitor Only)

  • No action taken on failed emails
  • Use during initial setup to monitor impact
  • Still receive reports to identify issues

p=quarantine

  • Failed emails sent to spam/junk folder
  • Intermediate policy during rollout
  • Balances security with deliverability risk

p=reject

  • Failed emails completely rejected
  • Strongest protection against spoofing
  • Final goal for mature DMARC implementation

DMARC Alignment

DMARC requires "alignment" between authenticated domain and "From" address:

Relaxed Alignment: Subdomains match (default)

  • Email from news.example.com passes for example.com domain

Strict Alignment: Exact match required

  • Only example.com passes for example.com
  • More secure but requires careful configuration

DMARC Reports

DMARC generates two types of reports:

Aggregate Reports (RUA)

  • Daily XML reports summarizing authentication results
  • Show all sources sending email as your domain
  • Help identify legitimate services needing SPF/DKIM setup
  • Identify spoofing attempts

Forensic Reports (RUF)

  • Real-time reports of individual authentication failures
  • Include email headers and sometimes content
  • Privacy concerns limit adoption
  • Useful for troubleshooting specific issues

Processing DMARC Reports

Raw XML reports are difficult to read. Use services to parse and visualize:

  • Free Options: Postmark DMARC Digests, dmarcian (limited free tier)
  • Paid Services: dmarcian, Valimail, Agari
  • Self-Hosted: parsedmarc (open-source reporting tool)

Implementation Roadmap

Phase 1: SPF Setup (Week 1)

  1. Inventory email sources: List all services sending email as your domain
  2. Create SPF record: Include all authorized sources
  3. Publish to DNS: Add TXT record to your domain
  4. Verify: Use SPF checking tools to confirm proper configuration
  5. Monitor: Watch for delivery issues, update as needed

Phase 2: DKIM Setup (Week 2)

  1. Enable DKIM in your email provider
  2. Generate keys: Create 2048-bit keys if not automatic
  3. Publish public key: Add provided DNS records
  4. Enable signing: Activate DKIM signing for outbound email
  5. Test: Send emails and verify DKIM signatures pass
  6. Enable for all services: Configure DKIM for marketing platforms, etc.

Phase 3: DMARC Monitoring (Weeks 3-6)

  1. Start with p=none: Monitor without impacting delivery
  2. Set up report processing: Use a DMARC report analyzer
  3. Publish DMARC record: Add to DNS with p=none policy
  4. Collect reports: Wait 1-2 weeks for report accumulation
  5. Analyze results: Identify all legitimate mail sources
  6. Fix failures: Update SPF/DKIM for failing legitimate sources

Phase 4: DMARC Enforcement (Weeks 7-12)

  1. Move to p=quarantine: Start with pct=10-25%
  2. Monitor impact: Watch for delivery issues
  3. Gradually increase: Raise percentage as confidence grows
  4. Reach p=quarantine at 100%: Maintain for 2-4 weeks
  5. Move to p=reject: Final enforcement policy
  6. Ongoing monitoring: Continue watching reports

Troubleshooting Common Issues

Email Delivery Problems After SPF Implementation

Symptom: Legitimate emails being rejected

Solutions:

  • Check SPF record includes all email sources
  • Verify DNS propagation (can take 24-48 hours)
  • Look for SPF syntax errors
  • Check for DNS lookup limit violations (10 max)

DKIM Signature Failures

Symptom: DKIM verification failing

Solutions:

  • Verify DNS record published correctly
  • Check for whitespace in DNS TXT record
  • Ensure key length matches (2048-bit)
  • Confirm DKIM signing enabled in email provider
  • Check if email was forwarded (breaks DKIM)

DMARC Report Overload

Symptom: Too many reports to process manually

Solutions:

  • Use DMARC report processing services
  • Set up automated report parsing
  • Focus on aggregate reports, not forensic
  • Filter reports for new sources only

Subdomain Spoofing

Symptom: Attackers using subdomains not explicitly protected

Solutions:

  • Add DMARC record to _dmarc of each subdomain, or
  • Use sp=reject in parent domain DMARC to apply policy to subdomains

Advanced Considerations

BIMI: Brand Indicators for Message Identification

BIMI displays your company logo next to authenticated emails in supporting email clients:

Requirements:

  • DMARC policy at p=quarantine or p=reject
  • Verified Mark Certificate (VMC) from authorized provider
  • Published BIMI DNS record

Benefits:

  • Brand visibility in inbox
  • Visual authentication for recipients
  • Phishing protection through brand recognition

Email Forwarding Challenges

Email forwarding can break SPF and DKIM:

SPF: Forwarded email comes from forwarding server (unauthorized IP) DKIM: Some forwards modify content, breaking signature

Solutions:

  • ARC (Authenticated Received Chain) for forwarders
  • Use relaxed DMARC alignment
  • Consider p=quarantine instead of p=reject if forwarding is common

Third-Party Senders

Marketing platforms and other services sending on your behalf need special handling:

Option 1: Subdomain delegation

  • Use marketing.yourdomain.com for third-party sending
  • Separate DMARC policy for subdomain

Option 2: Include in SPF/DKIM

  • Add third-party IPs to SPF
  • Configure DKIM with third-party

Monitoring and Maintenance

Monthly Tasks

  • Review DMARC reports for new sources
  • Check DMARC compliance percentage
  • Verify SPF/DKIM still passing

Quarterly Tasks

  • Audit all authorized email sources
  • Review and remove unused services from SPF
  • Check for email delivery issues

Annual Tasks

  • Rotate DKIM keys
  • Comprehensive email security audit
  • Review DMARC policy enforcement level

The Bottom Line

SPF, DKIM, and DMARC form the foundation of email security. These protocols:

  • Prevent attackers from spoofing your domain in phishing attacks
  • Improve email deliverability to customers and partners
  • Provide visibility into who's sending email as your domain
  • Demonstrate security maturity to partners and clients

Implementation requires initial effort but minimal ongoing maintenance. The protection against domain spoofing and improved email deliverability provide immediate value that far exceeds the setup cost.

Every business sending email should implement these protocols. Your domain's reputation and your customers' security depend on it.


Need help implementing SPF, DKIM, and DMARC for your domain? Get expert guidance from SimplCyber with step-by-step implementation support.

Tags:email securitySPFDKIMDMARCspoofingphishing prevention

Related Articles

SMB Security

How to Choose a Password Manager for Your Team

Password managers are essential for business security, but choosing the wrong one creates more problems than it solves. Learn what features matter and how to evaluate options.

Protect your business today

Get a comprehensive security assessment and actionable remediation plan.

Get Your Free Risk Scan