SPF, DKIM, and DMARC Explained: Email Authentication in Plain English

If you have ever wondered why some emails land in spam while others sail straight to the inbox, the answer often comes down to three acronyms: SPF, DKIM, and DMARC. These three protocols form the backbone of email authentication -- the system that helps receiving mail servers decide whether an incoming message is legitimate or a forgery. Understanding how they work does not require a networking degree. In fact, the core ideas are surprisingly straightforward once you strip away the jargon.

The Problem They Solve

Email was designed in the early days of the internet, when trust between systems was assumed. The original protocol has no built-in way to verify that a message actually came from the sender shown in the "From" field. That makes it trivially easy for anyone to forge a sender address -- a technique known as spoofing.

Spoofing is the engine behind most phishing attacks. An attacker sends an email that appears to come from your bank, your boss, or a trusted brand, but it actually originates from a completely different server. Without authentication, the receiving mail server has no reliable way to tell the difference. SPF, DKIM, and DMARC were created specifically to close this gap.

SPF: Who Is Allowed to Send?

SPF stands for Sender Policy Framework. It lets a domain owner publish a list of mail servers that are authorized to send email on behalf of that domain. This list is stored as a TXT record in the domain's DNS.

When an email arrives, the receiving server looks up the sender's domain and checks the SPF record. If the server that sent the message appears on the authorized list, the SPF check passes. If it does not, the check fails -- signaling that the message may be forged.

Here is a simplified example of what an SPF record looks like:

v=spf1 include:_spf.google.com include:mailgun.org -all

This record says: "Google's mail servers and Mailgun's servers are allowed to send for this domain. Reject everything else." The -all at the end is a hard fail -- it tells receiving servers to treat unauthorized senders as suspicious.

SPF is a strong first layer of defense, but it has limits. It only validates the server, not the content of the message. That is where DKIM comes in.

DKIM: Is the Message Authentic?

DKIM stands for DomainKeys Identified Mail. While SPF checks whether the sending server is authorized, DKIM goes a step further by verifying that the message itself has not been altered in transit.

Here is how it works. When a mail server sends a message, it creates a digital signature based on the email's headers and body. This signature is attached to the outgoing message as a special header. The corresponding public key is published as a TXT record in the sender's DNS, so any receiving server can look it up.

When the email arrives, the receiving server retrieves the public key from DNS, uses it to verify the signature, and confirms two things: the message was genuinely sent by the claimed domain, and nothing was changed after it left the sender's server.

Think of DKIM as a tamper-evident seal on a package. If someone opens the package and swaps the contents, the seal breaks -- and the recipient knows something is wrong.

DMARC: The Policy Layer

SPF and DKIM each handle a piece of the authentication puzzle, but neither one tells the receiving server what to do when a check fails. That is the job of DMARC -- Domain-based Message Authentication, Reporting, and Conformance.

DMARC is also published as a TXT record in DNS, and it does three important things:

1. Aligns the checks. DMARC requires that the domain in the visible "From" address matches the domain verified by SPF or DKIM (or both). This alignment step prevents a common trick where attackers pass SPF using their own domain but forge a different domain in the "From" field.
2. Sets a policy. The domain owner specifies what should happen to messages that fail authentication. The three policy levels are none (monitor only), quarantine (send to spam), and reject (block the message entirely).
3. Enables reporting. DMARC lets domain owners receive reports from mail servers around the world, showing who is sending email using their domain -- and whether those messages are passing or failing authentication.

A typical DMARC record looks like this:

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

This tells receiving servers: "Reject any message that fails authentication, and send aggregate reports to the specified address."

How the Three Protocols Work Together

SPF, DKIM, and DMARC are most effective when deployed together. Each one covers a gap that the others leave open:

• SPF confirms the sending server is authorized.
• DKIM confirms the message has not been tampered with and genuinely originated from the domain.
• DMARC ties SPF and DKIM to the visible sender address and tells receiving servers how to handle failures.

Without DMARC, a failed SPF or DKIM check might not result in any action at all -- the message could still land in the inbox. Without SPF or DKIM, DMARC has nothing to evaluate. All three need to be in place for the system to function as intended.

How to Check a Domain's Email Authentication

You do not need to read raw DNS records by hand to find out whether a domain has SPF, DKIM, and DMARC configured. There are a couple of quick ways to check:

• DNS Lookup -- Enter any domain and inspect its TXT record entries. SPF records start with v=spf1, and DMARC records start with v=DMARC1. DKIM records are stored under a specific selector subdomain, so they may require an additional lookup.
• Email Validator -- Validate a specific email address to see whether the domain behind it has the right MX record and authentication records in place.

If you manage a domain and have not set up these records yet, start with SPF, then add DKIM through your email provider, and finally publish a DMARC record with a policy of none so you can monitor results before enforcing a stricter policy.

Bringing It All Together

Email authentication is not a luxury -- it is a baseline requirement for anyone who sends email from a custom domain. SPF, DKIM, and DMARC work together to prove that a message is genuine, unaltered, and sent by someone who is actually authorized to use that domain. Without them, your messages are more likely to land in spam, and your domain is an easy target for impersonation.

The good news is that checking and setting up these records is easier than it sounds. Run a quick DNS lookup on your domain today and see where you stand. A few minutes of configuration can make a significant difference in both your deliverability and your security.