The Ultimate Email Deliverability Guide: SPF, DKIM, DMARC & ARC Explained (2026)

Email deliverability has never been more complex — or more important. In February 2024, Google and Yahoo jointly announced new requirements that shook the email industry: bulk senders must now authenticate with SPF, DKIM, and DMARC or face rejection at scale. If you're sending more than 5,000 emails per day to Gmail addresses and haven't configured these records, you're already in trouble. But even for lower-volume senders, these authentication standards are now effectively mandatory across the entire inbox provider ecosystem. Understanding not just what these protocols are, but exactly how to configure them correctly and what each one actually does for your deliverability, is the difference between consistent inbox placement and inexplicable spam folder relegation.

This guide covers the full authentication stack — SPF, DKIM, DMARC, ARC, and — plus the practical steps to achieve a 10/10 score on mail-tester.com, set up Google Postmaster Tools monitoring, and diagnose the most common deliverability problems that affect senders in 2026.

Understanding Email Authentication — Why It Exists

Email was designed in the early days of the internet under an assumption of universal good faith. The original SMTP protocol, standardized in 1982, had no mechanism to verify that the entity claiming to send an email was actually authorized to do so. Any mail server on the internet could send an email claiming to be from any domain it wanted — From: president@whitehouse.gov was as easy to spoof as any other address. This fundamental design gap enabled the explosion of spam and phishing that characterized the early 2000s email landscape. By 2003, analysts estimated that over half of all email traffic globally was spam, and phishing attacks — emails impersonating banks, government agencies, and trusted brands — were responsible for billions of dollars in fraud annually.

Email authentication protocols were developed as a direct response to this problem. SPF was first proposed in 2003, DKIM emerged from multiple predecessor standards around 2004–2005, and DMARC — which builds on both — was published in 2012. ARC, solving the specific problem of authenticated forwarding, came later in 2019. Together they form a layered authentication system that allows receiving mail servers to verify: who is authorized to send for this domain (SPF), that the email content hasn't been tampered with (DKIM), and what to do if verification fails (DMARC). Without all three working in alignment, no sender can claim to be doing email correctly in 2026.

SPF (Sender Policy Framework) — Authorizing Your Sending Sources

What SPF Does

SPF is a DNS TXT record that you publish at your sending domain, listing every IP address and mail server that is authorized to send email claiming to be from that domain. When a receiving mail server accepts an incoming email claiming to be from yourcompany.com, it queries the DNS for your domain's SPF record, looks up the IP address of the server that delivered the message, and checks whether that IP is listed in your SPF record as authorized. If it is, SPF passes. If it isn't — or if no SPF record exists — SPF fails, which is a significant negative signal for inbox placement and will cause DMARC failure if you have a DMARC policy in place.

It's important to understand what SPF checks and what it doesn't. SPF checks the envelope sender (also called the MAIL FROM or Return-Path) — the technical origin address used in the SMTP handshake — not the From address visible to the recipient in their email client. This distinction matters for understanding why SPF alone is insufficient and why DMARC alignment is necessary.

How to Create an SPF Record

An SPF record is a DNS TXT record at your root domain. A typical SPF record looks like:

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

Breaking this down: v=spf1 identifies this as an SPF version 1 record. ip4:203.0.113.45 explicitly authorizes a specific IPv4 address. include:_spf.google.com pulls in the SPF record maintained by Google (useful if you send some mail through Google Workspace). include:sendgrid.net includes SendGrid's authorized IPs. The final ~all is the "all" mechanism — a catch-all that defines what to do with IP addresses not listed earlier.

The qualifiers for the all mechanism are: +all (pass everything — never use this, it defeats the purpose of SPF), ?all (neutral — treat unlisted IPs as neither pass nor fail), ~all (softfail — unlisted IPs fail but the email should still be accepted and marked), and -all (hard fail — reject email from unlisted IPs). Start with ~all while verifying your setup is complete, then move to -all once you're confident every sending source is listed.

Common SPF mistakes to avoid:

