Email deliverability: SPF, DKIM, DMARC and Gmail, Yahoo, Outlook rules

Email deliverability is the likelihood that an email you send reaches the recipient's inbox rather than their spam folder. Three things decide it. One is proving who you are with Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting and Conformance (DMARC). The others are the reputation of your sending domain and IP addresses, and how recipients react to your mail.

Since 2024, Gmail, Yahoo and Microsoft have enforced written rules on all three. This guide takes those rules from the providers' own pages and explains how SPF, DKIM and DMARC work together and where alignment breaks. It also shows how customer relationship management (CRM) and lifecycle teams can set up their sending streams so that one program doesn't damage another.

Email deliverability is the set of identity, reputation and engagement signals that decides whether your messages land in the inbox or in spam. It is not the same as the delivery rate.

The delivery rate tells you whether the receiving server accepted the message instead of rejecting it. A server can accept a message and file it in spam, so your delivery rate looks healthy while the recipient never sees the email. The "delivered" figure in your ESP or CRM dashboard does not, on its own, tell you that you reached the inbox.

Mailbox providers judge every incoming message on three counts. First comes identity: was the message really sent on behalf of the domain in the From line, and was it changed in transit?

The second is reputation: what kind of mail has this domain and IP address sent before, and how many people marked it as spam? The third is engagement: do recipients open and reply to this sender's messages, or delete them and report them?

Authentication only gets you through the door. RFC 9989, the current DMARC standard, says so directly. A DMARC pass by itself does not guarantee that delivery to the recipient's inbox would be safe or desirable.

Why do emails go to spam?

Emails usually go to spam because of identity and reputation problems rather than wording. The rules and error codes the providers publish point to these causes most often:

• Missing or misaligned authentication: SPF or DKIM isn't set up, or the domain in the From line doesn't match the domain SPF or DKIM verified.
• Spam complaints: Recipients mark the message as spam and the complaint rate crosses the provider's threshold.
• Sudden volume spikes: A domain or IP address with no history starts sending large volumes at once.
• Mixed streams: Password resets and promotional campaigns leave from the same IP address and share one reputation.
• Neglected lists: You keep sending to invalid addresses, and recipients who haven't engaged in a long time are never removed.

The sections below take these causes one at a time. It helps to start with what the providers require today, because some of these items are no longer best practices but reasons for rejection.

Google and Yahoo announced their sender requirements in October 2023 and began enforcing them in February 2024. Microsoft introduced similar rules for Outlook.com in May 2025. All three split their rules into two groups: what every sender must do, and what high-volume senders must add.

Requirements for all senders

Google's email sender guidelines apply to everyone who sends to personal Gmail accounts (@gmail.com and @googlemail.com). They require SPF or DKIM, valid forward and reverse DNS (PTR) records for sending IPs, and a TLS connection. Messages must also follow RFC 5322, and the spam rate reported in Postmaster Tools must stay below 0.3%.

Yahoo's Sender Hub also asks every sender for SPF or DKIM and valid forward and reverse DNS. It requires compliance with RFCs 5321 and 5322 and a spam rate below 0.3%. TLS does not appear in Yahoo's list of requirements.

Requirements for bulk senders

Google treats anyone who sends close to 5,000 messages or more to personal Gmail accounts within 24 hours as a bulk sender. According to Google's FAQ, messages from the same primary domain count together. So a sender with 2,500 messages from example.com and 2,500 from promotions.example.com is a bulk sender.

Once you cross the threshold, the status is permanent. The guidelines don't apply to messages sent to Google Workspace accounts.

Bulk senders must set up both SPF and DKIM and publish a DMARC record (a policy of p=none is enough). They must align the From domain with either the SPF or the DKIM domain. They must also support one-click unsubscribe in marketing messages and include a clearly visible unsubscribe link in the body.

Yahoo asks bulk senders for the same set. That means SPF and DKIM, a DMARC record of at least p=none that passes, alignment, one-click unsubscribe and a visible link.

The difference is the threshold. Yahoo's FAQ says it will not specify a volume and only refers to a "significant volume". So "Yahoo's threshold is also 5,000 a day" is not accurate. Both Gmail and Yahoo require a DKIM key of at least 1024 bits and recommend 2048.

Microsoft Outlook.com's May 2025 requirements

In its April 2025 announcement, Microsoft set new rules for domains sending more than 5,000 emails a day. They must pass SPF and DKIM and publish a DMARC record of at least p=none, aligned with SPF or DKIM. The original plan was to route non-compliant mail to Junk.

An update on April 29, 2025 changed that: from May 5, 2025, Microsoft rejects these messages with the code "550 5.7.515". Microsoft's support page explains that the error means the domain in the From address didn't meet the required authentication level. Microsoft lists a working unsubscribe link and list hygiene as recommendations but publishes no spam-rate threshold.

What changed from 2024 to now

The rules didn't tighten all at once. Google added the TLS requirement in December 2023 and started enforcing the guidelines on February 1, 2024. From June 2024, bulk senders with a spam rate above 0.3% became ineligible for Google's mitigation support.

