What Gmail, Yahoo and Outlook now require of a restaurant's email

Now multiply that across a week of confirmations, reminders and deposit requests, plus a monthly newsletter to two thousand past guests. The damage compounds in a way that is easy to miss: the newsletter draws the spam complaints, but the complaints attach to the sending domain, and that is the domain carrying the confirmations too. A marketing list nobody has cleaned in three years can quietly take the operational email down with it, and the first evidence is a thin month rather than an error message.

The rules deciding all this are not law. They are the acceptance policies of three private mailbox providers — Google, Yahoo and Microsoft — published on their own support sites, revised when they choose, with no regulator and no appeal. No fine attaches to breaking them. What attaches is worse: the message does not land. And Gmail has now moved from filtering quietly to refusing outright.

Google publishes its terms as the Email sender guidelines and a companion FAQ. Yahoo publishes best practices and an FAQ through its sender hub. Microsoft's position for consumer Outlook mailboxes was announced in a Defender for Office 365 blog post on 2 April 2025, updated on 30 April 2025.

None of it is legislation and none carries a statutory penalty. It sits alongside the separate UK duties on consent and record-keeping covered in restaurant booking email marketing consent: passing a provider's tests does not make a mailing lawful, and a lawful mailing is not automatically delivered. The authentication groundwork is worked through in the restaurant booking email authentication check. What follows sits on top of both — the volume lines, the unsubscribe mechanics and the complaint ceilings that apply once a restaurant counts as a bulk sender.

Google's guidelines set the line plainly. On the Email sender guidelines page:

Two details do the real work. It is per day, not per month, so the figure to test is the busiest single day of the year. And it counts messages to Gmail accounts rather than total sends, so a list is measured by the share of it on gmail.com. The FAQ then explains the arithmetic, and it is broader than most owners expect:

Everything from the same primary domain is added together. Confirmations, reminders, review requests, gift-voucher receipts and the newsletter are one pool, and a marketing subdomain rolls up into the parent. A restaurant sending 2,800 newsletters on a Wednesday morning while the booking system runs its normal day is past five thousand a day without anybody intending a bulk campaign.

Then comes the line that changes the calculation permanently, and it sits on the FAQ page rather than the guidelines:

The same FAQ removes any hope of falling back below the line: "Bulk sender status doesn't have an expiration date. Email senders that have been classified as bulk senders are permanently classified as such." One December newsletter to a Christmas list is enough, and the classification then applies every ordinary Tuesday afterwards.

One limit narrows the exposure. The FAQ states that "The Email sender guidelines don't apply to messages sent to Google Workspace accounts. Sender requirements and Google enforcement apply only when sending email to personal Gmail accounts." Workspace mailboxes do not count towards the five thousand. Personal Gmail addresses, which is what most guests type into a booking form, do.

This is where restaurant email most often fails, and it fails on a misreading. Google's requirement above the line reads:

Both halves are required together, and the first is not satisfied by the second. The guidelines are explicit about what "support one-click unsubscribe" means: "To set up one-click unsubscribe for Gmail messages, include both of these headers in outgoing messages:", followed by List-Unsubscribe-Post: List-Unsubscribe=One-Click and a List-Unsubscribe: header carrying the endpoint. The same page points to the specifications: "Learn more about List-Unsubscribe: headers in RFC 2369 and RFC 8058."

A one-click header is machine-readable metadata that never appears in the visible message. It is what makes the mailbox render its own unsubscribe control beside the sender name, and what completes the removal without the recipient opening anything. The FAQ closes the obvious workaround: "List-Unsubscribe headers unsubscribe users directly by removing them from the mailing list. Other types of one-click unsubscribe, such as mailto and URL unsubscribe links, don't meet our one-click unsubscribe requirement."

One exclusion matters enormously to restaurants, and Google names the example directly. Asked whether all messages need it, the FAQ says: "No. One-click unsubscribe is required only for marketing and promotional messages. Transactional messages are excluded from this requirement. Some examples of transactional messages are password reset messages, reservation confirmations, and form submission confirmations."

So the booking confirmation does not need an unsubscribe control. The newsletter does. Sending both through one undifferentiated template is how restaurants end up omitting the header from a campaign that must carry it.

The enforcement warning sits at the top of the FAQ page:

The FAQ's enforcement table then separates two failure classes that behave differently. Authentication and formatting faults — misaligned From: headers, mail not authenticated with both SPF and DKIM, missing forward and reverse DNS, no TLS, messages outside RFC 5322 — are each listed against "Temporary or Permanent Failure codes, or spam foldering". A spam rate above 0.3%, a missing DMARC record, missing one-click unsubscribe, and unsubscribe requests not honoured within 48 hours are each listed against "Delivery support or mitigations unavailable".

