SPF, DKIM and DMARC in 2026: Gmail, Yahoo and Outlook Setup Guide

Gmail, Yahoo and Outlook all check whether your mail is authenticated before they decide where it goes. Gmail and Yahoo have required it since February 2024, and Gmail started rejecting non-compliant mail more aggressively in November 2025. Outlook.com has been refusing unauthenticated mail from high-volume domains since May 2025. If your SPF, DKIM and DMARC records are missing or misaligned, some of your list never sees the message.

The setup is a one-time job for most senders and fits in an afternoon. The catch is that small mistakes, like a misaligned domain or one DNS lookup too many, break authentication while everything looks fine in your dashboard. This guide covers what each provider requires, the records in the order you should publish them, what the May 2026 DMARC standard changed, and how to monitor the result.

What Gmail, Yahoo and Microsoft require

The three providers ask for roughly the same thing from bulk senders. The differences sit in who counts as “bulk”, what happens when you fail, and how they treat unsubscribes.

Gmail

Google’s rules apply to mail sent to personal Gmail accounts (@gmail.com and @googlemail.com), not to Google Workspace addresses.

Every sender, at any volume, must:

• Authenticate with SPF or DKIM
• Have valid forward and reverse DNS (PTR) records for sending IPs
• Send over TLS
• Keep the spam rate in Postmaster Tools below 0.3%
• Format messages to RFC 5322 and not impersonate Gmail in the From header

Senders of 5,000 or more messages a day to Gmail accounts must also:

• Set up both SPF and DKIM
• Publish a DMARC record (a policy of p=none is enough)
• Align the From domain with either the SPF or the DKIM domain
• Support one-click unsubscribe on marketing and subscribed mail, plus a visible unsubscribe link in the body

Google counts the 5,000 across the whole primary domain. Sending 2,500 from example.com and 2,500 from news.example.com makes you a bulk sender. The label is permanent: once you meet the threshold, Google keeps classifying you as a bulk sender even if your volume drops.

On spam rate, 0.3% is the hard line, and Google tells senders to stay below 0.1%. Its FAQ says spam rates above 0.1% already hurt inbox placement for bulk senders.

Yahoo

Yahoo’s list mirrors Google’s but with two differences worth knowing.

All senders must use SPF or DKIM, keep the spam rate below 0.3%, have valid forward and reverse DNS, and comply with RFC 5321 and RFC 5322. Bulk senders must use both SPF and DKIM, publish a DMARC policy of at least p=none that passes, align the From domain with SPF or DKIM (relaxed alignment is fine), support one-click unsubscribe with a visible link in the body, and honor unsubscribes within 2 days.

First difference: Yahoo does not publish a volume threshold. Its FAQ says a bulk sender is one “sending a significant volume of mail” and that it will not specify a number. Second: Yahoo calls the RFC 8058 POST method “highly recommended” but accepts a mailto: unsubscribe header.

Microsoft Outlook

Microsoft’s rules cover the Outlook.com consumer service: outlook.com, hotmail.com and live.com addresses. They apply to domains sending more than 5,000 emails a day. Those domains must:

• Pass SPF for the sending domain
• Pass DKIM
• Publish DMARC at p=none or stricter, aligned with SPF or DKIM (Microsoft says preferably both)

The consequence is harsher than at Gmail or Yahoo. Microsoft’s announcement, updated on 29 April 2025, says non-compliant mail is rejected from 5 May 2025 with 550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level. A rejected message never reaches the recipient, not even their Junk folder. Microsoft’s own Postmaster page still describes junk-folder routing first, with rejection to follow, so treat rejection as the behavior to plan for.

Beyond authentication, Microsoft lists hygiene practices it expects and “reserves the right” to filter or block over: a From or Reply-To address that can receive replies, a functional and visible unsubscribe link, regular removal of invalid addresses, and honest subject lines and headers. Unlike Google, it does not publish a spam-complaint percentage or make RFC 8058 one-click unsubscribe a stated requirement. Send the List-Unsubscribe and List-Unsubscribe-Post headers anyway, since Gmail requires them.

