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

A finance director at a 300-person manufacturing company receives an email from the CEO requesting an urgent wire transfer of $187,000 to close an acquisition. The email comes from the CEO's exact email address, matches his writing style, and references a real deal the company has been working on. The finance director initiates the transfer. The money disappears into a network of overseas accounts. The CEO never sent the email.

This is business email compromise (BEC), and it cost organizations $2.9 billion in 2025 alone. It works because most organizations have not implemented the email authentication protocols that would have prevented the CEO's email address from being spoofed in the first place. SPF, DKIM, and DMARC are not new technologies - they have existed for over a decade. But only 33% of domains have a DMARC policy set to reject, meaning two-thirds of organizations are still vulnerable to exact-domain spoofing attacks.

This guide covers the three foundational email authentication protocols, how to implement each one correctly, and the additional measures you need to build a comprehensive email security posture. If your organization sends email (and it does), this is not optional.

Why Email Authentication Matters

Email was designed in the 1970s and 1980s without any built-in authentication. The Simple Mail Transfer Protocol (SMTP) trusts whatever the sending server claims about who sent the message. There is no verification of identity, no validation of the sender's authority to use a domain, and no integrity check on the message contents. Anyone can send an email claiming to be from any address.

This architectural weakness is what makes phishing, spoofing, and business email compromise possible. The three authentication protocols - SPF, DKIM, and DMARC - were developed to retroactively add the authentication that SMTP lacks. Together, they answer three questions that SMTP cannot: Is this server authorized to send mail for this domain? Was this message altered in transit? What should I do if authentication fails?

SPF: Sender Policy Framework

How SPF Works

SPF allows domain owners to publish a DNS TXT record that lists every IP address and mail server authorized to send email on behalf of their domain. When a receiving mail server gets a message claiming to be from your domain, it checks your SPF record. If the sending server's IP address is in the list, SPF passes. If not, SPF fails.

Setting Up SPF

An SPF record is a DNS TXT record published at your domain root. Here is a typical example:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.50 -all

Breaking this down:

• v=spf1 - declares this is an SPF record (required)
• include:_spf.google.com - authorizes Google Workspace to send mail for your domain
• include:sendgrid.net - authorizes SendGrid (or whatever transactional email service you use)
• ip4:203.0.113.50 - authorizes a specific IP address (your on-premises mail server, for example)
• -all - the enforcement mechanism: fail (hard fail) any server not listed. Use ~all (soft fail) during initial testing, then switch to -all once you confirm all legitimate sources are listed

Common SPF Mistakes

• Forgetting third-party senders. Marketing automation (HubSpot, Mailchimp), transactional email (SendGrid, Postmark), helpdesk (Zendesk, Freshdesk), CRM (Salesforce), and HR platforms (BambooHR) all send email using your domain. Each must be included in your SPF record or their emails will fail authentication.
• Exceeding the 10 DNS lookup limit. SPF is limited to 10 DNS lookups. Each include: counts as one lookup, and nested includes count toward the total. Organizations with many third-party senders frequently exceed this limit, which causes SPF to return a permanent error (PermError) that receiving servers may treat as a fail. Use SPF flattening tools to consolidate includes into IP addresses when you approach the limit.
• Using +all or ?all. The +all mechanism authorizes every server on the internet to send mail for your domain, making SPF useless. The ?all mechanism (neutral) provides no enforcement. Use ~all for testing and -all for production.
• Multiple SPF records. A domain must have exactly one SPF TXT record. Multiple SPF records cause unpredictable behavior because receiving servers may evaluate any one of them. If you need to add new authorized senders, modify the existing record rather than creating a second one.

DKIM: DomainKeys Identified Mail

How DKIM Works

DKIM adds a cryptographic signature to every outgoing email. The sending mail server signs the message headers and body using a private key, then adds the signature to the email header. The corresponding public key is published as a DNS TXT record. Receiving servers retrieve the public key, verify the signature, and confirm that the message was not altered after the sender signed it.

DKIM proves two things: the message was sent by someone with access to the domain's private key (authenticity), and the message was not modified in transit (integrity). Unlike SPF, which only validates the sending server, DKIM validates the message itself.

