Automated Emails Going to Spam? Check the From Domain

Automated email lands in spam because of the address it was sent from, not the words inside it. Gmail and Microsoft both apply their bulk-sender rules to the domain in the From: header, both draw the line at 5,000 messages a day, and both treat crossing that line as permanent. So the decision that determines whether your automated mail reaches anyone is the one made at build time, when somebody picked the sending account for a workflow, and it is usually the account that was already configured.

The advice you will find on this is written for marketers: authenticate, warm up, clean your list, avoid spam trigger words. All fine. None of it addresses the failure that workflow builders create, which is pooling four unrelated kinds of mail onto one domain and then discovering that the cheapest of them decides delivery for the most important one.

Your send node reports success either way

Start here, because it explains why nobody catches this for months.

An SMTP send node reports the result of the handshake. A 250 response means the receiving server accepted the message for delivery. What happens next, whether it goes to the inbox, the junk folder, or straight to a filter that drops it silently, happens inside the recipient's mail system and is never reported back to your workflow. The execution log stays green. The success rate stays at 100 percent. This is the same shape as the other ways automations fail without telling you, and it is why "our emails stopped working" usually arrives as a customer complaint rather than an alert.

There are two signals that do come back, and both are worth wiring into a workflow. A hard bounce arrives as a 5xx rejection at send time and your node can catch it. Everything else has to be pulled: Google Postmaster Tools reports spam complaint rate and authentication pass rate per domain, and DMARC aggregate reports list every source sending mail as you. If you send automated mail at any volume and read neither, you are flying on the assumption that accepted equals delivered.

The 5,000-a-day line is per domain, and it is a one-way door

The two thresholds that matter are identical and are counted in a way most people get wrong.

Google classifies you as a bulk sender at 5,000 or more messages to Gmail accounts in a single day, counted against the domain in the From: address. The FAQ is blunt about what that means afterward: bulk sender status has no expiration date, senders classified as bulk are permanently classified as such, and changes in sending practices will not undo it. Microsoft uses the same number for Outlook.com, Hotmail, and Live, and since May 5, 2025 non-compliant mail from those domains is rejected outright with 550 5.7.515 Access denied, sending domain does not meet the required authentication level. Microsoft's own wording is that once the level is reached, all future messages must comply.

Read that as a counter you cannot reset. One heavy send day, once, and the requirements apply to your domain from then on.

Now the part that catches operators. That count is per domain, not per tool. Your CRM sequence, an n8n workflow sending order updates, a Make scenario emailing quotes, and a person on the sales team using an outreach extension are four separate systems that each look small on their own dashboard. Gmail adds them together because they all say @yourcompany.com. Nobody owns the total, so nobody notices the day it crosses.

The requirements themselves are not hard: SPF and DKIM both passing, a published DMARC record, and alignment, meaning the domain in the From: header matches the SPF domain or the DKIM domain. A DMARC policy of p=none satisfies the rule. Most failures we see are not missing records, they are alignment: mail sent through a third-party relay that signs with its own domain, so DKIM passes for the vendor and aligns with nothing you own.

Four mail streams, one domain, and the one that poisons the rest

Here is the actual killer detail. Complaint rate and reputation are tracked against the sending domain. Google's threshold is to stay below 0.10 percent and never reach 0.30 percent. At 5,000 messages, 0.30 percent is fifteen people clicking the spam button in one day. A single nurture batch to a list that has gone cold can do that on its own.

If that nurture sequence sends from the same domain as your invoices, the invoices are now in that reputation bucket. Route mail by what it is, not by whichever send node was already wired up.

Stream	Typical automated send	Send it from	What it must carry	Cost of getting it wrong
Transactional	Receipt, password reset, appointment confirmation, invoice	A dedicated subdomain, for example mail.yourco.com	Aligned SPF and DKIM, no unsubscribe required	Highest. A customer never gets the thing they paid for and calls you
Operational	Alerts and digests to your own staff, error notifications	Internal subdomain, or skip email entirely for chat	Aligned auth, low volume	Low, but it hides monitoring failures when it silently stops
Lifecycle and marketing	Drip sequences, re-engagement, newsletters, review requests	A separate marketing subdomain, for example news.yourco.com	One-click unsubscribe headers, visible unsubscribe link, suppression check	This is the stream that generates the complaints
Cold outreach	Prospecting sequences to people who never opted in	A different domain entirely, never the primary	Everything above, plus its own reputation to burn	Burns whatever domain it runs on. Expect it to

