Email Authentication Setup

Email authentication is how a receiving server answers one question before it trusts your mail: is this really from who it claims to be? The answer lives in a handful of DNS records, and since 2024 those records stopped being best practice and became a requirement — get them wrong at volume and your mail is rejected outright. But authentication is not a checkbox; it is a layered stack with strict dependencies and a setup process where the records are the easy part and the alignment is the trap. This page explains the layers, the order they go in, what is mandatory versus optional, and how we configure the whole thing from Toronto.

What is email authentication, and why is it mandatory now?

Email authentication is a set of DNS-published standards that let receiving mail servers verify a message genuinely comes from the domain it claims. The core three — SPF, DKIM and DMARC — work together: SPF lists which servers may send for your domain, DKIM cryptographically signs your messages so tampering is detectable, and DMARC ties those two to your visible sending domain and tells receivers what to do when authentication fails. For years these were strongly recommended and widely skipped. That ended when Gmail and Yahoo began requiring them for bulk senders in 2024, Microsoft followed in 2025, and non-compliant mail moved from “filtered to spam” to “rejected with an error.” Today any sender pushing meaningful volume must authenticate, and roughly four in five cold-email teams reported having to change their infrastructure to comply.

The shift is not only about deliverability. Authentication is also the main defence against someone spoofing your domain to send phishing in your name, which is why it sits at the intersection of marketing and security. Done right, it protects both your inbox placement and your brand.

The six layers, and why order matters

Authentication is best understood as a stack of six standards, each closing a gap the one below it leaves open. They are not interchangeable, and they cannot be added in any order.

The dependencies are architectural, not bureaucratic. DKIM without DMARC has no enforcement, because receivers can ignore an unaligned signature. DMARC without DKIM is fragile, because forwarding breaks SPF and leaves nothing to fall back on. BIMI without DMARC at enforcement does not render at all — publish the record and nothing appears, because the prerequisite is missing. You add the layers from the bottom up, and skipping ahead simply does not work.

SPF, DKIM and DMARC — the mandatory three

These three are the required foundation, and each fails in characteristic ways. SPF is a single DNS record listing every server allowed to send for your domain; the common mistake is exceeding the limit of ten DNS lookups, which causes a permanent error that fails SPF entirely, so the record has to be kept lean and flattened where needed. DKIM signs each message with a private key so the receiver can confirm it was not altered in transit, and the signature must use your domain, not a vendor’s, to be useful downstream. DMARC is the policy layer that pulls SPF and DKIM together, checks they align with your visible From domain, and instructs receivers what to do on failure. Published correctly, the three together tell every receiving server that your mail is genuinely yours — and published incompletely, they quietly send a fraction of your legitimate mail to rejection.

It helps to see what each one actually protects against, because they are not redundant. SPF stops a server that is not on your list from claiming to send for you, but it says nothing about the message contents and breaks the moment mail is forwarded. DKIM proves the message body and key headers were not altered after you signed them, but on its own it gives receivers no instruction about what to do if the signature is missing or wrong. DMARC closes both gaps: it requires that whatever passed actually belongs to your visible domain, and it tells receivers to quarantine or reject anything that does not. Remove any one of the three and a real attack vector reopens — which is precisely why the mailbox providers now require all three rather than accepting one or two as “good enough.”

Why does alignment matter more than “passing”?

This is the detail that breaks more setups than any other. DMARC does not simply ask whether SPF or DKIM passed; it asks whether the domain they authenticated matches the domain your recipients see in the From field. A marketing platform can send your campaign, sign it with DKIM using its own domain, and pass DKIM — yet because that signing domain does not align with your From address, DMARC fails and your mail is treated as unauthenticated. The same trap exists with SPF and the hidden return-path domain. So a setup can show green checkmarks on SPF and DKIM and still fail DMARC across a whole sending stream. Getting alignment right — signing with your domain, configuring the return path, telling each vendor to use your identity — is the unglamorous core of the job, and it is invisible to anyone who only checks whether the individual records “pass.”

The DMARC journey: from p=none to p=reject

DMARC has three policy levels, and the difference between them is the difference between watching and enforcing. A policy of p=none monitors without affecting delivery; p=quarantine sends failing mail to spam; p=reject refuses it outright. Gmail, Yahoo and Microsoft require at least p=none for bulk senders, but p=none is explicitly the minimum, not the destination — the point of DMARC is to reach p=reject, where nobody can spoof your domain. The danger is getting there too fast. Most organisations send through more services than they remember, and moving straight to p=reject rejects every one that is not yet aligned, including legitimate mail from tools you forgot you used. The safe path is to publish p=none with aggregate reporting, read those reports to discover every source sending as your domain, align the legitimate ones and shut down the illegitimate, and only then tighten to quarantine and then reject. Reaching enforcement typically takes six to eight weeks of this disciplined monitoring, and the reports are the part that makes it safe.

