Skip to navigation
Troubleshooting

Why are my emails not showing up?

The most common reason inbound emails go missing is that the sender's domain failed authentication.

Inbound emails are checked for SPF, DKIM, and DMARC authentication. AgentMail drops an email only when it fails DMARC under an enforcing policy (quarantine or reject). An email with no passing mechanism, or a DMARC failure under a none policy, is still delivered and labelled unauthenticated.

AgentMail verifies inbound email using SPF, DKIM, and DMARC authentication before delivering it to your inbox. Emails that fail DMARC under an enforcing policy are dropped to prevent spoofing, phishing, and spam from reaching your agents.

This is the same standard enforced by Gmail, Outlook, Yahoo, and other major email providers.

How inbound authentication works

When an email arrives, AgentMail inspects the SPF, DKIM, and DMARC verdicts computed by Amazon SES, the receiving mail server, and applies these rules in order:

  • The email is dropped when it fails virus scanning, or when DMARC fails and the sender’s published DMARC policy is quarantine or reject, unless a trusted forwarder’s ARC seal vouches for it (see forwarded mail below). A failing SPF or DKIM check on its own never drops an email.
  • The email is delivered with the unauthenticated label when DMARC fails under a none policy, or when none of SPF, DKIM, or DMARC passes (for example because the sender publishes no records). A From header that lists more than one mailbox is also labelled unless its chosen sender mailbox authenticated.
  • Otherwise the email is delivered as authenticated: at least one of SPF, DKIM, or DMARC passed.

The verdicts below are SES’s, written the way authentication_results reports them. SES’s GRAY verdict (nothing to evaluate) surfaces as none.

ScenarioSPFDKIMDMARCResult
Everything passespasspasspassDelivered
One mechanism passes, the rest not evaluatedpassnonenoneDelivered
SPF fails but DKIM and DMARC passfailpasspassDelivered
Nothing to evaluate (no SPF, DKIM, or DMARC records)nonenonenoneDelivered as unauthenticated
Only failures, no DMARC recordfailfailnoneDelivered as unauthenticated
DMARC fails under policy noneanyanyfailDelivered as unauthenticated
DMARC fails under policy quarantine or rejectanyanyfailDropped

Messages received since 2026-09-09 carry the verdicts in the authentication_results field, with spf, dkim, and dmarc each pass, fail, none, or another RFC 8601 result, and spf_domain, dkim_domain, and dmarc_domain naming the domain each verdict is about. A key is absent when SES could not compute it, or when the verdict does not speak for the sender: SPF authenticates the envelope (Return-Path) domain, so spf is kept only when that domain shares an organizational domain with the sender’s domain, and dkim and dmarc are kept only when every From mailbox is on the sender’s domain. The unauthenticated label is the acceptance decision and follows the looser rules above, so the two can disagree: a message whose only pass is an unaligned envelope SPF is delivered without the label while the field shows no pass. Use the label to decide whether AgentMail accepted the message, and the field to see which domain each mechanism authenticated. The Authentication-Results header itself is not included in headers; read this field instead.

Forwarded mail fails DMARC at the receiving hop, because the forwarder’s server is not authorized for the original sender’s domain. AgentMail delivers it as authenticated when a trusted forwarder sealed a valid ARC chain vouching for the original message. For those messages authentication_results reports the verdicts the forwarder recorded for the original message, and arc_sealer names the forwarder. See Get Message for each key. The trusted forwarders are google.com, microsoft.com, outlook.com, and icloud.com; an enforcing DMARC failure forwarded through any other service is dropped.

Emails dropped due to failed authentication are dropped silently, with no bounce-back to the sender. AgentMail’s servers accept the message before checking it, so the sender’s mail server reports successful delivery, but no message is created and no event is sent. To monitor emails delivered as unauthenticated, subscribe to the message.received.unauthenticated webhook or WebSocket event, which requires the label_unauthenticated_read permission on the API key.

Why this matters

Without these checks, anyone could send emails claiming to be from any domain. SPF and DKIM authentication proves that the sending server is authorized to send on behalf of the domain in the From address, while DMARC ties those results to the domain’s published policy. Dropping emails that fail DMARC under an enforcing policy protects your agents from:

  • Spoofing: forged sender addresses impersonating trusted contacts
  • Phishing: malicious emails designed to trick your agent into taking harmful actions
  • Spam: bulk unsolicited email from unverified sources

Diagnosing missing emails

If a sender reports that their email never arrived, check whether their domain’s authentication records are configured correctly:

# check for SPF record
dig TXT example.com +short
# look for a record starting with "v=spf1"

For DKIM, use MXToolbox DKIM Lookup or a similar tool. DKIM records are stored under a selector-specific subdomain (e.g., google._domainkey.example.com), and the selector name varies by email provider, so there is no single DNS query that covers all cases.

You can also use MXToolbox SPF Lookup to verify SPF records online.

If the sender’s domain publishes no SPF, DKIM, or DMARC records, AgentMail still processes the email and marks it unauthenticated. If DMARC fails under an enforcing policy, AgentMail drops the email, and other providers are likely to reject it as well.

What to tell the sender

The sender should configure SPF and/or DKIM on their domain’s DNS and make sure their mail provider includes authentication headers. This is not something you can fix on the AgentMail side, as the records and headers must be set up by the domain owner or their email provider.

  • Add an SPF record to authorize their mail server (e.g., v=spf1 include:_spf.google.com ~all for Google Workspace)
  • Enable DKIM signing through their email provider’s admin console
  • Consider adding a DMARC record for full authentication coverage

Most email providers have setup guides: Google Workspace, Microsoft 365, Amazon SES.

Google Workspace and internal routing

If the sender uses Google Workspace and the AgentMail inbox is on a subdomain of a Google Workspace domain, Google may route the email internally instead of sending it through external MX records. In this case, the email never reaches AgentMail’s servers at all.

For example, if the Google Workspace domain is yourcompany.com and the AgentMail inbox is on agents.yourcompany.com, Google Workspace may intercept emails to agents.yourcompany.com and deliver them internally.

How to fix: In Google Admin Console, go to Apps > Google Workspace > Gmail > Routing and add a routing rule that sends mail for the AgentMail subdomain to the external MX records instead of handling it internally.

Still not receiving emails?

If the sender’s domain does have SPF/DKIM configured and emails are still not arriving:

If none of the above resolves the issue, reach out in our Discord support channel or email support@agentmail.cc.