← Back to blog

DMARC, SPF & DKIM: Why Email Authentication Is Now a Deliverability Requirement

Gmail and Yahoo's stricter sender requirements made domain authentication non-negotiable. If your domain isn't properly protected, your campaigns risk the spam folder — or outright rejection. Here's what you need to know and do.

DMARC shield protecting email security and deliverability with SPF and DKIM

Until recently, setting up SPF, DKIM, and DMARC was considered best practice — something careful senders did, but not a hard requirement. That changed in February 2024, when Gmail and Yahoo announced they would begin enforcing authentication standards for all bulk senders. Campaigns from unauthenticated domains would be rejected or delivered directly to spam.

The shift wasn't a surprise to those following email deliverability closely. Spoofing attacks — where bad actors send phishing emails that appear to come from legitimate domains — had been rising for years. Authentication protocols were the obvious fix. What changed is enforcement: what was once optional is now the price of admission to the inbox.

This article breaks down how SPF, DKIM, and DMARC actually work, what Gmail and Yahoo now require, and how to use them to protect your domain reputation and campaign performance.

The Three Pillars of Email Authentication

Email authentication is built on three complementary DNS records. Each does something different, and all three work together to give receiving mail servers a complete picture of whether an email is legitimate.

SPF: Who Is Allowed to Send on Your Behalf

SPF (Sender Policy Framework) is a DNS TXT record that lists every mail server authorized to send email from your domain. When a receiving server gets an email claiming to be from yourcompany.com, it checks your SPF record to verify the sending IP is on the approved list.

A typical SPF record looks like this:

TXT record for yourdomain.com
v=spf1 include:mailgun.org include:_spf.google.com ~all

The ~all at the end is a "soft fail" — emails from unlisted servers are marked suspicious but not rejected. -all is a "hard fail" — they're rejected outright. Most senders start with ~all while they audit all their sending sources.

What SPF doesn't cover: SPF only checks the "envelope from" domain — the technical return path, not the From address visible to recipients. This gap is where DKIM comes in.

DKIM: A Cryptographic Signature on Every Email

DKIM (DomainKeys Identified Mail) adds a digital signature to each outgoing email. The signature is generated using a private key on your sending server and can be verified by anyone using the corresponding public key published in your DNS.

When a receiving server checks DKIM, it:

  1. Reads the DKIM signature in the email's headers
  2. Fetches the public key from your DNS
  3. Verifies the email content hasn't been altered in transit
  4. Confirms the email genuinely originated from a server with access to your private key

DKIM does two things simultaneously: it proves the email is from you, and it proves it hasn't been tampered with. Even if someone intercepts the email mid-delivery and changes a word, the DKIM signature breaks — and the receiving server knows something is wrong.

Your ESP (Mailchimp, Klaviyo, HubSpot, SendGrid, etc.) will provide DKIM setup instructions specific to their infrastructure. It typically involves adding two CNAME records to your DNS and enabling custom domain signing.

DMARC: The Policy Layer That Ties It Together

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy that tells receiving servers what to do when an email fails SPF or DKIM — and critically, reports back to you when failures occur.

A DMARC record has three possible policies:

A basic DMARC record:

TXT record for _dmarc.yourdomain.com
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100

The rua tag specifies where aggregate reports get sent. These XML reports arrive daily and show every IP that sent email claiming to be your domain — including unauthorized ones you didn't know about.

"DMARC reports often reveal a surprise: transactional platforms, CRMs, or legacy tools sending on your behalf that you forgot to authorize in SPF. The monitoring phase is when you discover your full sending footprint."

What Gmail and Yahoo Now Require

Since February 2024, both Gmail and Yahoo have enforced specific requirements for senders who send more than 5,000 emails per day to their platforms. But in practice, even lower-volume senders benefit from compliance — and some requirements are enforced regardless of volume.

The full requirement list:

Senders who don't meet these requirements see their emails temporarily rejected with a 421 or 550 error code. At scale, this means entire campaigns fail to deliver — not just individual emails.

Domain Reputation: Why Authentication Is the Foundation