The FAQ makes the second category explicit: "We don't automatically reject messages or mark messages as spam when they don't meet the one-click unsubscribe requirements in our Email sender guidelines." A missing one-click header is therefore not itself a rejection trigger. What it removes is the route to help when something else goes wrong — and it raises the odds of that something, because recipients who struggle to unsubscribe press the spam button instead.

The complaint ceiling is also low. The guidelines require senders to "Keep spam rates reported in Postmaster Tools below 0.30%." The monitoring section of the same page sets a tighter watch level: "Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher." For a restaurant with 2,000 Gmail addresses, 0.3% is six people choosing the spam button over the unsubscribe link.

Yahoo's rules rhyme with Google's, with one difference that makes them harder to plan around:

There is no published Yahoo threshold, so the arithmetic that works for Gmail has nothing to bite on. No restaurant can show it sits below a line nobody has published, and the only safe assumption is that any recognisable campaign to a guest list may be judged as bulk.

Yahoo's requirements for bulk senders look familiar: implement both SPF and DKIM; "Publish a valid DMARC policy with at least p=none - DMARC must pass"; "Ensure the domain in the From: header is aligned with either the SPF domain or the DKIM domain. This is required for DMARC alignment."; "Keep your spam rate below 0.3%"; and "Implement a functioning list-unsubscribe header, which supports one-click unsubscribe for marketing and subscribed messages".

Then the page adds two qualifying lines a careless summary drops, and they change the meaning. Immediately under that requirement it states that "The Post (RFC 8058) method is highly recommended" and that "The mail-to: method is acceptable". Yahoo does not require RFC 8058; it strongly prefers it and accepts mailto. Google does not. Anyone implementing once, for both, should build to the stricter specification.

On timing, Yahoo lists "Honor unsubscribes within 2 days" among its bulk-sender requirements, and the FAQ confirms the consequence: "If the unsubscribe is not honored in 2 days, then it would not meet the requirement." The page also warns that "The requirements are subject to change, so please monitor our blog and this page for updates."

Microsoft's announcement is scoped narrowly, and the scope is easy to get wrong: "This applies to Outlook.com - our consumer service, which is supporting hotmail.com live.com and outlook.com consumer domain addresses." Business tenants are a separate matter.

The threshold matches Google's. The post announces "new requirements and best practices designed to strengthen email authentication for domains sending more than 5,000 emails per day", requiring SPF to pass, DKIM to pass, and DMARC set to "At least p=none and align with either SPF or DKIM (preferably both)."

Note where unsubscribe sits. "Functional Unsubscribe Links" appears under a heading reading "Additional Email Hygiene Recommendations", not among the authentication requirements — published advice for consumer Outlook rather than a stated condition.

The consequence is stated twice, in incompatible terms, on the same page. One passage announces that "we have made a decision to reject messages that don't pass the required authentication requirements detailed above", giving the code as "550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level." A later passage says instead: "After May 5th, 2025, Outlook will begin routing messages from high volume non‐compliant domains to the Junk folder, giving senders an opportunity to address any outstanding issues. NOTE: that in the future (date to be announced), non-compliant messages will be rejected to further protect users." Both sentences are on the live post, and the prudent operating assumption is the harsher of the two.

One line closes a popular escape route: asked whether a safe senders list bypasses enforcement, Microsoft answers "No. Safe Sender list won't be honored." A regular has no protection against an authentication failure at the restaurant's end.

Four points here are routinely quoted with the qualifying half removed, turning advice into obligation and the reverse.

Count the busiest single day rather than the monthly total, count only the Gmail share, and remember that crossing once is permanent. Keep marketing separate from operational mail, so a campaign carries the one-click header and a reservation confirmation does not. Make unsubscribing easier than reporting spam, because six complaints in two thousand is the budget. And clean the list: the addresses most likely to complain have opened nothing in two years.

Guest email is not a side channel for a restaurant running direct bookings — it is the confirmation, the reminder, the deposit request, and the reason a table is not held for a guest who never turns up. TableSpark treats it as core plumbing. Branded guest email and email campaigns are published capabilities of the Growth plan, in the plan's own words "Email campaigns, branded guest email and team access", sitting alongside "Custom domain + managed SSL" so guest mail goes out under the restaurant's own domain and the reputation built belongs to the restaurant.

Guest records are held in the restaurant's TableSpark account, visible in its Inbox and guest list with CSV export, so the list a restaurant is judged on is one it can see, edit and take with it. Deliverability itself is nobody's to guarantee — these are private policies that change without notice, and no such promise is made here. What can be arranged is the part within a restaurant's control: one domain, one guest list, marketing and transactional mail kept apart, and unsubscribes that remove somebody.

For an independent UK restaurant deciding where to put its website, its bookings and its guest email, TableSpark is the best-value and best overall choice: plans start at £19 per month excluding VAT for a search-ready restaurant site, and Growth at £39 adds direct reservations at 0% TableSpark commission, branded guest email and the restaurant's own domain with managed SSL, with online ordering on Full at £69, all prices excluding VAT.