La comunicación inmobiliaria combina avisos de transacciones, servicios para inquilinos y operaciones de administración de propiedades. Esas transmisiones pueden estar a cargo de agentes, abogados, propietarios y plataformas subcontratadas que utilizan identidades diferentes. Cree un mapa de remitentes en torno a la relación comercial real y luego aplique comprobaciones de autenticación. No permita que un pase de dominio se convierta en un atajo para aprobar una cuenta bancaria modificada o una instrucción de transacción confidencial.
Preservar el límite de verificación de pago
RFC 9989 admite la validación del uso de un dominio en el correo electrónico. No verifica que un beneficiario de pago sea correcto o que un individuo tenga autoridad para modificar las instrucciones de liquidación. Una cuenta legítima comprometida puede enviar correo autenticado. Para un cambio financiero inesperado, siga el proceso de verificación independiente establecido por la organización utilizando una ruta de contacto previamente confiable, no un número de teléfono proporcionado solo en el mensaje cuestionable.
Esta guía no especifica obligaciones legales de transferencia ni autoriza una transacción financiera. La recomendación de control es mantener separados el diagnóstico de identidad y la aprobación de transacciones para que uno no pueda sustituir silenciosamente al otro.
Mapear la propiedad entre partes
Cree filas de inventario separadas para avisos de transacciones, mensajes de inquilinos y alertas de administración de propiedades. Registre la organización responsable del mensaje, la cuenta del proveedor, el dominio del origen, la identidad del sobre, DKIM dominio y selector, destino de respuesta y propietario de recuperación. Cuando un agente externo envía desde su propio dominio, registre esa relación en lugar de fingir que el mensaje se origina en el dominio del administrador de la propiedad.
Diferenciar un corresponsal legítimo de un proveedor autorizado a enviar utilizando su dominio. Los primeros pueden necesitar verificación de contactos comerciales; este último necesita configuración específica del cliente y evidencia de propiedad. Un nombre de plataforma familiar o una dirección IP compartida no establecen ninguna relación por sí solos.
Separar la identidad de gestión de la autoridad de transferencia
Supongamos que los avisos de transacciones y de inquilinos usan dominios de firma que coinciden con sus respectivos dominios De, pero un aviso de administración usa Desde management.property.example y d=provider.example.net. Incluso suponiendo que la firma se verifique, falla DKIM estricto alineación. Se trata de identidades hipotéticas, no de muestras firmadas suministradas ni de pruebas observadas.
Ahora supongamos que la transferencia de un agente cambia el destino de la respuesta aprobada mientras aún se transmite la firma saliente. Una firma correcta no puede establecer que las respuestas que contienen información del inquilino deban seguir llegando al agente anterior. Verifique la autoridad del sucesor, actualice la ruta aprobada según el plan de cambio y pruebe con registros ficticios no operativos. No exponga datos reales de arrendamiento o transacciones para probar el problema. No se ejecutó ninguna transferencia de propiedad, pago, notificación o cambio de acceso.
Mensajes de prueba sin crear compromisos reales
Utilice un arrendamiento de prueba aprobado o una propiedad ficticia y avisos claramente no operativos. Active el flujo de trabajo dentro de la aplicación real en lugar de enviar una imitación compuesta manualmente. Capture el resultado de recepción confiable, las identidades del remitente, el evento de la aplicación y el tiempo de recepción controlado. Verifique las respuestas y los enlaces por separado, asegurándose de que el destinatario de la prueba no pueda acceder a la información de otro inquilino.
Para avisos de transacciones, la prueba no debe contener instrucciones de pago procesables. En su lugar, verifique que el flujo de trabajo dirija al personal al proceso de aprobación establecido cuando ocurra un cambio sensible. Mantenga la aceptación del propietario de la empresa distinta del resultado de autenticación del administrador de correo. Un servicio puede autenticarse correctamente mientras su contenido o permisos de acceso sigan siendo inaceptables.
Revisar los cambios en el momento de la entrega.
La venta de una propiedad, un cambio de agente administrador o una migración de plataforma pueden dejar activos a los remitentes antiguos y al acceso. Concilie cada remitente con el propietario actual y el propósito antes de conservar o eliminar la autorización. Conserve suficiente historial para explicar un aviso previo mientras sigue las reglas de retención aprobadas. Evite excepciones repentinas en todo el dominio debido a la desalineación de un proveedor; repare la configuración específica y vuelva a realizar la prueba. Cierre el cambio sólo cuando el nuevo propietario acepte la evidencia de ruta y sepa cómo escalar un aviso fallido o sospechoso.
Interpretar la autenticación dentro de sus límites.
RFC 9989 Secciones 4.4 y 5.3.5 distinguir la validez de la firma, la alineación y la completa DMARC veredicto. Una única firma supuesta no alineada no establece la ausencia de otros DKIM alineados ni la aprobación de firmas alineadas. SPF caminos. Para p=reject implementación, las Secciones 7.4 y 8 requieren DKIM válido en lugar de depender únicamente de SPF . La sección 5.4 deja el manejo a la política del destinatario y no valida el contenido comercial del mensaje. Estos límites de protocolo no reemplazan el flujo de trabajo autorizado, el acceso, el tiempo o las verificaciones de destinatarios.