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.
Why Email Authentication Matters
Business email compromise (BEC) attacks cost organizations $2.77 billion in 2025, while 78% of organizations experienced at least one email-based breach. These staggering numbers reflect email's fundamental design flaw: 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. Each protocol serves a distinct purpose in proving email legitimacy.
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.
All three work together to provide comprehensive email authentication and protection against the 1 million+ phishing attacks that occurred in Q1 2025 alone.
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.
This simple verification stops the most basic spoofing attempts. Attackers using unauthorized servers can't pass SPF checks.
How SPF Works
You publish an SPF record in your domain's DNS. The SPF record lists all servers and IPs authorized to send email for your domain.
When receiving servers get email from your domain, they check the sender's IP against your SPF record. Emails from unauthorized IPs can be rejected or flagged as suspicious based on your policy.
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
Understanding SPF Components
The v=spf1 indicates this is an SPF version 1 record. The include:_spf.google.com authorizes Google Workspace to send email for your domain.
The include:spf.protection.outlook.com authorizes Microsoft 365 to send email. The -all mechanism rejects emails from any other source (alternatively, use ~all for soft fail during testing).
Common SPF Mechanisms
The ip4:192.0.2.0/24 mechanism authorizes a specific IP address or range. The include:domain.com includes another domain's SPF policy.
The a mechanism authorizes the domain's A record IP. The mx mechanism authorizes IPs of the domain's MX records.
Be Comprehensive with Email Sources
Include all legitimate email sources in your SPF record. This means your email service provider like Google or Microsoft, plus marketing platforms like Mailchimp or Constant Contact.
Don't forget CRM systems like Salesforce or HubSpot, ticketing systems like Zendesk, and any other service that sends email as your domain. Missing a source means legitimate emails could be rejected.
Watch DNS Lookup Limits
SPF has a 10 DNS lookup limit. Too many include: statements can break your SPF record entirely.
If you exceed this limit, consider flattening your SPF record or using subdomains for different email sources. This is one of the most common SPF configuration mistakes.
Use Strict Policy Settings
The -all mechanism tells receiving servers to reject emails from unauthorized sources. Use ~all (soft fail) only during initial testing and implementation.
Once you've verified all legitimate sources are included, switch to -all for maximum protection. This prevents attackers from exploiting any gaps in your policy.
Monitor and Update Regularly
When adding new email services, update your SPF record immediately. Outdated SPF records are a common cause of email delivery problems.
Set calendar reminders to review your SPF record quarterly. Services you no longer use should be removed to keep your record clean.
Testing Your SPF Record
Use online tools to validate your SPF configuration. MXToolbox SPF Checker, dmarcian SPF Inspector, and Google Admin Toolbox Messageheader are all reliable options.
Test by sending emails and checking the authentication results in message headers. Look for "SPF=PASS" to confirm proper configuration.
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 and that the message wasn't altered in transit.
Unlike SPF which checks the sending server, DKIM verifies the message content itself. This provides protection even if an attacker compromises an authorized email server.
How DKIM Works
Your email server generates a public/private key pair. The private key signs outgoing emails with a unique cryptographic signature.
The public key is published in your DNS for receiving servers to access. When they receive your email, they use the public key to verify the signature matches, confirming authenticity and integrity.
Setting Up DKIM
DKIM setup is typically handled by your email provider. The process varies by provider but follows the same basic pattern.
For Google Workspace, generate a DKIM key in Google Admin Console, add the provided TXT record to your DNS, then enable DKIM signing in Google Admin.
For Microsoft 365, enable DKIM signing in Microsoft 365 Admin Center, copy the provided CNAME records, then add those CNAME records to your DNS.
Other providers will have similar processes with provider-specific instructions for key generation and DNS record creation.
DKIM Record Example
A DKIM DNS record looks like this:
default._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."
Understanding DKIM Components
The default._domainkey is the selector and can be customized. The v=DKIM1 indicates the DKIM version.
The k=rsa specifies the key type (RSA). The p=... contains the actual public key used for verification.
Use Strong Key Length
Use 2048-bit keys for strong cryptographic protection. The older 1024-bit standard is becoming deprecated and offers insufficient security.
Most modern email providers default to 2048-bit keys. If you're managing DKIM manually, always choose the stronger key length.
Rotate Keys Periodically
Change DKIM keys annually as a security best practice. This limits the impact if a private key is ever compromised.
Plan key rotation during low-traffic periods. Keep the old public key published for a few days after rotation to handle emails in transit.
Use Multiple Selectors
Different keys for different mail streams enable granular troubleshooting. You can have one selector for transactional email and another for marketing.
This separation makes it easier to identify which email stream is having authentication issues. It also allows selective key rotation without impacting all email types.
Sign All Outgoing Email
Ensure DKIM signing is enabled for all email types. Some organizations only sign certain email categories, leaving others vulnerable.
Every email leaving your domain should carry a DKIM signature. This includes automated system emails, marketing messages, and transactional notifications.
Testing DKIM
Send test emails to a Gmail account and check original message headers. Look for authentication results showing DKIM status.
Use Mail-tester.com or dedicated DKIM validator tools for automated testing. The authentication results should show DKIM=PASS for properly configured signing.
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. It provides reports showing who's sending email using your domain.
Most importantly, DMARC prevents domain spoofing in phishing attacks. With phishing accounting for 16% of initial attack vectors in 2025, this protection is critical.
How DMARC Works
You publish a DMARC policy in your DNS specifying actions for failed authentication. Options include none (monitoring), quarantine (spam folder), or reject (block entirely).
Receiving servers check SPF and DKIM when emails arrive. If checks fail, they follow your DMARC policy for handling the suspicious email.
Receiving servers also send reports about email authentication results. These reports show all email sources claiming to use your domain, both legitimate and malicious.
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
Understanding DMARC Components
The v=DMARC1 indicates DMARC version. The p=reject sets the policy for failed authentication (options: none, quarantine, reject).
The pct=100 applies the policy to 100% of emails. The rua=mailto:... specifies where to send aggregate reports.
The ruf=mailto:... specifies where to send forensic reports. The aspf=s and adkim=s require strict SPF and DKIM alignment respectively.
Monitor Only Policy
The p=none policy takes no action on failed emails. Use this during initial setup to monitor impact without risking legitimate email delivery.
You still receive reports to identify issues with SPF or DKIM configuration. This monitoring phase is essential before enforcing stricter policies.
Quarantine Policy
The p=quarantine policy sends failed emails to the spam or junk folder. This is an intermediate policy during rollout that balances security with deliverability risk.
Recipients can still access quarantined emails if needed. This provides a safety net while you verify all legitimate sources are properly authenticated.
Reject Policy
The p=reject policy causes failed emails to be completely rejected and not delivered. This provides the strongest protection against spoofing.
Reaching reject policy is the final goal for mature DMARC implementation. However, only move to reject after thorough testing with quarantine.
DMARC Alignment Requirements
DMARC requires "alignment" between the authenticated domain and the visible "From" address. This prevents attackers from passing authentication while spoofing your domain in the From header.
Relaxed alignment allows subdomains to match. For example, email from news.example.com passes for the example.com domain policy.
Strict alignment requires exact domain match. Only example.com passes for example.com. This is more secure but requires careful configuration of all email sources.
Aggregate Reports
Daily XML reports summarize authentication results across all email claiming to use your domain. These reports show all sources sending email as your domain, helping identify legitimate services needing SPF or DKIM setup.
Aggregate reports also identify spoofing attempts. Seeing unauthorized sources try to use your domain confirms the value of your DMARC policy.
Forensic Reports
Real-time reports of individual authentication failures include email headers and sometimes content. These are useful for troubleshooting specific issues.
However, privacy concerns limit forensic report adoption. Many receiving servers don't send forensic reports even if requested.
Processing DMARC Reports
Raw XML reports are difficult to read manually. Use services to parse and visualize the data for actionable insights.
Free options include Postmark DMARC Digests and dmarcian's limited free tier. Paid services like dmarcian, Valimail, and Agari offer more features.
For self-hosted solutions, consider parsedmarc, an open-source reporting tool. This gives you complete control over your report data.
Implementation Roadmap
Phase 1: SPF Setup (Week 1)
Inventory all email sources by listing every service sending email as your domain. Include email providers, marketing platforms, CRM systems, and ticketing systems.
Create your SPF record including all authorized sources. Publish the TXT record to your DNS and allow time for propagation.
Verify using SPF checking tools to confirm proper configuration. Monitor for delivery issues and update as needed during the first week.
Phase 2: DKIM Setup (Week 2)
Enable DKIM in your email provider's admin console. Generate 2048-bit keys if not created automatically.
Publish the public key by adding provided DNS records to your domain. Enable DKIM signing for all outbound email.
Test by sending emails and verifying DKIM signatures pass in the headers. Configure DKIM for marketing platforms and other third-party senders.
Phase 3: DMARC Monitoring (Weeks 3-6)
Start with p=none to monitor without impacting delivery. Set up report processing using a DMARC report analyzer service.
Publish your DMARC record to DNS with the none policy. Wait 1-2 weeks for reports to accumulate from receiving servers.
Analyze results to identify all legitimate mail sources. Fix failures by updating SPF or DKIM for any failing legitimate sources.
Phase 4: DMARC Enforcement (Weeks 7-12)
Move to p=quarantine starting with pct=10-25% to limit initial impact. Monitor closely for any delivery issues reported by users.
Gradually increase the percentage as confidence grows. Once you reach p=quarantine at 100%, maintain for 2-4 weeks while monitoring.
Finally move to p=reject for full enforcement. Continue ongoing monitoring of DMARC reports even after full deployment.
Troubleshooting Common Issues
Email Delivery Problems After SPF
Legitimate emails being rejected usually means missing sources in your SPF record. Check that your SPF record includes all email sources.
Verify DNS propagation which can take 24-48 hours. Look for SPF syntax errors using validation tools.
Check for DNS lookup limit violations as SPF has a 10 lookup maximum. Too many includes will cause the entire SPF record to fail.
DKIM Signature Failures
DKIM verification failing usually indicates DNS configuration issues. Verify the DNS record published correctly without errors.
Check for whitespace or formatting issues in the DNS TXT record. Ensure key length matches between your email provider and DNS (2048-bit).
Confirm DKIM signing is enabled in your email provider settings. Note that forwarded emails may fail DKIM as forwarding can modify content.
DMARC Report Overload
Too many reports to process manually is a sign you need automation. Use DMARC report processing services to handle the volume.
Set up automated report parsing instead of reading raw XML. Focus on aggregate reports rather than forensic reports for actionable insights.
Filter reports to highlight only new sources. Once you've authenticated known sources, you only need to watch for new or suspicious senders.
Subdomain Spoofing
Attackers using subdomains not explicitly protected can bypass domain-level policies. Add DMARC records to _dmarc of each subdomain for specific protection.
Alternatively, use sp=reject in your parent domain DMARC to apply the same policy to all subdomains. This is simpler than managing individual subdomain records.
Advanced Considerations
BIMI: Brand Indicators for Message Identification
BIMI displays your company logo next to authenticated emails in supporting email clients. This requires DMARC policy at p=quarantine or p=reject as a prerequisite.
You'll also need a Verified Mark Certificate (VMC) from an authorized provider. Then publish a BIMI DNS record pointing to your logo file.
Benefits include brand visibility in the inbox and visual authentication for recipients. It also provides phishing protection through brand recognition that attackers can't replicate.
Email Forwarding Challenges
Email forwarding can break both SPF and DKIM authentication. Forwarded email comes from the forwarding server, which is an unauthorized IP for SPF purposes.
Some forwards modify content, breaking DKIM signatures. Solutions include implementing ARC (Authenticated Received Chain) for forwarders.
Consider using relaxed DMARC alignment to accommodate forwarding. You might also use p=quarantine instead of p=reject if forwarding is common among your recipients.
Third-Party Senders
Marketing platforms and other services sending on your behalf need special handling. One option is subdomain delegation using marketing.yourdomain.com for third-party sending.
This allows a separate DMARC policy for the subdomain. Alternatively, include third-party services in your SPF and configure DKIM with them.
The subdomain approach is cleaner and reduces DNS lookup count in your main SPF record. However, it requires recipients to trust a different domain name.
Monitoring and Maintenance
Monthly Tasks
Review DMARC reports for new sources attempting to send as your domain. Check DMARC compliance percentage to ensure authentication rates remain high.
Verify SPF and DKIM are still passing for your legitimate email sources. Address any newly reported failures promptly.
Quarterly Tasks
Audit all authorized email sources in your SPF record. Review and remove unused services to keep your SPF record clean and under the DNS lookup limit.
Check for email delivery issues reported by users. Even small authentication problems can impact deliverability over time.
Annual Tasks
Rotate DKIM keys as a security best practice. Plan rotation during low-traffic periods to minimize any potential issues.
Conduct a comprehensive email security audit reviewing all authentication protocols. Review DMARC policy enforcement level to ensure it still matches your security requirements.
Key Takeaways
Email authentication through SPF, DKIM, and DMARC is critical for protecting against the $2.77 billion lost to BEC attacks in 2025. These protocols prevent attackers from spoofing your domain in phishing attacks that now include 40% AI-generated BEC emails.
Implementation improves email deliverability to customers and partners while providing visibility into who's sending email as your domain. The protection demonstrates security maturity to partners and clients.
Start with SPF in week 1, add DKIM in week 2, then spend 4-6 weeks monitoring DMARC before enforcing policies. Gradual rollout prevents delivery issues while building toward full protection.
Regular monitoring and maintenance keep authentication working as your email infrastructure evolves. Monthly report reviews and quarterly audits ensure continued protection against evolving threats.
Need help implementing SPF, DKIM, and DMARC for your domain? Get expert guidance from SimplCyber with step-by-step implementation support.