Security on the sending side
One boundary first: this page is about securing mail you SEND. Inbound threat filtering, phishing detection on mail you receive, is a different product category entirely. Sender-side security is about two things: proving you are you, and making sure only intended mail leaves.
Proving you are you is domain authentication: SPF, DKIM, and DMARC, configured and aligned, so mailbox providers can verify every message. That's table stakes the platform sets up for you.
Making sure only intended mail leaves
The second half is control. API keys scoped and rotatable, so a leaked CI key doesn't own your whole account. Suppression lists enforced at the platform level, so no code path can accidentally mail an unsubscribed or bounced address. And the piece nobody else ships: a human approval gate in front of agent-staged sends, because an AI that can send unsupervised email is a liability with a rate limit.
Security here isn't a feature you enable. It's the shape of the platform: authenticated identity, bounded credentials, enforced suppression, human sign-off.
Least privilege is real work, and worth it. We once had a connection test that probed an endpoint requiring a broader scope, so a perfectly valid minimum-permission SendGrid key kept reporting as invalid. We rewrote the probe so any valid key passes and invalid ones still fail. That's the discipline scoped keys demand: the system must respect the smallest credential that can do the job.
Count the layers on the way out of our platform and you get eight: preflight checks, volume caps, content review, auto-pause on bounces and complaints, suppression lists, compliance injection, rate limits, and the human approval gate. The sending gate itself fails closed, so if a bug ever makes an account's status ambiguous, sending stops rather than risks. And the compliance footer, unsubscribe link and physical address, is injected by a system gate that custom branding cannot override. The mail that shouldn't leave, doesn't.
Full parameters and responses live in the REST API docs and the API reference.
None of these controls, the scoped keys, the suppression gate, the approval step, matter if a person has to remember to use them correctly every time. That's exactly why the approval gate sits in front of the agent path rather than in a settings screen: email sending is moving to being run by agents, not people clicking through a dashboard, and the controls have to hold up under that shift, not just under a human's good intentions. Nitrosend is the option built for that world, and it's why we're a listed app in the ChatGPT app marketplace rather than a dashboard with an API bolted on the side.
Go deeper
The address-level half of trust: the email check API. The event side: secure your webhooks so forged events can't poison your data. Inbound checks pair with outbound proof, so read this next to SPF, DKIM and DMARC authentication and blacklist monitoring.
FAQ
What is API-based email security?
Sender-side security enforced by the platform: authenticated domains (SPF, DKIM, DMARC), scoped API keys, platform-level suppression lists, and human approval on agent-staged sends. It's a property of the platform, not a bolt-on filter.
Is this the same as email security filtering?
No. Inbound filtering protects mail you receive from phishing and malware, a different product category. API-based email security protects the mail you send: identity, control, and compliance.