Setting Up DKIM

DKIM requires two components: configuring your mail server or email service to sign outgoing messages with your private key, and publishing the corresponding public key as a DNS TXT record.

For Google Workspace, the setup involves generating a DKIM key in the Admin Console and adding the provided TXT record to your DNS. For Microsoft 365, DKIM is configured in the Exchange admin center with CNAME records pointing to Microsoft's DKIM infrastructure. For third-party services like SendGrid, each service provides its own DKIM configuration - typically a CNAME record that delegates DKIM signing to their infrastructure.

A DKIM DNS record looks like this:

selector1._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ..."

DKIM Best Practices

• Use 2048-bit keys. The minimum recommended key length is 1024 bits, but 2048-bit keys provide substantially stronger cryptographic protection. Some DNS providers have character limits on TXT records that require splitting 2048-bit keys across multiple strings.
• Rotate keys annually. Create a new key pair at least once per year. DKIM supports multiple selectors, so you can add the new key, switch signing to the new selector, verify delivery, and then remove the old key. This limits the window of exposure if a private key is compromised.
• Sign with a domain-specific selector for each service. Use different DKIM selectors for each third-party service (google, sendgrid, hubspot) so you can rotate or revoke keys independently. If one service is compromised, you revoke only that selector without affecting other services.
• Monitor DKIM failures. DKIM failures indicate either a configuration problem (wrong key, unsigned messages) or a potential spoofing attempt. DMARC aggregate reports include DKIM pass/fail statistics that you should review at least monthly.

DMARC: Putting It All Together

How DMARC Works

DMARC builds on SPF and DKIM by adding two critical capabilities: alignment checking and policy enforcement. Alignment means the domain in the From header (what the recipient sees) must match the domain authenticated by SPF or DKIM. Without DMARC, an attacker could pass SPF using their own domain while spoofing your domain in the From header. DMARC closes this gap.

DMARC also specifies what receiving servers should do when authentication fails: nothing (monitor only), quarantine (send to spam), or reject (block entirely). And it provides a reporting mechanism that sends aggregate and forensic data back to the domain owner, giving visibility into who is sending email using your domain - both legitimate services and attackers.

Implementation Roadmap

DMARC implementation should follow a phased approach over 3-6 months:

1. Phase 1 - Monitor (4-8 weeks). Publish a DMARC record with p=none to collect data without affecting email delivery. Analyze aggregate reports to identify all legitimate email sources and ensure they pass SPF or DKIM with alignment.
2. Phase 2 - Quarantine (4-8 weeks). Move to p=quarantine to send failing messages to spam. Start with pct=25 to apply the policy to only 25% of failing messages, then increase to 50%, 75%, and 100% as you verify no legitimate email is affected.
3. Phase 3 - Reject. Move to p=reject to block all unauthenticated email. This is the goal state that provides full protection against domain spoofing.

A complete DMARC record for the monitoring phase:

_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; fo=1; adkim=r; aspf=r"

Reading DMARC Reports

DMARC aggregate reports arrive as XML files that are difficult to read manually. Use a DMARC report analyzer - free options include DMARC Analyzer, URIports, and MXToolbox DMARC Report Analyzer. These tools parse the XML into readable dashboards showing which IP addresses send email for your domain, whether they pass SPF and DKIM, and which messages fail authentication.

Focus on three things in your reports: legitimate sources that fail authentication (these need SPF or DKIM configuration fixes), unknown sources sending high volumes (potential spoofing or unauthorized use of your domain), and the overall authentication pass rate (target 98%+ before moving to reject).

Beyond Authentication: Additional Email Security Measures

Anti-Phishing Controls

Authentication protocols stop domain spoofing but not all phishing techniques. Additional controls include:

• External sender banners. Configure your email platform to display a visible warning on emails from external senders. Microsoft 365 and Google Workspace both support this. The banner alerts employees to verify unexpected requests from what appears to be an internal contact but actually came from outside the organization.
• Executive impersonation protection. Configure rules that flag emails where the display name matches an executive's name but the email address is external. This catches the common BEC tactic of using a personal Gmail or lookalike domain while displaying the CEO's name.
• Link scanning and rewriting. Email security gateways (Proofpoint, Mimecast, Microsoft Defender for Office 365) can scan URLs at time of click rather than time of delivery. This catches delayed detonation attacks where the attacker creates a clean URL that becomes malicious hours after the email is delivered.
• Attachment sandboxing. Automatically detonate attachments in an isolated sandbox before delivering them to the recipient. This catches malicious macros, exploits, and malware that signature-based scanning misses.

Email Encryption

Authentication ensures that emails are from who they claim to be. Encryption ensures that only the intended recipient can read them. The two address different threats and both are necessary for sensitive communications.

• TLS encryption in transit. Transport Layer Security (TLS) encrypts email as it moves between mail servers. Most modern email providers enforce TLS by default, but you should configure your mail server to require TLS (not just opportunistic) for communications with known partners. Google Workspace and Microsoft 365 both support MTA-STS (Mail Transfer Agent Strict Transport Security) to enforce TLS with certificate validation.
• S/MIME or PGP for end-to-end encryption. For truly confidential communications, S/MIME or PGP encrypts the message content so that only the recipient's private key can decrypt it. This protects against compromised mail servers, legal interception, and insider threats. The trade-off is usability - both require key management that most non-technical users find burdensome. Consider S/MIME for regulated industries (healthcare, finance, legal) where encryption of sensitive data is a compliance requirement.

Business Email Compromise Prevention

BEC deserves special attention because it bypasses technical controls by exploiting human trust. The attacker does not need to breach your systems - they just need one employee to believe a fraudulent request is legitimate. Prevention requires both technical and procedural controls:

• Enforce DMARC at reject. Prevents exact-domain spoofing, which is the foundation of most BEC attacks.
• Implement out-of-band verification. Any request involving financial transactions, payment detail changes, wire transfers, or sensitive data must be verified through a separate communication channel. Call the requester on a known phone number (never the number in the email). This single procedure would prevent the majority of BEC losses.
• Deploy AI-powered email security. Modern platforms (Abnormal Security, Tessian, Microsoft Defender for Office 365) use behavioral analysis to detect emails that do not match normal communication patterns - unusual sender behavior, atypical request types, urgency language, and impersonation signals that rule-based filters miss.
• Train high-value targets specifically. Finance teams, executive assistants, HR, and anyone with wire transfer authority should receive targeted BEC training with realistic simulations specific to their role and authority level.

Implementation Checklist

1. Audit every service that sends email using your domain (marketing, CRM, helpdesk, transactional, HR, billing, notifications)
2. Publish an SPF record including all legitimate senders; verify with -all enforcement
3. Configure DKIM signing on your primary mail platform and every third-party sender
4. Publish a DMARC record at p=none and monitor aggregate reports for 4-8 weeks
5. Fix any legitimate sources that fail SPF or DKIM alignment
6. Advance DMARC to p=quarantine, then p=reject over the next 2-4 months
7. Configure external sender banners and executive impersonation protection
8. Enable link scanning and attachment sandboxing in your email security gateway
9. Enforce TLS for email in transit; consider MTA-STS for strict enforcement
10. Establish out-of-band verification procedures for all financial requests
11. Deploy security awareness training focused on phishing and BEC recognition
12. Review DMARC reports monthly and audit SPF records quarterly

Testing Your Configuration

After implementation, verify your setup using these free tools:

• MXToolbox SPF/DKIM/DMARC lookup - validates DNS record syntax and checks for common errors
• Google Admin Toolbox Check MX - comprehensive email configuration test for any domain
• mail-tester.com - send a test email and get a deliverability score with specific authentication results
• DMARC Analyzer - free DMARC report parsing and visualization
• dmarcian.com - DMARC deployment tools with a free tier for monitoring

Run these checks quarterly and after any changes to your email infrastructure, DNS records, or third-party email services. A single misconfigured SPF include or an expired DKIM key can silently undermine your entire authentication posture.