Senders that already had an unsubscribe link had until June 1, 2024 to add one-click unsubscribe. Yahoo began enforcing its unsubscribe rule in June 2024 as well. Google said that from November 2025 it is ramping up enforcement on non-compliant traffic, with temporary and permanent rejections. Microsoft's rules have applied since May 2025.

The three protocols answer the same question from different angles: was this message really sent on behalf of this domain? To understand the "alignment" requirement in the rules, you need to see how the three fit together.

SPF: which servers may send

SPF (RFC 7208) lets a domain owner list the servers allowed to send on its behalf in a DNS TXT record. The receiving server checks whether the sending IP address is on that list.

The rule that causes the most trouble in practice is the 10-lookup limit. If the include statements and similar terms in the record add up to more than 10 DNS lookups, SPF evaluation returns "permerror". Every new tool that adds another include brings you closer to that limit.

SPF also checks the domain in the technical envelope (the Return-Path), not the From line the recipient sees. When an ESP sends with its own Return-Path domain, SPF passes but doesn't align.

DKIM: was the message changed in transit

DKIM (RFC 6376) lets the sender sign the message cryptographically and lets the receiver verify the signature with the public key in the domain's DNS. The signature shows that the message wasn't altered and that the signing domain takes responsibility for it.

What matters is which domain signs. Many ESPs sign with their own domain by default. DKIM passes, but because the signing domain isn't your From domain, there is no alignment. Setting up DKIM with your own domain in the ESP makes the signature carry your domain.

DMARC and alignment

DMARC compares the domain in the From line with the domains verified by SPF and DKIM. That comparison is what alignment means. Google and Yahoo accept bulk senders with either SPF or DKIM aligned. Google's FAQ adds that alignment with both will likely become a requirement eventually.

Alignment has two modes. Relaxed alignment treats subdomains as matching their organizational domain, and strict alignment requires an exact match. RFC 9989 notes that nearly all domain owners have found relaxed alignment sufficient, and Yahoo explicitly accepts it.

The policy (p) value in a DMARC record states what you want done with messages that fail. A value of none expresses no preference, and quarantine marks the mail as suspicious. A value of reject says the use of the domain is not valid.

The rua tag sets the address where receivers send aggregate reports, and without it receivers must not generate them. Yahoo strongly recommends including it during initial setup. The reports are XML files that show which IP addresses sent mail using your domain and which of them failed authentication.

DMARC became a Standards Track specification in May 2026. RFC 9989 replaced RFC 7489 from 2015, and reporting moved to RFC 9990 and RFC 9991. The new version removed the pct tag used for gradual rollout and added a test mode tag (t). Some help pages still describe pct, so check the current standard when you write your record.

Moving your DMARC policy from p=none to p=reject

For Gmail and Yahoo, p=none is enough. But p=none doesn't stop spoofed mail from being delivered, it only reports on it. Microsoft advises tightening the policy gradually from none to quarantine to reject.

In practice you start with p=none and a rua tag, and use the reports to find every source sending as your domain. Once every legitimate source passes aligned, you move to quarantine and then to reject. According to Google's DMARC setup page, if you don't use the sp tag, subdomains inherit the parent domain's policy.

BIMI (Brand Indicators for Message Identification), which shows your logo in the inbox, is an optional step at the end of that sequence. Google and Yahoo require a DMARC policy of quarantine or reject for BIMI. BIMI is still an Internet-Draft at the IETF, not an RFC.

Finding every tool that sends as your domain

Alignment problems usually come from a forgotten tool. You may send marketing email from one ESP, transactional email from another service, support replies from a helpdesk and invoices from accounting software. Each of them uses your domain in the From line. Each one also needs to be in your SPF record and to sign DKIM with your domain.

DMARC reports are the most reliable way to build that inventory, because they also show senders you didn't know about. I compared which CRM and marketing automation platforms cover which channels in the CRM and marketing automation tools post. When you choose a tool, check that it supports DKIM and a Return-Path on your own domain.

Making it easy to leave is the most direct way to reduce spam complaints. A recipient who can't find the unsubscribe link presses the spam button instead.

The List-Unsubscribe headers (RFC 8058)

One-click unsubscribe works through two header fields. The List-Unsubscribe header contains an HTTPS URL, and the List-Unsubscribe-Post header carries the value "List-Unsubscribe=One-Click".

RFC 8058 requires a valid DKIM signature covering both headers, and without it the receiver should not offer one-click unsubscribe. Gmail doesn't accept mailto or plain URL unsubscribe links as meeting its one-click requirement.

Yahoo highly recommends the POST method but also accepts mailto. Both also ask for a clearly visible unsubscribe link in the message body, which may lead to a preference page.

The requirement covers marketing and promotional messages. Google and Yahoo exclude transactional messages such as password resets, order confirmations and reservation confirmations. Google also notes that recipients, not Google, decide what kind of message they're receiving. Putting a promotion inside an order confirmation blurs that line.

What 0.1% and 0.3% mean

Google defines the spam rate as the percentage of messages delivered to the inbox that recipients then mark as spam, and calculates it daily. A rate of 0.1% means 1 complaint per 1,000 messages that reach the inbox, and 0.3% means 3.

