SPF, DKIM & DMARC: The Complete Guide to Email Authentication

What Is Email Authentication?

Email authentication is a set of technical standards that allow mail servers to verify that an email claiming to come from your domain actually originated from an authorized source. Without it, anyone can forge your domain in the "From" header of an email — a technique called email spoofing that powers most phishing campaigns and business email compromise (BEC) attacks.

Three DNS-based standards work together to solve this problem:SPF, DKIM, andDMARC. Each serves a different purpose, and together they create a defense-in-depth layer for your email ecosystem. Major email providers like Gmail, Outlook, and Yahoo now check these records for every inbound message, and failing authentication can land your emails in spam or get them rejected outright.

SPF (Sender Policy Framework)

SPF is a DNS TXT record that lists every server authorized to send email on behalf of your domain. Think of it as a guest list for your email system: if a server isn't on the list, receiving mail servers know the message might be forged.

How SPF Works

When a receiving server gets an email, it looks up your domain's SPF record, checks the sending server's IP address against the authorized list, and applies the policy you've defined. The key mechanisms include:

• ip4/ip6 — Authorize specific IP addresses or ranges
• include — Delegate authority to another domain's SPF record (commonly used for email service providers)
• a/mx — Authorize your domain's A or MX records
• all — Catch-all mechanism with a qualifier that defines the default action

SPF Qualifiers

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic digital signature to every outgoing email. The signature is created using a private key held by your mail server, and receivers verify it using a public key published in your DNS. This proves two things: the email genuinely came from your domain, and it wasn't tampered with in transit.

How DKIM Works

DKIM uses a pair of cryptographic keys:

• Private key — Stored securely on your mail server. Used to sign outgoing messages.
• Public key — Published as a DNS TXT record under a "selector" subdomain (e.g.,google._domainkey.yourdomain.com).

When a message arrives, the receiving server looks up the DKIM signature header, finds the selector and domain, fetches the public key from DNS, and verifies that the signature matches. If it doesn't, the message could have been altered in transit or might not be legitimate.

DKIM Key Sizes

Most email service providers generate DKIM keys automatically. Industry best practice recommends 2048-bit RSA keys over 1024-bit. While 1024-bit is still functional, 2048-bit provides significantly stronger protection against cryptographic attacks

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC is the policy layer that tells receiving mail servers what to do when SPF and/or DKIM checks fail. Without DMARC, even if you have perfect SPF and DKIM records, each receiving server decides on its own whether to accept, quarantine, or reject unauthenticated mail. DMARC unifies that behavior into a single published policy.

DMARC Policies

DMARC Reporting

One of DMARC's most valuable features is reporting. By addingrua (aggregate) and ruf (forensic) tags, you receive daily XML reports showing which sources send email as your domain, pass rates, and rejection volumes — invaluable for catching legitimate senders you missed in SPF and DKIM.

Example DMARC record:v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=r; aspf=r

How SPF, DKIM and DMARC Work Together

Think of email authentication as a three-layer security system:

1. SPF checks the envelope — It verifies that the sending server's IP is authorized to send mail for your domain. This is like checking the return address on a physical letter.
2. DKIM checks the content — It verifies that the email body and headers haven't been altered and were signed by your domain's private key. This is like a tamper-proof seal on an envelope.
3. DMARC is the referee — It tells the receiving server what to do if SPF and/or DKIM check fails. It also requires that the domain in the "From" address aligns with the domains checked by SPF and DKIM (identifier alignment).

For DMARC to pass, either SPF or DKIM must passand the domain used must align with the "From" address domain. This is why you need both SPF and DKIM configured — if one breaks (for example, a forwarded email that fails SPF), the other can still pass DMARC.

Step-by-Step Setup Guide

Step 1: Audit Your Current Email Senders

Before creating any records, identify every service that sends email as your domain. Common sources include:

• Google Workspace / Microsoft 365
• Email marketing platforms (Mailchimp, Constant Contact, Klaviyo)
• Transactional email services (SendGrid, Amazon SES, Mailgun, Postmark)
• CRM systems (HubSpot, Salesforce)
• IT monitoring tools (PagerDuty, Datadog)
• Your own mail server or web host

Each provider will give you an SPF include mechanism (e.g.,include:spf.mailgun.org) and a DKIM selector with public key. Collect these before writing your records.

Step 2: Create Your SPF Record

1. Start with v=spf1 — the version identifier.
2. Add include: statements for each ESP or email service you use.
3. Add ip4: or ip6: for any static IP addresses that send mail directly.
4. Add a and/or mx if your domain's web server or MX servers also send mail.
5. End with ~all (softfail) initially, moving to-all once you confirm everything works.

Important: SPF records are limited to 10 DNS lookups per the RFC. Each include: mechanism counts as one lookup, and some providers' SPF records contain multiple lookups themselves. Use our SPF Checker to validate your record and count lookups.

Step 3: Configure DKIM for Each Email Service

Each email provider handles DKIM setup differently, but the pattern is the same: your provider generates a public/private key pair, gives you a DNS record to publish (typically underselector._domainkey.yourdomain.com), and starts signing outgoing mail with the private key.

After publishing the DKIM record, use our DKIM Checker to verify the record is correctly configured and the public key is properly formatted. Common issues include missingp= tags and whitespace errors in the base64 key.

Step 4: Publish a DMARC Policy

1. Start with p=none — Publishv=DMARC1; p=none; rua=mailto:[email protected]. This tells receivers to send you reports without affecting email delivery. Monitor for 1-2 weeks.
2. Review your reports — Analyze the aggregate reports to ensure all legitimate senders appear in your SPF record and have DKIM configured. Add any missing senders.
3. Move to p=quarantine — Once you've confirmed all legitimate senders are authenticated, update your DMARC policy to quarantine failing messages. Monitor for another week.
4. Graduate to p=reject — The final and most secure policy. Only move here when you've verified no legitimate email fails authentication. Use our DMARC Analyzer to review your reports and confirm you're ready for reject.

Step 5: Add Reporting Addresses

Add the rua (aggregate) and ruf(forensic) tags to your DMARC record. You can use a free DMARC analysis service or your own mailbox. Aggregate reports arrive daily as XML; forensic reports are sent for each individual authentication failure.

Testing and Monitoring

After publishing your records, testing is critical. Here's a recommended monitoring routine:

Daily (first week)

• Check DMARC aggregate reports for new sending sources
• Verify no legitimate email is failing SPF or DKIM
• Watch for any services you forgot to include

Weekly

• Run our SPF/DKIM/DMARC Record Viewer to get a quick health score for your domain
• Review the breakdown of SPF, DKIM, and DMARC status for each sending service
• Check for any DNS propagation issues if you recently made changes

Monthly

• Rotate DKIM keys if your provider supports it
• Review aggregate report trends over time
• Update SPF include records when you add or remove email services
• Confirm your DMARC policy is still appropriate

Common Issues to Watch For

• SPF too large — Exceeding 10 DNS lookups causes permanent errors. Consolidate includes or use a service provider that can aggregate.
• DKIM key rotation — If you rotate DKIM keys, publish the new public key in DNS before switching your mail server to the new private key.
• Third-party forwarding — Mailing lists break SPF because the forwarder's IP isn't in your SPF record. DKIM survives forwarding, so configure DKIM properly.
• Subdomain coverage — Use thesp= tag in DMARC to set a separate policy for subdomains.

Tools to Check Your Records

BizSecurityTools provides a suite of free tools to help you set up, test, and monitor your email authentication configuration.