Right now, anyone in the world can send email that says it is from your business

Here is a test you can run in about ninety seconds, and it is the only part of this post that will change your mind about whether it matters.

Open a terminal and ask the internet what your domain says about who is allowed to send email as you:

dig +short TXT _dmarc.yourdomain.com

If that returns nothing, then anyone, anywhere, can send an email with accounts@yourdomain.com in the From line, and no receiving mail server has been given any instruction about whether to believe it. Not “it will look slightly suspicious.” There is no published policy, so there is nothing to enforce.

That is the same missing record that is probably sending your invoices to spam. The spoofing problem and the deliverability problem are one problem, which is convenient, because fixing it once fixes both.

The three records, in the order they make sense

Email was designed in an era when the network was small and everyone on it was trusted. The From line is a claim, not a credential, in exactly the way the return address on a paper envelope is. The three records below are patches bolted on afterwards, and knowing which job each one does is most of the battle.

SPF is a list of who is allowed to send for your domain. It lives in a TXT record on your domain and names the servers and services you use: your mail host, your invoicing tool, your newsletter platform, your website’s contact form. The receiving server checks whether the machine that connected to it is on the list.

SPF has one specific trap and you should know about it before it bites. The specification caps evaluation at ten DNS lookups. Every include: in your record can chain to more lookups inside the provider’s own record, so the count is not the number of entries you can see. Go over ten and SPF does not degrade gracefully, it returns a permanent error and fails completely. The way this happens to a real business is boring: a team signs up for one more SaaS tool over four years, pastes in one more include:, and email that worked yesterday starts failing today. Old includes for services you cancelled are the usual dead weight. Remove them.

DKIM is a signature. Your mail server signs each outgoing message with a private key, publishes the matching public key in DNS, and the receiver verifies that the message really came from you and was not modified in transit. It survives forwarding in a way SPF does not, which is why you want both rather than either. Google’s guidance is a 1024-bit key minimum and 2048-bit recommended, and most providers now default to 2048.

DMARC is the policy, and it is the one people skip. It does two things SPF and DKIM cannot do alone.

The first is alignment. SPF checks the envelope sender, which is invisible to the recipient, and DKIM signs on behalf of whatever domain the signer chose. Neither one, on its own, has anything to say about the From address a human actually reads. DMARC requires that the domain in the visible From line matches the domain that passed SPF or the domain that signed with DKIM. This is why a message can pass SPF and still fail DMARC, and it is the single most common source of “but I set up SPF and it is still broken.”

The second is instruction. Your DMARC record tells receiving servers what to do when a message claiming to be from you fails alignment:

• p=none means do nothing, just tell me about it. Monitoring.
• p=quarantine means put it in spam.
• p=reject means refuse it outright.

A minimal starting record looks like this:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

That record protects you from nothing. It is the right first step anyway, because the rua address starts collecting daily aggregate reports from every major mail provider telling you exactly who is sending as your domain and whether it passes. You need those reports before you turn on enforcement, because the thing that goes wrong when people jump straight to p=reject is that they discover the payroll system was a legitimate sender only after it stops being delivered.

What the mailbox providers now require

Three enforcement waves, and the direction of travel is the point.

Gmail and Yahoo, from February 1, 2024. Google’s sender guidelines split into two tiers. Every sender, at any volume, needs SPF or DKIM, valid forward and reverse DNS records for the sending IP, a TLS connection, messages formatted per RFC 5322, and a spam rate under 0.3% as reported in Postmaster Tools. Senders of 5,000 or more messages a day to personal Gmail accounts additionally need SPF and DKIM, a DMARC record at minimum p=none, From-header alignment with SPF or DKIM, and one-click unsubscribe on marketing and subscribed mail, implemented with the List-Unsubscribe and List-Unsubscribe-Post headers of RFC 8058 and honoured within two days. Google’s own recommendation is stricter than its requirement: keep spam complaints under 0.10% and never reach 0.30%. Yahoo landed the same requirements on the same timeline.

Microsoft, from May 5, 2025. Senders of more than 5,000 messages a day to outlook.com, hotmail.com, and live.com must pass SPF, DKIM, and DMARC, with DMARC at minimum p=none and alignment on SPF or DKIM. Microsoft’s original plan was to route non-compliant mail to the junk folder. Days before the deadline it changed the plan: non-compliant mail is rejected at the SMTP level and not delivered at all, on the reasoning that a rejection tells the sender something and a junk folder tells nobody anything.

That last change is the one to absorb. The failure mode for unauthenticated mail is no longer “it goes to spam and the customer eventually finds it.” It is “it does not arrive, and you do not find out unless someone is reading bounce messages.”

Why the 5,000-a-day threshold is a distraction

Almost every article about this is written for e-commerce marketers, so it treats 5,000 messages a day as the line where the rules start. For a ten-person business in Toronto sending quotes, invoices, appointment reminders, and maybe a monthly newsletter to four hundred people, that threshold reads as permission to ignore all of it.

