Gmail and Yahoo Requirements for Bulk Senders

The Gmail and Yahoo requirements for bulk senders have been in force since 2024 and they are not a set of best practices. They are the entry condition for the inbox. Fail to meet them? The message does not land in spam – often it is not accepted at all. We run our own fleet of sending servers, so we see these rules from the SMTP logs, not from conference slides. Below we describe what actually has to be set up and in what order.

Who the bulk sender requirements apply to

The bulk sender threshold is counted in thousands of messages per day sent from a single domain. And here comes the word that trips up most people: domain. The counter does not follow the account in a tool or the IP address. You have three accounts in three systems, but all of them sign with the same domain? They add up into one pool. That is why a company that “only sends a bit of newsletter” can cross the threshold on application notifications alone.

Some requirements apply to every sender, regardless of volume. Correct SPF or DKIM, a PTR record for the sending address, no spoofing of other people’s domains and header formatting that follows the standard. These points are checked at ten messages a day too. Seriously, at ten.

Transactional and marketing traffic from the same domain falls into a shared reputation pool. An order confirmation shares the fate of a promotional campaign that someone marked as spam. This is the most common cause of the situation where password reset emails suddenly stop arriving. If notifications leave the application through a connection with the sending system, that traffic counts towards the shared pool as well.

Yahoo publishes far less diagnostic data than Gmail. There is no panel with a complaint chart there. Do not count on comfort – you verify the configuration by how the traffic behaves: the share of rejections, the content of the server response and the pace at which messages are accepted.

Authentication: SPF, DKIM and DMARC with no shortcuts

Three records are the minimum for entry. But what counts is domain alignment, not the mere fact that the records exist somewhere. DMARC checks whether the domain in the From header matches the domain authenticated by SPF or signed by DKIM. Without that alignment you get green marks in diagnostic tools and a red result at the filter. I have seen this a dozen or so times.

SPF and Return-Path

SPF has a limit of ten DNS lookups. Every include pulls in more, and those pull in their own. After a few integrations the record exceeds the limit and returns permerror, which filters treat as a missing SPF. Check the number of lookups after every provider change. The Return-Path domain has to match the From domain, otherwise SPF passes but alignment does not.

DKIM

A 2048-bit key, a separate selector for each sending system, key rotation on a fixed rhythm. Separate selectors let you cut off one tool without touching the rest. And watch out for mailing lists and forwarding: modifying the body or the subject along the way breaks the signature.

DMARC

Start from p=none with a RUA address. Review the reports before you move to quarantine and then to reject. The most common mistake from our practice: the policy is set up perfectly, but sending from a third-party tool has the Return-Path in the provider’s domain. Then everything rests on a single mechanism and falls apart at the first forward.

• The number of DNS lookups in SPF below ten, with no include nested on include.
• Return-Path in your domain or subdomain, not in the provider’s domain.
• A separate DKIM selector for each system, a 2048-bit key.
• A DMARC record with a working RUA address and a mailbox that somebody reads.
• One SPF record per domain – two records are a syntax error.

One-click unsubscribe, meaning List-Unsubscribe

Commercial messages have to carry the List-Unsubscribe and List-Unsubscribe-Post headers. Only both of them together produce the unsubscribe button next to the sender name. List-Unsubscribe on its own with a mail address is an old mechanism and does not meet the requirement. We go through the whole configuration step by step in a separate text about List-Unsubscribe and one-click unsubscribe.

The endpoint has to accept a POST request with no login and no intermediate form. No “confirm your choice”, no question about the reason, no redirect to the customer panel. There is no browser on the recipient’s side – there is a server that sends one request and waits for the response. A page with a survey means the unsubscribe did not work.

You have at most two days to process the request. In practice it is done straight away, because a delay means another send to somebody who has just refused. And a person like that no longer clicks unsubscribe, they click the spam report button.

The visible unsubscribe link in the footer stays. The header does not replace it, it complements it. Some recipients read mail in clients that do not show the button.

Tip: test the unsubscribe on a test account in Gmail and check in the database whether the address actually changed status. An entry in the log means nothing on its own if the application accepted the request and did not save the change.

Complaint rate under control

Gmail sets a hard complaint threshold measured in Postmaster Tools. Crossing it works with a delay, and the effects last long after the cause is fixed. The filter watches the trend, not a single day, so getting back to normal takes weeks.

Keep your working target clearly below the threshold. One failed campaign can push up the average for the whole period, and the buffer is then the only thing that saves you.

