Email Deliverability Guide 2026: SPF, DKIM, and DMARC Explained

What Is Email Deliverability and Why Does It Matter in 2026?

Email deliverability is the ability of your emails to actually reach your recipients' inboxes rather than being filtered into spam or rejected outright. It sounds simple, but for millions of businesses, it is a silent revenue killer.

Think about what you use email for: invoices, order confirmations, marketing campaigns, password resets, sales outreach. If those emails land in spam, your customers miss them. Your invoices go unpaid longer. Your campaigns generate no clicks. Your users think your product is broken because they never got the confirmation email.

In 2026, email deliverability is more important than ever because inbox providers like Google and Yahoo have dramatically raised the bar for what they accept. The old days of sending email and hoping for the best are over. If you have not set up proper email authentication, you are likely already losing emails you do not even know about.

Google and Yahoo's Bulk Sender Requirements (Enforced Since February 2024)

In late 2023, Google and Yahoo jointly announced new requirements for bulk email senders, with enforcement beginning in February 2024. These requirements apply to anyone sending more than 5,000 emails per day to Gmail addresses, but in practice the authentication requirements apply to all senders.

Here is what they now require:

SPF or DKIM authentication (both is strongly recommended)
DMARC policy published on your domain
A one-click unsubscribe mechanism in marketing emails
Spam complaint rates below 0.3% (with a target under 0.1%)

Failure to meet these requirements means your emails will be rejected or quarantined by Google. For a business that relies on email marketing or transactional emails, this can be catastrophic. The good news is that fixing these issues is mostly a matter of adding the right DNS records to your domain, which takes less than an hour once you know what to do.

SPF: Proving Your Mail Server Is Authorized

SPF stands for Sender Policy Framework. It is a DNS record that tells the world which mail servers are allowed to send email on behalf of your domain.

Here is an analogy that makes it click: imagine you are a business owner and you have authorized a courier company to deliver packages on your behalf. SPF is like publishing a public list that says "only this courier company is authorized to deliver packages with my company name on them." When a package arrives from someone claiming to be your company, the recipient can check that public list. If the delivery truck is not on your approved list, the recipient knows something is wrong.

Without SPF, anyone can send email claiming to be from your domain. With SPF, receiving mail servers can verify that the email came from a server you actually authorized.

An SPF record lives in your DNS as a TXT record and looks something like this:

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

This says: emails from my domain can come from Google's mail servers or SendGrid's servers, and anything else should be treated with suspicion (~all means softfail, while -all means reject).

Common SPF Mistakes

Too many DNS lookups: SPF has a limit of 10 DNS lookups per evaluation. If your record includes too many include: statements, it breaks.
Missing sending services: If you use a third-party tool like Mailchimp, HubSpot, or SendGrid to send email, you need to include their servers in your SPF record. Many businesses forget to update SPF when they add a new email tool.
No SPF at all: Surprisingly common, especially for smaller businesses or those using domain registrars that do not set up email authentication by default.

DKIM: Digitally Signing Your Emails

DKIM stands for DomainKeys Identified Mail. While SPF verifies that a message came from an authorized server, DKIM goes further by cryptographically signing the message content itself.

Think of DKIM like a wax seal on an envelope from centuries ago. When the recipient gets a letter with your official seal intact, they know two things: it came from you (or someone with your seal), and the letter has not been tampered with since you sent it. If the seal is broken or missing, something is wrong.

DKIM works using a public/private key pair. Your mail server signs outgoing emails with a private key. The corresponding public key is published in your DNS. When a receiving mail server gets your email, it looks up your public key, verifies the signature, and confirms the email is authentic and unmodified.

A DKIM DNS record looks like this:

selector._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."

The selector part lets you have multiple DKIM keys for different sending services. Google Workspace might use google._domainkey, while SendGrid might use s1._domainkey.

Most email service providers (Google Workspace, Microsoft 365, Mailchimp, etc.) will give you the exact DNS records to add when you set up your account. The key step is actually going into your domain registrar's DNS settings and adding those records.

DMARC: Telling Providers What to Do With Failures

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It builds on SPF and DKIM by giving domain owners a way to specify what should happen when an email fails authentication checks, and to receive reports about authentication failures.

