Los recibos personalizados de USAePay requieren un dominio que usted controle. La opción Correo electrónico de la puerta de enlace cambia lo que ven los destinatarios, por lo que los recibos de comerciantes de inventario, las facturas y cualquier correo de socios fluyen por separado. No utilice la transacción real de un cliente como prueba de autenticación ni incluya detalles de pago en servicios de diagnóstico.
Configurar la autenticación de dominio personalizado
Los documentos del proveedor include:spf.usaepay.com para SPF. Agréguelo a la política SPF aplicable existente, antes del mecanismo terminal, en lugar de publicar otro Registro SPF. La guía oficial desaconseja mantener una lista de IP copiada porque las direcciones de los proveedores pueden cambiar.
Para DKIM, crea tres CNAME registros debajo de su dominio de envío: gps1. _domainkey apunta a gps1._default.dkim.safewebservices.com ; gps2 y gps3 siguen el mismo patrón numerado. Reemplace solo su propia parte del dominio de envío, no los destinos del proveedor. La guía dice que las claves públicas gps2 y gps3 son reservas intencionalmente vacías para rotación. Publicar sus delegaciones incluso si un validador clave marca los objetivos vacíos; La aceptación del mensaje de hoy depende de la selector realmente usado. Referencia de configuración de USAePay
El portal ofrece validación SPF y DKIM . Úselo como verificación de configuración y luego inspeccione un recibo de prueba entregado. La documentación dice que la marca personalizada no autenticada puede recurrir a safewebservices.com . Registre la dirección De remitente observada en lugar de asumir que un recibo entregado todavía lleva su marca. Si no puede controlar el dominio deseado, acuerde una identidad de remitente aprobada en lugar de falsificar una dirección de correo web pública.
El proveedor ahora requiere estos registros de autenticación para todos los dominios de envío personalizados, no solo para las campañas masivas. Trate la IP de muestra pública utilizada en un ejemplo de validación antiguo como una ilustración de diagnóstico, no como una prueba de la IP de salida actual o de la identidad del sobre realmente emitida.
Verifique DNS y un resultado de recepción real
Antes de cambiar la configuración del remitente de facturas y recibos comerciales, exporte los valores DNS existentes, registre la diferencia aprobada y nombre el propietario de la reversión. Confirme si el editor DNS espera una etiqueta relativa o un nombre completo; duplicar el sufijo del dominio crea un récord que ningún verificador previsto encontrará. Consulta el nombre del propietario real después de guardar, incluido cualquier objetivo CNAME , en lugar de confiar en el banner de éxito del editor.
SPF debe seguir siendo una política en el dominio relevante y permanecer dentro de los límites del término de consulta DNS en RFC 7208. Agregar una inclusión no establece por sí solo alineación. Bajo RFC 9989, DMARC pasa cuando al menos un resultado SPF o DKIM exitoso se alinea con el dominio De visible en el modo aplicable. No exija que ambos mecanismos se alineen como condición impuesta por el estándar, y no confunda un pase de dominio de proveedor con un pase de dominio de cliente alineado.
Envíe un recibo de prueba inofensivo generado por el flujo de trabajo real del comerciante a un buzón que usted controle. Guarde los resultados de autenticación confiable del sistema receptor, visibles desde, identidad del sobre, valores DKIM d= y s=, marca de tiempo y estado del proveedor. Una búsqueda DNS solo muestra la clave disponible; RFC 6376 La verificación también evalúa la firma del mensaje recibido. Utilice contenido no confidencial y evite exponer mensajes completos de los clientes a verificadores públicos.
Utilice una decisión de aceptación y reversión limitada
Solo caso de diagnóstico escrito ficticio: UP-01 asume que un recibo inofensivo estaba destinado a usar receipts@shop.example pero su origen visible es noreply@safewebservices.com . Se desconocen SPF y todas las identidades/resultados DKIM . La entrega no cumple con el requisito de marca personalizada. El propietario del comerciante debe verificar la identidad de la puerta de enlace y el estado de validación, y el propietario DNS debe comparar las tres delegaciones documentadas antes de realizar una nueva prueba aprobada. Las llaves de reserva vacías por sí solas no establecen una falla del selector activo. Para este ejemplo no se probó ninguna cuenta, DNS , retransmisión o mensaje.
Si la prueba falla, separe DNS faltantes, el selector incorrecto, la configuración del proveedor inactivo, el enrutamiento inesperado y la modificación de mensajes antes de realizar otro cambio. Vuelva a probar el mismo flujo de trabajo después de cada corrección aprobada. No debilite la política DMARC de todo el dominio para ocultar un problema de un solo remitente. Cuando sea necesario realizar una reversión, restaure el enrutamiento anterior aprobado o la configuración del remitente y conserve los registros clave mientras los mensajes firmados en cola aún los necesiten. Guarde las pruebas de prueba y las excepciones no resueltas con el inventario de dominio. No se realizó ningún acceso de inquilino, cambio DNS ni envío real durante la preparación de esta guía.
Mantenga un registro de aceptación responsable
Cree una fila por cuenta, dominio y ruta materialmente diferente. Registre el propietario de la empresa, el propietario DNS , la referencia de cambio, el origen previsto, el origen observado, el dominio del sobre y el resultado SPF , cada DKIM d= y s= con su resultado, modo de alineación aplicable, receptor confiable y marca de tiempo, estado de activación del proveedor, observación de ubicación, pregunta no resuelta y siguiente acción. Marque los valores faltantes como desconocidos en lugar de tratarlos como aprobados o reprobados. El propietario acepta únicamente la ruta prevista y la identidad respaldada por la evidencia registrada; de lo contrario, mantenga esa ruta y siga el plan de recuperación aprobado.
Separar un mensaje pasajero de la preparación para hacer cumplir la ley
RFC 9989 La sección 7.4 requiere DKIM válido para la publicación de un dominio p=reject y advierte sobre la interoperabilidad del correo indirecto. Un único resultado alineado SPF no justifica por sí solo la implementación de una política de rechazo. Revise todas las rutas legítimas y la propiedad de la política por separado de la configuración de este proveedor.