Testa e-post från Amazon SES

Kontrollera först sandbox-statusen, eftersom den avgör om detta över huvud taget fungerar. Ett nytt SES-konto börjar i sandbox-läge i varje Region, och så länge det är där levererar SES endast till verifierade adresser, verifierade domäner och den egna mailbox simulator. Dessutom gäller en gräns på 200 meddelanden per 24 timmar och ett meddelande per sekund.

Att verifiera en Email Spam Tester-adress löser inte problemet. SES verifierar en mottagare genom att skicka ett e-postmeddelande med en länk, och eftersom våra adresser tar emot exakt ett meddelande innan de stängs skulle verifieringsmeddelandet förbruka adressen. I praktiken behöver du därför produktionsåtkomst i den Region som du skickar från. AWS lovar ett första svar på begäran inom 96 timmar.

Eftersom sandbox-statusen gäller per Region kan ett konto som har produktionsåtkomst i eu-west-1 fortfarande vara i sandbox-läge i us-east-1. Identiteter gäller också per Region, var och en med egna DKIM-poster.

Hämta en adress och skicka ett meddelande

Öppna email-spam-tester.com och kopiera adressen som visas. Den kräver inget konto eller någon API-nyckel och ser ut som test- följt av tjugo tecken på t.email-spam-tester.com. Du har en timme och ett meddelande, så förbered sändningskommandot innan du hämtar adressen.

Det enklaste sättet att skicka är via CLI. Kommandot är anpassat från AWS eget exempel på sidan om SES-klientorganisationer, men flaggorna för klientorganisation och konfigurationsuppsättning har tagits bort:

aws sesv2 send-email \
  --from-email-address "sender@yourdomain.com" \
  --destination "ToAddresses=test-xxxxxxxxxxxxxxxxxxxx@t.email-spam-tester.com" \
  --content "Simple={Subject={Data='Test Subject',Charset=utf-8},Body={Text={Data='Test email body',Charset=utf-8}}}"

From-adressen måste vara en verifierad identitet, även i produktion. En brödtext med enbart text som denna räcker för att testa autentiseringen och IP-adressen, men säger nästan ingenting om innehållet. För ett rättvisande resultat ska du skicka det meddelande som din applikation faktiskt skickar, med dess HTML-del och rubriker. Använd också samma kodväg, oavsett om det är boto3s send_email, ett SMTP-bibliotek eller något annat. Om utskick i produktion använder en konfigurationsuppsättning ska du även lägga till --configuration-set-name här, så att testet körs med samma inställningar.

Inkorgstestet använder samma kommando. Lägg till leverantörernas inkorgar i ToAddresses bredvid testadressen och dess markör i Subject-data. Ett anrop fyller då i två rapporter. Den andra visar i vilken mapp meddelandet hamnade hos Gmail, Outlook, Yahoo och andra leverantörer. Dessa inkorgar är inte heller verifierade, så även detta kräver produktionsåtkomst.

Det går också att använda konsolen. Öppna Configuration > Identities, klicka på identiteten och välj Send test email. Välj Raw om du vill klistra in ett fullständigt MIME-meddelande med egna rubriker. AWS beskriver konsolen som ett verktyg som du vanligtvis bara använder för testmeddelanden, och dokumentationen beskriver inget testprefix eller någon annan ändring av meddelandet. I sandbox-miljön måste fältet Custom recipient innehålla en verifierad adress, vilket för dig tillbaka till problemet ovan.

Så ser en ny SES-identitet ut i rapporten

DKIM. Easy DKIM är standard för domänidentiteter och signerar varje meddelande med en 2048-bitarsnyckel. Konfigurationen består av tre CNAME-poster med namnet token._domainkey.yourdomain.com som pekar på token.dkim.<region>.amazonses.com. Om DKIM-kontrollen misslyckas bör du först kontrollera två saker: om DNS-ändringarna har hunnit slå igenom (AWS anger upp till 72 timmar) och om din DNS-leverantör lade till domänen i namnet och skapade token._domainkey.yourdomain.com.yourdomain.com. Med BYODKIM publicerar du i stället en TXT-post med din egen väljare. Under ett byte mellan de två kan SES skicka helt utan signatur, vilket rapporten markerar som DKIM saknas. DKIM-kontrollen använder tokenvärdet som väljare.

