SPF vs DKIM vs DMARC Explained

SPF, DKIM, and DMARC are three complementary email authentication protocols that work together to verify sender identity and protect domains from spoofing. SPF specifies which servers can send email for a domain, DKIM adds a cryptographic signature proving the message was not altered, and DMARC ties them together with a policy that tells receivers how to handle failures.

Together, these protocols form the foundation of modern email security. Without them, anyone can forge the “From” address in an email and impersonate your organization. Since February 2024, Google and Yahoo require all three for domains that send more than 5,000 messages per day. Even if you send fewer emails, implementing SPF, DKIM, and DMARC improves deliverability and protects your brand reputation.

Quick Comparison

SPF (Sender Policy Framework)

SPF is the first layer of email authentication. It works by publishing a DNS TXT record on your domain that lists every server authorized to send email on your behalf. When a receiving mail server gets a message claiming to be from your domain, it looks up this record and checks whether the sending server's IP address is on the list. If the IP matches, SPF passes. If it does not, SPF fails.

How SPF Works

The SPF check happens during the SMTP transaction, before the email body is delivered. The receiving server extracts the domain from the Return-Path (envelope sender) and queries DNS for a TXT record starting with v=spf1. It then evaluates each mechanism in the record from left to right until it finds a match or reaches the default qualifier at the end.

Example SPF Record

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

This record authorizes Google Workspace and SendGrid to send email for the domain. The -all at the end means any server not explicitly listed should fail the SPF check.

SPF Mechanisms Explained

• include:— Authorizes the SPF record of another domain. Commonly used for third-party services like Google Workspace, Microsoft 365, or SendGrid.
• a— Authorizes the IP address(es) returned by the domain's A record.
• mx— Authorizes the IP addresses of the domain's MX (mail exchange) servers.
• ip4: — Authorizes a specific IPv4 address or CIDR range (e.g., ip4:192.0.2.0/24).
• ip6:— Authorizes a specific IPv6 address or CIDR range.
• -all(hard fail) — Reject messages from unlisted servers. This is the recommended setting for production domains.
• ~all(soft fail) — Accept but mark messages from unlisted servers. Useful during initial SPF rollout.
• ?all(neutral) — Take no action on messages from unlisted servers. Effectively disables SPF enforcement.

The 10 DNS Lookup Limit

SPF has a critical limitation: each record is allowed a maximum of 10 DNS lookups. Every include:, a, mx, and redirect mechanism counts as one lookup. The ip4: and ip6: mechanisms do not count because they do not require DNS resolution. If your record exceeds 10 lookups, SPF will return a permanent error (PermError) and authentication will fail for all messages. Large organizations that use many third-party senders often hit this limit and must consolidate or flatten their SPF records.

Check your SPF record with our free SPF Checker tool →

DKIM (DomainKeys Identified Mail)

DKIM is the second layer of email authentication. It uses public-key cryptography to prove that an email was genuinely sent by the claimed domain and that the message body and headers were not modified in transit. Unlike SPF, which only checks the sending server, DKIM validates the message content itself.

How DKIM Works

When your mail server sends an email, it uses a private key to generate a cryptographic hash of selected message headers and the body. This hash is added to the email as a DKIM-Signature header. The corresponding public key is published in DNS as a TXT record under a specific subdomain called a selector.

When the receiving server gets the email, it reads the DKIM-Signature header, extracts the selector name and signing domain, fetches the public key from DNS, and uses it to verify the signature. If the signature is valid, the receiver knows the message came from the claimed domain and was not altered after signing.

Selectors Explained

A DKIM selector is a label that allows a domain to publish multiple DKIM keys simultaneously. This is essential when you use several services to send email. For example, Google Workspace might use the selector google, while SendGrid uses s1. Each selector's public key is published at [selector]._domainkey.yourdomain.com. The selector name is included in the DKIM-Signature header so the receiver knows which key to fetch.

How the Signature Is Verified

1. The receiving server reads the DKIM-Signature header and extracts the d= (domain), s= (selector), and b= (signature) values.
2. It queries DNS for the TXT record at s=._domainkey.d= to retrieve the public key.
3. It re-computes the hash of the signed headers and body using the algorithm specified in the signature.
4. It decrypts the signature using the public key and compares the result to the re-computed hash.
5. If they match, the signature is valid and DKIM passes. If they do not match, the message may have been tampered with and DKIM fails.

Key Sizes: 1024-bit vs 2048-bit

