Skip to content
AgentMail
AgentMail
Extras

Security and compliance

AgentMail's SOC 2 compliance, email authentication, and spam and virus protection.

How AgentMail protects your data and your mail: SOC 2 Type I and Type II compliance, the email authentication protocols behind every domain, and the automatic scanning applied to every inbound message. For procurement, legal, or security-review requests, see Requesting documents at the end of this page.

SOC 2 compliance

AgentMail has achieved SOC 2 Type I (July 2025) and Type II (Q1 2026) compliance.

Current status

Type I Achieved

Completed July 2025 - Controls properly designed and in place

Type II Achieved

Completed Q1 2026 - Operational effectiveness validated over time

PhasePeriodStatus
Type I PreparationJune 2025Completed
Type I AssessmentJuly 2025Completed
Type II Observation PeriodAug 2025 - Dec 2025Completed
Type II CertificationQ1 2026Completed

What is SOC 2?

SOC 2 is an attestation standard by AICPA (The American Institute of Certified Public Accountants) evaluating controls over:

  1. Security - Protection against unauthorized access, both physical and logical
  2. Availability - System accessibility and operational performance as committed
  3. Processing Integrity - System processing is complete, valid, accurate, timely, and authorized
  4. Confidentiality - Information designated as confidential is protected
  5. Privacy - Personal information is collected, used, retained, disclosed, and disposed per privacy commitments

There are two report types:

  • Type I: Verifies that security controls are properly designed at a point in time.
  • Type II: Validates that controls operate effectively over a period (typically 6–12 months).

AgentMail’s SOC 2 Type I and Type II reports confirm that our security infrastructure is properly designed, implemented, and operates effectively over time.

Security controls implemented

The following controls have been audited and verified as part of our SOC 2 Type I & Type II compliance:

Access control

  • Role-based access; least privilege enforced
  • MFA (Multi-Factor Authentication) for administrative access and sensitive operations
  • Quarterly access reviews and revocation upon role change

Encryption & key management

  • TLS 1.2+ for all service/API communications
  • Data at rest encrypted using industry-standard ciphers
  • Centralized KMS (Key Management Service) for key generation, rotation, and revocation
  • Encrypted point-in-time backups with 30-day retention

See Security Overview for more details.

Email authentication & anti-abuse

  • SPF, DKIM, DMARC configured across all sending domains
  • Real-time scanning of inbound/outbound messages for malware/phishing
  • IP-based rate limiting and behavioral abuse detection

See Email authentication below for technical details.

Monitoring & incident response

  • Centralized logging and anomaly detection with alerting
  • Documented incident response process: detect → triage → contain → eradicate → recover → post-incident review
  • Responsible disclosure channel for external security researchers

Resilience, backup & recovery

  • Daily encrypted backups with 30-day retention
  • Regular restore tests to validate RTO/RPO targets
  • Multi-AZ/high-availability architecture for critical components

SOC 2 control mapping

Control AreaImplementationSOC 2 Criteria
Access ControlRBAC, MFA, quarterly reviewsCC6.1–CC6.7
Encryption & KMSTLS 1.2+, at-rest encryption, key rotationCC6.8–CC6.9
Email AuthenticationSPF/DKIM/DMARC, anti-abuse filtersCC7.1–CC7.4
Threat MonitoringCentralized logs, alerts, malware scanningCC7.2–CC7.4
Backup & RecoveryDaily backups, 30-day retention, restore testsCC7.3
Incident ResponseRunbooks, post-mortems, disclosure programCC7.4–CC7.5
Workforce SecuritySecurity training, NDAs, background checksCC5.3–CC5.4

The above mappings reflect our audited Type I and Type II controls.

Type II certification

AgentMail completed the Type II observation period (August 2025 - December 2025) and received full SOC 2 Type II certification in Q1 2026 from an independent CPA firm.

What was validated:

  • Continuous Operation: Controls functioned consistently without gaps
  • Change Management: Security maintained through system updates and changes
  • Evidence Collection: Logs, tickets, training records, access reviews
  • Incident Handling: Real-world response to security events

SOC 2 Type II certification provides the highest level of assurance that AgentMail’s security controls are not only well-designed but also operate effectively over time.

Email authentication (SPF, DKIM, DMARC)

When you add a custom domain to AgentMail, we ask you to add several records to your DNS settings. We understand that this can seem daunting, and we want to be completely transparent about what these records are and why they are necessary.

In short, by adding these records, you are giving AgentMail permission to do two things:

  1. Send emails on your behalf that are trusted and pass spam filters.
  2. Receive emails for you so your agents can process them.

This process is standard practice for any third-party email service, and it does not give us control over your website or any other part of your domain. Let’s break down what each piece does.

