> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt
> Use this file to discover all available pages before exploring further.
# Recepción de correo
> Dirija direcciones de destinatario a temas de Notifications y recupere correos aceptados de forma segura.
Configure la recepción en una identidad de dominio verificada. La configuración de recepción contiene solo `enabled` y `attachments_bucket`. El campo `dns_records` de la identidad contiene instrucciones DNS de envío y recepción, incluido el valor MX completo. Todas las identidades usan las mismas comprobaciones de propiedad e IAM.
## Habilitar la recepción y añadir una regla
Abra Email → **Identities** y seleccione el dominio.
1. En **Settings**, elija un **Attachments bucket** en la tarjeta **Receiving**, active el interruptor y seleccione **Save**. El bucket debe pertenecer a la misma cuenta y región.
2. Abra **Recipient rules** y seleccione **Create rule**. Elija una dirección exacta, un prefijo de dirección o todas las direcciones y seleccione un tema de Notifications de la misma cuenta y región en el selector de recursos.
3. Abra **DNS records** y publique el registro MX de **Receiving records**. **Sending records** contiene los registros usados para verificar y enviar, incluidos los de MAIL FROM personalizado.
La tabla de reglas de destinatario muestra cada tema de destino por nombre. Seleccione una regla para acceder a los controles de eliminación o use su acción de habilitar/deshabilitar. La retención de mensajes y el bucket de adjuntos seleccionado aparecen en los detalles de la identidad sobre las pestañas. Las cuotas de la organización controlan el tamaño de los mensajes y el tráfico.
Envíe `PATCH /v1/identities/{identity_id}/receiving`:
```json theme={null}
{"enabled":true,"attachments_bucket":"incoming-email-files"}
```
Envíe `POST /v1/identities/{identity_id}/recipient-rules`:
```json theme={null}
{"match_type":"exact","local_part":"support","topic":"incoming-mail","enabled":true}
```
Esto dirige `support@example.com` cuando la identidad es `example.com`. Tras configurar la regla, publique el registro MX de `dns_records` de la identidad con `group: "receiving"`.
Guarde las solicitudes JSON de la pestaña API, en orden, como `request-1.json`, `request-2.json`. Establezca `IDENTITY_ID` con el UUID del recurso. Use la cuenta y la región configuradas.
```bash theme={null}
basaltic email identity update-receiving "$IDENTITY_ID" --from-file request-1.json
basaltic email recipient-rule create "$IDENTITY_ID" --from-file request-2.json
```
Guarde las solicitudes JSON de la pestaña API, en orden, como `request-1.json`, `request-2.json`. Establezca `IDENTITY_ID` con el UUID del recurso. Configure las credenciales, la cuenta y la región mediante las variables de entorno del SDK.
```go theme={null}
package main
import (
"context"
"encoding/json"
"fmt"
"os"
basaltic "github.com/basaltic-sh/sdk-go"
"github.com/basaltic-sh/sdk-go/email"
)
func readJSON(path string, value any) error {
data, err := os.ReadFile(path)
if err != nil {
return err
}
return json.Unmarshal(data, value)
}
func run() error {
ctx := context.Background()
cfg, err := basaltic.NewConfig(ctx)
if err != nil {
return err
}
client := email.New(cfg)
var request1 email.UpdateReceivingConfigurationRequest
if err := readJSON("request-1.json", &request1); err != nil {
return err
}
if err := client.UpdateReceivingConfiguration(ctx, os.Getenv("IDENTITY_ID"), &request1); err != nil {
return err
}
var request2 email.CreateRecipientRuleRequest
if err := readJSON("request-2.json", &request2); err != nil {
return err
}
result2, err := client.CreateRecipientRule(ctx, os.Getenv("IDENTITY_ID"), &request2)
if err != nil {
return err
}
fmt.Printf("%+v\n", result2)
return nil
}
func main() {
if err := run(); err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
}
```
Crear una regla requiere `email:CreateRecipientRule` sobre la identidad y `notifications:Publish` sobre el tema de destino. También se aplican las denegaciones de la política del tema. Seleccionar un bucket delega `storage:PutObject` y `storage:GetObject` bajo `email/{identity_id}/` en ese bucket. Siguen aplicándose los permisos IAM actuales, los límites de permisos, las políticas del bucket y las restricciones de la sesión original. Consulte [Permisos](/es/email/permissions).
## Coincidencia de destinatarios
`match_type` define explícitamente el comportamiento de coincidencia:
| Modo | `local_part` | Coincidencia |
| - | - | - |
| `exact` | `support` | Solo `support@example.com`. |
| `prefix` | `reply+` | Direcciones que empiezan por `reply+`. |
| `all` | Omitido o vacío | Cualquier dirección de esta identidad. |
Las reglas exactas tienen prioridad, seguidas del prefijo coincidente más largo y después de la regla general. Solo las reglas habilitadas aceptan destinatarios. Un destinatario sin coincidencia se rechaza durante la entrega SMTP. Puede configurar hasta 100 reglas por identidad.
Las reglas tienen UUID y CRN propios. `POST` crea una regla y devuelve 409 cuando su patrón de coincidencia ya existe. Lea o elimine una regla en `/v1/identities/{identity_id}/recipient-rules/{rule_id}`. Use `PATCH` en esa ruta para cambiar solo los campos proporcionados. Las respuestas de listado incluyen la paginación normal en `meta`. El campo `topic` de la respuesta es un ResourceRef con UUID, CRN y nombre.
El PATCH de configuración también conserva las omisiones. Enviar `attachments_bucket: null` borra el vínculo solo cuando la recepción está deshabilitada. Para deshabilitar y desvincular a la vez, incluya `enabled: false` y `attachments_bucket: null` en la misma solicitud.
## Leer correos aceptados
`GET /v1/received-messages` lista metadatos de toda la cuenta, con filtros opcionales `identity`, `recipient` y `review_reason`. Lea un registro por UUID y solicite `/content`, `/raw` o `/attachments/{attachment_id}` por separado. `/content` devuelve texto y HTML decodificados completos; `/raw` descarga el MIME reconstruido. Los ID de adjuntos son UUID opacos estables. Los metadatos y el contenido requieren permisos separados. Trate el HTML como datos no confiables y sanitícelo antes de renderizarlo.
`identity` es un ResourceRef. `rfc_message_id` en el contenido es la cabecera RFC Message-ID, no el UUID del recurso Email. `notification_status` es `pending`, `retrying` o `published`; `notification_error` proporciona detalles seguros del fallo. La publicación se reintenta automáticamente hasta el vencimiento. Estos campos describen el evento de notificación, no la aceptación SMTP, que ocurrió antes de devolver el mensaje.
`review_reason` puede ser `clear`, `malware`, `spam` o `sender_unverified`. El contenido con malware queda en cuarentena y no puede descargarse mediante la API de contenido. Compruebe `content_available` y `expires_at` antes de intentar recuperarlo. `published_at` indica cuándo se publicó el evento de Notifications, no cuándo terminaron de procesarlo todos los suscriptores.
Los campos `message_id`, `in_reply_to` y `references` del contenido analizado son cabeceras RFC de correo. No son UUID de recursos Basaltic ni ResourceRefs.
## Almacenamiento de adjuntos
Cada adjunto aceptado se almacena como un objeto separado en el bucket seleccionado. Sus metadatos contienen un ResourceRef `bucket`, `key`, `version_id` opcional y `sha256`. Se aplican normalmente los precios, cuotas, cifrado y reglas de ciclo de vida de Storage. No hay una franquicia adicional de almacenamiento de Email ni un límite acumulado de almacenamiento de adjuntos. Un objeto ausente, modificado o eliminado no está disponible para descargar.
Email confirma una entrega SMTP entrante solo después de persistir sus adjuntos y el registro del mensaje. Los fallos de almacenamiento devuelven un fallo SMTP temporal para que el remitente reintente. Los reintentos no cobran una segunda entrega recibida. Los adjuntos con malware nunca se escriben en el bucket del cliente.
Cambiar el bucket afecta a los mensajes nuevos; no mueve objetos existentes. Deshabilitar la recepción conserva el bucket seleccionado y el correo ya aceptado. Borrar `attachments_bucket` con `null` requiere que la recepción esté deshabilitada.
## Cuotas y retención
El contenido de los mensajes enviados y recibidos se conserva **30 días**, incluidos en el precio de envío o recepción. `expires_at` identifica el plazo. Los mensajes vencidos dejan de estar disponibles en las API aunque haya fallado la publicación de la notificación. La limpieza en segundo plano elimina el contenido retenido; pueden permanecer registros operativos de facturación y deduplicación. Los objetos de adjuntos **no** se eliminan al vencer un correo: el propietario del bucket controla su ciclo de vida y paga su almacenamiento.
Las cuotas de la organización se aplican entre cuentas e identidades de cada región:
| Cuota | Valor predeterminado | Significado |
| - | - | - |
| `email/message_size_bytes` | 10 MiB | Correo codificado completo, incluidos los adjuntos; configurable hasta el máximo de 50 MiB del servicio. |
| `email/received_recipients_per_second` | 100 | Entregas aceptadas a destinatarios en una ventana móvil de un segundo; el tráfico excedente recibe un fallo SMTP temporal. |
| `email/sent_recipients_per_second` | 28 | Destinatarios de envío aceptados en una ventana móvil de un segundo. |
| `email/sent_recipients_per_day` | Sin límite | Destinatarios de envío aceptados en 24 horas móviles; una configuración de la organización puede imponer un límite. |
No hay una franquicia diaria de recepción. Un mensaje aceptado para tres destinatarios cuenta como tres entregas recibidas. Los reintentos duplicados se confirman sin volver a contar. SMTP rechaza mensajes que superan la cuota de tamaño de la organización; los fallos temporales de capacidad o dependencias piden al remitente que reintente.
La coincidencia de destinatarios admite 100 reglas por dominio. El análisis MIME tiene límites técnicos de complejidad, independientes de la capacidad de almacenamiento en bytes. La API de contenido devuelve texto y HTML completos dentro de la cuota de tamaño de mensajes de la organización. Recupere adjuntos del bucket o mediante el endpoint de descarga de adjuntos durante la retención.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.