• Multiple SPF records: You can only have one SPF TXT record per domain. Having two invalidates both and causes SPF to fail. If you need to add new sources, edit the existing record rather than creating a second one.
• Exceeding the DNS lookup limit: SPF has a hard limit of 10 DNS lookups during evaluation. Each include: mechanism counts as one lookup, and those included records may themselves trigger further lookups. Exceeding 10 causes SPF to return a PermError, which many receivers treat as a failure. Use tools like MXToolbox's SPF Record Checker to count your lookups.
• Forgetting sending sources: Every service that sends email on behalf of your domain — your ESP, your CRM, your marketing automation platform, your transactional email provider — must be included in your SPF record. Missing one means those emails will fail SPF.

Testing Your SPF Record

MXToolbox's SPF Record Lookup tool at mxtoolbox.com/spf.aspx lets you enter your domain and see your full SPF record evaluated, including all included records expanded out, a lookup count, and any errors or warnings. A clean SPF check should show all your authorized sending sources listed, lookup count under 10, and no syntax errors. mail-tester.com also evaluates SPF as part of its comprehensive email score.

DKIM (DomainKeys Identified Mail) — Cryptographic Email Signing

What DKIM Does

DKIM adds a cryptographic digital signature to every outgoing email, embedded as a header in the message. When you configure DKIM, you generate a public/private key pair. The private key is stored securely on your sending server and used to sign each outgoing message. The public key is published in your DNS as a TXT record. When a receiving server gets a DKIM-signed email, it retrieves your public key from DNS and uses it to verify the signature. If the signature is valid, it proves two things: the email genuinely originated from a server authorized to use your private key, and the email content (including specified headers and body) has not been modified since it was signed.

Unlike SPF, which checks the SMTP envelope, DKIM checks the message content and headers — including the visible From address. This is why DKIM is the more important of the two for DMARC alignment purposes, as DMARC alignment requires either SPF or DKIM to align with the visible From domain, and DKIM alignment is more reliable across forwarding and routing scenarios.

Setting Up DKIM

Generate a 2048-bit RSA key pair (2048-bit is the current minimum recommended; 1024-bit keys are now considered weak and rejected by some receivers). Most MTAs and ESPs have built-in key generation tools. On Postfix with OpenDKIM, the command is:

opendkim-genkey -b 2048 -d yourdomain.com -s mail2026

This generates a private key (mail2026.private) and a DNS record file (mail2026.txt). The selector (mail2026 in this example) is an arbitrary label that allows you to have multiple DKIM keys simultaneously — useful for rotation. The DNS TXT record to publish looks like:

mail2026._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."

The p= value is your base64-encoded public key. After publishing the DNS record and configuring your MTA to sign with the matching private key, verify DKIM is working by sending a test email to mail-tester.com or using MXToolbox's DKIM Lookup tool with your domain and selector.

DKIM Rotation

Rotating DKIM keys periodically is a security best practice — if a private key is ever compromised, rotating limits the exposure window. The safe way to rotate without breaking mail flow is: generate a new key pair with a new selector name, publish the new public key in DNS, wait 24–48 hours for DNS propagation, update your MTA configuration to sign with the new key, verify the new key is working, then remove the old DNS record. Never remove the old DNS record before verifying the new key is active, as emails signed with the old key and still in transit will fail verification if the old record disappears before they're delivered.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

What DMARC Does

DMARC builds on SPF and DKIM by adding two critical capabilities they lack individually: alignment checking and policy enforcement. Alignment means DMARC requires that either the SPF-authenticated domain or the DKIM-signing domain matches the visible From address domain. This closes the gap that allowed spammers to pass SPF or DKIM by using a different domain in the technical envelope while showing a spoofed From address to the recipient. Policy enforcement means DMARC tells receiving servers what to actually do with emails that fail alignment — nothing, quarantine them, or reject them entirely. And crucially, DMARC enables reporting: receiving servers send aggregate data back to you about every email they received claiming to be from your domain, whether it passed or failed authentication, and from which IP addresses.

DMARC Policies Explained

A DMARC record is a DNS TXT record at _dmarc.yourdomain.com. A basic starting record looks like:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; fo=1

The three policy levels are:

• p=none: Monitor only. Receiving servers process the email normally regardless of authentication outcome and send reports to your rua address. This is the right starting point — it gives you visibility without any risk of legitimate mail being blocked due to misconfiguration.
• p=quarantine: Emails that fail DMARC alignment are sent to the recipient's spam/junk folder rather than the inbox. This is an active enforcement stance that begins protecting your domain from spoofing while still allowing failed emails to potentially be reviewed.
• p=reject: Emails that fail DMARC are rejected outright by the receiving server — they never reach the recipient at all. This is the strongest protection against domain spoofing and phishing, and is required for implementation.

