Securing Your Email With SPF, DKIM, and DMARC — EasyDMARC Overview

Email's core protocol has never authenticated senders. SMTP will deliver a message claiming to be from anyone, and it has been that way since the beginning. The three protocols that patch this (SPF, DKIM and DMARC) have existed for years, but they crossed from best practice into requirement in February 2024, when Google and Yahoo made authentication a condition of reaching their users' inboxes.

That deadline is why this matters even if you're not a bulk sender. It's also why the guidance has changed: the standards were revised in May 2026.

The problem in one paragraph

Anyone can put your domain in the From: header of an email. Recipients see your brand, your customers' mail filters see a plausible sender, and nothing in the protocol stops it. Spoofing enables phishing that's indistinguishable from your real mail, and it damages your sending reputation when the resulting spam gets attributed to you.

Authentication doesn't stop someone claiming your domain. It gives receiving servers a way to check whether the claim is true, and a policy for what to do when it isn't.

SPF: which servers may send as you

Sender Policy Framework publishes, in DNS, the list of servers allowed to send mail for your domain. The receiving server takes the IP that opened the SMTP connection and checks it against your published record.

A basic record:

example.com.  TXT  "v=spf1 ip4:192.0.2.0/24 include:mailprovider.example -all"

Reading it left to right:

• v=spf1, declares this as an SPF record
• ip4:192.0.2.0/24, a permitted sending range
• include:mailprovider.example, pull in another domain's permitted senders, which is how you authorise a third-party mail service
• -all, hard fail anything else

Use -all, not ?all or ~all, once you're confident. A softfail tells the receiving server "probably not us" and leaves the decision to them; a hard fail tells it "not us". The soft version is a common and costly default, because it leaves spoofed mail passing.

Two limitations worth knowing. SPF checks the envelope sender (MAIL FROM), not necessarily the visible From: header your recipient sees, which is why a message can pass SPF and still be spoofing your domain. And there's a 10-DNS-lookup limit, so a record stacked with include: statements from marketing platforms will silently stop being evaluated. If your SPF record has more than about eight lookups, consolidate it.

DKIM: proof the message wasn't altered

DomainKeys Identified Mail adds a cryptographic signature to outgoing mail. The sending server signs selected headers and the body with a private key; the public key sits in DNS so receiving servers can verify it.

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."

The selector lets you run more than one key at once, a common pattern is a separate selector per sending service, which means revoking one provider's access doesn't break the others.

DKIM does two things SPF can't. It survives forwarding, because the signature travels with the message rather than depending on the connecting IP. And it verifies integrity, so an attacker who intercepts and modifies a message breaks the signature.

Use 2048-bit keys. Yahoo's bulk sender rules require a minimum of 1024 bits and recommend 2048. There's no reason to be at the floor.

DMARC: the policy layer

SPF and DKIM produce a verdict. DMARC decides what happens next, and it requires that the domain passing the check aligns with the domain in the visible From: header, closing the gap SPF alone leaves open.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; fo=1"

• p=, the policy: none (monitor), quarantine (spam folder), reject (block)
• rua=, where to send aggregate reports, the XML summaries that tell you who's sending as you and whether it's passing
• rua is the one to set first, because you cannot safely pick a policy until you know what your own mail looks like from the outside

Alignment comes in two flavours. Relaxed alignment accepts a subdomain of your domain; strict requires an exact match. Relaxed is the usual choice and the default.

What changed in May 2026: DMARCbis

The IETF published the DMARC revision in May 2026 as RFC 9989 (core), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting), replacing RFC 7489, which had governed DMARC since 2015.

Three changes matter for anyone deploying now:

• The pct= tag is gone. You could previously stage a rollout, apply a policy to 10% of failing mail, then 50%, then 100%. That's no longer available, so the move from p=none to p=quarantine is a deliberate all-or-nothing switch. Plan for it rather than expecting to ease in.
• SPF is evaluated on MAIL FROM only. HELO/EHLO-based SPF checking is eliminated for alignment purposes, which makes the envelope-sender distinction above more important, not less.
• New tags (np, psd and t) are available but backward compatible. Existing v=DMARC1 records still satisfy the bulk sender requirements unchanged, so nothing breaks if you don't touch anything.

