> For clean Markdown content of this page, append .md to this URL. For the complete documentation index, see https://www.agentmail.to/docs/llms.txt.

# Why are my emails not showing up?

> **Warning**
>
> **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`.

| Scenario                                             | SPF  | DKIM | DMARC | Result                         |
| ---------------------------------------------------- | ---- | ---- | ----- | ------------------------------ |
| Everything passes                                    | pass | pass | pass  | Delivered                      |
| One mechanism passes, the rest not evaluated         | pass | none | none  | Delivered                      |
| SPF fails but DKIM and DMARC pass                    | fail | pass | pass  | Delivered                      |
| Nothing to evaluate (no SPF, DKIM, or DMARC records) | none | none | none  | Delivered as `unauthenticated` |
| Only failures, no DMARC record                       | fail | fail | none  | Delivered as `unauthenticated` |
| DMARC fails under policy `none`                      | any  | any  | fail  | Delivered as `unauthenticated` |
| DMARC fails under policy `quarantine` or `reject`    | any  | any  | fail  | Dropped                        |

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](/api-reference/inboxes/messages/get) 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.

> **Warning**
>
> 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:

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

For DKIM, use [MXToolbox DKIM Lookup](https://mxtoolbox.com/dkim.aspx) 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](https://mxtoolbox.com/spf.aspx) 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](https://support.google.com/a/answer/33786), [Microsoft 365](https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-spf-configure), [Amazon SES](https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-spf.html).

## 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:

* Verify your domain's MX records are correctly pointing to AgentMail (see [MX record conflicts](/knowledge-base/mx-record-conflicts))
* Check that your domain is fully verified in the [AgentMail Console](https://console.agentmail.to)
* Make sure you are listening for incoming emails via [webhooks or WebSockets](/knowledge-base/handling-inbound-emails)

If none of the above resolves the issue, reach out in our [Discord](https://discord.com/invite/hTYatWYWBc) support channel or email [support@agentmail.cc](mailto:support@agentmail.cc).