Side by side

Requirement	Gmail	Yahoo	Outlook.com
Bulk threshold	5,000+/day to Gmail, per primary domain	Not published	5,000+/day
SPF and DKIM	Both (bulk); one of them (all)	Both (bulk); one of them (all)	Both must pass
DMARC	p=none or stricter, aligned	p=none or stricter, must pass	p=none or stricter, aligned
One-click unsubscribe	Required (bulk)	Required (bulk), mailto: accepted	Functional unsubscribe link recommended
Spam rate	Below 0.3%, aim for 0.1%	Below 0.3%	No published figure
PTR records	Required	Required	Not in the announcement
Failure result	Temporary or permanent rejection, or spam	Delivery impact	550 5.7.515 rejection
Since	February 2024	February 2024	May 2025

Smaller senders are not formally held to the bulk list, but the same filters judge everyone. A 400-subscriber list that authenticates still lands better than one that doesn’t.

Before you start

Gather these first:

• DNS access for every domain and subdomain you send from. That is usually your registrar or DNS host (Cloudflare, Namecheap, GoDaddy).
• Admin access to every service that sends as your domain. Your email marketing tool is rarely the only one. Billing, help desk, CRM, form tools and calendar invites often send from your domain too, and each needs its own SPF and DKIM setup.
• A mailbox for DMARC reports, such as dmarc@yourdomain.com. Aggregate reports arrive as XML files, so keep them out of your main inbox and plan on a tool that parses them.
• Patience for DNS propagation. Most changes apply within an hour; some providers take up to 48.

Send marketing mail from a subdomain like news.yourdomain.com rather than your root domain. It keeps your marketing reputation separate from the address you use for day-to-day business email, so a bad campaign week does not affect your invoices and support replies. It does not get you under Gmail’s bulk threshold, since Google counts the whole primary domain. Every record below can be published on a subdomain.

Step 1: Publish SPF

SPF (Sender Policy Framework) is a public list of the servers allowed to send mail for your domain. Receivers check it when a message claims to come from you.

Add one TXT record on the domain (or subdomain) you send from. Your email tool gives you the exact value. It looks like this, with the include pointing at your provider:

v=spf1 include:_spf.your-esp.example ~all

~all (soft fail) tells receivers to treat unlisted servers with suspicion. If you send through several services, they all go in the same record:

v=spf1 include:_spf.your-esp.example include:_spf.your-crm.example include:_spf.your-helpdesk.example ~all

Publish only one SPF record per domain. Two v=spf1 records is an error that invalidates both.

Step 2: Sign with DKIM

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. The receiver uses a public key in your DNS to confirm the message came from your domain and was not changed in transit.

You don’t generate keys yourself. Your platform creates the key pair, keeps the private key and gives you records to publish. Most tools use CNAME records that point back to the provider, which lets them rotate keys without you touching DNS again:

Host:  s1._domainkey.news.yourdomain.com
Type:  CNAME
Value: s1.dkim.your-esp.example

Copy the records exactly, then go back to your email tool and run its verification check. A DKIM record with one wrong character fails without an obvious error, so don’t skip this step. If you publish a TXT key yourself, use a 2048-bit key where your provider supports it; some DNS hosts need the long value split into quoted strings.

Repeat this for every sending stream. Your marketing tool is signed because its onboarding walked you through it. The invoicing tool sending billing@yourdomain.com through a default relay often isn’t, and every message from it fails.

Step 3: Start DMARC in monitoring mode

DMARC ties SPF and DKIM to the domain in your visible From address, tells receivers what to do when a message fails, and asks them to send you reports. It is the record all three providers check for bulk senders, and the one most likely to cause damage if you rush it.

Add a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