Google recommends staying below 0.1% and says that rates above 0.1% already hurt inbox delivery for bulk senders. A sender above 0.3% is ineligible for mitigation until the rate stays below 0.3% for 7 consecutive days. Yahoo also calculates the rate on mail delivered to the inbox.

Three lifecycle programs push this rate hardest. One is win-back campaigns to people who have been silent for a long time. The others are imported lists, and sends whose frequency rises in a short period. When you think about a complaint budget, look at the rate for these risky streams rather than at your total volume.

If your password resets and your discount campaign share one reputation, the campaign's complaints can make it harder for password resets to reach the inbox. That's why Yahoo recommends segregating email types by IP address or DKIM domain. It also advises against sending bulk marketing from the IPs you use for transactional mail. Each IP and DKIM domain has its own reputation.

Google recommends sending from a single IP if possible. If you must use several, it recommends a different IP for each message type. It also recommends sending the same category of message from the same From address and not mixing promotions into receipts.

In practice this means separating three streams: transactional email (passwords, orders, invoices), lifecycle automations (welcome, cart reminders, win-back) and bulk campaigns. Many teams do this with a separate subdomain and DKIM domain per stream. That isn't a written Google or Yahoo requirement but one way to apply Yahoo's advice to segregate by DKIM domain.

For Gmail's 5,000 threshold, mail from subdomains counts toward the primary domain. The compliance dashboard in Postmaster Tools shows data for primary domains only.

Increasing volume slowly

A new domain, subdomain or IP address has no reputation history. Google recommends starting with a low volume to engaged users, increasing slowly over time, sending at a consistent rate and avoiding bursts.

It warns that suddenly doubling volume can lead to rate limiting or reputation drops. It also says you can increase volume faster when you send daily rather than weekly. You should reduce volume if messages start bouncing or being deferred.

Yahoo adds that a sudden spike can get you flagged as a compromised sender. None of the providers publishes a day-by-day warm-up schedule. The warm-up tables you see online come from ESPs and consultants, not from the mailbox providers. The same applies when you switch ESPs or move to a new subdomain.

Permission is the base of every rule above, but permission alone doesn't keep you out of spam. A subscriber who opted in years ago and no longer opens your mail is still a valid recipient. Yet a spam report from them counts toward your complaint rate in the same way.

Providers measure reactions, not the age of the consent record.

Every unsubscribe has to reach a single suppression list quickly, wherever it comes from. That could be the one-click header, the visible link, the preference center or a support request.

Google recommends honoring unsubscribes within 48 hours and Yahoo requires 2 days. So a nightly batch that syncs your ESP and CRM can already be too slow if it fails once.

Hard bounces are addresses that permanently don't exist, and they should be suppressed on the first bounce. Continued sends to invalid addresses tell providers the list isn't maintained.

Subscribers who haven't engaged for a long time need a sunset policy. Reduce frequency first, then ask a preference question, and stop marketing email if there's no answer. The Unengaged subscriber sunset journey lays out that flow step by step.

To decide who counts as inactive, the recency logic in the RFM (recency, frequency, monetary) analysis post is a useful starting point. The retention, churn and lifetime value (LTV) post explains how retention and churn are defined.

Don't rely on opens alone. Google states that it doesn't track open rates, and open tracking varies by email client. Combining clicks, purchases or app activity gives a more reliable signal.

You can't see the spam rate in your own dashboard, because the provider measures it. Google's Postmaster Tools shows the spam rate for DKIM-authenticated mail and a compliance status dashboard that tells you whether your domain meets the requirements.

Yahoo requires an active complaint feedback loop (CFL) for every DKIM domain, which reports the messages Yahoo users mark as spam. DMARC aggregate reports show every day which sources failed authentication.

Watching these three sources alongside the bounce, complaint and unsubscribe rates in your ESP lets you spot a problem before a campaign finishes. Google's error codes also help with diagnosis: 5.7.26 points to authentication, for example, and 4.7.32 to a From alignment problem.

Before you start sending from a new domain, a new ESP or a new campaign stream, check these points:

1. Every sending service is in your SPF record, and the record stays within 10 DNS lookups.
2. Every service signs DKIM with your own domain, with a key of at least 1024 bits and preferably 2048.
3. A DMARC record is published, the rua tag points to an address someone reads, and the reports show no unknown sources.
4. The From domain aligns with the SPF or DKIM domain.
5. Marketing messages carry List-Unsubscribe and List-Unsubscribe-Post headers and a visible unsubscribe link in the body.
6. Unsubscribes from every source land in one suppression list within 48 hours.
7. Transactional email and campaigns go out in separate streams, and transactional messages carry no promotions.
8. Volume on a new domain or IP rises gradually, and the spam rate in Postmaster Tools stays below 0.1%.

Each item rests on a rule or standard the providers or the IETF publish themselves. Because the rules keep changing, check the Gmail, Yahoo and Microsoft pages a few times a year. Together with regular reading of your DMARC reports, that is the simplest way to protect your inbox placement.