Reading DMARC Reports

DMARC aggregate reports (rua) arrive as XML files attached to emails, typically once per day from each major receiver. They contain data on every email your domain sent during the reporting period: source IP, volume, SPF/DKIM pass/fail status, and DMARC disposition. Raw XML is difficult to read, so use a DMARC report parser — Dmarcian, Postmark's DMARC Digests, or the free tier of EasyDMARC are all good options. In the reports, look for: unexpected IP addresses sending email claiming to be from your domain (potential spoofing or forgotten sending sources), SPF or DKIM failures from known legitimate sources (indicating a configuration problem), and volume from sources you didn't know were sending on your behalf (shadow IT, forgotten integrations).

Progressive DMARC Implementation

Jumping straight to p=reject on a domain with any complexity is dangerous. Forgotten sending services, misconfigured third-party integrations, or legacy systems you didn't know existed will have their emails rejected — including potentially important operational messages. The safe path is progressive: start with p=none and collect reports for two to four weeks. Identify and fix any authentication failures from legitimate sources. Once your reports show consistent near-100% DMARC pass rates for all legitimate sending sources, advance to p=quarantine at a low percentage using the pct tag (e.g., pct=10 means only 10% of failing emails get quarantined, the rest are treated as p=none). Gradually increase the percentage over two to four weeks while monitoring for unexpected failures. Then advance to p=reject using the same gradual percentage approach.

ARC (Authenticated Received Chain) — The Forwarding Problem

Why ARC Exists

SPF and DKIM both have a specific failure mode when email is legitimately forwarded. SPF checks the IP of the server that delivered the message to the receiving server. When an email is forwarded, the forwarder's IP — not the original sender's IP — is what the final receiving server sees. This causes SPF to fail even for completely legitimate forwarded mail. DKIM is more resilient to forwarding because the signature is in the message headers, but some forwarders modify message content (adding footers, rewriting links) in ways that break the DKIM signature. The result is that a legitimate email that passed authentication at every intermediate hop can arrive at the final destination looking like an authentication failure.

ARC solves this by creating a chain of authentication results. Each intermediate server that handles the message adds an ARC header set documenting the authentication results it observed, signed with its own DKIM key. The final receiving server can follow this chain backward through all the intermediate hops to evaluate whether the email was properly authenticated at origin, even if the original SPF and DKIM checks no longer pass at the final hop.

When ARC Matters

ARC is most important for operators of mailing lists, forwarding services, and any system that relays email on behalf of others. If you're a direct sender whose emails go straight from your server to the recipient's mail server, ARC adds relatively little value. But if you use services that forward, relay, or re-send email — including some corporate email security gateways — ARC implementation by those intermediaries protects your delivery rates. When evaluating email infrastructure providers, ARC support is a signal of technical depth.

(Brand Indicators for Message Identification)

is the most visible deliverability enhancement available today: it places your brand logo directly next to your emails in supported inboxes. Gmail, Yahoo Mail, Apple Mail, and Fastmail all support, meaning the combined addressable inbox share for display is substantial. Implementing requires DMARC at p=quarantine or p=reject, a Verified Mark Certificate (VMC) from an approved certification authority, and a DNS TXT record at default._bimi.yourdomain.com pointing to an SVG version of your logo. VMCs require a registered trademark, which limits to organizations with formally registered brand marks, but for those that qualify, the inbox visibility improvement is measurable — studies consistently show open rate improvements of 10–15% for senders with brand logo display.

Achieving 10/10 on Mail-Tester.com

Mail-tester.com is the most useful single-URL deliverability diagnostic tool available. Send a test email to the address it provides, hit "Check your score," and it evaluates your email against a comprehensive set of authentication, configuration, and content criteria. A 10/10 score requires all of the following to be correct:

1. SPF passes with no errors — your sending IP is explicitly authorized in your SPF record, no lookup limit exceeded, no syntax errors.
2. DKIM passes with 2048-bit key — signature validates against public key in DNS, selector resolves correctly, 1024-bit keys will be flagged.
3. DMARC record present — at minimum p=none is required; higher policies score no higher but the record must exist and be valid.
4. Reverse DNS (PTR record) configured — the sending IP's PTR record resolves to a hostname that matches your EHLO/HELO greeting and forward-resolves back to the same IP.
5. No blacklist hits — the sending IP must be clean on all major blacklists checked by mail-tester (Spamhaus, SORBS, Barracuda, SpamCop, and others). Even one major blacklist hit will significantly reduce your score.
6. SpamAssassin score below 1.0 — the content of your email is evaluated against SpamAssassin's content rules. Spam trigger words, all-caps subject lines, excessive links, and certain HTML structures can accumulate points. Keep the score below 1.0 for a clean result.
7. HELO/EHLO hostname matches PTR — your MTA's configured hostname in the SMTP greeting must exactly match what the PTR record resolves to. Mismatches are a common misconfiguration.
8. No open relay — your server must not accept and forward email for arbitrary third-party domains. An open relay will immediately blacklist your IP across most major lists.
9. TLS enabled for outbound connections — modern mail servers negotiate TLS (STARTTLS) for encrypted transmission. Sending in plaintext is now a negative signal.
10. ARC configured — present in mail-tester's checks, though its weight in the scoring is lighter than SPF/DKIM/DMARC.

Google Postmaster Tools — Your Deliverability Dashboard

Google Postmaster Tools is a free service from Google that provides senders with visibility into how their email is performing at Gmail — the single largest inbox provider globally. Setting it up requires verifying ownership of your sending domain by adding a DNS TXT record or HTML meta tag. Once verified, Postmaster Tools provides a dashboard with several key metric categories.

Domain Reputation is the most important metric: Google assigns your sending domain one of four reputation levels — High, Medium, Low, or Bad. High means Gmail trusts your domain and delivers your emails to the inbox consistently. Medium means there are some signals of concern but Gmail is still delivering most of your mail. Low means Gmail is sending a significant portion of your email to spam. Bad means Gmail considers your domain a spam source and is rejecting or filtering the vast majority of your email. Any domain showing Low or Bad reputation requires immediate action: stop sending, diagnose the cause (usually list quality or authentication failures), fix it, and gradually rebuild.

Spam Rate shows the percentage of your Gmail recipients who are marking your emails as spam. Google's guidance is to keep this below 0.10% consistently, and never let it exceed 0.30% even briefly. Spam rates above these thresholds trigger automatic deliverability degradation. Note that this metric shows the rate as Google observes it — your own unsubscribe rate is not a proxy for what Google sees.

Delivery Errors shows rejected or deferred messages along with error codes that explain the reason. Error codes beginning with 5xx indicate permanent rejections (your message was refused); 4xx codes indicate temporary deferrals. Common 5xx errors include policy-based rejections (your IP or domain is on Google's blocklist), authentication failures (DMARC rejection), and reputation-based blocks.

Feedback Loop data and DKIM/DMARC Compliance charts complete the picture, showing what percentage of your inbound-to-Gmail volume is passing authentication. You should see 100% DKIM compliance and 100% DMARC compliance for legitimate sending. Any failures indicate a misconfigured sending source that's slipping through your authentication setup.

Common Deliverability Problems and How to Fix Them

Conclusion

Email authentication is no longer a technical nicety that careful senders implement for extra credit — it is the mandatory foundation on which all deliverability is built in 2026. SPF authorizes your sending sources. DKIM proves your messages haven't been tampered with. DMARC aligns both with your visible From domain, enforces policy on failures, and gives you reporting visibility. ARC extends that trust through forwarding scenarios. Together they establish your identity as a legitimate sender to every inbox provider that receives your mail.

Getting all of these configured correctly — and verifying with tools like mail-tester.com and Google Postmaster Tools — is the prerequisite for everything else in deliverability: IP reputation, list hygiene, engagement optimization, and content quality. Senders who skip the authentication layer and focus on content or volume tactics are building on an unstable foundation.

If you're operating on infrastructure that makes proper authentication configuration difficult — or if you've inherited a setup where you're not sure what's configured correctly — the fastest path to a verified 10/10 foundation is working with infrastructure built specifically for deliverability. See how SendHaven's infrastructure handles authentication setup and ongoing deliverability management as part of the core service, and book a demo to talk through your current setup with our team.