La communication immobilière combine les avis d'opéré, les services aux locataires et les opérations de gestion immobilière. Ces flux peuvent être gérés par des agents, des avocats, des propriétaires et des plateformes externalisées utilisant différentes identités. Créez une cartographie des expéditeurs autour de la relation commerciale réelle, puis appliquez des contrôles d'authentification. Ne laissez pas un passe de domaine devenir un raccourci pour approuver un changement de compte bancaire ou une instruction de transaction sensible.
Préserver la limite de vérification des paiements
RFC 9989 prend en charge la validation de l'utilisation d'un domaine dans le courrier électronique. Il ne vérifie pas qu'un bénéficiaire du paiement a raison ou qu'une personne a le pouvoir de modifier les instructions de règlement. Un compte légitime compromis peut envoyer du courrier authentifié. En cas de changement financier inattendu, suivez le processus de vérification indépendant établi par l'organisation en utilisant un itinéraire de contact préalablement fiable, et non un numéro de téléphone fourni uniquement dans le message douteux.
Ce guide ne précise pas les obligations légales en matière de transfert de propriété ni n'autorise une transaction financière. La recommandation en matière de contrôle est de séparer les diagnostics d’identité et l’approbation des transactions afin que l’un ne puisse pas se substituer silencieusement à l’autre.
Cartographier la propriété entre les parties
Créez des lignes d'inventaire distinctes pour les avis de transaction, les messages des locataires et les alertes de gestion immobilière. Enregistrez l'organisation responsable du message, le compte du fournisseur, le domaine d'origine, l'identité de l'enveloppe, DKIM domaine et sélecteur, répondez à la destination et au propriétaire de la récupération. Lorsqu'un agent externe envoie depuis son propre domaine, enregistrez cette relation plutôt que de prétendre que le message provient du domaine du gestionnaire immobilier.
Différenciez un correspondant légitime d'un fournisseur autorisé à envoyer en utilisant votre domaine. Le premier peut avoir besoin d’une vérification des contacts professionnels ; ce dernier nécessite une configuration spécifique au client et des preuves de propriété. Un nom de plate-forme familier ou une adresse IP partagée n’établit aucune relation en soi.
Séparer l’identité de gestion de l’autorité de transfert
Supposons que les avis de transaction et de locataire utilisent des domaines de signature correspondant à leurs domaines From respectifs, mais qu'un avis de gestion utilise From management.property.example et d=provider.example.net. Même en supposant que la signature soit vérifiée, elle échoue DKIM strict alignement. Il s’agit d’identités hypothétiques, non fournies de spécimens signés ni de tests observés.
Supposons maintenant qu'un transfert d'agent modifie la destination de réponse approuvée alors que la signature sortante est toujours transmise. Une signature correcte ne peut pas établir que les réponses contenant des informations sur le locataire doivent continuer à parvenir à l'ancien agent. Vérifiez l'autorité du successeur, mettez à jour l'itinéraire approuvé dans le cadre du plan de modification et testez avec des enregistrements fictifs non opérationnels. N’exposez pas les données réelles de location ou de transaction pour prouver le problème. Aucun transfert de propriété, paiement, avis ou changement d'accès n'a été effectué.
Tester les messages sans créer de réels engagements
Utilisez une location test approuvée ou une propriété fictive et des avis clairement non opérationnels. Déclenchez le flux de travail dans l’application réelle plutôt que d’envoyer une imitation composée manuellement. Capturez le résultat de réception fiable, les identités de l’expéditeur, l’événement d’application et l’heure de réception contrôlée. Vérifiez les réponses et les liens séparément, en vous assurant que le destinataire du test ne peut pas accéder aux informations d'un autre locataire.
Pour les avis d’opéré, le test ne doit pas contenir d’instructions de paiement exploitables. Vérifiez plutôt que le flux de travail dirige le personnel vers le processus d'approbation établi lorsqu'un changement sensible se produit. Conservez l'acceptation du propriétaire de l'entreprise distincte du résultat de l'authentification de l'administrateur de messagerie. Un service peut s'authentifier correctement alors que son contenu ou ses autorisations d'accès restent inacceptables.
Examiner les modifications lors du transfert
Une vente de propriété, un changement d’agent de gestion ou une migration de plateforme peuvent laisser les anciens expéditeurs et accès actifs. Rapprochez chaque expéditeur avec le propriétaire et l’objectif actuels avant de conserver ou de supprimer l’autorisation. Conservez suffisamment d’historique pour expliquer un préavis tout en suivant les règles de conservation approuvées. Évitez les exceptions soudaines à l'échelle du domaine en cas de désalignement d'un fournisseur ; réparer la configuration spécifique et retester. Clôturez la modification uniquement lorsque le nouveau propriétaire accepte la preuve de l'itinéraire et sait comment faire remonter un avis d'échec ou suspect.
Interpréter l’authentification dans ses limites
RFC 9989 sections 4.4 et 5.3.5 distinguer la validité de la signature, l'alignement et l'intégralité DMARC verdict. Une seule signature supposée non alignée n'établit pas l'absence d'autres DKIM alignés ou alignés de passage SPF chemins. Pour p=reject Pour le déploiement, les sections 7.4 et 8 nécessitent DKIM valide plutôt que de s'appuyer uniquement sur SPF . La section 5.4 laisse la gestion à la politique du destinataire et ne valide pas le contenu commercial du message. Ces limites de protocole ne remplacent pas les contrôles autorisés du flux de travail, de l'accès, du timing ou des destinataires.