Bulk Email Sender Requirements: SPF, DKIM, DMARC Guide

If you send more than 5,000 messages a day to personal Gmail accounts, Google expects SPF, DKIM and DMARC on your sending domain, a From domain that aligns with one of them, and one-click unsubscribe on marketing mail. Senders below that line still need SPF or DKIM, valid reverse DNS, TLS and a low spam rate. It helps publishers, bloggers and shop owners who run a newsletter or send order emails work out which rule applies to which message stream.

Permission and authentication are two separate problems. Whether you may email someone at all is a consent question, covered in our piece on consent-based newsletter signups. Whether a receiving server can tell that a message really came from you is a technical question, and that is the subject here. A clean list with broken authentication still runs into trouble, and perfect authentication on an unwanted list does not stop complaints.

Do these rules apply to you? Reading the 5,000 line

Google's email sender guidelines (Opens in a new tab) split requirements into two groups: everyone who sends to personal Gmail accounts, and senders of 5,000 or more messages per day to those accounts. The page says a personal Gmail account ends in @gmail.com or @googlemail.com, and it gives February 1, 2024 as the date the bulk-sender requirements took effect. Google's thresholds and wording can change, so read the live page before you act on any number below.

What counts toward the line

The page does not explain in detail which messages are counted. Practical suggestion: treat every stream that leaves your domain as one reputation, including the newsletter, order confirmations, password resets and contact-form replies, and count the Gmail addresses across all of them. A shop with a modest newsletter can still approach the line once transactional mail is added.

Baseline for every sender

For anyone sending to personal Gmail accounts the guidelines list these items: set up SPF or DKIM for the sending domain; make sure the sending domain or IP has valid forward and reverse DNS (PTR) records; use TLS; keep the spam rate reported in Postmaster Tools below 0.3%; format messages according to RFC 5322; and do not impersonate Gmail From: headers. The page also asks for a single email address in the From: header and for the same From: address on messages of the same category.

Extra requirements at 5,000 or more per day

At the higher tier the page asks for SPF and DKIM together, DMARC with an enforcement policy that may be "none", and alignment between the From: domain and either the SPF domain or the DKIM domain. Marketing messages and subscribed messages must support one-click unsubscribe and carry a clearly visible unsubscribe link in the body.

If you send through Google Workspace

The page points Workspace senders who mail large volumes to the separate spam and abuse policy in Gmail. That policy is a separate document, so read it directly if your newsletter leaves through Workspace.

Unsubscribe and complaints: the part readers feel first

Recipients do not see a missing DKIM key. They do see how hard it is to leave your list. That is why the guidelines treat unsubscribe handling and spam complaints as first-class requirements, with numbers attached.

The two headers behind one-click unsubscribe

The guidelines ask for two headers on marketing messages: List-Unsubscribe-Post with the value List-Unsubscribe=One-Click, and List-Unsubscribe containing an https address. When a recipient uses the mail client's unsubscribe control, the sender receives a POST request with List-Unsubscribe=One-Click in the body. The page says other mechanisms, such as letting recipients manage individual lists or automatically unsubscribing after repeated bounces, can supplement one-click unsubscribe but should not replace it.

The visible link still has to be there

The same requirement asks for a clearly visible unsubscribe link in the message body. The page does not state how many days you have to process an unsubscribe request, so do not quote a deadline from this page; look for the rule in the official source that governs your market.

Spam rate: requirement versus recommendation

The page sets the requirement at below 0.3% for all senders and below 0.30% for bulk senders, measured in Postmaster Tools. In its monitoring guidance it recommends staying below 0.10% and never reaching 0.30% or higher. It adds that user spam reports can lower your domain's reputation over time. The first number is a requirement and the second is a recommendation.

Practical suggestion: with a small list, one angry subscriber moves a percentage a long way, so judge the trend over several weeks rather than a single day. That reading is advice, not something Google writes.

Make leaving easier than complaining

If the quickest exit is the spam button, the spam rate climbs. Put the unsubscribe link where people look, confirm the removal on the next page without a login, and stop sending right away. Sponsored blocks inside the newsletter add another trust question: readers should be able to tell advertising from editorial, and our note on labeling sponsored content covers how.

Authentication as the receiving server sees it

Take the position of the server that receives your newsletter. It has an IP address, an envelope sender, a message with headers and a visible From: domain. SPF, DKIM and DMARC each look at a different part of that picture.

SPF checks the envelope, not the From line

Under RFC 7208 (Opens in a new tab), a verifier checks the HELO identity and the MAIL FROM identity (sections 2.3 and 2.4). The visible From: header is not what SPF evaluates directly. Google's page asks you to publish an SPF record that includes all of your domain's email senders and warns that third-party senders you leave out are more likely to be marked as spam. How to write the record is a separate topic.

DKIM checks a signature, and who signed matters

