Gmail, Yahoo & Microsoft Sender Requirements: Checklist
Your monthly payment reminder goes out on the 1st, like always. A few days later a client calls: they never got it. The message did leave your system — but Gmail filed it in spam, or bounced it with 550 5.7.26 This mail has been blocked because the sender is unauthenticated. Nothing changed on your side. The rules on the receiving side did.
Gmail and Yahoo have enforced bulk sender requirements since February 2024, and Microsoft has applied similar rules to Outlook.com, Hotmail and Live addresses since May 2025. Here they are as a practical checklist, with how to verify each item yourself.
Who the rules apply to
The strict tier covers bulk senders: domains sending roughly 5,000 or more messages a day to personal Gmail, Yahoo or Outlook.com addresses. Two details matter:
- It's counted per domain, across all your sending — client notices, invoice reminders and your office mailbox add up. For Gmail, once you cross the threshold you stay a bulk sender, even if volume drops.
- Small senders aren't exempt from the basics. Everyone sending to Gmail needs at least SPF or DKIM, valid reverse DNS, TLS and a low spam rate.
A small office sending statements to 800 clients won't hit 5,000 a day. But providers keep raising the bar, and a domain that already meets the bulk rules has nothing to fix next time. Treat the full checklist as your baseline.
The checklist: 7 requirements and how to verify them
1. SPF record published and passing
What it is: a DNS TXT record listing the servers allowed to send mail for your domain.
What good looks like: exactly one record, starting with v=spf1, including every service that sends for you and ending with ~all or -all, e.g. v=spf1 include:_spf.google.com include:spf.example-esp.com ~all. It must stay within 10 DNS lookups, or it fails with permerror even though it looks fine.
How to verify: use the SPF Checker to see the record, the lookup count and syntax problems. If it reports errors, see how to fix SPF record errors.
2. DKIM signature on every message
What it is: a cryptographic signature on each email. The public key sits in your DNS under a selector, e.g. selector1._domainkey.yourdomain.com, and proves the message came from your domain unaltered.
What good looks like: every service sending for you signs with your domain, not just its own, with a key of at least 1024 bits (2048 recommended).
How to verify: look up your selector with the DKIM Checker. Then send a test to a Gmail address, choose Show original and look for DKIM: 'PASS' with domain yourdomain.com. If your provider's domain appears there instead, the signature won't help with alignment (item 4).
3. DMARC record, at least p=none
What it is: a TXT record on _dmarc.yourdomain.com telling receivers what to do with mail that fails authentication and where to send reports.
What good looks like: the accepted minimum is v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. The rua tag is optional, but without reports you can't see who sends as your domain.
How to verify: check it with the DMARC Checker. p=none meets the requirement but doesn't stop spoofing — when reports look clean, follow DMARC from p=none to p=reject.
4. Alignment with the From domain
What it is: for DMARC to pass, the domain that passed SPF or DKIM must match the domain in the visible From: address. Send as office@yourfirm.com with a DKIM signature of d=sendingplatform.net and the platform's Return-Path, and both checks pass while DMARC fails.
What good looks like: DKIM with d=yourfirm.com and/or a Return-Path on your domain or a subdomain like bounces.yourfirm.com.
How to verify: in Show original, DMARC: 'PASS' confirms alignment; the mailed-by and signed-by details should show your domain.
5. Reverse DNS (PTR) and TLS
What it is: the sending IP needs a PTR record pointing to a hostname that resolves back to the same IP (dig -x 203.0.113.25 returns mail.example.net, which resolves to 203.0.113.25), and the connection must be encrypted with TLS.
How to verify: in Gmail's message details you should see standard encryption (TLS); a red open padlock means it arrived unencrypted. With Google Workspace, Microsoft 365 or an email platform, PTR and TLS are the provider's job. The risk is in legacy senders: an old server, a website contact form, an office scanner.
6. One-click unsubscribe, honoured within 2 days
What it is: marketing and subscribed messages must support one-click unsubscribe (RFC 8058) through two headers:
List-Unsubscribe: <https://yourdomain.com/unsubscribe/abc123>List-Unsubscribe-Post: List-Unsubscribe=One-Click
Gmail and Yahoo use them to show an "Unsubscribe" button next to your name. The request must take effect within 2 days, and you still need a visible unsubscribe link in the body. Strictly transactional mail (password resets, order confirmations) is exempt; recurring reminders are a grey zone, so include the headers on anything sent to a list.
How to verify: send a test email to your Gmail account, search Show original for List-Unsubscribe-Post, then unsubscribe and confirm the address is left out of the next send.
7. Spam complaint rate below 0.3%
What it is: the share of delivered messages marked as spam. Gmail's hard limit is 0.3% (three per 1,000), and Google recommends staying below 0.1%. Above 0.3%, problems arrive fast and recovery takes weeks.
How to verify: register your domain in Google Postmaster Tools, join Yahoo's Complaint Feedback Loop, and use Microsoft SNDS if you run your own IPs.
How to keep it low: send only to people who expect your mail, use a sender name they recognise, keep subjects honest and remove bouncing addresses. A complaint is often an unsubscribe the recipient couldn't find.
A 15-minute verification routine
- Run the Domain Health Check on every domain and subdomain you send from.
- Fix anything red: SPF and DKIM first, then DMARC.
- Send a real reminder or statement to a Gmail and an Outlook.com account and confirm SPF, DKIM and DMARC show PASS for your domain, plus the unsubscribe headers.
- Check your spam rate in Postmaster Tools after the next large send.
- Repeat whenever you add a tool that sends email for you — that's when SPF and alignment usually break.
550 5.7.515, Gmail with 5.7.26. Both point to authentication, so start with items 1–4, not with your email content.How MailerBit helps
MailerBit is built for businesses that send recurring emails to their own clients, like payment reminders and statements, so most of this checklist is part of the setup:
- Domain verification before sending. Campaigns can't go out until your domain is verified. We generate the DKIM and Return-Path records for your DNS and verify them with one click (Check Verification), so mail is authenticated with your own domain in the From field (items 2 and 4). You publish the DMARC record yourself — see our DMARC guide.
- One-click unsubscribe. Campaign emails carry
List-UnsubscribeandList-Unsubscribe-Postheaders, and unsubscribed or bounced recipients are skipped in later sends (item 6). - Your own domain reputation. Mail is signed with your own domain, so the domain reputation you build is yours.
- Automatic warm-up. New accounts ramp up over five days (200, 500, 1,000, 2,000, then the full plan limit), so providers see a steady pattern instead of a spike.
- Protective limits. If bounce or complaint rates climb too high, sending is blocked before your domain takes serious damage (item 7).
More on the deliverability page.
Check your domain today
Start with the free Domain Health Check — no account needed. When you're ready to send reminders and statements from a domain that meets the Gmail, Yahoo and Microsoft rules, create your MailerBit account and verify your domain in a few minutes.