p=none asks receivers to take no action on failures but send aggregate reports to the rua address. That already meets the Gmail, Yahoo and Microsoft minimum. Leave it there for at least a month and read the reports. They show which of your legitimate senders pass and which fail, so you can fix them before anything is blocked. Microsoft sends aggregate reports but has said it has no plans to send failure (ruf) reports.

Step 4: Check alignment

Passing SPF or DKIM is not enough on its own. DMARC also requires alignment: the domain in your visible From address must match the domain that SPF or DKIM authenticated.

A message can pass SPF against your provider’s bounce domain and still fail DMARC, because the authenticated domain was theirs, not yours. That is the most common reason a sender with all three records still gets rejected, and why you authenticate your own sending domain instead of relying on your tool’s shared default.

Only one of the two needs to align. Google, Yahoo and the DMARC standard all accept either SPF or DKIM. Alignment can be strict (exact domain match) or relaxed (same organizational domain, so news.yourdomain.com aligns with yourdomain.com). Relaxed is the default and what Yahoo explicitly accepts.

To check, send a test to a Gmail account, open it and use “Show original”. You want PASS for SPF, DKIM and DMARC. Mail-Tester and MXToolbox also confirm your records resolve and flag SPF lookup overruns.

Step 5: Move to enforcement, carefully

Once your reports show every legitimate source passing and aligned, raise the policy to quarantine:

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

Failing mail now goes to spam instead of the inbox. Watch the reports for another month. If nothing legitimate fails, you can move to:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

At p=reject, receivers are asked to refuse failing mail. It gives the strongest protection against spoofing of your domain. Either quarantine or reject also qualifies you for BIMI in Gmail, which shows your logo next to your messages (see our BIMI guide).

Two cautions from the new DMARC standard:

• A p=reject domain must sign with DKIM. RFC 9989 says domains publishing p=reject must not rely on SPF alone, because forwarding breaks SPF while DKIM signatures usually survive.
• Think twice before p=reject on a domain where staff send everyday mail. RFC 9989 says domains whose users might post to mailing lists should not publish p=reject, because list traffic fails DMARC and causes problems for the lists and their subscribers. For a dedicated marketing subdomain this rarely matters. For your main company domain, quarantine may be the better stopping point.

The new DMARC standard: RFC 9989, 9990 and 9991

In May 2026 the IETF published three RFCs that replace RFC 7489, the document every DMARC record so far was written against. RFC 7489 was an Informational RFC published outside the IETF standards process. The new documents are on the Standards Track as Proposed Standards. The draft people called “DMARCbis” is now simply DMARC.

The work is now split three ways:

• RFC 9989 covers the core protocol: publishing policy, evaluating messages and handling failures. It also obsoletes RFC 9091, the experimental spec for public suffix domains.
• RFC 9990 covers aggregate reports, the daily XML files listing who sent mail as your domain.
• RFC 9991 covers failure reports, the per-message notices.

None of this sets a deadline. Your existing record keeps working, because the standard says receivers must ignore tags they don’t recognize. The rules Gmail, Yahoo and Microsoft enforce live in their own policies, not in the RFCs.

What changed

Three tags were removed. pct (apply the policy to a percentage of mail), rf (failure report format) and ri (aggregate report interval). The RFC explains that pct was rarely applied accurately except at 0 or 100, and implementations varied widely.

Three tags were added:

• t is test mode. t=y asks receivers to apply one level below your stated policy: quarantine is treated as none, reject as quarantine. It replaces the one useful job pct=0 used to do.
• np sets the policy for non-existent subdomains, which attackers spoof because they were never registered. It was imported from RFC 9091.
• psd flags a public suffix domain. It matters to registry operators, not to ordinary senders.

The Public Suffix List is out. Receivers used to find your organizational domain by consulting the community-maintained Public Suffix List. RFC 9989 replaces that with a “DNS Tree Walk” that queries up the DNS hierarchy for policy records. You don’t implement this; receivers do. The RFC notes that during the transition, receivers on the old and new methods can reach different answers for unusual subdomain setups, and that strict alignment plus an explicit DMARC record on every From domain avoids the problem.