Two reasons that reading is wrong.

The all-sender requirements have no threshold. SPF or DKIM, reverse DNS, TLS, and a low complaint rate apply to your two hundred invoices exactly as they apply to a retailer’s two million. Those are the ones a small business most often fails, usually through a misconfigured application server rather than through anything a mail provider does.

The thresholds describe when providers guarantee enforcement, not when they start scoring you. Every filter in the chain reads the same signals for everyone. An unauthenticated invoice from a domain with no DMARC record does not get a pass because you only sent nine of them. The 5,000 line is a floor for a formal policy, not a shelter.

And none of that touches spoofing, which does not care about your volume at all. The businesses actually hurt by domain spoofing are small ones: a supplier gets an email from accounts@yourdomain.com with new banking details, and there is nothing in the message a normal person could use to tell it apart from you. Without DMARC at quarantine or reject, you have published no way for their mail server to tell either.

Where this breaks in software we build

Three failure patterns turn up constantly in application code, and all three are fixable in an afternoon.

The contact form that sends as the customer. A form takes the visitor’s email address and puts it straight in the From header, so the site owner can hit reply. It is a natural thing to write. It also means your server is sending mail claiming to be from someone@gmail.com, a domain you have no authority over. The message cannot align, so it fails DMARC, and it gets junked or rejected. Google’s sender guidelines address this directly and tell senders not to put Gmail From: headers on mail they send, precisely because Gmail’s own DMARC policy then applies to it. The business meanwhile concludes that its contact form is broken and nobody can say why.

The fix is one line: put your domain in From, and the visitor’s address in Reply-To. Reply still works. Authentication passes.

The application server nobody authorized. Password resets, receipts, and booking confirmations get sent from the app, often through a transactional provider like Resend, Postmark, or SES, and often after the domain’s SPF and DKIM were set up for the office mailboxes and never revisited. The provider’s setup wizard will hand you the exact DNS records. This is a ten-minute task that gets skipped because the mail appears to work when you test it against your own inbox, which is the one inbox in the world most likely to trust you.

Marketing and transactional mail sharing one reputation. Send the newsletter from a subdomain, news.yourdomain.com or similar, with its own DKIM key. A bad campaign then damages the newsletter’s reputation instead of your invoices’ reputation. Transactional mail is the mail that must arrive, so give it its own lane.

The Canadian part

CASL is a separate obligation and authentication does not satisfy it. Canada’s anti-spam law is consent-based: with limited exceptions, you need express or implied consent before sending a commercial electronic message, and the burden of proving consent is yours. Every message must identify who is sending it and on whose behalf, and must carry an unsubscribe mechanism that stays valid for at least 60 days and is honoured without delay, and in any event within 10 business days.

The penalties are the part people underestimate: up to $1 million per violation for an individual and $10 million per violation for a corporation, enforced by the CRTC. That is a per-violation maximum rather than a typical outcome, and actual penalties have been far smaller, but the ceiling explains why “we bought a list” is worse advice in Canada than in most places.

Note the two-day and ten-business-day figures are different clocks from different rulebooks. Gmail’s is a deliverability requirement, CASL’s is a legal one. Honour unsubscribes immediately and you satisfy both without thinking about it. If you are already reviewing how your business handles customer data, our walkthrough of Bill C-36 covers what is changing on the privacy side.

What to actually do, in order

1. Check what you have. dig +short TXT yourdomain.com for SPF, dig +short TXT _dmarc.yourdomain.com for DMARC. Most free DMARC checkers will do the same thing in a browser and will also count your SPF lookups for you.
2. Inventory every system that sends mail as you. Mail host, invoicing, CRM, booking tool, e-commerce platform, the website itself, payroll, the helpdesk. Almost everyone misses at least one, and the one they miss is usually the one that breaks when enforcement goes on.
3. Get SPF and DKIM right for all of them, and confirm you are under ten SPF lookups with nothing left over from a cancelled vendor.
4. Publish DMARC at p=none with an rua address, and actually read the reports for a few weeks. Aggregate reports are XML and unpleasant by hand; a free tier of any DMARC reporting service is worth it for the visibility alone.
5. Move to p=quarantine, then p=reject, once the reports show all your legitimate sources passing. This is the step that ends spoofing of your domain, and it is the step almost everyone stops short of. A DMARC record parked at p=none forever is a smoke detector with the battery taken out.
6. Fix the From header on your contact form if it is sending as the visitor.

None of this costs money. All of it is DNS records and one configuration change in an application. It takes an afternoon the first time, and then it is done, which is a rare shape for a security task.

If you are not sure which systems send email as your domain, or your quotes keep landing in spam and nobody can tell you why, send us a note. It is usually a DNS problem with a name, and it is usually fixable the same day.