A DKIM signature travels in the DKIM-Signature header with a domain (d=) and a selector (s=). The receiver looks up the public key in DNS. In RFC 6376 (Opens in a new tab) section 3.6.2.1 the lookup name is the selector, then "._domainkey.", then the domain. The Gmail page says keys of 1024 bits or longer are required to send to personal Gmail accounts and recommends 2048 bits if your domain provider supports it. A signature proves the signed content did not change after signing. It does not, by itself, tell the receiver that the signing domain is the same as the From: domain (RFC 6376 sections 1.2 and 3.11).

DMARC ties the two to the From domain

DMARC is a TXT record at _dmarc.yourdomain (RFC 7489 (Opens in a new tab), section 6.1) with a p tag of none, quarantine or reject (section 6.3). A message passes when at least one of SPF or DKIM passes for an identifier that is aligned with the From domain (section 4.2). The RFC states that DMARC authenticates only a domain, does not evaluate content and does not grant elevated delivery (section 4.2 and the abstract). The RFC 7489 page itself notes that it has since been replaced by RFCs 9989, 9990 and 9991, so section numbers here refer to the 7489 text and the current documents deserve a look too.

Order of work

The Google Workspace DMARC instructions (Opens in a new tab) say SPF and/or DKIM must be on before DMARC and recommend waiting 48 hours after setting them up. The DMARC record itself is added at your domain host, not in the Admin console.

Alignment: where setups quietly fail

An authentication report can show "pass" for SPF and "pass" for DKIM while DMARC fails. The Gmail page explains why: the authenticating domain must be the same domain that appears in the From: header, and for direct email the From: domain must align with either the SPF domain or the DKIM domain.

Passing for the wrong domain

A sending tool may put its own domain in the envelope sender and in the DKIM signature until you complete a domain setup. SPF and DKIM then pass for the tool's domain, not for yours, and neither lines up with your From: domain. The fix lives in the tool: verify your sending domain there and publish the DNS records it gives you, so the signature or envelope sender falls under your domain. RFC 7489 section 3.1.1 adds that with several DKIM signatures on one message, a single aligned and verified signature is enough.

Relaxed and strict

RFC 7489 defines two alignment modes. Relaxed compares organizational domains; strict requires an exact match (sections 3.1.1 and 3.1.2). The adkim and aspf tags default to relaxed (section 6.3). The organizational domain is found by consulting a public suffix list, which the RFC describes as a heuristic process (section 3.2). Practical suggestion: if your newsletter uses a dedicated subdomain, leave both tags at relaxed unless you have a reason to tighten them.

Example scenario: a camera-gear shop

Example scenario: A small camera-gear shop sends order confirmations from its shop platform and a monthly promotion through a separate newsletter tool. Both use the shop's domain in the From: line. The shop platform signs with the platform's domain only, and the newsletter tool has never had the shop's domain verified. DMARC reports would show passing SPF and DKIM in both streams but no alignment in either. To fix it, the owner verifies the domain in both tools, adds the DNS records each tool provides, merges the two senders into one SPF record, and only then thinks about a stricter DMARC policy.

Checklist for the From: line

• One address in From:, as the Gmail page asks.
• The same From: address for messages of the same category.
• Never a Gmail address in From: for mail you send yourself.
• Old plugins and scripts that rewrite From: checked one by one.

Plumbing and message format

Reverse DNS, TLS and message format sound like hosting concerns, but the guidelines list them as sender requirements. If a newsletter service sends for you, those parts belong to the service. If your own server sends anything, they are yours.

Forward-confirmed reverse DNS

The page asks that the sending IP match the IP of the hostname in its PTR record, and that the PTR hostname have an A or AAAA record resolving back to the same IP. In words: the address names a host, and that host name points back to the address. The party that controls the IP address, such as your hosting or IP provider, sets the PTR record, so the request goes to them rather than to your DNS panel for the website domain.

TLS and RFC 5322 details

The page names three format points: a valid Message-ID on every message, single-instance headers (From:, To:, Subject:, Date:) appearing only once, and a single address in From:. Homemade notification scripts are a likely place to break these, for instance by emitting two Subject: headers or no Message-ID. Authentication can be flawless and the format check still fail.

Quick checks for the plumbing

• Does the PTR name resolve back to the sending IP?
• Is every connection to the receiving server made over TLS?
• Does every message carry exactly one Message-ID, From:, To:, Subject: and Date:?

Rerun these checks whenever the sending setup changes. After a service change, also remove the old provider's records from DNS; leftover records keep authorizing a sender you no longer use.

A decision table for every system that sends as you

Newsletter tools are not the only systems that can use your domain. Build one row per system and fill the same columns. The columns below are a practical suggestion drawn from the Gmail page's requirements.

The decision rule

1. If a system sends with your domain in From:, at least one of SPF or DKIM must be aligned to that domain, and at the 5,000 tier both must be set up.
2. If a system sends marketing or subscribed mail, add the two unsubscribe headers and the visible link.
3. If a system cannot be aligned or cannot unsubscribe, move it to a separate subdomain or retire it. Separate subdomains keep a weak stream from dragging down a strong one; that is a practical suggestion, not a Google statement.

Treat any empty cell as a to-do. Do not leave "unknown" in the table: ask the tool's support or open its settings until you know.