To prevent spam and phishing, the modern email ecosystem relies on these three core technologies. Our goal is to handle all the complexity of these protocols for you. Your DNS records are simply the way you tell the world that you’ve authorized us to do so.

SPF: Sender Policy Framework

  • What it is: Think of SPF as a public list of all the servers that are allowed to send email for your domain.
  • How it works: You add a TXT record to your DNS that lists the approved IP addresses or domains. When an email server receives a message from you@your-domain.com, it checks the SPF record for your-domain.com. If the server that sent the email is on that list, the check passes.
  • Your Record:
    TXT | mail.domain.com | v=spf1 include:amazonses.com -all
    This record tells the world that AgentMail is an authorized sender for the mail.domain.com subdomain. AgentMail sends through Amazon SES, which is why the record authorizes amazonses.com rather than an AgentMail hostname. The -all part suggests that any server not on this list should be considered unauthorized.

DKIM: DomainKeys Identified Mail

  • What it is: DKIM is like a digital signature for your emails. This signature proves two things: that the email actually came from your domain and that its content hasn’t been messed with in transit from you to who you are trying to send to.
  • How it works: We generate a unique, secure key for your domain. When we send an email, we “sign” it with this key. The public part of that key is published in your DNS. Receiving servers use this public key to verify the signature.
  • Your Records:
    TXT | agentmail._domainkey.example.com | v=DKIM1; k=rsa; p=MIIB...
    AgentMail gives you a custom DKIM selector host and TXT value. Publishing the key directly at that selector gives receiving servers a precise public key to verify signatures from your domain.

Legacy orgs should keep existing working DNS records in place. For new domain setup, add the TXT selector records AgentMail returns.

DMARC: Domain-based Message Authentication, Reporting, and Conformance

  • What it is: DMARC is the policy that ties SPF and DKIM together. It tells receiving email servers what to do if an email claims to be from you but fails the SPF or DKIM checks (or both).
  • How it works: You publish a TXT record that specifies your policy. You can tell servers to reject the message, quarantine it (mark as spam), or do nothing. It also allows you to get reports on which emails are passing and failing these checks.

We typically tell servers to reject the message as this increases deliverability.

  • Your Record:
    TXT | _dmarc.domain.com | v=DMARC1; p=reject; rua=mailto:dmarc@agentmail.to
    This policy tells servers to reject any email that fails authentication. The rua tag specifies that aggregate reports about these failures should be sent to dmarc@agentmail.to, allowing us to monitor your domain’s health and deliverability on your behalf.

Receiving mail: the MX records

Finally, MX (Mail Exchange) records tell the internet where to deliver your agents’ email.

  • What they are: MX records are the post office address for your domain’s email.
  • How they work: When someone sends an email to your-agent@your-domain.com, their mail server looks up the MX record for your-domain.com to find out where to send it.
  • Your Records:
    MX | domain.com | 10 inbound-smtp.us-east-1.amazonaws.com
    MX | mail.domain.com | 10 feedback-smtp.us-east-1.amazonses.com
    The hostnames are AWS ones because AgentMail’s mail infrastructure runs on Amazon SES. The first record directs all incoming mail for your domain to our servers, so we can ingest it and trigger your agents. The second feedback-smtp record is specifically for routing automated feedback, like bounce and complaint notifications from other mail servers, which is crucial for maintaining a healthy sender reputation.

Spam and virus detection

AgentMail automatically scans every inbound message for spam and viruses before it reaches your inbox. This happens transparently; there is nothing you need to configure.

Virus detection

Emails that contain viruses or malware are rejected at the gateway and are never stored. Your inboxes will never contain a message flagged as infected. This protects your agents from processing potentially dangerous content.

Spam detection

Emails identified as spam are still stored in your inbox so you never lose a message that might be a false positive. However, they are excluded from API results by default to keep your agent’s workflow clean.

When you call the List Threads or List Messages endpoint, spam messages are filtered out unless you explicitly request them.

Accessing spam threads

To include spam in your results, pass the include_spam (includeSpam in TypeScript) parameter when listing threads.

# list threads including spam
agentmail inboxes:threads list \
  --inbox-id <id> \
  --include-spam

Each thread object includes a spam label indicating whether it was flagged as spam, so you can handle flagged threads differently in your application logic.

Example spam thread
{
  "thread_id": "thread_abc123",
  "subject": "You have won a prize!",
  "labels": ["spam"],
  "from": "suspicious@example.com",
  "to": ["your-agent@your-domain.com"]
}

Requesting documents

Organizations evaluating AgentMail can request compliance and legal documentation:

Was this page helpful?Suggest editsRaise issue