# mcsnet · authentication check · example.com
spf          pass · 1 record · 7/10 lookups (lean)
dkim         pass · 2048-bit · aligned to From domain
dmarc        p=quarantine · rua reporting on · aligned
shadow src   2 unaligned senders found in reports (crm, invoicing)
mta-sts      not deployed (optional for this profile)
next         align crm + invoicing → move to p=reject

The mistake that breaks authentication

If there is one finding that recurs in nearly every audit, it is this: a new sending source added without updating authentication. A team adds a CRM, an invoicing service, a help desk or a new marketing platform, and nobody updates the SPF record or configures DKIM for it, so an entire stream of legitimate mail begins failing authentication the day it goes live. It is invisible in normal use because the mail still sends; it only surfaces as deliverability quietly eroding or, under p=reject, as that stream being rejected outright. This is exactly why authentication is not a one-time task. Every time you add a tool that sends mail as your domain, the records need updating, and a maintained authentication setup is one that gets revisited whenever the sending landscape changes.

Do you need MTA-STS, ARC and BIMI?

Honestly, not everyone does, and pretending otherwise sells records nobody needs. ARC earns its place when your mail is regularly forwarded or passes through mailing lists, because it preserves authentication that forwarding would otherwise break. MTA-STS, paired with TLS-RPT, enforces encrypted transport into your domain and defends against downgrade attacks — genuinely valuable if you receive sensitive mail, work in a regulated industry, or have already reached p=reject and want to harden the rest, but not the priority if your basics are still shaky. Adoption tells the story: well under one percent of major domains publish MTA-STS, and in Canada only a few percent do, so it is a differentiator rather than a baseline. The rule we apply is simple: get the mandatory three solid and enforced first, then add the situational layers where they actually fit your risk and sending profile.

What BIMI takes, and whether it’s worth it

BIMI is the layer your recipients can actually see — your verified, trademarked logo displayed next to your messages in Gmail, Yahoo and Apple Mail. It is also the strictest about prerequisites, which is why so many domains publish a BIMI record and see nothing appear. To render, it needs DMARC at enforcement with full coverage, a logo registered as a trademark, that logo in a specific secure SVG format, and a Verified Mark Certificate issued by an authorised authority at roughly US$1,200 a year, renewed annually. For a consumer brand sending from its main domain, the visual trust can lift open rates meaningfully and the cost pays back. For business-to-business cold outreach on secondary domains, the certificate rarely earns its keep, and the honest advice is to skip it. We assess whether BIMI fits before recommending the spend, rather than treating it as a box everyone should tick.

How we set up authentication

Our setup follows the order the standards demand. We start by inventorying every source that sends mail as your domain — the marketing platform, the CRM, the invoicing tool, the help desk, the gateways — because authentication that misses one of them leaves a hole. We fix SPF to list them within the lookup limit, configure DKIM to sign with your domain for each, and publish DMARC at p=none with reporting so we can see the full picture. Then we read the reports, align every legitimate sender, and tighten the policy step by step to quarantine and reject, watching at each stage so nothing legitimate is caught. Where they fit, we add ARC, MTA-STS with TLS-RPT, and BIMI, in that order. Because we also host the sending infrastructure, we control the setup end to end rather than handing you records and hoping your vendors cooperate — and the result is verifiable in any authentication checker, which we encourage you to run.

The work does not end at enforcement, either. Authentication is a living configuration: keys should be rotated periodically, the SPF record needs revisiting every time a sending source is added or removed, and DMARC reports keep arriving with news of new sources — some legitimate, some spoofing attempts worth knowing about. We keep the records current as your sending landscape changes, watch the reports for the unaligned senders that signal either a forgotten tool or an impersonation attempt, and adjust before either turns into a delivery problem. A setup that was perfect six months ago drifts out of true as the business adds tools, and the maintenance is what keeps the foundation solid rather than slowly cracking.

Why work with us?

Two reasons. First, data and consent: we configure authentication with your infrastructure hosted in Toronto under PIPEDA, and our CASL-aware approach means the setup supports consent-based sending rather than just technical compliance. Second, operator depth: authentication is unforgiving of small mistakes — a lookup over the limit, an unaligned signature, a rushed policy change — and you get operators who have configured the full stack many times and know exactly where it breaks. Pairing the people who run your sending with the people who authenticate it means the two stay in sync, which is harder to achieve when authentication is bolted on by a separate vendor.

Who this is for, and who it is not

It is for any sender at volume that needs to meet the mandatory requirements correctly — email platforms, agencies, SaaS and e-commerce businesses — and for teams whose mail is failing authentication or who are stuck partway up the stack and unsure how to reach enforcement safely. It is also for brands that want BIMI done right rather than published and broken. It is not strictly necessary for a tiny sender whose single platform already handles SPF, DKIM and DMARC correctly — though even then, a quick check is worthwhile, since the gaps are invisible until something breaks. Authentication is the foundation everything else in deliverability stands on: it pairs with the deliverability audit that finds the gaps, the SPF and DKIM configuration and DMARC setup work that goes deeper on each, and the reputation and placement work that only matters once identity is solved. Get it right, in order, and the rest of the inbox becomes reachable.