A 30 day rollout in three phases

The phases are a suggestion. Google's pages only fix one interval, the 48 hour wait between SPF or DKIM and DMARC.

Days 1 to 10: inventory and baseline

1. List every system that sends with your domain and note the From: domain each uses.
2. Add your domain to Postmaster Tools and begin watching the spam rate. If the interface is localized, menu names may differ from the English labels used in Google's documentation.
3. Export or copy all existing DNS TXT records so you can roll back.
4. Pick one mailbox or group to receive DMARC reports. The Workspace page recommends a dedicated mailbox because reports can arrive in large volumes.

Days 11 to 20: SPF, DKIM, then DMARC in monitoring mode

1. Combine all authorized senders into one SPF record. RFC 7208 section 4.5 says a domain with more than one SPF record produces a permerror.
2. Publish DKIM keys for each sending tool, using 2048 bits where your provider supports them.
3. After 48 hours, publish the DMARC TXT record at _dmarc with v and p first and p=none. Add rua for reports. The Workspace page notes that Gmail does not support ruf.
4. Check the new record with an online DMARC checker. The page warns that some hosts append the domain automatically, so confirm the host name was not doubled.

Days 21 to 30: unsubscribe, review, decide

1. Confirm that your newsletter tool sends both unsubscribe headers and shows a visible link.
2. Read the aggregate reports and look for unknown senders and unaligned legitimate streams.
3. When every legitimate stream passes aligned, plan a move to quarantine or reject. The Workspace page says to raise the policy once you understand how your mail is authenticated, and the pct tag can apply the policy to a share of messages during the change.
4. Write down who owns each DNS record so the next change is not guesswork.

Common mistakes and what they cost

Authentication opens the door but does not guarantee the inbox

Passing SPF, DKIM and DMARC does not promise inbox placement. RFC 7489 says receivers may still apply local policy to mail that passes and to mail that fails despite a reject policy (section 6.7), and Google's page lists spam rate and user reports as separate factors. Authentication is the entry condition. Reputation then builds from list quality and from how easy it is to leave.

Where to look for each symptom

• Messages never arrive: authentication results, reverse DNS and TLS.
• Messages land in spam: spam rate, complaints, list quality and whether readers asked for the mail.
• One provider accepts and another does not: that provider's own policy. The Gmail page covers Gmail only.

When the newsletter is part of a media offer

Publishers who sell newsletter placements to advertisers should be able to state their list size honestly and keep the figure current. Where that figure lives in a website media kit deserves its own attention, and click tracking for those placements is easier to read when links carry consistent tags, as described in our post on sponsored-post reporting with UTM and Search Console.

Frequently Asked Questions

Which senders does Gmail's 5,000 messages per day rule cover?

According to Google's email sender guidelines, senders of 5,000 or more messages per day to personal Gmail accounts must meet extra requirements: SPF and DKIM together, DMARC, alignment, and one-click unsubscribe on marketing messages. Smaller senders still need SPF or DKIM, reverse DNS, TLS and a low spam rate. Check the live page, because Google's wording can change.

Do I have to set DMARC to reject right away?

No. The Gmail guidelines say the DMARC enforcement policy can be none for bulk senders. The Google Workspace instructions recommend starting at none, learning from the reports, and raising the policy to quarantine or reject later.

SPF and DKIM pass but DMARC fails. Why?

Most likely alignment is missing. The Gmail page says the From: domain must align with the SPF domain or the DKIM domain. A newsletter tool that signs with its own domain can pass both checks for that domain without aligning to yours, so verify your domain inside the tool.

How does one-click unsubscribe work?

The Gmail page asks for a List-Unsubscribe-Post header with the value List-Unsubscribe=One-Click and a List-Unsubscribe header containing an https address. When a recipient unsubscribes, the sender receives a POST request with List-Unsubscribe=One-Click in the body. A clearly visible unsubscribe link in the message body is also required.

What spam rate is acceptable?

The Gmail page requires the Postmaster Tools spam rate to stay below 0.3% for all senders and below 0.30% for senders of 5,000 or more per day. It recommends keeping the rate below 0.10% and never reaching 0.30% or higher.

Does a small newsletter need all of this?

Below the 5,000 line the page lists SPF or DKIM, reverse DNS, TLS, RFC 5322 formatting and a low spam rate. DMARC and one-click unsubscribe belong to the higher tier. Practical suggestion: if growth is likely, setting up the higher tier from the start avoids doing the work twice.

Conclusion

The sender rules come in two tiers. Anyone sending to personal Gmail accounts needs SPF or DKIM, valid reverse DNS, TLS and a low spam rate. Senders of 5,000 or more messages a day also need SPF and DKIM together, DMARC, an aligned From: domain and one-click unsubscribe. Build in order: inventory every sender, then SPF and DKIM, then DMARC at none after 48 hours, then test alignment and read the reports before tightening. Authentication does not guarantee inbox placement; a consented list and an easy exit protect your reputation.

If you want to put your newsletter audience in front of advertisers, you can browse guest post listings on Akua Adforce; scope and terms are written on each product page.