Agenter får ingen egen inkorg. Samma CAN-SPAM-regler, samma gränsvärden hos Gmail, samma behov av att skilja marknadsföring från transaktionsmejl i utskicken.
En agent kan starta en kampanj via samma utskicksinfrastruktur som en människa. Gmail ser fortfarande avsändaren, domänen och meddelandet.
E-postleverantörerna bedömer domäner, IP-adresser och klagomålsfrekvens. De bedömer inte om det var en människa som klickade på Skicka. Om agenten skickar säljande innehåll via den transaktionella IP-adressen får du samma problem som om du hade gjort det själv, bara snabbare.
Det här inlägget kompletterar guiden om leveransbarhet för e-post men ersätter den inte. Guiden går igenom rykte, autentisering och listhygien. Det här inlägget handlar om misstagen som dyker upp när det är programvara som trycker på Skicka.
CAN-SPAM gäller kommersiella meddelanden. Bedömningen av huvudsakligt syfte handlar om ämnesraden och brödtexten, inte om vem som skrev dem.
Om ett meddelande blandar en faktura och ett erbjudande behöver du bedöma dess huvudsakliga syfte. Ämnesraden, var kontoinformationen står och hur framträdande erbjudandet är spelar roll. En kort säljande sidfot gör inte automatiskt ett kontoutdrag kommersiellt. FTC:s vägledning innehåller exempel. Kommersiella meddelanden behöver sanningsenliga headers och ämnesrader, en fysisk postadress och en fungerande avregistrering.
Det gäller också åt andra hållet. En lösenordsåterställning som agenten triggade utifrån en verklig säkerhetshändelse är fortfarande transaktionell, så länge brödtexten håller sig till den händelsen.
Gmails krav på avsändare omfattar regler för alla avsändare och striktare regler för storskaliga avsändare som når ungefär 5 000 meddelanden per dag till personliga Gmail-konton. De striktare kraven omfattar bland annat:
p=none eller en striktare policy.List-Unsubscribe och List-Unsubscribe-Post.Transaktionsmejl är undantagna från kravet på avregistrering med ett klick. De är inte undantagna från autentisering, och de går inte fria från spamklagomål om du fyller mallen med en rea.
Yahoo ber avsändare med stora volymer att lägga marknadsförings- och transaktionsmejl på olika IP-adresser, och helst på olika domäner. Kontrollera vilken avsändaridentitet agenten kommer att använda i stället för att lämna det åt en vag standardinställning.
Ge agenten en avsändaridentitet för marknadsföring att använda i kampanjer och automatiseringar: domänen som du värmer upp, IP-adressen där du räknar med klagomål och avregistreringsheaders som du har testat.
Håll transaktionsmejl på en separat identitet. I Brew är den identiteten en domän med transaktionellt syfte, och själva utskicket är en publicerad automatisering med en utlösare. Agenten kan gärna skriva mallen. Men varje händelse ska fortfarande skickas via POST /v1/automations/triggers/{triggerEventId}/fire med en JSON-nyttolast, inte via ”skicka det här utkastet till listan”.
Låt inte agenten välja From-adress bland en hög med verifierade domäner ”för att se vad som hamnar i inkorgen”. Det är så du bygger upp två rykten samtidigt utan att förstå något av dem.
Det typiska felet är inte ett stavfel. Det är ett välformulerat stycke som citerar en siffra som du aldrig har publicerat, eller en ämnesrad som ser ut som ett kvitto.
Innan du låter en agent skicka utan godkännande i förväg:
Cory Nelson på Harmonya berättade för Noah Adelstein att han läste igenom den första kampanjen på det sättet innan han litade på upplägget. Det är rätt ordning.
Autentisera domänen, välj rätt avsändaridentitet och stäm av den första kampanjen mot den godkända briefen. Kontrollera också assistentens behörigheter och inställningar för bekräftelse. Alla MCP-klienter ber inte om godkännande på samma sätt.
Briefen som stoppar påhittade siffror finns i så briefar du en mejlagent. Genomläsningen av Harmonyas första kampanj beskrivs i så blev Harmonyas nyhetsbrev ett livscykelprogram.
