SPF, DMARC, and DKIM Setup Guide: Protect Your Domain from Email Spoofing

Email spoofing is one of the most common and effective attack vectors against businesses of all sizes. An attacker sends an email that appears to come from your domain but actually comes from their server, tricking employees, customers, or partners into clicking malicious links or transferring money. The attack works because email, by default, has no authentication—it's trivially easy to forge the "From" address. SPF, DMARC, and DKIM exist to solve this problem by authenticating email and preventing spoofing. Yet most organizations haven't implemented them, leaving their domains vulnerable. This guide walks you through the technical implementation of email authentication, from DNS record configuration to testing and troubleshooting, so you can close this critical security gap in your domain.

Understanding Email Authentication and Why You Need It

Email authentication mechanisms answer three questions: Is this email actually from who it claims to be? Can we cryptographically prove who sent it? What should we do if the answer is no? SPF, DMARC, and DKIM provide these answers through DNS records that email providers query when they receive messages from your domain.

Without authentication, an attacker can send an email with "From: ceo@yourcompany.com" and it appears legitimate to recipients. The attacker doesn't need to access your email servers—they just need to send an email through any mail server and forge the From header. This is devastating for phishing attacks: a spoof email from your CEO asking employees to transfer funds or reset passwords is shockingly effective. Business email compromise (BEC) attacks exploit unauthenticated email to extract millions from companies annually. SPF, DMARC, and DKIM prevent this by making it mathematically difficult to forge emails from your domain.

SPF is foundational—it lists which servers are authorized to send email from your domain. DKIM adds cryptographic signatures to prove the email came from a server you authorized. DMARC ties them together and tells receiving mail servers how to handle authentication failures. Together, they make email spoofing technically difficult and give receiving mail servers confidence that emails from your domain are legitimate. Email providers (Gmail, Outlook, etc.) increasingly require these mechanisms for good deliverability. Some major mail providers now refuse to accept unauthenticated email from corporate domains.

Implementing SPF: Authorizing Your Mail Senders

SPF records are DNS TXT records that list IP addresses and domains authorized to send email from your domain. Start by identifying all services that send email on your behalf: your email provider (Gmail, Office 365, Zoho), transactional email services (SendGrid, Mailgun), marketing platforms (Mailchimp, HubSpot), notification services, payment processors, and any internal mail relays.

For each service, get the SPF include string from their documentation. Most major services publish SPF includes specifically for this purpose. For example: SendGrid's include is include:sendgrid.net, Mailchimp's is include:servers.mcsv.net. These includes tell mail receivers to check that service's SPF records for the actual authorized IPs. Building your SPF record is straightforward: combine all the includes plus your own mail server (if you have one) into a single SPF record.

The syntax is: v=spf1 [mechanisms] [qualifier]. Mechanisms are either includes (include:service.com) or direct IP addresses (ip4:203.0.113.0 or ip6:2001:db8::1). The qualifier at the end controls the handling of non-matching senders: ~all (soft fail—accept but mark suspect), -all (hard fail—reject), +all (accept all, defeats the purpose), or ? (neutral). Use ~all initially while testing, then move to -all once you're certain your SPF record is complete.

A typical SPF record for a small company might look like: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.5 ~all. Log into your domain registrar or DNS provider, create a new TXT record for your domain (not a subdomain), and paste your SPF record. DNS changes can take 24 hours to propagate, but most updates propagate within minutes.

After publishing your SPF record, check it for errors using MXToolbox's SPF checker. It will highlight syntax errors, overly long records (SPF has a 255 character limit, sometimes requiring optimization), and configuration issues. The most common problem is including too many services—SPF records have a 10 include limit. If you exceed it, consolidate or remove less critical services.

Configuring DKIM: Cryptographic Proof of Origin

DKIM requires generating a keypair: a private key that your mail server uses to sign outgoing emails, and a public key that receivers use to verify the signature. Most email services handle this automatically—you don't generate the keypair yourself. Instead, your email provider generates it and gives you the public key to add to DNS.

Log into your email provider's settings and locate the DKIM configuration section. For Google Workspace, this is under Security > Authentication. For Microsoft 365, it's under Exchange admin center > Mail flow > DKIM. For SendGrid, it's under Settings > Sender Authentication > DKIM. Each provider gives you a DNS record or set of records to add. The record looks like: default._domainkey IN CNAME sendgrid.net. or a long TXT record containing the public key itself.

Add the DKIM DNS record to your domain. If your provider gives you multiple records (one for each mail server or region), add all of them. Test the record using MXToolbox's DKIM checker—it verifies that your public key is correctly published and queryable. Some providers require you to confirm the DKIM setup in their admin console after publishing the DNS record.

For multiple email providers (e.g., Google Workspace for employee email plus SendGrid for transactional email), you'll have multiple DKIM selectors. This is fine—each provider's system will use its own DKIM key to sign emails, and mail receivers will verify each signature. Gmail messages will be signed with Gmail's key, SendGrid messages with SendGrid's key.

Enforcing Authentication with DMARC

DMARC policies tell receiving mail servers what to do when emails from your domain fail SPF or DKIM checks. Start with a monitoring policy to identify any legitimate services that might fail: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. This tells mail servers to accept all mail but send you daily aggregate reports showing what passed and failed SPF/DKIM.

Review these reports for two weeks. You'll see patterns: legitimate services that configured SPF correctly, any services that didn't, and phishing attempts (which will typically fail both SPF and DKIM). Once you're confident you've found all legitimate senders, upgrade to a stricter policy: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com. Quarantine moves suspicious emails to spam instead of rejecting them—safer than rejection in case legitimate mail fails. After another week of monitoring, upgrade to: v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com. Reject tells mail servers to refuse email that fails SPF or DKIM, preventing spoofing entirely.

Add the DMARC record as a TXT record on _dmarc.yourdomain.com (not your root domain). You can also set p=quarantine or p=reject on subdomains (_dmarc.newsletter.yourdomain.com) separately from your main domain if you have different mail sources for different subdomains.

Testing and Ongoing Monitoring

After implementing all three mechanisms, test your configuration using multiple tools. MXToolbox's email authentication tester sends a test email and shows you exactly how major mail providers will handle it. 250ok and DKIM tester provide similar functionality. Send test emails from your domain and check them against these tools.

Monitor DMARC reports for unusual patterns. A sudden spike in failing emails might indicate an active spoofing attack—now that you have DMARC in place, those forged emails are being blocked automatically. Watch for any legitimate services that are failing authentication and update your SPF or DKIM configuration to include them.

Email authentication requires maintenance. When you add a new email service or integrate a new platform that sends email on your behalf, immediately update your SPF record to include it. When a mail provider changes their infrastructure or certificate (which happens annually), they'll notify you and provide updated DKIM records—update them promptly. Failing to maintain these records results in degraded deliverability and leaves you vulnerable to spoofing for any services that aren't configured.

Email spoofing is trivial to prevent with proper authentication setup. SPF, DMARC, and DKIM take a few hours to implement, cost nothing, and prevent an entire attack vector that currently works against most organizations. Once configured, they work continuously without ongoing effort, blocking spoofed emails and protecting your domain reputation.

RedRadar can audit your email authentication setup to ensure SPF, DMARC, and DKIM are properly configured, test your implementation against real mail provider standards, and identify any legitimate services that might be failing authentication.