The short answer
Usually because the receiving system cannot confirm your mail is really yours. Check in this order: SPF, DKIM and DMARC published and passing; the From: domain aligned with what actually authenticated; a sending address with real history; a working unsubscribe on bulk mail; honest subject lines. Nobody publishes exact scoring.
Start with the honest part, because it changes how you should read everything below. The large receiving systems do not publish the rules that decide whether your message lands in the inbox, the promotions tab, the junk folder or nowhere. There is no scoring table to consult, no threshold to hit, no certificate to buy. Anyone who tells you they know the formula is selling something.
What is published, in full and for free, is the set of standards your mail is measured against. Those standards say exactly what a correctly identified message looks like. So the practical goal is not "get a good score" - it is "leave no ambiguity about who sent this". Work down the list in order. The first three items cause the large majority of the cases we see, and they are the cheapest to fix.
1. Missing or broken authentication
This is the most common cause by a wide margin, and it is the one small businesses most often do not know exists. Three separate standards do three separate jobs.
SPF lets a domain publish, in DNS, which hosts are authorised to send mail using its name. The specification is precise about which name: SPF checks the "MAIL FROM" identity - the reverse-path in the SMTP envelope - and the "HELO" identity given by the connecting host [1]. SMTP treats that envelope as a distinct thing from the message header section a person eventually reads [4]. So SPF is checking the delivery paperwork, not the letterhead.
DKIM attaches a cryptographic signature to the message itself. It permits a person, role or organisation to claim some responsibility for a message by associating a domain name with it, validated by fetching that domain's public key from DNS [2]. The domain claiming responsibility is carried in the signature's d= tag, the Signing Domain Identifier [2]. Relays that do not substantively alter the message preserve the signature, so it survives the trip [2].
DMARC ties the first two to the address your reader sees, and adds a way to state what you want done with mail that fails. A domain owner publishes a policy of none, quarantine or reject [3], and can ask for periodic aggregate reports back on how mail claiming to be from the domain is authenticating [3].
How to check it: query your own DNS for the three records - a TXT record at your domain starting v=spf1, a TXT record at _dmarc.yourdomain.ca starting v=DMARC1, and a DKIM key at the selector your mail system uses. Then send yourself a message at an account elsewhere and read the received headers: authentication results are recorded there. If you find nothing, you have found your problem, and you have not yet needed to touch anything else.
2. The From: domain does not align with what actually authenticated
This one is subtle and it catches businesses that believe they are already set up. You can pass SPF and carry a valid DKIM signature and still fail DMARC, because DMARC does not merely ask "did something authenticate" - it asks whether an authenticated identifier lines up with the domain in the From: header field, the originator field a mail app displays [5].
The SPF specification flags this gap itself. Authorising the "MAIL FROM" and "HELO" identities provides no assurance about the authenticity of other identities in the message; a sender can list an entirely different domain in the header while passing SPF on its own, and a reader who does not notice the mismatch may be lulled into a false sense of security [1]. DMARC exists to close that gap: it compares the RFC 5322 From: domain against the SPF-validated domain and against the DKIM d= domain, and considers the message aligned if either matches [3]. Alignment can be evaluated in strict mode, requiring exact fully qualified domain names, or relaxed [3]. Note also that alignment cannot occur at all where the From: field is malformed, absent or repeated [3].
In practice this breaks when third-party services send on your behalf. Your booking form, your invoicing app, your newsletter tool - each is configured to put your address in the From: field while sending through its infrastructure. The mail authenticates beautifully as that provider and aligns with nothing you own.
How to check it: publish a DMARC record with an aggregate reporting address, wait a week, and read what comes back [3]. It will list the sources sending as you. Most owners are surprised by at least one entry. Then either get each legitimate source properly signing for your domain, or stop it from using your domain in the From: field.
3. Sending from a residential or shared address with no history
Here we leave the standards and enter judgement, so treat this section as weaker than the two above. There is no published rule about source addresses. What is structurally true is that a receiving system deciding what to do with an unfamiliar connection has very little to go on, and history is one of the few things it has.
Mail sent from a dynamic home connection, or from a shared address pool you have no control over, carries whatever history that address has - possibly none, possibly someone else's. You cannot audit it and you cannot fix it.
How to check it: look at the Received headers of a message you sent and find the address it originated from. Ask two questions: is this address specifically intended for sending mail, and do I control what else sends from it. Two noes is a reason to move.
4. No working unsubscribe on bulk mail
For newsletters and any other commercial electronic message this is both a legal obligation in Canada and a deliverability question, which is a rare and convenient alignment.
CASL prohibits sending a commercial electronic message to an electronic address unless the recipient has consented, expressly or by implication, and the message sets out information identifying the sender, a way to readily contact them, and an unsubscribe mechanism [7]. A commercial electronic message is defined broadly by content and purpose - encouraging participation in a commercial activity - and a message merely asking for consent counts as one too [7]. The mechanism must let the recipient opt out at no cost to them, must specify an electronic address or a web page for the purpose, and both that and the contact information must stay valid for at least 60 days [7]. The request must be given effect without delay and in any event no later than 10 business days, with no further action required from the person [7].
Implied consent has real limits worth knowing: an existing business relationship generally runs from a purchase or contract within the previous two years, or an inquiry within the previous six months [7].
On the technical side, one-click unsubscribe is what makes a mail app show an unsubscribe button instead of leaving the reader hunting. The sender places a List-Unsubscribe header containing an HTTPS URI and a List-Unsubscribe-Post header containing the single pair List-Unsubscribe=One-Click, and the message must carry a valid DKIM signature covering both headers [6]. The URI must identify the recipient and the list well enough to complete automatically, should include a hard-to-forge component, and must not return an HTTPS redirect [6]. This is for bulk and list mail; it is not something to bolt onto ordinary correspondence.
5. Misleading subject lines and header details
No standard scores subject lines, so be sceptical of any specific claim here, including ours. What can be stated from primary sources is narrower: CASL requires a commercial message to set out prescribed information identifying the person who sent it and the person on whose behalf it was sent [7]. DMARC's own design notes acknowledge that attacks exist in the human-readable display name portion of the From: field, outside what the mechanism evaluates [3].
The defensible advice, then, is not a trick list. It is that a subject describing the actual contents, and a From: name matching the business the recipient dealt with, remove reasons for both a filter and a human to distrust the message. "Re:" on a message that is not a reply does the opposite.
6. Content patterns
This is last for a reason: it is where most advice starts, and it is the item you can say least about honestly. Nobody publishes which words or structures count against a message, and lists of "spam trigger words" circulating online are folklore, not documentation. Chasing them is how owners spend a week rewriting copy while a missing DKIM record sits untouched.
What is worth doing costs nothing: send messages a person would recognise as coming from your business, keep the plain-text and HTML versions saying the same thing, avoid the single-giant-image message with no readable text, and do not link to domains you cannot vouch for.
The concession: sometimes the mail is genuinely unwanted
Here is the case where none of the above is your answer. If people are receiving your mail and actively marking it as spam, no configuration will fix that. Authentication proves who you are; it cannot make a recipient want to hear from you, and DMARC says as much in its own text - receivers may reject or quarantine mail even when it passes the check, and final disposition of a message is always a matter of local policy [3].
When the complaints are real, the fix is editorial, not technical: send less mail to people who asked for it, rather than more mail to everyone. A list of 300 people who opted in beats a list of 3,000 scraped addresses on every measure that matters, including the one where your domain keeps its good name. CASL's structure points the same way - consent first, then contents [7].
Do this this week
One afternoon, in order. Look up your domain's SPF and DMARC TXT records and your DKIM key; if any is missing, that is the whole job. Add a DMARC record with an aggregate reporting address even if you set the policy to none, so you start receiving data on who sends as you [3]. Send a test to an account on a different provider and read the received headers to see what authenticated and whether it aligned with your From: address [5]. If you send any bulk mail, confirm the unsubscribe link works, that it takes effect well within 10 business days, and that your contact information is current [7]. Then stop, and leave the subject lines alone until the first four are clean.