What did not change

The evaluation model is the same. DMARC passes when the From domain aligns with either an authenticated SPF identifier or an authenticated DKIM signature. Strict and relaxed alignment work as before. Passing DMARC proves authorized use of your domain and nothing more; inbox placement still depends on reputation, engagement and content.

Updating your record

1. Query what is actually published at _dmarc.yourdomain.com for every domain and subdomain that sends.
2. Remove pct, rf and ri. Receivers ignore them, so this is tidying, not a fix. If you were partway through a pct rollout, pick your real policy and publish it whole, or use t=y while you test.
3. Decide whether np belongs. With dozens of subdomains, or evidence of spoofing against subdomains that don’t exist, np=reject closes a gap. With a flat setup, sp and p already cover you.
4. Check sp is deliberate. Plenty of records set a strict root policy and leave subdomains open by accident.
5. Retire domains that no longer send. A parked domain should publish p=reject and an SPF record of v=spf1 -all.

Monitoring after setup

Google Postmaster Tools shows your Gmail spam rate, authentication results and compliance status by domain. This is where the 0.1% and 0.3% thresholds are measured, so check it after every large send.

Yahoo’s Complaint Feedback Loop (CFL) reports complaints per DKIM domain. Yahoo says an active CFL is needed for all DKIM domains and that its spam rate is calculated on mail delivered to the inbox.

Microsoft SNDS and JMRP cover Outlook.com. Smart Network Data Services shows volume, complaint rates, trap hits and filter status for your sending IPs (not your domain, unlike Postmaster Tools). The Junk Mail Reporting Program is Microsoft’s feedback loop. Both changed in 2026:

• SNDS moved to a new portal at substrate.office.com, replacing the old sendersupport.olc.protection.outlook.com site. Network access now expires 10 months after approval or migration and has to be reattested.
• In January 2026, Microsoft told SNDS users that complaint sample downloads were discontinued, that JMRP reports would carry only the original headers plus selected authentication headers with the message body dropped and the address redacted, and that automated report links would expire after 30 days (reported by Spam Resource).

In practice, put campaign or stream identifiers in your own headers so you can trace a complaint back to its send, and check any script or dashboard that pulls SNDS data. A job running on an expired link returns empty data, which looks just like no problems.

If you send through a shared-IP marketing platform, the SNDS data for those IPs belongs to the platform, not you. SNDS is most useful when you have your own dedicated IPs.

Common mistakes

• Two SPF records. Only one v=spf1 record per domain. Merge them.
• Too many SPF lookups. Past 10, SPF fails with permerror while the record looks valid.
• Authenticating the wrong domain. Records on the root while sending from a subdomain, or the reverse, break alignment. Authenticate the exact From domain.
• A forgotten sending source. Invoicing, help desk and CRM mail fails DMARC unless each one is authenticated.
• Jumping to p=reject. It feels efficient. If any legitimate source isn’t authenticated yet, you block your own mail the moment you publish it.
• Never reading reports. At p=none with no one opening the reports, you are collecting data, not monitoring.
• Assuming Gmail compliance covers Outlook. The overlap is large, but Outlook rejects failures outright, so a gap costs you more there.
• Testing with one Outlook address. A single seed account tells you one message arrived. Check accepted rates by recipient domain in your platform’s logs instead.
• Treating 550 5.7.515 as a bad address. It is a domain authentication failure.

What success looks like

• A test message to Gmail shows SPF, DKIM and DMARC passing on the exact From domain you send from.
• Postmaster Tools shows a spam rate under 0.1% and authentication passing.
• Your DMARC aggregate reports list only senders you recognize, all aligned.
• Your published DMARC record has no retired tags and a policy you chose, not one you inherited.
• Your accepted rate to Outlook.com addresses is close to your Gmail rate.

