AI SDR: Whose Name Sits in the From Line, and Who Replies

An AI SDR is software that runs the mechanical stages of outbound sales development: sourcing prospects, drafting and sending the first touch, following up, booking the meeting. The governance question it raises is not whether it works. It is whose name is in the From line.

That question sounds small. It is the one that decides your legal exposure, your domain reputation, what happens when a prospect replies, and whether an employee finds out six months later that a stranger has been having conversations under their name. Every other AI SDR control sits downstream of it: send caps, suppression lists, approval gates. Get the sender identity wrong and the rest is scaffolding on sand.

The problem is already being described by the people on the receiving end of it. Writing on Hacker News in April 2025, the commenter mgdev described the moment the abstraction breaks: after an AI has written as you, "they might reference specifics from 'your' message that you have no actual knowledge of" (Hacker News, item 43804771; the item page rate-limits non-browser clients, so the comment is also readable through Hacker News's Algolia item API). The comment was about AI email assistants in general. Run the same mechanic at outbound volume, with a persona and a headshot, and you have an AI SDR programme.

The short answer: Before an AI SDR sends its first email, four things must be true of the name in the From line. That person exists, knows, can answer, and can revoke. If any one is false, you do not have a sender, you have an exposure.

Last updated: July 31, 2026.

What an AI SDR Is, and Where the Governance Question Actually Sits

An AI SDR is an agent that performs sales development work end to end: it builds a prospect list, enriches it, writes and sends the opening message, waits, follows up, interprets the reply, and either books a meeting or disqualifies the lead. The label describes a job, not a technology. Most products in the category are an orchestration layer over a language model, a data provider, and a mailbox.

That last item is the one governance keeps missing. An AI SDR is only interesting because it sends. It does not recommend an email for someone to send later; it puts a message into a stranger's inbox with a name attached. Everything a sales team argues about, from personalisation quality to reply rates to cost per meeting, is downstream of two configuration fields set during onboarding: which mailbox, and which display name.

This is why define your guardrails is such an unhelpful instruction on its own. A send cap is a guardrail. A suppression list is a guardrail. Both of them meter volume, and neither one tells you who the recipient thinks they are talking to.

So the useful way to frame the category is by what it emits, not by what it automates. Each outbound message carries three assertions to the recipient: that a company is contacting them, that a specific named individual is contacting them, and that a reply will reach a party able to act on it. A programme is well governed when all three assertions are true and evidenced. It is badly governed when the first is true and the other two were never examined.

This is not the same question as whether an AI SDR is allowed to promise things. What an outbound agent may commit the company to, whether price, terms, timing or product claims, is a separate control problem, and one we worked through in our earlier analysis of the four binding sentences in AI for sales. Identity comes first, because a commitment made by a name that does not exist is worse than one made by a name that does.

The From-Line Test: Four Questions Before the First Send

The From-Line Test is four questions you answer once per sender identity, in writing, before the first message leaves your infrastructure. It is a page of decisions, not a project, and it is the control everything else in this article depends on.

Exists. Is the name in the From line a real person? Not "is it a plausible name". Is there a human being, employed by or contracted to your company, who corresponds to it? A yes and a no are both workable answers. An unexamined answer is not.

Knows. If the name is a real person, do they know their name is being used this way, in writing, with the scope described? "They approved it in a meeting" is not the artifact you want when someone objects eighteen months later.

Answers. When the prospect replies, and replies are the point, who reads it, in what time, and under what identity does the response go back? A persona that cannot answer is a persona that will be found out on the first curious reply.

Revokes. Can the named person withdraw? Can the company kill the identity? When an employee resigns, does the sequence stop that day, and what happens to the threads already open under their name?

Name the test and use it consistently, because the failure mode is that these questions get asked informally, by different people, at different times, and never written down anywhere a compliance reviewer can find them. Four questions, one page, one owner, one date. That is the entire artifact.

The test is deliberately indifferent to which answer you choose. There are defensible AI SDR programmes that run under a real rep's name and defensible ones that run under an explicitly non-human sender. There are no defensible programmes where nobody can say which.

Four Sender Identities, and What Each One Exposes

There are only four things you can put in the From line of an outbound message. They form a ladder, and the exposure changes at every rung. Below, each mode is given the same treatment: what the recipient sees, what breaks, what rules touch it, and the verdict.

Mode 1 — Attributed assist. A real employee's name, and that employee reviewed or wrote each message before it went.

What the recipient sees: an email from a person who wrote it. What breaks: throughput. This does not scale past a few hundred touches per rep per week, which is the reason teams leave it. Rules that touch it: ordinary commercial email rules; the sender identity itself is uncontroversial. Verdict: the only mode with no identity question at all. Use it for named accounts and for the first four weeks of any new sequence, as the baseline you measure the other modes against.

Mode 2 — Delegated send. A real employee's name, and the agent sends without per-message human review.

What the recipient sees: identical to Mode 1. They cannot tell. What breaks: the employee's knowledge of their own correspondence. This is precisely the situation mgdev described: the rep walks into a meeting continuing a conversation they never had. Rules that touch it: the From line is accurate, so the header rules are satisfied; the pressure moves to the consent and disclosure questions below. Verdict: workable, and the mode that most obviously trades throughput for exposure, but only defensible with a written consent record, a reply routing contract, and a revocation path. Without those three it is the mode most likely to produce an internal incident rather than an external one.

Mode 3 — Synthetic persona. An invented human name, often paired with a generated or purchased headshot, sometimes with a social profile.

What the recipient sees: a person. What breaks: everything, on contact with curiosity. The prospect searches the name, finds a profile with no history, and the company's first impression is now a question about honesty. Rules that touch it: email header accuracy, platform terms of service, and, depending on jurisdiction and context, bot-disclosure statutes. Verdict: the highest-exposure option and the one with the least upside. It buys a warmer From line and costs you the ability to answer the simplest question a prospect can ask, which is "who are you?"

Mode 4 — Named machine sender. A sender that is explicitly not a person: a team alias, a product name, or a person's name with a visible on-behalf-of construction.

What the recipient sees: a company, honestly. What breaks: reply rates, probably, though this is exactly the trade the whole category is arguing about. Rules that touch it: the fewest of the four, because there is no misapprehension to correct. Verdict: the mode that survives scrutiny best, and the one mgdev himself proposed in the same Hacker News comment — agents with "their own distinct identities" rather than pretending to be their users. It is also the only mode where a disclosure obligation, wherever it lands, is satisfied by construction rather than by a footer.

Exists: What the Law Says About a Name That Is Not a Person

Start with the rule that is genuinely settled, because it is short and it is about the From line specifically. The FTC's compliance guide to the CAN-SPAM Act states the requirement in one sentence: "Your 'From,' 'To,' 'Reply-To,' and routing information — including the originating domain name and email address — must be accurate and identify the person or business who initiated the message" (FTC, CAN-SPAM Act: A Compliance Guide for Business, fetched July 31, 2026). The same guide notes that the law "makes no exception for business-to-business email," and that each separate violating email is subject to penalties of up to $53,088 — a civil penalty figure the FTC adjusts for inflation annually, so check the current number rather than quoting this one in a year's time.

Read that sentence carefully, because it does two things. It requires accuracy, and it offers a disjunction: the header must identify the person or business who initiated the message. A message sent under a company name, from a company domain, identifying the company, is squarely inside it. A message under an invented human name is where the argument starts, and it is not an argument we are going to settle for you in a blog post. What is not arguable is that the header is a regulated field rather than a creative one, and that the volume multiplier attached to it is per-email.

The FTC guide adds a second point that matters for anyone buying an AI SDR rather than building one: "Monitor what others are doing on your behalf." Responsibility for the header does not transfer to the vendor whose platform pressed send.

Then there is the impersonation rule, and here the useful finding is about what it does not reach. The FTC's Rule on Impersonation of Government and Businesses, published at 89 FR 15030 on March 1, 2024, makes it a violation to "materially and falsely pose as, directly or by implication, a business or officer thereof," and defines "officer" to include "executives, officials, employees, and agents" (16 CFR Part 461, fetched July 31, 2026). That is aimed at posing as someone else's business or someone else's staff, the scam where a message claims to come from a bank or a supplier. A company inventing a fictional employee of itself is not the fact pattern the rule was written around, and we found no published enforcement applying it that way. Treat it as an open question rather than a green light: the rule's absence is not a permission.

The honest summary of the "exists" question is therefore narrower than either the enthusiasts or the alarmists would like. The header accuracy requirement is real, specific, per-email, and applies to B2B. Whether a fictional-employee From line breaches it in a given campaign is a question with a genuine answer, and the person who should give it is your counsel looking at your actual sequences, not an article looking at the statute in the abstract.

Knows: What You Owe the Employee Whose Name You Send Under

Mode 2, a real rep's name on messages they did not write, is the mode where the exposure points inward. The person you may harm first is your own employee.

There is settled statutory law directly on this, and it is unusually plain. California Civil Code section 3344 provides that "any person who knowingly uses another's name, voice, signature, photograph, or likeness, in any manner ... for purposes of advertising or selling, or soliciting purchases of, products, merchandise, goods, or services, without that person's prior consent" is liable for damages, and sets a statutory floor: "an amount equal to the greater of seven hundred fifty dollars ($750) or the actual damages," plus attorney's fees to the prevailing party (California Civil Code § 3344, fetched July 31, 2026). Most US states have a comparable right-of-publicity statute or common-law doctrine; the details differ and the operative words in section 3344 are the ones to hold onto. Prior consent. Name, signature, photograph, likeness. Soliciting purchases.

An outbound sequence is soliciting purchases. A rep's name and headshot in an email signature are name and likeness. The question that remains is consent, and consent is a document you either have or do not.

We are not telling you an employment relationship fails to supply that consent. In many cases it plainly can, through the employment agreement, a media release, or a policy the employee acknowledged. The point is operational rather than doctrinal: the consent is either recorded, specific, and retrievable, or it is a recollection. What a defensible record looks like:

That table is short enough to be a form and specific enough to be evidence. It also produces a second benefit that has nothing to do with law: a rep who has read the scope line knows what is going out under their name, which is the fastest possible fix for the mgdev problem.

For teams already treating agents as identities with owners and expiry dates, this is the same discipline extended to a name rather than a credential. Our earlier analysis of non-human identity — owner, scope, expiry works through the credential half; the consent record is the human half of the same object.

Answers: The Reply Nobody Designed For

Outbound exists to produce replies. So the design question that gets skipped is the only one guaranteed to occur: what happens to the reply.

Walk one thread. Your AI SDR sends a first touch on Monday under the name Dana Whitfield. On Wednesday the prospect replies: "Dana — we looked at this last year and it stalled on procurement. Are you the person who handled the Contoso rollout?" That message now needs an answer that is true. There are exactly three things that can happen to it, and only one of them is a design.

The agent answers as Dana. It has now made a factual claim about a person's work history, or dodged the question in a way that reads as evasive. If Dana is a real rep who did not handle Contoso, the agent has misdescribed a real person. If Dana does not exist, the agent has answered a question about a fictional career.

The reply lands in a shared inbox and a human answers as Dana. Workable, and the only one of the three that can be called a design, but it requires that a human is genuinely assigned, within a stated response window, and that the handover carries the full thread. It also requires that whoever answers can say something true about who they are.

Nothing happens. The reply sits in an unmonitored mailbox. The sequence then continues on schedule to someone who already replied. That is a configuration mistake rather than a legal one, right up until the person who replied posts a screenshot of it.

The control is a reply routing contract, agreed before launch, with four fields:

The fourth field is the one that saves the programme. An agent that keeps sending after a human has answered turns a warm reply into a complaint, and complaints are the input to the deliverability arithmetic below.

There is a version of this question people ask about voice rather than email, about who owns the number and what the carrier attests to, and it has its own answers, which we covered in who owns the number for an AI caller. The email version is easier to fix and easier to ignore.

Revokes: The Persona That Outlives the Person

Reps leave. An AI SDR programme that ties sender identities to employees inherits a lifecycle event it did not plan for, and the failure is quiet.

Three things must happen the day the rep's employment ends. The mailbox gets suspended, which is a standard offboarding step. The sequences must stop, and the open threads must be reassigned with an honest transition message — and those two are the Revokes gate, which is why the gate exists as a written commitment rather than an assumption about the runbook.

A suspended mailbox with a live sequence is the worst combination available. Sends may continue from the platform's own infrastructure while replies bounce, so the company is soliciting under the name of a person who has left and cannot receive an answer. Anyone who replies gets a rejection notice with a former employee's address in it.

The revocation checklist, which belongs in the offboarding runbook and not in the sales ops backlog:

1. Suspend the mailbox and revoke the platform credential the same hour, together.
2. Halt every sequence where that identity is the sender, before reassignment, not after.
3. Enumerate open threads under that identity and assign each to a named human.
4. Send a transition message on each open thread, from the new owner, under the new owner's name.
5. Retire the display name from the sender pool so it cannot be reissued to an agent.
6. Record the date, the actor, and the thread count in the audit trail.

Step five is the one people argue about. A departed rep's name is a warm asset, because the account list already recognises it, so reusing it is a decision somebody will propose. Reusing the name of a person who no longer works there, on messages they cannot see, is Mode 3 with extra steps.

The wider version of this problem is the ownership question every automated process eventually hits: what happens to the work when the person who set it up goes. We wrote that up as the leaver test for workflow software, and an AI SDR sender identity is a textbook instance of it.

Disclosure: What Is Settled, What Is Not, and What Belongs With Counsel

Whether you must tell a prospect they are corresponding with software is the question this topic is famous for, and the honest state of it is: narrower than people assume, moving, and jurisdiction-specific. Here is what the primary text actually says.

California's bot law. Business and Professions Code section 17941, added by SB 1001 in 2018, makes it "unlawful for any person to use a bot to communicate or interact with another person in California online, with the intent to mislead the other person about its artificial identity for the purpose of knowingly deceiving the person about the content of the communication in order to incentivize a purchase or sale of goods or services in a commercial transaction or to influence a vote in an election." It then supplies a complete safe harbour: "A person using a bot shall not be liable under this section if the person discloses that it is a bot," and the disclosure "shall be clear, conspicuous, and reasonably designed" (California Business and Professions Code §§ 17940–17943, fetched July 31, 2026).

Two features of that text deserve attention. The prohibition is keyed to intent to mislead about artificial identity, not to automation as such. An unlabelled but non-deceptive automated message is a different fact pattern from a persona built to read as human. And the statute's definitions section defines "online" as "appearing on any public-facing Internet Web site, Web application, or digital application, including a social network or publication," while separately defining an "online platform" by a 10,000,000-monthly-US-visitor threshold that the operative prohibition does not use. Whether a private email exchange is "online" within that definition, and how the two definitions interact, is not something we could find resolved by a published decision. That is a question for counsel with your campaign in front of them, not a question an article should answer with confidence.

The EU AI Act. Article 50(1) of Regulation (EU) 2024/1689 requires that providers "ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use" (EUR-Lex, Regulation (EU) 2024/1689, fetched July 31, 2026). Whether a one-way outbound email that a human never reviews is a "direct interaction" for those purposes, and how the provider and deployer roles divide, are exactly the questions being worked through now. Our read of the Act's timeline for deployers sits in our EU AI Act guide; the application to your outbound programme belongs with your counsel.

Platform terms, which bind faster than statutes. If the AI SDR touches LinkedIn, the contract is not ambiguous. The LinkedIn User Agreement requires members to "Use your real name on your profile," and section 8.2 states that you will not "Create a false identity on LinkedIn, misrepresent your identity, create a Member profile for anyone other than yourself (a real person), or use or attempt to use another's account" (LinkedIn User Agreement §§ 8.1–8.2, fetched July 31, 2026). A synthetic AI SDR persona with a LinkedIn profile is a plain breach of a contract you accepted, enforceable by account restriction without a regulator being involved at all.

The practical posture that follows from all three, and the one we would defend: pick the disclosure position deliberately, write it on the sender identity record, and let it be the same in every jurisdiction you send to rather than segmenting by law. A single honest sender construction is cheaper to run than four conditional ones, and it does not need re-litigating each time a statute moves. Nothing in this section is legal advice; it is a summary of primary text with the contested parts marked as contested.

Deliverability: What Persona Sending Does to Your Domain

The identity question has a second consequence that is purely mechanical and has nothing to do with law.

Persona-based sending at volume means many mailboxes, and frequently several lookalike domains, so that no single sender trips a rate limit. That architecture runs into the sender rules the large mailbox providers published in 2024, which are the operative standard Gmail now applies to inbound mail at scale.

Google's requirements are specific. All senders to Gmail accounts must, since February 1, 2024, set up SPF or DKIM for their sending domains, maintain valid forward and reverse DNS, use TLS, and "keep spam rates reported in Postmaster Tools below 0.3%." Senders of more than 5,000 messages per day to Gmail accounts must additionally set up both SPF and DKIM plus DMARC for the sending domain, ensure "the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain," and support one-click unsubscribe on marketing and subscribed messages (Google Workspace Admin Help, Email sender guidelines, fetched July 31, 2026).

Three consequences fall out of that for an AI SDR programme:

The From-header alignment requirement makes the sender identity a DNS fact. The display name is cosmetic; the domain is not. A persona sending from a lookalike domain is not disguised, it is enumerated. Every message publishes which domain authenticated it.

The 0.3% spam-rate threshold is a per-domain budget. At 5,000 messages a day, 0.3% is fifteen complaints. A persona that reads as deceptive, or a sequence that keeps sending after someone replied asking it to stop, spends that budget quickly, and the cost lands on whichever domain authenticated the mail.

Lookalike domain sprawl transfers risk rather than removing it. Sending from a shadow domain protects the primary domain's reputation, which is the point. It also means the messages your prospects receive are authenticated by a domain that is not yours in any recognisable sense, which is a strange thing to be doing while asking for a meeting.

We have not run a persona-based sending programme ourselves and are not going to quote a reply-rate figure we did not measure. What is verifiable is the published threshold, the alignment requirement, and the arithmetic that follows from them, and those are enough to size the decision.

Deliverability engineering for high-volume senders is a discipline of its own, and the sender guidelines from providers other than Google were not all reachable for verification while writing this. Microsoft's high-volume sender documentation returned 403 to every fetch attempt we made, so we have not characterised its requirements here rather than paraphrase them second-hand.

The Sender Identity Card: One AI SDR, Fully Specified

Everything above collapses into one artifact. A sender identity card is a single page per From line, and it is the thing you hand a compliance reviewer, a new sales ops hire, or an enterprise prospect's security questionnaire. Here is a complete one. It is an illustrative example rather than a real deployment, with invented names, addresses and dates, filled in for the least exotic case: a mid-market SaaS company running delegated send under a real rep's name.

Nothing in that card is exotic. Almost all of it is information the programme already has, scattered across a CRM, a DNS zone, an HR folder, and somebody's memory. The work is not gathering it. It is deciding that one page owns it.

Prerequisites Before the First AI SDR Send

If you are evaluating an AI SDR right now, this is the shortest honest list of things that must exist before the first message goes out. None of them is the product itself.

1. A named owner for sender identity. One person, not a committee, accountable for every From line the company sends outbound from.
2. The From-Line Test answered in writing for each identity you intend to use, with a date and a signature.
3. A consent record for every real person's name and likeness in use, with a scope and an expiry.
4. A reply routing contract with a named human, a response window, and hard sequence suspension on inbound.
5. Sending infrastructure that authenticates — SPF, DKIM, DMARC alignment on the actual sending domain, and Postmaster Tools access so the spam rate is a number somebody watches.
6. Suppression at the source of truth, not inside the AI SDR platform. Customers, open opportunities, opt-outs, and do-not-contact entries must be enforced from the CRM, so they survive a vendor change.
7. An audit trail that survives the vendor. Every message, recipient, template version, and approval event exported somewhere you control. A vendor's dashboard is not a record; it is a view of one.
8. A written disclosure position, decided deliberately, applied uniformly, and reviewed by counsel if you send into the EU or California.

A team that has these eight can evaluate AI SDR products on their merits. A team that does not is not choosing a vendor, it is choosing which unowned risks to inherit.

Six Ways This Fails, and the Artifact That Prevents Each

Four of these are a failed gate from the From-Line Test; two are a missing prerequisite from the list above. They are derived from those two artifacts rather than observed across a set of deployments, and each is tagged with the thing that would have caught it.

1. The persona gets searched. (Exists.) A prospect looks up the name, finds nothing, and asks a colleague. The conversation the company wanted to have about its product becomes a conversation about whether it invents people. There is no recovery move that is better than not having done it.

2. The rep finds out sideways. (Knows.) An account executive meets a prospect who references an exchange the rep never had. This is a trust event inside the company, not outside it, and it is the one that produces a policy overnight.

3. The sequence outlives the reply. (Answers.) Someone answers, and the follow-up fires anyway on Thursday. The single most reliable way to convert a warm response into a spam complaint.

4. Suppression lives in the wrong system. (Prerequisite 6.) The do-not-contact list is maintained inside the AI SDR platform. Three months later the team switches vendors and the list does not come with it, or a second sequence in a second tool never sees it.

5. The spam rate becomes visible only after the damage. (Prerequisite 5.) Nobody has Postmaster Tools access, so Google's 0.3% threshold is not a metric anyone watches until deliverability drops and a quarter's outbound has already been filtered.

6. Offboarding halves. (Revokes.) The mailbox is suspended, the sequences are not, and mail continues to go out under the name of somebody who left, with replies bouncing.

Every one of these is prevented by an artifact rather than by vigilance, which is the argument for writing the card before the pilot rather than after the incident.

When a Human SDR Still Wins, and What an AI SDR Is Not

The AI SDR vs human SDR comparison gets framed as cost per meeting, which flatters the machine and misses where the difference actually is. The difference is in what each can be accountable for.

A human SDR still wins clearly in four situations. When the account is named and strategic, and the first email is a considered artifact rather than an attempt. When the buying committee is small enough that being remembered matters more than being frequent. When the message must contain a judgement about a competitor, a timeline or a commitment that nobody wants an agent making. And when your buyer's own norms make automated outreach a negative signal, which is a judgement your own reps can make about their own market better than any framework can.

An AI SDR wins on coverage of segments no human was going to work, on consistency of follow-up, and on the parts of the job that were always mechanical: enrichment, sequencing, and the second and third touch that reps skip.

What an AI SDR is not:

• It is not a rep with a quota. It cannot be accountable, so the accountability stays with a named human. If your org chart says otherwise, the chart is wrong.
• It is not a compliance layer. Sending correctly is not the same as being allowed to send, and no AI SDR product resolves consent, suppression provenance, or disclosure for you.
• It is not a fix for a bad list. An agent applying a good sequence to a bad list produces more complaints faster, and complaints are metered against your domain.
• It is not a reason to stop reviewing. The review moves from per-message to per-template and per-sequence. It does not disappear.

Where LeapForce Fits, and Where It Does Not

LeapForce does not sell an AI SDR and does not write your outbound. What it governs is the layer underneath: which agents exist, what identity and credentials each one carries, what it is permitted to touch, and what record survives the interaction. Access and identity treats non-human identities as first-class, with an owner, a scope, and an expiry on every agent. That is the same object as the sender identity card, expressed as a credential rather than a name. Observability and audit is where the per-message record lives, including what was refused, which is the half of the trail that matters when someone asks why a message did not go. And the rollout model we use for the gateway — observe first, enforce second, optimize third — is the right shape for an AI SDR programme too: run the sequences in observe mode long enough to see what your agents actually send before you write the policy that constrains them.

If you already have a sender identity card, a consent record, and a reply routing contract that hold under audit, you do not need us for this. These artifacts have no natural home in the stack. A sender identity is not a CRM object, not an HR record, and not something an outbound tool asks for, which is why it tends to be nobody's field to fill in.

Honest Limits and Open Questions

We have not run an AI SDR persona programme. Every operational recommendation here is derived from primary legal and platform text plus the published sender requirements, not from a campaign we ran. Where a number would be useful, such as reply rate by sender mode or complaint rate by persona type, we do not have one and have not invented one.

The disclosure question is genuinely unsettled for email. California's bot statute is written around online communication with an intent to mislead; the EU AI Act's Article 50 is written around systems interacting directly with natural persons. Neither was drafted with one-way AI-generated outbound email specifically in view, and we found no published enforcement or decision applying either to that fact pattern. Anyone telling you the answer is clear is selling something.

Right-of-publicity law varies by state and country. We quoted California's section 3344 because its text is plain and its remedies are specific. Whether your jurisdiction's equivalent reaches an employee's name in a sales signature, and whether your employment agreement already supplies consent, are questions with local answers.

Some sources were not reachable. Microsoft's high-volume sender requirements documentation returned 403 to repeated fetches, so the deliverability section covers Google's published requirements only and does not characterise Outlook's. Reddit's search endpoint returned 403 to our fetches, so we did not draw on it; the practitioner voice cited here comes from Hacker News and skews toward a technical audience rather than a sales one.

Nothing here is legal advice. The statutes, rules, and platform terms quoted above are summarised from primary sources and linked so you can read them yourself. How they apply to your outbound programme is a question for your counsel.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.