Check authentication, provider responses, audience quality, and unsubscribe behavior to understand why email is rejected or placed in spam.
Delivery and inbox placement are different. A receiving server can accept a message and put it in spam. A campaign dashboard showing "delivered" does not prove that the reader saw it.
When a problem appears, collect the evidence before changing the copy or switching providers. The failing part may be authentication, reputation, the audience, or the message itself.
For rejected or deferred messages, inspect the actual SMTP response and enhanced status code. Temporary failures and permanent rejections require different handling. Google's sender FAQ describes both; it does not say that all noncompliance now produces permanent errors.
If messages are accepted but appear in spam, inspect authentication results in the received headers, provider reputation data where available, and recent changes in audience or volume. A few seed inboxes help diagnose a problem, but they do not measure placement across the whole list.
An enhanced status code has three numbers separated by dots, defined in RFC 3463. The first number is the class. A code starting with 4 is a temporary failure, and the sending server should retry later. A code starting with 5 is a permanent failure, so retrying the same message unchanged will not help.
The second number narrows the subject. Codes in the X.1.X range concern addressing, and 5.1.1 usually means the mailbox does not exist. Suppress that address. Codes in the X.7.X range concern security or policy, which is where authentication and reputation problems tend to appear.
Google lists the responses Gmail returns in its SMTP error reference. Read the full response text as well as the code, because one code can cover several different reasons.
Google Postmaster Tools shows how Gmail sees your sending domain, including the user-reported spam rate that Google's requirements refer to. You verify the domain with a DNS record. Gmail shows data only once a domain sends enough daily mail to its users, so a small sender may see empty dashboards.
Microsoft's Smart Network Data Services, known as SNDS, reports on mail from specific IP addresses to Outlook.com consumer mailboxes, including complaint rates and spam trap hits. You register IP addresses you control, so it is most useful with dedicated sending IPs. On shared IPs, ask your sending provider what it monitors.
Neither tool tells you where a single campaign landed. They show daily trends, which is what you need when a problem built up over several sends.
SPF authorizes sending infrastructure for an envelope domain. DKIM signs a message with a domain identity. DMARC checks alignment with the visible From domain and publishes a policy and reporting mechanism. None of them guarantees inbox placement.
Use the records supplied by your sending provider and verify the result in a real received message. Do not add conflicting SPF records or assume that a DNS record proves every sending path uses it correctly. Your infrastructure also needs appropriate reverse DNS and secure transport.
In Brew, follow the domain verification workflow and publish the requested records. Review the From address used by the actual campaign or automation, especially when an agent operates several brands.
A DMARC policy is a TXT record at the _dmarc host of the domain in the From address. Start with p=none. It asks receivers to take no specific action on failing mail, and they still send aggregate reports to the rua address.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"The reports list every source sending mail as your domain and whether each one passed SPF or DKIM with alignment. Expect to find tools you forgot about, such as a billing system or a help desk. Fix or remove each failing source.
Once all legitimate mail passes, move to p=quarantine. It asks receivers to treat failing mail as suspicious, which usually means placing it in spam.
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"The strictest policy, p=reject, asks receivers to refuse failing mail. Move to it only after quarantine has run for a while without legitimate mail failing. Keep reading the reports at every stage. A new tool that starts sending as your domain will show up there first.
A dedicated sending subdomain, such as mail.example.com, is the exception. When nothing else sends from it and your provider has verified its SPF and DKIM, it can start at p=reject. Brew recommends p=reject for a dedicated subdomain it set up, and p=none for a main domain where other services may send.
Google's guidelines distinguish requirements for all senders from stricter rules for senders reaching roughly 5,000 messages a day to personal Gmail accounts. Google calls for spam rates below 0.1% and warns against reaching 0.3%. Its bulk requirements include SPF and DKIM, DMARC, alignment, and one-click unsubscribe for relevant subscribed traffic.
Google's list for every sender, at any volume, includes these:
Bulk senders must also do the following:
p=none.Google counts mail from the same primary domain together when it applies the threshold, and a domain that has crossed it once keeps the bulk sender label. Its sender FAQ covers how the count works.
Yahoo's guidance also covers authentication, complaints, and unsubscribe. Yahoo does not publish the same numerical bulk-sender threshold; consult its FAQ rather than applying Gmail's number to every provider.
Microsoft announced in 2025 that domains sending more than 5,000 emails a day to its consumer mailboxes, the outlook.com, hotmail.com and live.com addresses, must pass SPF and DKIM and publish DMARC. The DMARC policy can be p=none, and it must align with SPF or DKIM.
Provider guidance reviewed September 28, 2026. Check the linked pages when diagnosing a new incident.
One-click unsubscribe under RFC 8058 is a header and HTTPS POST mechanism. A visible footer link is also useful and required by relevant rules, but a preferences page alone does not implement the protocol.
A message that supports one-click unsubscribe carries two headers:
List-Unsubscribe: <https://example.com/unsubscribe/opaque-token>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickWhen the reader clicks unsubscribe in the inbox, the mailbox provider sends a POST to the HTTPS URL with the body List-Unsubscribe=One-Click. The mailto: address is an alternative for mail software that does not support one-click. RFC 8058 also requires a valid DKIM signature that covers both headers. Make the URL specific to the recipient and hard to guess. Security scanners often fetch links in incoming mail, so a plain GET to that URL should not unsubscribe anyone.
Brew adds List-Unsubscribe and List-Unsubscribe-Post headers to marketing sends, pointing at a signed, per-recipient HTTPS URL that accepts the one-click POST.
Confirm that a marketing unsubscribe prevents later marketing sends through every path you use. Preserve suppressions when importing contacts or changing platforms. Keep essential transactional messages separate in purpose and sending configuration.
Review where the addresses came from and what people expected at signup. Remove invalid addresses through the provider's suppression process, investigate complaint spikes, and avoid resending to people simply because tracking says they did not open.
There is no universal list age, image-to-text ratio, or forbidden word that guarantees delivery. A sudden volume increase to a poorly understood list is a more serious problem than using the word "free."
If an agent sends the campaign, the same checks apply. Use verified facts, a relevant audience, and a monitored reply address. Fix the identified cause, send a controlled test, and review provider responses before expanding again.