At that point the setup is stable. CNAME-based DKIM keys rotate on their own and DMARC keeps reporting. You only come back to it when you add a sending tool, and then you run the same steps: SPF include, DKIM records, and a check that the new source shows up aligned in your reports.

Which tools make this easiest

Authentication depends on your DNS records far more than on your platform. Platforms differ in how clearly they present the records, whether they check your setup, and how much delivery detail you get afterwards.

MailerLite is a good fit for marketing mail. Its domain authentication screen gives you the DKIM (CNAME), SPF (TXT) and domain verification records for your host, and a “Check DNS records” button confirms they match. The free plan covers 250 subscribers and 2,500 emails a month, enough to authenticate a domain and test deliverability, and the Comfort plan starts at $12 a month. The trade-offs are lighter automation than ActiveCampaign, and shared sending IPs on every plan below Enterprise, so your Outlook reputation partly depends on other customers.

Postmark is the stronger choice when you need to see exactly what happened to each message, especially transactional mail like receipts and password resets. Bounces come with the receiving server’s response, so an Outlook rejection shows up as 550 5.7.515 rather than a generic bounce. Transactional and broadcast mail go through separate message streams on separate IP pools, so a marketing problem can’t drag down your password resets. The free Developer plan includes 100 emails a month and never expires. Basic is $15 a month for 10,000 emails, with extra emails at $1.80 per 1,000. DMARC monitoring is an add-on at $14 a month per domain if you would rather not parse XML reports yourself.

Postmark has real limits. There is no annual billing. Dedicated IPs start at $50 a month per IP, only on Pro plans or higher and only for senders of 300,000 or more emails a month. It is built as a sending API, not a campaign tool, so most marketers run it alongside something like MailerLite.

The two are not substitutes, so choose by job: newsletters and automation in MailerLite, transactional mail in Postmark. The DNS records follow the same standard either way, and switching platforms mostly means swapping one SPF include and one set of DKIM records. For more options, see our best deliverability tools, high-volume senders and transactional email services roundups. Authentication is only part of reaching the inbox; the email deliverability guide covers reputation and content, and the list cleaning guide covers the bounce handling Microsoft expects.

The bottom line

Publish SPF, sign with DKIM, start DMARC at p=none, confirm alignment, then tighten one step at a time while reading your reports. Do it on a dedicated sending subdomain and for every service that sends as you. That meets the Gmail, Yahoo and Outlook.com rules, keeps your record current with the 2026 DMARC standard, and stops people from spoofing your domain.

Prices verified 5 October 2026 on the vendors’ pricing pages. Prices change, so confirm before you budget.

Sources

1. Google — Email sender guidelines — accessed 2026-10-05
2. Google — Email sender guidelines FAQ — accessed 2026-10-05
3. Google — Set up BIMI — accessed 2026-10-05
4. Google Postmaster Tools — accessed 2026-10-05
5. Yahoo — Sender Requirements & Recommendations — accessed 2026-10-05
6. Yahoo — Sender FAQs — accessed 2026-10-05
7. Microsoft — Strengthening Email Ecosystem: Outlook's Requirements for High-Volume Senders — accessed 2026-10-05
8. Microsoft — Outlook.com Postmaster — accessed 2026-10-05
9. Microsoft — Smart Network Data Services — accessed 2026-10-05
10. Spam Resource — January 2026 Microsoft SNDS Updates — accessed 2026-10-05
11. IETF — RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — accessed 2026-10-05
12. IETF — RFC 9990: DMARC Aggregate Reporting — accessed 2026-10-05
13. IETF — RFC 9991: DMARC Failure Reporting — accessed 2026-10-05
14. MailerLite — Pricing — accessed 2026-10-05
15. MailerLite — How to verify and authenticate your domain — accessed 2026-10-05
16. Postmark — Pricing — accessed 2026-10-05
17. Postmark — Bounce API — accessed 2026-10-05
18. Postmark — Message Streams — accessed 2026-10-05
19. Postmark — DMARC monitoring — accessed 2026-10-05