SPF vs DKIM vs DMARC: Understanding the Differences

Email was designed in the 1980s without any authentication mechanism. Anyone could (and still can) send a message pretending to be someone else. To address this flaw, three complementary protocols were created over time:

• SPF (2006) — verifies that the sending server is authorized by the domain.
• DKIM (2007) — adds a cryptographic signature to the message to guarantee its integrity.
• DMARC (2012) — orchestrates SPF and DKIM, and tells receiving servers what to do when checks fail.

Each one covers a different aspect of authentication. Used separately, they leave gaps. Combined, they form a robust defense against spoofing and phishing.

SPF (Sender Policy Framework) is the first layer of protection. It lets you declare in DNS which servers are authorized to send emails on behalf of your domain.

• Works by comparing the sending server's IP against authorized IPs
• Protects against sending from unauthorized servers
• Limitation: only checks the envelope address (MAIL FROM), not the visible From header
• Maximum of 10 DNS lookups per record

Read the full SPF guide →

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The receiving server can verify this signature using the public key published in the sender's DNS.

• Ensures the message content has not been tampered with in transit
• Ties the message to a specific domain via a digital signature
• Survives email forwarding (unlike SPF)
• Limitation: does not tell the receiving server what to do if verification fails

Read the full DKIM guide →

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the keystone that makes SPF and DKIM work together. It checks alignment: the From header domain must match the domain verified by SPF and/or DKIM.

• Defines a clear policy: none (monitor), quarantine (spam), reject (block)
• Sends reports on spoofing attempts
• Protects the visible From header (the gap SPF alone leaves open)
• Prerequisite: at least SPF or DKIM must be configured

Read the full DMARC guide →

Here is what happens when a server receives an email claiming to come from your domain:

1. SPF check — The receiving server extracts the domain from the MAIL FROM address and checks whether the sender's IP is authorized in the SPF record. Result: pass or fail.
2. DKIM check — The receiving server looks for a DKIM signature in the message headers, retrieves the public key from DNS, and verifies that the signature is valid. Result: pass or fail.
3. DMARC check — The receiving server verifies that the From header domain is aligned with the domain verified by SPF and/or DKIM. Only one of the two needs to be aligned for DMARC to pass.
4. Policy enforcement — If DMARC fails, the server applies the defined policy: none (no action, but report sent), quarantine (send to spam), or reject (outright rejection).

This combination makes spoofing extremely difficult: an attacker would need to send from an authorized server (SPF), sign the message with your private key (DKIM), and have everything aligned with the From header (DMARC).

Here is the recommended implementation order to protect your domain progressively:

1. Configure SPF — List your sending servers and create your SPF record. This is the simplest to set up. See the SPF guide
2. Configure DKIM — Enable DKIM signing with your email provider and publish the public key in your DNS. See the DKIM guide
3. Deploy DMARC in monitoring mode — Start with p=none to collect reports without impacting deliverability. See the DMARC guide
4. Move to quarantine — Once you have analyzed reports and identified all legitimate sources, switch to p=quarantine to send unauthenticated emails to spam.
5. Move to reject — When everything is stable, enable p=reject to permanently block unauthenticated emails. This is the maximum level of protection.

This progressive approach avoids accidentally blocking legitimate emails while steadily strengthening your security.