Real-estate communication combines transaction notices, tenant services and property-management operations. Those streams may be run by agents, solicitors, landlords and outsourced platforms using different identities. Build a sender map around the actual business relationship, then apply authentication checks. Do not let a domain pass become a shortcut for approving a changed bank account or a sensitive transaction instruction.
Preserve the payment-verification boundary
RFC 9989 supports validation of a domain's use in email. It does not verify that a payment beneficiary is correct or that an individual has authority to alter settlement instructions. A compromised legitimate account can send authenticated mail. For an unexpected financial change, follow the organisation's established independent verification process using a previously trusted contact route, not a phone number supplied only in the questionable message.
This guide does not specify legal conveyancing duties or authorise a financial transaction. The control recommendation is to keep identity diagnostics and transaction approval separate so that one cannot silently substitute for the other.
Map ownership across parties
Create separate inventory rows for transaction notices, tenant messages and property-management alerts. Record the organisation responsible for the message, vendor account, From domain, envelope identity, DKIM domain and selector, reply destination and recovery owner. When an external agent sends from its own domain, record that relationship rather than pretending the message originates from the property manager's domain.
Differentiate a legitimate correspondent from a supplier authorised to send using your domain. The former may need business-contact verification; the latter needs customer-specific configuration and ownership evidence. A familiar platform name or shared IP address does not establish either relationship by itself.
Separate management identity from handover authority
Suppose transaction and tenant notices use signing domains matching their respective From domains, but a management notice uses From management.property.example and d=provider.example.net. Even assuming that signature verifies, it fails strict DKIM alignment. These are hypothetical identities, not supplied signed specimens or observed tests.
Now suppose an agent handover changes the approved reply destination while the outgoing signature still passes. A correct signature cannot establish that replies containing tenant information should continue to reach the former agent. Verify the successor’s authority, update the approved route under the change plan and test with non-operative fictional records. Do not expose actual tenancy or transaction data to prove the issue. No property transfer, payment, notice or access change was executed.
Test messages without creating real commitments
Use an approved test tenancy or fictitious property and clearly non-operative notices. Trigger the workflow inside the actual application rather than sending a manually composed imitation. Capture the trusted receiving result, sender identities, application event and controlled receipt time. Check replies and links separately, ensuring the test recipient cannot access another tenant's information.
For transaction notices, the test should not contain actionable payment instructions. Instead, verify that the workflow directs staff to the established approval process when a sensitive change occurs. Keep the business owner's acceptance distinct from the mail administrator's authentication result. A service can authenticate correctly while its content or access permissions remain unacceptable.
Review changes at handover
A property sale, managing-agent change or platform migration can leave old senders and access active. Reconcile each sender with the current owner and purpose before retaining or removing authorisation. Preserve enough history to explain a prior notice while following approved retention rules. Avoid sudden domain-wide exceptions for one vendor's misalignment; repair the specific configuration and retest. Close the change only when the new owner accepts the route evidence and knows how to escalate a failed or suspicious notice.
Interpret authentication within its limits
RFC 9989 Sections 4.4 and 5.3.5 distinguish signature validity, alignment and the complete DMARC verdict. A single assumed unaligned signature does not establish the absence of other aligned DKIM or passing aligned SPF paths. For p=reject deployment, Sections 7.4 and 8 require valid DKIM rather than relying only on SPF. Section 5.4 leaves handling to receiver policy and does not validate the message’s business content. These protocol boundaries do not replace authorized workflow, access, timing or recipient checks.