SPF och Return-Path. Som standard använder SES en underdomän till amazonses.com som MAIL FROM. SPF godkänns, men för amazonses.com, så rapporten visar SPF som inte justerad med din From-adress. När DKIM är justerad kostar detta lite (2 poäng på den 100-gradiga skalan i stället för 5), och DMARC godkänns fortfarande genom DKIM. Om du även vill justera SPF konfigurerar du en anpassad MAIL FROM-underdomän med exakt en MX-post, 10 feedback-smtp.<region>.amazonses.com, och en TXT-post, v=spf1 include:amazonses.com ~all. Välj inte en underdomän som tar emot e-post och ta inte med aspf=s i din DMARC-post, eftersom AWS uppger att SPF-justering med SES inte fungerar med en strikt SPF-policy.

DMARC. SES publicerar ingen sådan post åt dig. AWS exempel är v=DMARC1;p=quarantine;rua=mailto:my_dmarc_report@example.com. Om ingen läser dina DMARC-rapporter ännu skulle jag börja med p=none och skärpa policyn senare. DMARC-kontrollen visar vad du har, och DMARC fail beskriver vanliga fel.

List-Unsubscribe. SES lägger endast till List-Unsubscribe och List-Unsubscribe-Post när du skickar med ListManagementOptions som pekar på en kontaktlista och ett ämne. Även då gäller det bara meddelanden till en enda mottagare och endast med Easy DKIM, och SES skriver över eventuella avregistreringshuvuden som du själv har angett. Allt annat skickas helt utan avregistreringshuvuden. För ett nyhetsbrev innebär det att List-Unsubscribe-kontrollen och kontrollen för avregistrering med ett klick misslyckas om du inte själv lägger till dem. Sedan mars 2024 accepterar v2 API anpassade huvuden utan rå MIME. Anpassade från AWS blogginlägg om avregistrering med ett klick ser de två huvudena ut så här:

"Headers": [
  { "Name": "List-Unsubscribe",
    "Value": "<https://yourdomain.com/unsub?address=x&topic=x>, <mailto:unsubscribe@yourdomain.com>" },
  { "Name": "List-Unsubscribe-Post",
    "Value": "List-Unsubscribe=One-Click" }
]

Din slutpunkt måste sedan hantera POST-anropet. Lösenordsåterställningar och kvitton utan listhuvuden är ett annat fall, och för dem markerar rapporten gruppen för massutskick som överhoppad. Läs mer om huvudet på vår sida om List-Unsubscribe.

IP-adresser och blockeringslistor

Nya konton skickar från IP-adresser som delas med andra SES-användare, och AWS rekommenderar att du använder dem om inte din sändningsvolym är stor och regelbunden. Rapporten kontrollerar den sändande IP-adressen mot 21 blockeringslistor. För delade adresser gäller en träff hela IP-poolen. Dedikerade IP-adresser finns som Standard, där du själv värmer upp dem, eller Managed, där SES hanterar uppvärmningen. Då är en listning kopplad till dina egna utskick. Du kan kontrollera alla IP-adresser som visas på fliken Headers direkt med kontrollen av blockeringslistor.

AWS övervakar också ditt konto. I deras vanliga frågor om regelkontroll står det att du ska testa mot riktiga adresser som kan ta emot e-post, eller använda simulatorn, så att påhittade mottagare inte ökar antalet studsar. Ett konto granskas om studsfrekvensen når 5 % eller klagomålsfrekvensen når 0,1 %.

Åtgärdsplanen längst ned listar upp till åtta ändringar, var och en med den DNS-post som ska kopieras när en sådan behövs. Poängen bredvid varje åtgärd är de aktuella avdragen för de kontroller som den påverkar. Modellen väljer och förklarar åtgärder. Den prissätter dem inte. Om ett kontrollnamn inte säger dig något förklaras var och en av de 42 kontrollerna i dokumentationen.