DMARC has three policy options that determine what happens when an email fails SPF and DKIM checks:

none (p=none): Monitor only. Failing emails are still delivered, but you receive reports about failures. This is the right starting point when you first set up DMARC because it lets you see what is happening without risking legitimate email being blocked.
quarantine (p=quarantine): Failing emails go to the spam folder. Use this once you are confident your SPF and DKIM are correctly configured and you have reviewed the DMARC reports.
reject (p=reject): Failing emails are rejected outright and never delivered. This is the strongest protection and what Google and Yahoo want you to eventually reach. Only move here once you have verified that all your legitimate email sources are properly authenticated.

A DMARC record looks like this:

_dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"

The rua tag specifies an email address where you want to receive aggregate reports. These reports are XML files that tell you which servers are sending email on your behalf and whether they are passing authentication. They are not easy to read raw, but tools exist to parse and visualize them.

The recommended progression is: start with p=none for a few weeks to collect data, then move to p=quarantine once you are confident, then eventually to p=reject for the strongest protection.

How to Check Your Email Deliverability

Before you can fix anything, you need to know what is broken. The fastest way to check your current setup is to run a scan on your domain. MailScore checks your SPF, DKIM, DMARC, and MX records and gives you a plain-English report with specific fixes in seconds.

Enter your domain below to get your deliverability score right now. It is free and takes about 10 seconds.

Beyond automated scanning, here are the things you should check manually:

Log into your email service provider (Google Workspace, Microsoft 365, Mailchimp, etc.) and look for any warnings about authentication setup.
Check your domain registrar's DNS settings to confirm the SPF, DKIM, and DMARC records actually exist and look correct.
If you use multiple sending services, verify that each one is included in your SPF record and has a DKIM key configured.
Review your Google Postmaster Tools data if you send to Gmail recipients at scale. It shows your domain reputation and spam rates.

Common Mistakes Businesses Make

After scanning thousands of domains, these are the most common problems we see:

No DMARC record at all: The most common issue. Many businesses have SPF and DKIM set up but never added DMARC. Google and Yahoo now require it.
DMARC stuck at p=none forever: Setting up DMARC with p=none and then never reviewing the reports or moving to a stricter policy. You get no protection this way.
Forgotten sending services: Adding a new marketing tool or CRM that sends email and forgetting to add it to SPF and configure its DKIM. The new tool's emails fail authentication.
SPF record over the 10-lookup limit: Happens when you use many email services. Each include: in your SPF counts toward the limit. Some services offer flattened SPF records as a workaround.
DKIM selector mismatch: The DKIM public key in DNS does not match what your mail server is signing with, usually because a key was rotated on one side but not the other.
Incorrect MX records: Less common, but broken MX records mean you cannot receive email at all, which also affects deliverability reputation.
High bounce and spam complaint rates: Technical authentication is only half the battle. Sending to bad lists or content that triggers spam filters will hurt your reputation even with perfect authentication.

Getting to a Clean Bill of Health

The good news is that all of these issues are fixable. Here is the order of operations:

First, scan your domain to see exactly what is missing or broken.
Fix your SPF record to include all services that send email on your behalf.
Enable DKIM through each of your email sending services and add the DNS records they provide.
Add a DMARC record starting with p=none and an email address for reports.
Wait two to four weeks, review the DMARC reports (or use a report analyzer tool), and confirm all your legitimate senders are passing.
Move your DMARC policy to p=quarantine, then eventually to p=reject.

Once everything is in place, run your domain through MailScore again to confirm you are getting a clean score. If you want ongoing monitoring so you are alerted the moment something breaks, you can set up automatic daily or weekly scans from the dashboard.

The Bottom Line

Email authentication is no longer optional. Google and Yahoo made that clear in February 2024, and the requirements are only going to get stricter over time. If your emails are landing in spam or getting rejected, authentication issues are the most likely cause and the most important thing to fix.

The technical setup takes less than an hour if you know what you are doing. The tricky part is knowing what to look for and interpreting the results. That is exactly what MailScore is built to help with: a 10-second scan that tells you exactly what is broken and what to do about it, in plain English that anyone on your team can follow.

Do not wait until a customer tells you your emails are going to spam. Check your domain now and fix any issues before they cost you revenue.