DMARC alignment is a match test on the one part of an email a person can see. If your notice arrives from leasing@northernpm.ca but the authentication that passed belonged to a vendor domain like mail.some-listing-tool.com, the two do not line up, and the message counts as unauthenticated no matter how green the result looks in the vendor's dashboard.
What DMARC alignment checks
DMARC sits on top of two older mechanisms, and neither of them looks at the name your recipient reads. SPF says which servers are allowed to send mail for a domain, and it checks the envelope sender, a hidden address used for bounces. DKIM attaches a cryptographic signature tied to a domain. Both were designed before anyone worried about the visible From line.
DMARC adds the missing step. A message passes DMARC when at least one of these is true:
- SPF passes, and the domain SPF checked matches the From domain.
- DKIM passes, and the domain that signed the message matches the From domain.
That matching is alignment, and it has two modes. Relaxed, the default, accepts a subdomain, so a DKIM signature from mail.northernpm.ca aligns with a From address at northernpm.ca. Strict demands an exact match. Most operators want relaxed, and most never touch the setting.
One aligned pass is enough. That detail is what makes a broken vendor fixable without rebuilding anything else.
Why rental operators trip on this more than most businesses
Count the systems that send email carrying your name. The property management system sends rent receipts and maintenance updates. The syndication tool answers portal enquiries. The screening provider invites applicants to submit. The e-signature service delivers the lease. The accounting platform chases arrears. Someone runs a newsletter through a marketing tool nobody else has opened in years.
Every one of those puts your domain in the From line, and every one sends from its own infrastructure. Each is a separate alignment problem. A vendor that passes SPF on its own bounce domain and signs DKIM with its own key has produced a message that is authenticated for the vendor and unauthenticated for you.
The failure is quiet. Nothing bounces back while your policy is set to none. The message lands in a spam folder or nowhere at all, and the applicant concludes you did not reply.
Where people get this wrong
A passing SPF result is not a passing DMARC result
SPF was checked against the bounce domain, which usually belongs to the vendor. DMARC was checked against the From domain, which belongs to you. Both results can be true at once, and only the second decides delivery.
Publishing p=none is compliance, not protection
Google's sender guidelines require bulk senders, defined as those sending more than 5,000 messages a day to Gmail accounts, to set up SPF, DKIM and DMARC, and state that the enforcement policy can be set to none. Google also requires every sender, at any volume, to have SPF or DKIM on the sending domain. Microsoft brought in a comparable rule for its consumer mailboxes on 5 May 2025, covering domains sending more than 5,000 messages a day to Outlook.com, Hotmail.com and Live.com, and now rejects non-compliant mail outright with a 550 5.7.515 error.
Both rules are satisfied by a record that says p=none, which instructs the receiver to do nothing. Publishing one buys compliance and, more usefully, aggregate reports naming every system sending as you. It buys no protection until you tighten the policy.
Reject is not automatically the finish line
Advice online treats p=reject as the goal. The specification is more careful. RFC 9989 states that domains used for general-purpose email should not deploy p=reject, because forwarding, role addresses and mailing lists break SPF in transit and legitimate mail gets destroyed. It also states that any domain publishing reject must apply valid DKIM signatures rather than relying on SPF, since DKIM survives most forwarding.
The workable shape for a rental business is to split the domains. Put bulk and transactional mail on a dedicated subdomain you can lock down, and leave the address your staff use for ordinary correspondence at a softer policy.
What changed in May 2026
DMARC became a Standards Track specification in May 2026 with the publication of RFC 9989, which replaces RFC 7489. Four changes are worth knowing before you read a guide written earlier:
- The pct tag is gone. It applied a policy to a percentage of failing mail, and receivers implemented it inconsistently.
- A t tag replaces part of that job. Setting t=y tells receivers to apply one level below your stated policy, so quarantine behaves as none and reject behaves as quarantine while you test.
- An np tag sets the policy for subdomains that do not exist, a common source of forged mail.
- Organizational domain discovery no longer uses the Public Suffix List. It uses a DNS tree walk instead.
That last one has a practical edge the document calls out: a receiver still running the old method can reach a different conclusion about which record applies to you. Publishing an explicit DMARC record on every domain you send from removes the ambiguity.
How to check your own domain this afternoon
- Look up what you have. Run dig +short TXT _dmarc.yourdomain.ca, or on Windows, nslookup -type=TXT _dmarc.yourdomain.ca. An empty answer means no DMARC record.
- List every system that sends mail showing your domain. Include the ones you inherited. This list is longer than you expect.
- Send one test from each into a mailbox where you can read raw headers. In Gmail, open the message and choose Show original, then read the Authentication-Results line for dmarc=pass.
- For each failure, ask the vendor to enable DKIM signing on your domain. It is normally two or three CNAME records at your DNS host.
- Publish p=none with a rua address, then read the aggregate reports for a month. They will name senders you forgot about.
- Tighten one step at a time, quarantine before reject, and split your domains before you get to reject.
None of this makes your email better written. It makes it arrive. An applicant who never sees your reply behaves the same as an applicant you ignored, and from your side the two are indistinguishable.
One more thing for step two: any tool that answers enquiries on your behalf, QuickCasa included, belongs on that list. A new sender using your name is a new alignment check, and the DKIM records are easier to set up on the day you sign the contract than to diagnose six months later, when one channel converts worse than the rest and nobody can say why.