Recepción de correo

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

Console
API
CLI
Go

Abra Email → Identities y seleccione el dominio.

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

{"enabled":true,"attachments_bucket":"incoming-email-files"}

Envíe POST /v1/identities/{identity_id}/recipient-rules:

{"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.

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.

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.

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.

Primeros pasos

Productos

Plataforma

Ayuda

Recepción de correo

Habilitar la recepción y añadir una regla

Coincidencia de destinatarios

Leer correos aceptados

Almacenamiento de adjuntos

Cuotas y retención

​Habilitar la recepción y añadir una regla

​Coincidencia de destinatarios

​Leer correos aceptados

​Almacenamiento de adjuntos

​Cuotas y retención

Habilitar la recepción y añadir una regla

Coincidencia de destinatarios

Leer correos aceptados

Almacenamiento de adjuntos

Cuotas y retención