Using Amazon SES? Don't rewrite your code. Just change the endpoint and key to MailGuard's — the AWS SigV4 signature is verified on our side, and your existing boto3/SDK keeps working as-is. Your data is in Turkey, your invoice is in TL, and your support is local.
MailGuard is fully compatible with the Amazon SES v2 SendEmail call and verifies the AWS SigV4 signature. That means you don't rewrite your existing SES integration: in the SDK client you only need to change the endpoint_url and the key.
# Your Amazon SES code — only 2 lines change import boto3 ses = boto3.client("sesv2", endpoint_url="https://email.mailguard.com.tr", # ← the only change aws_access_key_id="AKIA…", # from the MailGuard panel aws_secret_access_key="…", region_name="eu-central-1") # Your sending code DOES NOT CHANGE: ses.send_email( FromEmailAddress="hello@yourcompany.com", Destination={"ToAddresses": ["customer@example.com"]}, Content={"Simple": {"Subject": {"Data": "Hello"}, "Body": {"Text": {"Data": "Test message"}}}})
The same applies to the other AWS SDKs (JavaScript, PHP, .NET, Go…) — any SDK that signs with SigV4 works. With Content.Raw (base64 MIME) you can also send attachments and custom headers. For detailed examples, see the docs.
SES is technically powerful, but your data is kept abroad, your invoice is in foreign currency, and your support is remote. MailGuard offers the same developer experience — the same SDK, the same signature — with data in Turkey, KVKK compliance and local support. On top of that, inbound filtering and SMTP relay, which SES does not cover, are on the same platform.
endpoint_url + key in your SDK client — leave your sending code untouched.relay.mailguard.com.tr:587 SASL.| MailGuard | Amazon SES | |
|---|---|---|
| Code change | Only endpoint + key | — |
| SDK compatibility | Same boto3/SDK (SigV4) | boto3/SDK |
| Data location | Turkey data center | US / EU regions |
| KVKK compliance | Full compliance | Requires cross-border transfer |
| Billing | TL + e-invoice | USD |
| Support | Local, Turkish | Remote / English |
| DKIM signing | Automatic (we sign) | You set it up |
| Inbound spam/virus filtering | Included (MX routing) | None (outbound only) |
| SMTP relay | Included (same account) | Included |
| Suppression + webhook | Included (panel + API) | Included |
endpoint_url to https://email.mailguard.com.tr and use the key that MailGuard provides. The SigV4 signature is verified on our side and your sending code works as-is./v2/email/outbound-emails). Both Simple (subject/body) and Raw (base64 MIME — attachments, custom headers) content are supported.relay.mailguard.com.tr:587 (STARTTLS) / 465 (SSL) with SASL. The API and SMTP work on the same account.We clearly saw the improvement in delivery rates, especially on bulk email campaigns.
A great solution I would recommend to anyone dealing with mail delivery problems.
The integration was far easier than we expected. The whole system runs flawlessly.
A great solution that met our expectations on both security and delivery.
Let's talk through your existing SES integration, your volume and your requirements, and map out a migration plan tailored to you. The code doesn't change; the endpoint and key do.
Get a QuoteAn SES-compatible API is an email sending service that mirrors Amazon SES's sending interface (SendEmail v2 + AWS SigV4 signature) exactly. Its purpose is to let teams already using SES move to a different provider without rewriting their application code, by changing only the endpoint and the credential key.
MailGuard provides this compatibility by verifying the SigV4 requests signed by existing AWS SDKs and connecting them to its own delivery infrastructure (DKIM signing, reputation-managed IP pools, suppression and quota). This way, SES-specific code, libraries and workflows are preserved exactly; only the delivery and data layer changes.
This approach is especially suitable for SaaS, e-commerce and enterprise teams that have a data-residency (KVKK) obligation in Turkey and want to avoid foreign-currency billing and remote support. Your transactional emails (sign-up confirmations, password resets, order notifications) are sent with the same code from a local, compliant infrastructure.