SPF, DKIM, and DMARC Explained: Email Authentication for Everyone

Every day, 3.4 billion phishing emails are sent worldwide. The three protocols that stand between those emails and your inbox are SPF, DKIM, and DMARC. If you have ever wondered what those abbreviations mean when you see them in email headers — or why some phishing emails make it through while others are caught — this guide explains it all in plain language.

The Problem: Email Was Built Without Authentication

The Simple Mail Transfer Protocol (SMTP), designed in 1982, has no built-in mechanism to verify sender identity. Sending an email "from" any address is as easy as writing any return address on a postal envelope. SPF, DKIM, and DMARC were added decades later to patch this fundamental flaw.

SPF: Who Is Allowed to Send

Sender Policy Framework (SPF) answers one question: is the server sending this email authorized by the domain owner?

How It Works

1. A domain owner publishes an SPF record in their DNS (the internet's address book). This record lists every IP address and server authorized to send email on behalf of that domain.
2. When your email provider receives a message claiming to be from that domain, it checks the sending server's IP address against the SPF record.
3. If the IP is listed: SPF pass. The server is authorized.
4. If the IP is not listed: SPF fail. The server is not authorized to send on behalf of this domain.

Example SPF Record

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

This says: "Emails from our domain are legitimate only if they come from Google's servers, SendGrid's servers, or the IP address 203.0.113.5. Reject everything else (-all)."

Limitations

• SPF checks the envelope sender (Return-Path), not the From header you see. A phishing email can have a valid SPF for its actual sending domain while displaying a forged From address.
• SPF breaks when emails are forwarded, because the forwarding server's IP is not in the original domain's SPF record.

DKIM: The Digital Signature

DomainKeys Identified Mail (DKIM) answers a different question: was this email altered after it was sent, and can the sending domain cryptographically prove it sent this message?

How It Works

1. The sending server creates a cryptographic hash of certain email headers and the body.
2. This hash is encrypted using a private key that only the domain owner possesses, creating a digital signature.
3. The signature is added to the email as a DKIM-Signature header.
4. The receiving server retrieves the corresponding public key from the domain's DNS records.
5. It decrypts the signature and compares the hash to its own hash of the received email.
6. If they match: DKIM pass. The email is authentic and unmodified.
7. If they do not match: DKIM fail. The email was either forged or modified in transit.

Example DKIM Signature Header

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
  h=from:to:subject:date;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...

The d=example.com identifies the signing domain. The s=selector1 tells the receiver which public key to retrieve from DNS. The b= value is the signature itself.

Strengths

• Survives email forwarding (unlike SPF), because the signature travels with the email.
• Proves the email was not modified after signing.
• Provides cryptographic proof of domain association.

Limitations

• DKIM alone does not tell you what to do with failed messages. That is DMARC's job.
• DKIM does not encrypt the email — it only signs it.
• The signing domain (d=) does not have to match the From header. Without DMARC, a scammer could sign with their own domain while displaying a forged From.

DMARC: The Policy Layer

Domain-based Message Authentication, Reporting, and Conformance (DMARC) ties SPF and DKIM together and adds a critical element: a policy telling receiving servers what to do with emails that fail authentication.

How It Works

1. The domain owner publishes a DMARC record in DNS that specifies a policy.
2. When a receiving server gets an email, it checks SPF and DKIM results.
3. DMARC requires alignment: the domain in SPF and/or DKIM must match the From header domain (or be a subdomain of it). This closes the loophole where SPF and DKIM might pass for one domain while the From displays another.
4. If alignment passes, the email is authenticated.
5. If alignment fails, the receiving server follows the DMARC policy.

DMARC Policies

• p=none — Monitor only. Failed emails are delivered but reports are sent to the domain owner. This is used during initial setup.
• p=quarantine — Failed emails are sent to the recipient's spam folder.
• p=reject — Failed emails are blocked entirely. This is the strongest protection.

Example DMARC Record

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100

This says: "Reject 100% of emails that fail DMARC alignment, and send aggregate reports to dmarc-reports@example.com."

How They Work Together

Think of it as three layers of security at a building entrance:

1. SPF is the approved visitor list. It checks if the person delivering the message is on the list of approved couriers.
2. DKIM is the tamper-proof seal on the envelope. It proves the message was not opened or altered after the sender sealed it.
3. DMARC is the security policy. It tells the front desk what to do if the courier is not on the list or the seal is broken: let them through (none), send them to a waiting room (quarantine), or turn them away (reject).

When all three work together, spoofing a domain becomes extremely difficult. An attacker would need to either compromise the domain's actual mail servers or find a vulnerability in the authentication chain.

What This Means for You as a User

You do not need to set up SPF, DKIM, or DMARC yourself (your email provider handles it). But understanding them helps you:

• Evaluate phishing emails. When you view email headers, the Authentication-Results field tells you whether SPF, DKIM, and DMARC passed. Three passes means the email genuinely came from the claimed domain.
• Understand why some phishing gets through. If a domain has p=none DMARC policy, failed authentication does not result in blocking. Not all domains have strong policies.
• Use tools effectively. When you paste an email into IsThisAScam.to, the tool checks these authentication results as part of its analysis. Understanding what SPF, DKIM, and DMARC mean helps you interpret the results.

Checking Authentication Yourself

In Gmail, the quickest check is:

1. Open the email
2. Click the three dots (⋮) → "Show original"
3. Look for the summary at the top showing SPF, DKIM, and DMARC results

If all three show "PASS," the email is authenticated. If any show "FAIL," treat the email with significant suspicion — especially if it asks you to click a link, download something, or provide personal information.

The Current State of Adoption

As of early 2026, approximately 85% of the world's email traffic is covered by at least one authentication protocol. However, only about 35% of domains have a DMARC policy set to reject or quarantine. Major email providers like Google and Yahoo began requiring SPF and DKIM for bulk senders in 2024, significantly improving the ecosystem. Microsoft followed with similar requirements in 2025.

The trend is clear: email authentication is becoming mandatory. Until coverage reaches 100%, your ability to check these results manually remains an important defense layer.