> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mailglyph.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Receiving emails

> Receive inbound emails at your domain and trigger `email.received` workflows

MailGlyph can receive emails sent to your verified domain and emit an `email.received` event when inbound email is enabled for that domain. You can use this event in workflows for support automation, routing, and custom integrations.

## How it works

When someone sends an email to your domain (for example `support@yourdomain.com`) and inbound email is enabled, MailGlyph:

1. Receives the email through inbound processing
2. Creates or updates a contact for the sender
3. Triggers an `email.received` event for workflows
4. Includes inbound metadata in the event payload

## Set up inbound email

**1. Verify your domain first**

Domain verification is required before inbound processing can be configured. Follow
[Verifying domains](https://docs.mailglyph.com/guides/verifying-domains.md).

**2. Enable Inbound Email in Domains**

Open **Domains** in the dashboard, expand your domain, and turn on the **Inbound Email** switch.

The switch is disabled by default.

**3. Add the inbound MX record**

Open **Domains** in the dashboard, expand your domain, and find the **Inbound Email** DNS section.

Add the record shown there. It uses this pattern:

* **Type**: `MX`
* **Name**: `<your-domain>`
* **Value**: `inbound-smtp.<region>.amazonaws.com`
* **Priority**: `10`

> [!WARNING]
>
> **Multiple MX records**
>
> If you already use MX records for another mailbox provider (for example Google Workspace or Microsoft 365), plan DNS carefully. A domain can only have one effective inbound routing setup.
> Consider using a subdomain (e.g., mail.yourdomain.com) if you need to maintain both services.

**4. Wait for DNS propagation**

DNS changes can take a few minutes up to 48 hours.

```bash theme={null}
dig MX yourdomain.com
```

Confirm the response includes `inbound-smtp.<region>.amazonaws.com`.

## Use `email.received` in workflows

Create a workflow with `email.received` as the trigger to react to inbound mail.
The event is emitted only for domains where **Inbound Email** is enabled.

### Event payload fields

| Field | Type | Description |
| - | - | - |
| `messageId` | `string` | Unique identifier for the received message |
| `from` | `string` | Email address of the sender |
| `fromHeader` | `string` | Full "From" header including display name |
| `to` | `string` | Primary recipient email address |
| `subject` | `string` | Email subject line |
| `timestamp` | `string` | ISO 8601 timestamp when the email was received |
| `recipients` | `string[]` | All recipient email addresses |
| `hasContent` | `boolean` | Whether the email body was captured |
| `body` | `string` | HTML body of the email (or plain text if no HTML is available) |
| `spamVerdict` | `string` | Spam check result (e.g., "PASS", "FAIL") |
| `virusVerdict` | `string` | Virus scan result (e.g., "PASS", "FAIL") |
| `spfVerdict` | `string` | SPF authentication result |
| `dkimVerdict` | `string` | DKIM authentication result |
| `dmarcVerdict` | `string` | DMARC authentication result |
| `processingTimeMillis` | `number` | Time taken to process the email |

You can access these fields in your workflow using variable syntax, for example: `{{event.subject}}`, `{{event.from}}`, or `{{event.body}}`.

### Example: Auto-reply workflow

Here's a simple workflow that sends an automatic reply when an email is received at `support@yourdomain.com`:

1. **Trigger**: `email.received`
2. **Condition**: Check if `{{event.to}}` equals `support@yourdomain.com`
3. **Send Email**:
   * **To**: `{{event.from}}`
   * **Subject**: `Re: {{event.subject}}`
   * **Body**: `Thank you for your message. We have received your email: "{{event.body}}". We'll get back to you soon!`

This workflow reads the incoming email body and includes it in the auto-reply response.

### Example: Forward to webhook

For more advanced processing (like ticket creation or AI analysis), you can forward the email content to your own API:

1. **Trigger**: `email.received`
2. **Webhook**:
   * **URL**: `https://api.yourdomain.com/support/tickets`
   * **Method**: `POST`
   * **Body**:
     ```json theme={null}
     {
       "from": "{{event.from}}",
       "subject": "{{event.subject}}",
       "body": "{{event.body}}",
       "timestamp": "{{event.timestamp}}"
     }
     ```

Your backend receives the full email content and can process it (create a ticket, run AI analysis, etc.).

## Multi-workspace domains

If the same verified domain exists in multiple workspaces, MailGlyph processes inbound mail for each matching workspace and emits separate `email.received` events per workspace.
Each workspace will:

* Create/update the sender as a contact in that workspace
* Trigger the `email.received` event in that workspace
* Run any workflows configured for that event

This allows you to segment inbound email handling across different workspaces if needed.

## Current limitations

* **Catch-all addresses**: MailGlyph receives emails sent to any address at your verified domain (e.g., `anything@yourdomain.com`).
  You can use workflow conditions to route emails based on the to field.
* **Attachments**: Attachments are not stored or exposed.
* **Email size**: The maximum message size limit for inbound emails is 40 MB.

## Security considerations

MailGlyph captures several security verdicts for each incoming email:

* **SPF (Sender Policy Framework)**: Verifies the sender's mail server is authorized
* **DKIM (DomainKeys Identified Mail)**: Validates the email hasn't been tampered with
* **DMARC (Domain-based Message Authentication)**: Combines SPF and DKIM for additional validation
* **Spam verdict**: MailGlyph's spam detection result
* **Virus verdict**: MailGlyph's virus scanning result

You can use these verdicts in workflow conditions to automatically filter or quarantine suspicious emails before processing them.

## Troubleshooting

### Emails not being received

1. **Check DNS propagation**: Verify the MX record is correctly set using `dig MX yourdomain.com`
2. **Check inbound switch**: Ensure **Inbound Email** is enabled for the domain in the **Domains** UI
3. **Verify domain**: Ensure your domain is fully verified in MailGlyph (all DKIM, SPF, and MX records for sending)
4. **Check workflow**: Create a simple test workflow with just an `email.received` trigger and a webhook to verify events are being generated
5. **Check sender**: Try sending from a different email provider as some may cache DNS records

### Duplicate events

If you have the same domain verified in multiple workspaces, you will receive duplicate `email.received` events (one per workspace). This is expected behavior. Use workspace-specific workflows to handle this.

### Security verdicts failing

If incoming emails consistently show failing security verdicts:

* **SPF failures**: The sender's domain may not have SPF configured correctly
* **DKIM failures**: The sender's domain may not have DKIM configured, or the email was forwarded/modified in transit
* **DMARC failures**: The sender fails both SPF and DKIM checks

These are issues with the sender's configuration, not your MailGlyph setup. You can choose to process these emails anyway or filter them using workflow conditions.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.