What are SPF, DKIM, & DMARC? Guide for 2026

If you've ever sent an important email campaign only to find it swallowed by the spam folder, you've felt the sting of poor email deliverability. In 2026, sending an email and hoping for the best is no longer a strategy; it's a liability. The digital landscape has evolved, and mailbox providers like Google and Yahoo now have strict, non-negotiable rules for anyone who wants to reach the inbox.

At the heart of these rules are three technical acronyms: SPF, DKIM, and DMARC. Think of them as the digital passport, security seal, and border control for your email. Without them, your messages look suspicious, untrustworthy, and are prime candidates for being blocked or marked as spam. For businesses that rely on email for marketing, sales, or transactional messages, getting this wrong means losing revenue and damaging your brand reputation.

This guide will demystify email authentication. We'll break down what each protocol does using simple analogies, show you exactly how to set them up, and explain why mastering them is the key to taking full control of your email deliverability—something that's only truly possible when you own your sending infrastructure.

Why Email Authentication is No Longer Optional in 2026

The days of optional email authentication are over. In 2024, Google and Yahoo rolled out new sender requirements that turned these technical best practices into mandatory table stakes. This move was a direct response to the rising tide of phishing, spam, and domain spoofing that plagues users' inboxes.

The impact was immediate and significant. According to analysis from Valimail and Google, these changes led to 2.3 million new DMARC implementations and, more importantly, a 65% reduction in unauthenticated messages reaching Gmail users. The message from mailbox providers is clear: if you don't authenticate, we won't deliver your mail.

For businesses, developers, and marketers, this means that proper setup of SPF, DKIM, and DMARC is no longer just for deliverability experts. It's a fundamental requirement for professional communication. Failing to comply doesn't just risk the spam folder; it risks your emails being rejected outright, never even reaching their destination.

What is SPF? The 'Guest List' for Your Email

The simplest way to understand SPF is to think of it as a guest list for a private party. You give this list to the security at the door, and they only let in people whose names are on it. Anyone else is turned away.

In technical terms, your SPF record is a list of IP addresses that are permitted to send emails from your domain (e.g., `yourbusiness.com`). When an email server receives a message, it looks at the sender's domain, checks its DNS for an SPF record, and compares the IP address of the sending server to the "guest list" in the record. If the IP is on the list, the SPF check passes. If not, it fails.

Example SPF Record

An SPF record is a single line of text stored in your DNS. A simple one looks like this:

v=spf1 ip4:192.168.0.1 include:sendgrid.net ~all

Let's break that down:

