Why real estate email lands in spam, and the complete fix — authentication in plain English, sending domains, list hygiene, bounce triage, and how to tell a broken setting from a broken foundation.
Real estate email fails for structural reasons, not mysterious ones.
Every receiving system scores three things before deciding where your message lands: whether you can prove the mail is really from you, what your domain's sending history looks like, and how recipients react when it arrives. Real estate businesses tend to score badly on all three — almost always for the same short list of reasons.
Bulk listing sends from your working address. Just-listed, just-sold, and open-house blasts go to the entire database at once — image-heavy, link-heavy, from the same address that carries your contracts. One campaign that draws complaints damages the address you close deals with.
Transactions are relay races. A single deal forwards through the agent, the coordinator, the lender, title, and the client. Each forward re-sends your message from a server you don't control, which breaks SPF and can break DKIM when a system appends a footer or rewrites the body.
Lookalike and single-listing domains. Agents buy a domain per property, teams register three spellings of the brand, brokerages accumulate variants. New domains have zero sending history — and real estate is a heavily targeted industry for wire-fraud impersonation, so filters and recipients are already primed to distrust unfamiliar property-and-title-sounding domains.
Consumer accounts doing business work. A free consumer mailbox gives you no control over authentication, no domain reputation of your own, and no administrative visibility when something breaks.
Databases nobody prunes. Portal leads, open-house sign-in sheets, an exported sphere list from a brokerage you left three years ago. Old addresses go dead, get recycled, and eventually become spam traps.
Several platforms sending as you at once. Your mail tenant, your CRM, your e-signature tool, your transaction platform, a marketing app somebody set up years ago. If they aren't all authorized and aligned, some share of your mail is unverifiable by definition.
3 Rules
Prove who you are. Separate what you send. Only mail people who expect it. Nearly every real deliverability fix is one of those three — everything below is the detail.
Authentication
SPF, DKIM and DMARC, in Plain English
Three DNS records. They are not interchangeable, they do genuinely different jobs, and the one most setups get wrong is the relationship between them.
SPF — who is allowed to send
A public list, published in your domain's DNS, of the mail servers permitted to send on your behalf. The receiver checks the IP a message actually arrived from against that list. Two rules people break constantly: you may publish only one SPF record per domain — two records means neither is trusted — and the record is capped at a fixed number of DNS lookups. Stack enough include: entries for every tool you've ever connected and it silently exceeds the cap and starts failing. SPF also breaks on forwarding, by design, because the forwarding server isn't on your list.
DKIM — proof the message is really yours
Your sending platform signs each outgoing message with a private key and publishes the matching public key in your DNS. The receiver verifies the signature and learns two things: the message came from a system holding your key, and the signed parts weren't altered in transit. DKIM survives most forwarding — which is exactly why it matters more than SPF in a business where every thread gets passed along. Each platform sending as you needs its own key published; one DKIM record does not cover the others.
DMARC — what happens when those fail
A policy record telling receiving systems what to do with mail that claims to be from your domain but can't prove it: none (deliver, but report), quarantine (junk it), or reject (refuse it outright). DMARC is also the only one of the three that reports back. Point it at an address you actually read and you get a rolling inventory of everything sending as your domain — including the tools you forgot about and anyone impersonating you.
Alignment — the part most setups miss
DMARC doesn't just want SPF or DKIM to pass. It wants the passing domain to match the domain your recipient sees in the From line. This is where marketing platforms quietly fail: the mail passes SPF, but it passes for the platform's own domain, not yours, so DMARC still considers it unauthenticated. If your campaigns are failing and the records look fine, alignment is the first thing to check.
How to actually roll this out
Inventory first. Write down every system that sends mail using your domain — mail tenant, CRM, e-signature tool, accounting software, website contact form, scheduler. You cannot authenticate a list you haven't made. Then publish one consolidated SPF record covering exactly those systems, add a DKIM key for each platform that supports signing, and publish DMARC at p=none with a reporting address.
Then wait and read. Aggregate reports will surface sources you didn't expect — that is the entire point of starting at none. Fix or remove each one until every legitimate source passes and aligns. Only then move to quarantine, watch again, and finally to reject. Rushing to reject on a domain you haven't audited doesn't harden your email; it quietly deletes mail you didn't know you were sending.
One note on the receiving side: the major mailbox providers have tightened requirements for anyone sending at volume. Authentication, a working one-click unsubscribe on bulk mail, and a spam-complaint rate under their published threshold are now table stakes. Read the current sender guidelines from Google and Yahoo directly rather than trusting a number in a blog post — they are the only authoritative source for their own thresholds, and those thresholds move.
Sending Identity
Your Domain Is the Asset. Protect It Accordingly.
A consumer mailbox is not a business sending identity. You can't publish authentication for a domain you don't own, you inherit whatever reputation that provider's shared infrastructure has today, and if the account is ever restricted you have no administrative path to fix it. Every serious deliverability decision starts with sending from a domain you control.
Owning the domain is the floor. The next decision matters just as much: don't send everything from the same place. Reputation is tracked at the domain level, so mixing a promotional blast into the address that carries your purchase agreements means one bad campaign degrades both. Split them.
Primary domain — human mail only. One-to-one client conversation, transaction threads, referrals, vendor coordination. This is the address that must never fail to deliver, and its reputation is built by real people replying to real messages.
A marketing subdomain — everything bulk. Newsletters, listing announcements, drip sequences, nurture campaigns. It inherits your organizational credibility while building and carrying its own reputation, so a bad campaign is contained.
Never a per-listing domain. Single-property domains are fine as a landing page that redirects to your site. Sending mail from one throws away every bit of reputation you've built and hands the receiver a brand-new domain that looks exactly like a fraud pattern.
Warm anything new. A fresh domain or subdomain with no history that suddenly emits thousands of messages looks precisely like a compromised account. Start with your most engaged contacts, in small batches, and increase volume gradually over weeks.
This is also the point where the Microsoft 365 foundation stops being an IT detail and starts being a deliverability decision. A properly provisioned tenant gives you DNS you control, per-user identity, DKIM signing you can manage, and an admin console that tells you when a mailbox is compromised or your organization has been restricted from sending. We go deeper on that foundation in our guide to Microsoft 365 for real estate, and on how the pieces fit together on what we build and manage.
Lists & Consent
Most Spam Problems Are List Problems
Receiving systems learn far more from how people respond to your mail than from anything in your DNS. Opens, replies, moving a message out of junk, and adding you to contacts are positive signals. Deletes without opening, complaints, and bounces are negative. A large old list mails mostly to the second group.
The uncomfortable truth for most real estate databases: a smaller, engaged list delivers better and produces more business than a large stale one. The rules are simple and unglamorous.
Send only to people who gave you their address for this. A sign-in sheet, an inquiry, a signed client relationship. Not a scraped list, not a purchased list, not an export from a brokerage you no longer work at.
Remove hard bounces immediately. A permanent failure means the address is gone. Mailing it again is a direct signal that you don't maintain your list.
Sunset the silent. If someone hasn't opened or clicked in a long stretch, send one clear re-engagement message and then stop mailing them. Dead addresses get recycled into spam traps, and hitting a trap is one of the fastest ways to get filtered.
Make unsubscribing trivial. A visible one-click unsubscribe that works immediately is protective. When people can't find the exit, they use the spam button instead — and that button is far more damaging than an opt-out.
Segment before you send. Past clients, active buyers, active sellers, and cold sphere want different mail. Sending everyone the same blast guarantees most of it is irrelevant to most of the list.
Never buy a list. There is no version of this that ends well. Purchased lists are dense with traps and complaints, and the damage lands on the domain you use to close deals.
On the legal side: US commercial email falls under the CAN-SPAM Act, which broadly requires accurate headers and non-deceptive subject lines, identification of commercial messages, a valid physical postal address, and a working opt-out honored promptly. State rules and your brokerage's advertising policy may add more. Read the FTC's own guidance and talk to your broker or counsel rather than a vendor's summary — this page is operational guidance, not legal advice. Texting carries a separate and stricter regime, covered in our guide to real estate texting compliance.
Triage
What to Check First When a Send Starts Failing
Work in this order. Most people start at step five, changing settings at random, and never establish what actually broke.
1
Separate bouncing from filtering
Different failures, different fixes. A bounce means the receiving server refused the message and told you so. Filtering means it was accepted and dropped in junk — no error, no report, just silence. If you're guessing, send a test to accounts you control at two or three major providers and see where it actually lands before touching anything.
2
Read the actual bounce text
Don't summarize it — read it. Bounce codes beginning with 4 are temporary; the sending server will retry and the issue may clear on its own. Codes beginning with 5 are permanent. The body usually names the reason and often links to the receiving provider's own explanation page. That text tells you more in one line than an afternoon of guessing.
3
Establish the blast radius
Is it one recipient domain or all of them? One sender or the whole company? One platform or every system you send from? A failure confined to a single mailbox provider is a reputation or policy issue with that provider. A failure across all of them, starting at the same moment, is almost always DNS or a tenant-level restriction.
4
Check whether DNS changed
Records get edited, registrars get transferred, a vendor's onboarding wizard adds a second SPF record and breaks the first. Pull your live records and confirm there is exactly one SPF record, that it still covers every sending system, and that your DKIM keys resolve. A failure that starts abruptly on a specific day is DNS until proven otherwise.
5
Check your own tenant for a compromise
If a mailbox in your organization gets taken over, the attacker's outbound spam gets attributed to you, and your provider may restrict sending for the whole organization. Look for restricted users, unexpected mail-forwarding rules, unfamiliar sign-in locations, and outbound volume spikes. This is the failure mode that looks worst and gets caught latest, because nobody thinks to check it.
6
Then look at what you sent
Only once the infrastructure checks out should you examine the message. What went out immediately before the problem started? A blast to a list you hadn't mailed in months? A template that's mostly image with a shortened link? A volume jump on a domain with no history? Content rarely causes total failure on its own — but it's frequently the trigger that exposes a weak foundation.
Know the Difference
When the Fix Is Structural, Not a Setting
Everything above is genuinely fixable in an afternoon by someone comfortable in a DNS panel. Some situations aren't settings problems at all — they're foundation problems, and no amount of record-editing resolves them. You're looking at a structural fix when:
Your business runs on consumer mailboxes, so there's no domain to authenticate and no admin console to diagnose from.
Marketing and transactional mail share one domain, and you've already damaged the reputation your contracts depend on.
Nobody can produce the list of systems sending as your domain — which means nobody can authenticate them.
A brokerage domain is shared across agents with no policy, so one person's bulk habits set delivery for everyone.
Your CRM sends on its own domain rather than yours, so nothing aligns and every campaign is unverifiable.
The domain is already burned, and what's needed is a rehabilitation plan over weeks, not a record edit today.
Those are ownership problems. They stay broken because deliverability sits between IT, marketing, and whoever set up the CRM, and none of them owns the whole chain. That's the seam Genesis AI closes: one accountable operator running the mail foundation, the authentication, the sending policy, and the campaign layer as a single system. Genesis CRM is configured to send aligned on your domain, from a subdomain kept separate from transaction mail — because a CRM that quietly damages your primary domain is worse than no CRM.
One consolidated SPF record
DKIM per sending platform
DMARC reports actually read
Marketing on its own subdomain
Lists pruned, not hoarded
Want the rest of the picture? See how the buildout works, what's included at each tier on pricing, or read the weekly operational posts on the Genesis AI blog — several of which go deeper on individual pieces of this guide.
Our Approach
Use this whether or not you ever hire us.
Everything on this page is the actual fix, in the actual order we'd do it. If you'd rather someone own the whole chain — mail foundation, authentication, sending policy, and campaigns — that's the service. If you'd rather run it yourself, run it yourself. Either way you should stop landing in junk.
My SPF and DKIM are set up correctly. Why is my email still going to spam?
+
Authentication proves you are who you say you are. It does not prove anyone wants your mail. SPF and DKIM get you past the front door; reputation decides which room you land in. If the records are clean and you are still filtered, the problem is almost always behavior: complaint rates from bulk sends, dead addresses in your database, a sudden jump in volume, or marketing and transactional mail sharing one domain. Fix the sending pattern, not the DNS.
Should I send listing blasts from the same domain as my client email?
+
No. Send marketing from a dedicated subdomain and keep your primary domain for one-to-one client and transaction mail. Reputation is tracked at the domain level, so a campaign that draws complaints can degrade delivery for the same address you use to send contracts. A subdomain isolates that risk. It inherits your organizational credibility but builds and carries its own sending reputation.
Does buying a separate domain for each listing help my marketing?
+
It hurts your email. A brand new domain has no sending history, and receiving systems treat unknown domains with suspicion, especially in real estate, where property and title impersonation is a common fraud pattern. Single-property domains are fine as a landing page that redirects to your site. Never send email from one. All outbound mail should come from the domain you have been building reputation on.
How long does it take to recover a domain that is already being filtered?
+
Longer than it took to damage it, and there is no button. Recovery means stopping the sends that caused the problem, cutting your list back to people who actually engage, fixing authentication so every message is provably yours, and then rebuilding volume slowly over weeks. Receiving systems are watching a trend, not a single day. If the domain is badly burned, moving marketing to a fresh subdomain while you rehabilitate the parent is often faster than waiting it out.
Is a DMARC policy of reject risky for a small brokerage?
+
It is risky only if you skip the homework. Publish DMARC at p=none first with a reporting address, then read the reports until you can account for every service sending as you: your mail platform, your CRM, your e-signature tool, your accountant. Once all of them are aligned and passing, move to quarantine, then to reject. Going straight to reject on a domain you have not audited will silently kill legitimate mail you forgot existed.
Do I need a dedicated IP address to send real estate email?
+
Almost certainly not. A dedicated IP only helps at volumes high enough to keep it consistently warm, and most real estate operations never reach that. Below that threshold a well-managed shared pool delivers better, because the pool has established reputation and yours would not. Spend the effort on domain reputation, authentication, and list quality instead. Those matter at every volume.
Book a Consult
Tell Us About Your Operation.
Send your details and we'll set up a consult — a working session on your current setup and what a managed AI foundation would change. No pressure, no generic sales funnel.