The 2024 bulk sender rules, and where they stand now

In February 2024 Google and Yahoo made authentication a requirement for bulk senders. The rules themselves haven't changed since; what has changed is enforcement.

Google. A domain sending close to 5,000 or more messages a day to personal Gmail accounts is a bulk sender. The threshold is per primary organisational domain (subdomains roll up to the parent) and bulk status is permanent once triggered, so it doesn't expire if your volume drops back under the line. Bulk senders must publish SPF, DKIM and a DMARC record, with p=none acceptable. Since November 2025, non-compliance draws temporary and permanent rejections (4.7.26, 550 5.7.26) rather than a quiet deliverability penalty.

Yahoo refuses to publish a numeric threshold ("a bulk sender is classified as an email sender sending a significant volume of mail") so assume it applies. Yahoo requires SPF and DKIM (not either), a passing DMARC record of at least p=none, and From-header alignment with either. Keys must be at least 1024 bits.

Microsoft has no volume threshold at all: its requirements apply to all commercial senders.

Two clarifications that catch people out. The requirements apply to mail going to personal consumer accounts (@gmail.com and similar) not to mail between users inside a Workspace tenant, which is exempt. And in 2026, p=none is increasingly read as a trust gap rather than compliance; p=quarantine is the practical target.

Alongside authentication, bulk senders need a spam complaint rate under 0.1% (0.3% triggers active enforcement) and working one-click unsubscribe: a List-Unsubscribe header plus a functioning List-Unsubscribe-Post endpoint, per RFC 8058.

The deployment order that works

The mistake is starting with p=reject. You will break legitimate mail, and it will be your own, password resets, invoices, notifications from services you forgot were sending as you.

1. Publish SPF and DKIM for every legitimate sender. Inventory first: your mail host, your CRM, your ticketing system, your marketing platform. Each one needs to be authorised or it will start failing when you enforce.
2. Publish DMARC with p=none and a rua= address. Change nothing else. This is monitoring mode.
3. Read the aggregate reports for two to four weeks. You're looking for sources sending as your domain that you didn't know about, and for alignment failures on sources you did. This step is where the actual work is, and it's the one people skip.
4. Move to p=quarantine. Watch deliverability for a week.
5. Move to p=reject. This is the state you want, it's the only one that actually stops spoofing.

Since DMARCbis removed pct, steps 4 and 5 are full switches. Make sure step 3 is genuinely finished before you take them.

Where tooling helps

The technical setup is a day's work. The ongoing part is the reporting: aggregate reports arrive as XML, one per receiving provider, often compressed, and reading them across a handful of domains by hand is tedious enough that it doesn't get done.

That's the gap managed DMARC platforms fill, and it's a real one rather than a marketing one. Several providers offer it, including:

• EasyDMARC. DNS record generation, an aggregated reporting dashboard, multi-domain management, and policy handling across the monitor-to-enforce path. Free and lower-cost tiers exist for small domains.
• Cloudflare DMARC Management, free, if your DNS is already on Cloudflare, and enough for a single domain.
• Postmark's free DMARC monitor, reporting only, but it costs nothing and does the step-3 job.

Disclosure: the EasyDMARC link above is a referral link. All three options will get you through the deployment order in the previous section; the difference is multi-domain management, support, and how much of the policy work you want handled for you.

If you're setting up a domain from scratch rather than auditing an existing one, how to set up a custom domain with Proton Mail walks through publishing SPF, DKIM and DMARC records with real values at each step, a useful companion to this piece, which is about the strategy rather than the individual records.

The short version

SPF says which servers may send as you. DKIM proves the message wasn't altered in transit. DMARC ties both to the domain your recipient actually sees, and tells receiving servers what to do when the check fails. Deploy in that order, monitor before you enforce, and get to p=reject.

If you send more than a few thousand messages a day to Gmail or Yahoo, none of this is optional any more, and since November 2025 the consequence of skipping it is rejection, not a dip in the spam folder.

For the wider picture, this is one part of a broader email privacy and security strategy.