The Gmail and Yahoo sender rules, three months in

In the second week of February a client's Friday campaign went out exactly as it had for two years, and a large share of it never reached Gmail. The bounce text said the message had been blocked because the sender was not authenticated. Nothing in the campaign had changed.

What had changed was that Google and Yahoo had begun applying the bulk sender requirements they announced the previous October. Three months on, almost every team we work with has the records in place. The requirements were published clearly and were not hard to read.

The awkward part was never the reading. Meeting them forced teams to find out things about their own mail that nobody had ever written down. This is what we found between February and now, roughly in the order it caused trouble.

What the rules actually ask for

For senders above roughly five thousand messages a day to Gmail, the list is short. Authenticate the sending domain with SPF and DKIM, and publish a DMARC record for it. Offer one-click unsubscribe in marketing mail and act on it within two days. Keep the spam complaint rate below 0.3 per cent. Yahoo published a matching set on the same timetable.

None of those are new ideas. SPF has been in use for well over a decade, DMARC is not far behind, and one-click unsubscribe has been in the specification for years. The change is that they stopped being good practice and became a condition of delivery.

Authentication was easy; alignment was where it failed

Almost every programme already had SPF and DKIM in place. DMARC was often missing, and publishing a record is a ten-minute job. The teams that stopped there were the ones that kept having problems into March.

DMARC does not simply check that SPF or DKIM passed. It checks that one of them passed for a domain that matches the domain in the From header. That match is called alignment, and it is where established programmes broke.

Two cases came up again and again:

• The email platform signs with its own DKIM domain rather than a subdomain of yours, so DKIM passes and aligns with nothing.
• SPF passes for the platform's return-path domain, which is also not yours, so it does not align either.

Both look healthy in a platform dashboard. Both fail DMARC. The fix is branded DKIM signing on a subdomain you control, plus a custom return path, and then a re-check. Most platforms support both, and the work is mostly waiting for DNS to propagate.

The other recurring failure was the SPF lookup limit. An SPF record may trigger at most ten DNS lookups, and a marketing team that has added one new tool a year quietly passes that limit. Once it does, SPF returns a permanent error and stops helping anyone. Flattening the record, or removing the four vendors that no longer send, is a morning's work.

The senders nobody had written down

The requirements apply to your domain, not to your marketing platform. So the first genuinely useful output of the whole exercise was an inventory of everything that sends mail as your company.

Publish a DMARC record in monitoring mode with an aggregate report address, wait two weeks, and read the reports. They will name sources you have forgotten. The help desk, the survey tool, the review request service, the billing system, a regional office running its own instance, and usually one source nobody can identify at all.

Then decide, for each one, whether it should be sending as your main domain at all. Plenty should not. Moving a review-request tool onto its own subdomain is easier than authenticating it properly, and it keeps that traffic away from your marketing reputation.

One-click unsubscribe is plumbing, not a header

This caused more engineering work than the DNS did. The requirement has two halves. The message must carry the right headers, and the unsubscribe must be honoured within two days.

Most email platforms added the headers to their marketing streams automatically. What broke was everything outside that path:

• Mail sent through a separate transactional system or a homegrown service, where nobody had added the headers at all.
• Endpoints that answered the one-click request with a confirmation page instead of processing it, because the page behind them expected a human.
• Suppression that lived in one system while sends were scheduled from another, so most of the two-day window was spent waiting for a nightly sync.
• Regional instances where an unsubscribe recorded in one market never reached the others.

The check is not whether the header is present. Send yourself a campaign, use the unsubscribe control the mail client shows at the top rather than the link in the footer, and confirm the suppression is visible in every system within minutes.

The complaint rate is the one you cannot engineer

Authentication is a configuration problem with a finish line. The complaint rate is not. It measures how people feel about your mail, and it is reported by the mailbox provider rather than by your platform.

Two practical consequences follow. You need Postmaster Tools access for every sending domain, and someone has to look at it weekly. A blended complaint figure across all providers is useless here, because the threshold is applied per provider.

When a rate runs hot, the causes are usually from the same short list:

• An acquisition source that produces addresses with no real intent, such as a prize draw or a co-registration partner.
• Frequency that crept upward over a year without anyone deciding that it should.
• A footer unsubscribe that is hard to find, which pushes people towards the spam button instead.
• Re-engagement sends aimed at people who have not opened anything in a year.

The fix that feels wrong is the one that works. Make unsubscribing easier and more visible. Someone who leaves quietly costs you one address, while someone who reports spam costs you a share of your sending reputation.

Who can edit DNS is now a marketing question

The slowest part of February was rarely technical. It was finding the person allowed to edit a DNS record, discovering they had left, and raising a ticket into a queue measured in weeks.

If that describes your company, fix it now rather than during the next incident. Agree who may change sender authentication records, how a change is requested, and how long it should take. Deliverability work stalls at that step more often than any other, and it is the cheapest thing on this page to sort out.

Then plan the step most teams have not taken. A monitoring-only DMARC policy observes and does nothing. Moving to quarantine, and eventually to reject, is what actually stops other people sending as you. Do it in stages, with the reports open, and only once the sender inventory is complete. This is the sequence our implementation engagements now start from.

February was a floor rather than a target, and it will not be the last set of requirements. The teams that found it straightforward were the ones who already knew every system that sends mail as them. Keeping that list current is the thing worth owning.