AntiPhishers DMARC, SPF, and DKIM Setup: Email Authentication for Businesses
DMARC, SPF, and DKIM Setup: Email Authentication for Businesses
Email spoofing, where attackers send messages that appear to come from your domain, enables phishing, business email compromise, and brand impersonation. DMARC, SPF, and DKIM are three complementary DNS-based protocols that authenticate email and tell receiving servers how to handle messages that fail authentication. Properly configured, they virtually eliminate the ability of attackers to spoof your domain.
SPF: Who Can Send on Your Behalf
Sender Policy Framework (SPF) publishes a DNS TXT record listing the mail servers authorized to send email for your domain. When a receiving server gets an email claiming to be from your domain, it checks the SPF record. If the sending server is not listed, SPF fails.
Configuration: Add a TXT record to your domain’s DNS. Example: v=spf1 include:_spf.google.com include:amazonses.com -all. This authorizes Google Workspace and Amazon SES to send on your behalf and instructs receivers to reject (-all) all other senders. Use ~all (soft fail) during initial testing before switching to -all (hard fail).
Limitation: SPF only validates the envelope sender (Return-Path), not the From header that users see. This means SPF alone does not prevent display-name spoofing.
DKIM: Cryptographic Signing
DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outgoing emails. The sending server signs the message with a private key; the receiving server verifies the signature using a public key published in your DNS. This confirms the message was sent by an authorized server and was not modified in transit.
Configuration: Generate a DKIM key pair through your email provider. Your provider signs outgoing messages automatically. Publish the public key as a DNS TXT record. Most email providers (Google Workspace, Microsoft 365, Mailchimp, SendGrid) provide specific DKIM setup instructions.
DMARC: Tying It Together
Domain-based Message Authentication, Reporting, and Conformance (DMARC) tells receiving servers what to do when SPF and DKIM fail, and sends you reports about authentication results.
Configuration: Add a DNS TXT record: v=DMARC1; p=none; rua=mailto:[email protected]. Start with p=none (monitor only) to collect data without affecting email delivery. Review reports to identify all legitimate email sources. Add them to your SPF record and ensure DKIM is configured. Gradually escalate to p=quarantine (send failures to spam) and finally p=reject (block failures entirely).
DMARC alignment requires that the domain in the From header matches the domain validated by SPF or DKIM. This closes the gap that SPF alone leaves open, preventing attackers from spoofing the display domain.
Implementation Timeline
Week 1: Audit all email-sending services (marketing platforms, CRM, transactional email, support ticketing). Week 2: Configure SPF and DKIM for all legitimate senders. Week 3: Publish DMARC at p=none and begin monitoring reports. Weeks 4-8: Resolve authentication failures identified in reports. Week 9+: Escalate to p=quarantine, then p=reject after confirming no legitimate email is being blocked.
For the broader email security context, see our email security best practices guide. To understand the phishing threats these protocols defend against, explore our brand impersonation phishing guide.
Common Implementation Mistakes
SPF record too long. SPF has a DNS lookup limit of 10. If you include too many third-party senders, the SPF evaluation fails entirely. Use SPF flattening tools or consolidate sending services to stay within the limit.
Missing email sources. Organizations often forget about email-sending services like CRM platforms, marketing tools, helpdesk systems, and transactional email services. Audit all email-sending systems before implementing DMARC enforcement, or legitimate email will be blocked.
Jumping to p=reject too quickly. Moving to reject policy before identifying all legitimate senders causes email delivery failures. Spend at least 4-6 weeks in monitoring mode (p=none), analyzing DMARC reports to identify all legitimate email sources, before escalating to quarantine and then reject.
Not monitoring DMARC reports. DMARC reports are XML files that most humans cannot read easily. Use a DMARC reporting service like Dmarcian, Valimail, or EasyDMARC to parse and visualize your reports. These services identify authentication failures, unauthorized senders, and configuration issues.