Authentication protocols don't directly improve your inbox placement — but they make everything else possible. Without authentication, there's no stable identity for inbox providers to build a reputation score around.

Think of domain reputation as a credit score for your sending domain. Gmail, Microsoft, and Yahoo all maintain internal scores based on:

A domain with strong authentication and clean engagement history will consistently outperform an unauthenticated domain with better-written emails. The algorithm trusts authenticated senders more, rewards engagement more, and downgrades unauthenticated anomalies faster.

The Spoofing Problem: Why DMARC Protects Your Reputation Even When You're Not Sending

Here's the scenario that surprises most senders: your domain reputation can be damaged by emails you never sent. Without a DMARC enforcement policy, anyone can send phishing or spam emails that appear to come from your domain. Their spam complaints register against your domain. Their low engagement history drags down your sender score.

With p=reject, those spoofed emails never reach inboxes — so their damage never happens. This is the most compelling reason to eventually move beyond p=none to enforcement, once you're confident your legitimate sends all authenticate correctly.

The Alignment Requirement: A Common Mistake

One of the most frequent DMARC failures comes from domain misalignment. DMARC requires that the domain in the visible From address matches (or is a subdomain of) the domain that passes SPF or DKIM.

A common scenario: a company sends marketing emails with a From address of hello@yourcompany.com, but their ESP sends via a shared infrastructure using a different return-path domain. SPF passes for the ESP's domain, but it doesn't align with yourcompany.com — so DMARC fails even though SPF technically passed.

The fix is custom domain authentication: configure your ESP to sign emails with your own domain's DKIM keys and set up a custom return path. Every major ESP supports this. It's the difference between being a tenant in someone else's domain and owning your sending identity.

Moving from p=none to p=reject: A Practical Roadmap

Most senders should progress through three stages:

  1. Deploy p=none and collect reports (weeks 1–4)
    Set up DMARC with monitor-only policy. Use a DMARC reporting tool (Postmark, MXToolbox, Dmarcian, or Google Postmaster Tools) to parse the incoming XML reports. Identify every IP and service sending as your domain.
  2. Authorize legitimate senders and fix alignment (weeks 4–8)
    Add all legitimate sending sources to your SPF record. Enable custom DKIM signing for each ESP or tool. Verify DMARC alignment by checking that authenticated domain matches your From domain.
  3. Move to p=quarantine, then p=reject (weeks 8–12)
    Once your DMARC reports show near-100% pass rates, step up to quarantine. Monitor for any drop in legitimate email delivery. After confirming everything passes cleanly, advance to reject. This is when full protection kicks in.

"The journey from p=none to p=reject typically takes 6–12 weeks for organizations with multiple sending tools. The monitoring phase is where most of the work happens — and where most of the surprises are found."

What This Means for Your Email Marketing in Practice

Authentication is infrastructure — it doesn't write better subject lines or improve your segmentation. But it creates the stable foundation that everything else depends on. Here's how it translates into day-to-day campaign management:

The Bigger Picture: Authentication as the New Baseline

Gmail and Yahoo's 2024 requirements formalized what deliverability experts had been recommending for a decade. The subtext of the announcement was clear: the era of unauthenticated bulk email is ending. The inbox is being treated as a curated space, and the price of access is a verified, accountable sending identity.

For email marketers, this is ultimately good news. A world where authentication is enforced is a world where your legitimate, opted-in campaigns aren't competing on equal terms with spoofed spam. The signal-to-noise ratio in the inbox improves when every sender has skin in the game.

The practical takeaway is simple: if you haven't audited your authentication setup recently, do it this week. Check your SPF record covers all your sending sources. Verify DKIM is configured with your domain — not just your ESP's default. Set up DMARC at minimum with p=none and start reading the reports. Then work toward enforcement.

Your domain reputation is a long-term asset. Every campaign you send either builds it or spends it. Authentication is how you make sure you're getting credit for the good sends — and blocking anyone from spending your reputation without your permission.

Send campaigns that actually reach the inbox

MailyGent builds campaigns with the structure, copy, and strategy that inbox algorithms — and real humans — find worth reading. Authentication handles the foundation. We handle the rest.