The separation is not cosmetic. Each subdomain gets its own DKIM key and its own reputation, so a bad week on news.yourco.com does not follow your receipts. It costs one DNS session to set up and it is the single highest-leverage change on this list.

One caveat from experience: do not split streams and then leave both sending from the root domain in the From: header. The reputation follows the domain in From:, so if the header still says @yourco.com, you have separated nothing.

The headers a plain SMTP node does not add

If your lifecycle mail goes out through a generic send node with an SMTP server behind it, it is almost certainly non-compliant right now, and perfect SPF and DKIM will not save it.

Gmail requires marketing and subscribed messages from bulk senders to support one-click unsubscribe, which means two headers on the message: List-Unsubscribe pointing at a URL, and List-Unsubscribe-Post: List-Unsubscribe=One-Click. A visible unsubscribe link in the body is required as well. Google's guidance is to process the requests within two days. A commercial email platform sets all of this for you. A raw SMTP node sets none of it unless you add the headers yourself, and most workflow-built sequences never do.

The workflow-side half of this is the part that gets skipped even by teams that add the headers. One-click unsubscribe is a POST to your endpoint. Something has to receive it, write the suppression, and have the sending workflow honor it. Two implementation rules make the difference:

The suppression check belongs in the send step, not the list-building step. A five-day sequence that queries the list on day zero will keep mailing someone who unsubscribed on day one, and it will do it from a workflow whose logs show nothing wrong. Check the suppression list immediately before each send, inside the loop.

The unsubscribe endpoint has to write to the same place the workflow reads. We have seen a hosted unsubscribe page updating a field in the email tool while the sending workflow filtered on a different field in the CRM. Unsubscribes were captured correctly and the mail kept going out. Two days to honor a request is not a long window when the round trip is broken.

Authentication problem or reputation problem?

These have completely different fixes and completely different timelines, so identify which one you have before changing anything.

What you observe	What it is	Time to fix
Hard bounces citing an authentication level, such as 550 5.7.515	SPF, DKIM, or DMARC alignment is wrong for that domain	Hours, once DNS propagates
Mail accepted with 250 but filed in junk at one provider	Reputation with that provider, or a mismatch between the stream and the domain	Weeks of clean, separated sending
Delivery drops with no change on your side	Volume crossed a threshold, or another sender started using your domain	Days, once you find the source
Only new recipients affected, existing contacts fine	Engagement-based filtering on a cold list	Fix the list, not the DNS

For the third row, DMARC aggregate reports are the tool. They arrive as XML from each receiver and list every IP sending mail with your domain in From:, which is how you find the marketing tool a department signed up for last quarter and never told anyone about. Point your rua address at a parser and read it once a month. It is the closest thing to an alert on something that stopped working correctly that exists for email.

Where to start: a 45-minute mail audit

List every system in your business that sends email automatically. Every workflow with a send node, every CRM sequence, every SaaS tool with notifications turned on, every reporting job. For each one, write down four columns: the From: address it uses, which of the four streams above it belongs to, the volume it sends on a normal day, and whether anything in it needs an unsubscribe.

Then sort by stream and total the volume per domain, because that number, not any per-tool count, is what Gmail and Microsoft are measuring. Anything in the lifecycle or cold-outreach rows moves to its own subdomain with its own DKIM key. Anything transactional stays on a subdomain reserved for it. Check alignment on each one by sending a test to a Gmail account and reading the original message headers, where SPF, DKIM, and DMARC each report PASS or FAIL in plain text.

Most stacks we audit have somewhere between six and twelve senders on one domain, and at least one of them is a sequence nobody has looked at in a year. If your lead follow-up is part of that pile, customer acquisition systems is where we usually rebuild the routing, and the broader cleanup is ordinary workflow automation work. Want a second set of eyes on the inventory before you start moving domains? Send us the list and we will tell you which stream is doing the damage.