DKIM keys come in two common sizes: 1024-bit and 2048-bit. While 1024-bit keys are still technically valid, they are considered increasingly vulnerable to brute-force attacks as computing power grows. Industry best practice is to use 2048-bit keys for stronger security. Some DNS providers have character limits on TXT records that make 2048-bit keys harder to publish, but most modern providers support them without issues. If your provider requires it, you can split the key across multiple strings within a single TXT record.

Verify your DKIM configuration with our free DKIM Checker tool →

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

DMARC is the third and final layer of email authentication. It builds on SPF and DKIM by adding two critical capabilities: a published policy that tells receivers what to do when authentication fails, and a reporting mechanism that gives domain owners visibility into how their domain is being used for email.

How DMARC Works

When a receiving server gets an email, it performs SPF and DKIM checks as usual. Then it checks for a DMARC record at _dmarc.yourdomain.com. The DMARC record contains a policy (p=) that tells the receiver what to do if both SPF and DKIM fail to authenticate the message in alignment with the From domain.

DMARC Alignment

Alignment is the concept that makes DMARC more powerful than SPF and DKIM alone. DMARC requires that the domain authenticated by SPF or DKIM must match (align with) the domain in the visible From header — the address the recipient actually sees.

• SPF alignment— The domain in the Return-Path (envelope sender) must match the domain in the From header.
• DKIM alignment — The domain in the DKIM signature's d= tag must match the domain in the From header.

Alignment can be set to relaxed (the default) or strict. Relaxed alignment allows subdomains to match the organizational domain (e.g., mail.example.com aligns with example.com). Strict alignment requires an exact domain match. For a message to pass DMARC, either SPF or DKIM must pass and be aligned with the From domain.

Policy Levels

DMARC offers three policy levels that control what happens to unauthenticated messages:

• p=none— Monitor only. No enforcement action is taken on failing messages. Use this when you first deploy DMARC to collect reports and understand your email ecosystem without affecting delivery.
• p=quarantine— Messages that fail DMARC are delivered to the spam or junk folder. This is an intermediate step that lets you catch spoofed messages while minimizing the risk of blocking legitimate email.
• p=reject— Messages that fail DMARC are rejected outright and never delivered. This is the strongest policy and the goal for full domain protection. Only move to p=reject after confirming all legitimate senders pass DMARC.

Reporting (rua and ruf)

One of DMARC's most valuable features is its reporting capability. The rua tag specifies where aggregate reports should be sent. These XML reports summarize authentication results for all email sent from your domain, typically delivered daily. They show which IP addresses are sending as your domain, how many messages passed or failed, and what policies were applied.

The ruf tag specifies where forensic (failure) reports should be sent. These contain details about individual messages that failed DMARC, including headers and sometimes partial message content. Not all receivers send forensic reports due to privacy concerns, but when available they are useful for investigating specific spoofing incidents.

Analyze your DMARC record with our free DMARC Checker tool →

How They Work Together

SPF, DKIM, and DMARC are designed as layers in a single authentication system. Here is the step-by-step journey of an email through all three protocols:

1. Sending server connects. Your mail server (or a third-party service like Google Workspace) establishes an SMTP connection to the receiving server and identifies the envelope sender (Return-Path).
2. SPF check.The receiving server looks up the SPF record for the Return-Path domain and checks whether the sending server's IP address is authorized. It records the result (pass, fail, soft fail, or neutral).
3. DKIM signing. Before the message was sent, the sending server signed it using its DKIM private key, adding a DKIM-Signature header to the email.
4. DKIM verification. The receiving server reads the DKIM-Signature header, fetches the public key from DNS using the selector, and verifies the signature. It records the result (pass or fail).
5. DMARC evaluation. The receiving server looks up the DMARC record for the From header domain. It checks whether SPF passed and the SPF domain aligns with the From domain, or DKIM passed and the DKIM domain aligns with the From domain.
6. Policy application. If neither SPF nor DKIM passes with alignment, the receiver applies the DMARC policy: deliver normally (none), send to spam (quarantine), or reject the message (reject).
7. Reporting. The receiving server aggregates the results and sends a DMARC aggregate report to the address specified in the rua tag, giving the domain owner visibility into authentication outcomes.

Why You Need All Three

Each protocol on its own has limitations that the others compensate for:

• SPF alone can be bypassed.SPF checks the envelope sender (Return-Path), not the From header the user sees. An attacker can set up their own domain as the Return-Path (passing SPF) while spoofing your domain in the From header. DMARC's alignment requirement closes this gap.
• DKIM alone has no policy. DKIM proves a message is authentic, but if the signature is missing or fails, there is no instruction for what the receiver should do. Without DMARC, the receiver makes its own judgment, which is inconsistent across providers.
• DMARC requires SPF or DKIM. DMARC does not perform its own authentication. It evaluates the results of SPF and DKIM checks and adds policy enforcement and reporting on top. Without at least one of the underlying protocols, DMARC has nothing to evaluate.

Which Do I Need?

Short answer: all three. SPF, DKIM, and DMARC are complementary protocols that address different aspects of email authentication. Implementing only one or two leaves gaps that attackers can exploit and that inbox providers will penalize.

If you are starting from scratch, implement them in this priority order:

1. SPF first.It is the simplest to set up — a single DNS TXT record listing your authorized sending services. Most email providers give you the exact record to add.
2. DKIM second. This requires generating a key pair in your email service and publishing the public key in DNS. Most providers automate this process.
3. DMARC third. Start with p=none to collect reports without affecting delivery. Once you have confirmed all legitimate senders pass authentication, move to p=quarantine and eventually p=reject.

Minimum Viable Setup

The absolute minimum to get started is an SPF record, DKIM signing enabled on your mail service, and a DMARC record set to p=none with a ruaaddress for reports. This configuration does not block any email but gives you complete visibility into your domain's email authentication status. From there, you can analyze the reports, fix any issues, and gradually increase your DMARC policy to full enforcement.

Implementation Checklist

Follow these steps to implement all three protocols from scratch. Each step builds on the previous one.

1. Inventory your sending services. List every service that sends email from your domain: your email provider (Google Workspace, Microsoft 365), marketing platforms (Mailchimp, HubSpot), transactional senders (SendGrid, Postmark), and any custom applications.
2. Create your SPF record. Build a TXT record that includes all authorized services. Verify it stays within the 10 DNS lookup limit.
3. Publish the SPF record.Add the TXT record to your domain's DNS zone. Only one SPF record is allowed per domain.
4. Enable DKIM signing. In each sending service, generate a DKIM key pair and note the selector name and public key value.
5. Publish DKIM public keys. For each service, add a TXT record at [selector]._domainkey.yourdomain.com containing the public key. Use 2048-bit keys where possible.
6. Create your DMARC record. Start with a monitoring policy: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
7. Publish the DMARC record. Add the TXT record at _dmarc.yourdomain.com.
8. Monitor DMARC reports. Review aggregate reports for 2 to 4 weeks. Identify any legitimate senders that are failing authentication and fix their SPF or DKIM configuration.
9. Tighten the policy. Once all legitimate senders pass consistently, move to p=quarantine. After another monitoring period with no issues, advance to p=reject.
10. Set up ongoing monitoring. DNS records can change unexpectedly. Use a monitoring tool to detect configuration drift, track compliance scores, and alert you to unauthorized senders.

Read our step-by-step DMARC setup guide for detailed instructions →

Frequently Asked Questions

Do I need all three — SPF, DKIM, and DMARC?

Yes. SPF, DKIM, and DMARC are complementary protocols that each address a different aspect of email authentication. SPF verifies the sending server, DKIM verifies message integrity, and DMARC ties them together with a policy and reporting. Without all three, gaps remain that attackers can exploit. Google and Yahoo now require all three for bulk senders.

Which should I set up first?

Start with SPF because it is the simplest to implement — you only need to add a single DNS TXT record listing your authorized sending servers. Next, configure DKIM by generating a key pair and publishing the public key in DNS. Finally, add a DMARC record starting with p=none to collect reports before moving to enforcement.

Can SPF and DKIM work without DMARC?

SPF and DKIM can function independently, but without DMARC there is no policy telling receivers what to do when authentication fails. This means attackers can still spoof your domain and receivers will handle failures inconsistently. DMARC also provides reporting that gives you visibility into who is sending email on behalf of your domain.

What is DMARC alignment?

DMARC alignment ensures that the domain used in SPF or DKIM matches the domain in the From header that the recipient sees. SPF alignment checks that the Return-Path domain matches the From domain. DKIM alignment checks that the d= domain in the DKIM signature matches the From domain. Alignment can be relaxed (subdomains allowed) or strict (exact match required).

Do these protocols prevent all spam?

No. SPF, DKIM, and DMARC prevent domain spoofing — they stop attackers from sending email that appears to come from your domain. However, they do not filter incoming spam or prevent phishing from lookalike domains. For comprehensive email security, combine authentication protocols with spam filters, threat intelligence, and user awareness training.