Complaints say something about the list and about the promise made at signup, rarely about the content of the email. Somebody signed up for one piece of material and gets a weekly promotion. Somebody else landed in the database during a purchase and never ticked consent to marketing. Fixing subject lines will not repair that. Not one bit.

Hook up feedback loops at the providers and automatically unsubscribe every address that filed a complaint. Segment by activity: inactive recipients get less frequent sends, addresses with no opens over a longer period get retired. Keeping them in the database costs reputation, not just limits.

Tip: do not mix fresh signups and a two-year-old database in one send. The old part drives up rejections and complaints, and the filter judges the whole send together.

Technical hygiene on the server side

The PTR for the IP address has to resolve both ways: the IP points to a name, the name comes back to the same IP. The hostname in PTR has to match what the server gives in HELO/EHLO. A mismatch here produces rejections before the content is even checked.

A TLS connection, header syntax according to RFC 5322, one readable From address with the sender name. No duplicated headers, no empty Message-ID, no encoding that breaks Polish characters.

Do not send with an address in a mailbox provider’s domain as From. The DMARC policy of such domains rejects other people’s sends, and rightly so – that is spoofing after all. The sender has to be your domain, and the address in a free mailbox belongs in the Reply-To field at most.

Separate the streams. A separate subdomain and a separate IP for transactional, separate ones for marketing. Then a problem with a campaign does not hold up order confirmations.

We have our own fleet of sending servers, so we set up PTR, TLS and address reputation ourselves, without queuing for a provider’s support. We describe the details on the page of the MailCraft email marketing platform, and the full scope of what the panel does is in the description of the system features.

ARC matters with mail forwarding, but it is signed by the intermediary the message passes through. The sender does not set it up on their side.

Consent and the list: GDPR and PKE article 398

Polish law requires consent for commercial sends in B2B relations too. A company address exempts you from nothing – article 398 of the Electronic Communications Law (PKE) covers messages directed at subscribers and end users, regardless of whether there is a consumer or a company on the other side.

Bought databases break the law and ruin reputation in the same week. Addresses from such lists are largely inactive or they are traps. You see the effect after the first send: high rejections, complaints, a blocked stream.

Proof of consent has to be reproducible years later. Record the date, the source of the signup, the exact wording of the clause in force at that moment and the IP address. The clause has changed? Keep the versions – showing today’s one is not enough.

Double opt-in is cheaper than getting out of a block. It costs you some signups at the start and pays that back with lower complaints and a cleaner database. We treat legal compliance as a product feature, not a paragraph in the terms: without a legal list there is no deliverability worth fighting for technically.

Warmup and getting out of blocks

A new IP and a new domain start from small volumes sent to the most engaged recipients. The point is to build a history of positive signals before larger traffic appears. Sending to the whole database on day one ends in rejections regardless of the quality of the DNS records.

Raise the volume gradually, at a separate pace for each big filter. Gmail and Yahoo react differently and have their own memory of your domain. One schedule for all of them is an average that fits nowhere.

Read the server responses literally. A temporary rejection means rate limiting – slow down and come back later. A permanent rejection points to a rule on the filter side, and retrying only makes things worse. If the responses mention a listing, start with checking the DNSBL blacklists and the delisting procedure.

We admit to a limitation: automatic detection of block patterns is not in the panel yet. We analyse the logs by hand. It is on the to-do list.

1. Stop sending to the filter that rejects. The remaining streams keep going.
2. Pull the response text out of the logs and check whether it is temporary or permanent.
3. Find the source: a new segment, a new template, a database import, a change in DNS.
4. Remove the cause and clean out the addresses that generated rejections and complaints.
5. If the filter offers a report form, send a report with specifics.
6. Come back slowly, starting from the most active recipients, watching the responses.

Summary and a checklist before your next send

The Gmail and Yahoo requirements for bulk senders come down to four areas. Authentication with domain alignment, one-click unsubscribe, a low complaint rate and a clean transport layer. The rest are consequences of those four points.

Starting from zero? The order is this. First SPF, DKIM and Return-Path in your own domain. Then DMARC with p=none and reading the reports for a few weeks. Next PTR, TLS and splitting the streams across subdomains. After that List-Unsubscribe with a working POST endpoint. Finally warmup and tightening the DMARC policy.

Configuration is continuous work. DNS records change with every new integration, DKIM keys need rotation, and the list ages by itself. An environment set up once drifts out of shape within a year if nobody looks at it.

We do not promise a way around the filters, because there is no such method. What counts is recipient consent, a sensible sending pace and technical order. Those three things decide whether the message arrives.