• v=spf1: This identifies the record as SPF version 1.
• ip4:192.168.0.1: Authorizes a specific IPv4 address (e.g., your NetSendo server's IP).
• include:sendgrid.net: Includes all the IP addresses authorized by another service's SPF record (e.g., a third-party email provider). The receiving server will do another DNS lookup for SendGrid's record.
• ~all: This is a qualifier that tells the receiver what to do with mail from sources not on the list. ~all stands for "SoftFail," meaning it suggests marking it as suspicious but likely not rejecting it outright. Other options are -all (HardFail - reject) and +all (Allow - not recommended).

⚠️ Warning: The 10-DNS-Lookup Limit. A common SPF mistake is having too many include, a, or mx mechanisms. SPF policies cannot generate more than 10 DNS lookups. Exceeding this limit will cause a permanent error, and your SPF record will fail validation. Always flatten your record where possible or use a dedicated service if you have many sending sources.

What is DKIM? The 'Tamper-Proof Seal' on Your Message

If SPF verifies the *sender*, DKIM verifies the *message*. The best analogy for DKIM is a tamper-proof wax seal on a medieval letter. The seal doesn't say who sent it, but it proves that the letter hasn't been opened or altered since it was sealed by the sender.

Here’s how it works:

1. Key Generation: You generate a pair of cryptographic keys: a private key (kept secret on your sending server) and a public key (published in your DNS).
2. Signing: When an email is sent, the sending server uses the private key to create a unique signature based on the content of the message (body and headers). This signature is added to the email header.
3. Verification: The receiving server sees the incoming email, finds the DKIM signature in the header, and retrieves the public key from the sender's DNS. If the public key successfully verifies the signature, the DKIM check passes. This proves two things: the email really came from your domain, and it wasn't changed along the way.

So, what happens if DKIM fails? A DKIM failure signals to the receiving server that the message may have been tampered with or that the sender is not who they claim to be. This significantly increases the likelihood of the email being sent to the spam folder or rejected, especially if DMARC is in place.

Example DKIM Record

A DKIM record is also a TXT record, but it looks more complex. It's typically created by your email sending service or server software (like NetSendo).

netsendo._domainkey.yourbusiness.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3..."

• netsendo._domainkey: This part is the "selector." It's a unique name that helps the receiving server find the correct public key, as you might have multiple DKIM keys for different services.
• v=DKIM1: Identifies the DKIM version.
• k=rsa: Specifies the key type (RSA is standard).
• p=...: This is the long string of characters representing your public key.

What is DMARC? The 'Security Policy' for Your Domain

DMARC is the final piece of the puzzle. If SPF is the guest list and DKIM is the tamper-proof seal, then DMARC is the security guard's instruction manual. It tells the guard (the receiving email server) exactly what to do when someone shows up who isn't on the guest list (SPF fail) or has a broken seal on their letter (DKIM fail).

DMARC does two critical things:

1. Policy Enforcement: You can tell servers how strictly to enforce your rules.
   • p=none: Monitor mode. Do nothing to the message, but send me reports.
   • p=quarantine: Treat failing messages with suspicion. Send them to the spam folder.
   • p=reject: Reject failing messages outright. They will not be delivered.
2. Reporting: You can receive aggregate and forensic reports about emails sent using your domain, showing which ones passed, which failed, and from where they were sent. This is invaluable for spotting misconfigurations and abuse.

ℹ️ Note: Alignment is Key for DMARC. For DMARC to pass, SPF or DKIM (or both) must not only pass, but also be *aligned*. This means the domain used in the "From" address that the user sees must match the domain in the passing SPF or DKIM record. This is what prevents spoofing.

Example DMARC Record

To create a DMARC record, you add one more TXT record to your DNS, at the `_dmarc.yourbusiness.com` address.

_dmarc.yourbusiness.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourbusiness.com; pct=100"

• v=DMARC1: DMARC version.
• p=quarantine: The policy. Here, we're telling receivers to send failing mail to spam.
• rua=mailto:dmarc-reports@yourbusiness.com: The address where aggregate reports should be sent.
• pct=100: Applies the policy to 100% of emails. You can start with a lower percentage (e.g., `pct=10`) to test your policy.

How SPF, DKIM, and DMARC Work Together

Many people ask, "Do I need all three?" or "Which is more important, SPF or DKIM?" The answer is that they are designed to work as a team. You absolutely need all three for a modern, secure email setup.

Here's the combined workflow:

1. An email from `you@yourbusiness.com` arrives at a server.
2. The server checks for the DMARC policy at `_dmarc.yourbusiness.com`.
3. The server performs an SPF check: "Did this email come from an IP address authorized by `yourbusiness.com`?"
4. The server performs a DKIM check: "Does this email have a valid signature from `yourbusiness.com`?"
5. The server checks for alignment: "Does the domain in the 'From' address match the domain in the passing SPF/DKIM record?"
6. Based on the results and the DMARC policy (`p=reject`, `quarantine`, or `none`), the server decides whether to deliver the email to the inbox, send it to spam, or reject it.

The 'Enforcement Gap': Why Your DMARC Policy Might Not Be Protecting You

While the adoption of DMARC has soared, a critical issue has emerged: the 'enforcement gap'. According to a 2026 report from EasyDMARC, while DMARC adoption has reached 52.1% among top domains, a large majority of those are using the non-enforced `p=none` setting. Further analysis reveals a stark reality: only 2.5% of 73.3 million domains globally enforce the strictest 'p=reject' policy.

This means that while many organizations are collecting reports, they are not actually protecting their domains from spoofing. An attacker can still send fraudulent emails from a domain with a `p=none` policy, and those emails are likely to be delivered.

The goal of any DMARC implementation should be to progressively move from `p=none` to `p=quarantine` and ultimately to `p=reject`. Staying at `p=none` is like installing a security camera system but never locking the doors.

How to Set Up and Verify Your Authentication Records

Setting up your records is a straightforward process that involves adding TXT records to your domain's DNS settings. This is usually done through your domain registrar (like Namecheap, GoDaddy) or DNS provider (like Cloudflare).

1. Identify Your Sending Sources

   Make a list of every service and server that sends email for your domain. This includes your own servers (like a NetSendo instance), your transactional email provider (e.g., Amazon SES), and your marketing platform.

2. Generate Your Records

   For each service, find their documentation on setting up SPF and DKIM. Your NetSendo server will provide you with the exact records you need. You will then combine all SPF sources into a single record and create separate DKIM records for each service/selector.

   For DMARC, you can use a generator tool or create it manually, starting with `p=none`.

   v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbusiness.com;

3. Add Records to Your DNS

   Log in to your DNS provider and navigate to the DNS management section. You will be adding three types of TXT records:

   • SPF: One TXT record at your root domain (e.g., `yourbusiness.com`).
   • DKIM: One or more TXT records at specific selector subdomains (e.g., `selector1._domainkey.yourbusiness.com`).
   • DMARC: One TXT record at the `_dmarc` subdomain (e.g., `_dmarc.yourbusiness.com`).

[Image: DNS Records Configuration in Cloudflare]

4. Verify Your Configuration

   DNS changes can take time to propagate. After an hour, use one of the tools listed below to check that your records are set up correctly and are visible to the internet. Send a test email to a service like mail-tester.com to get a full report.

Free Tools to Check Your SPF, DKIM, and DMARC Setup

You don't have to guess if your setup is correct. Use these excellent free tools to verify your configuration: