Email authentication
in 2026.

The November 2025 Gmail strict enforcement was not a single event. It was the third step on a ladder that started in October 2023, when Google and Yahoo published the bulk sender requirements that everyone read once and then mostly ignored for eighteen months. The senders who treated the announcement as informational are the ones now seeing 22 to 34 percent of their volume land in spam folders. The senders who started the migration in early 2024 are mostly fine. The gap between those two cohorts is wider than vendor messaging admits — reputation data accumulates at the major providers, and a sender who misbehaved through 2024 is still paying for that in 2026 placement.

Here is the timeline that matters, with the dates that actually moved the needle. October 2023: Google and Yahoo publish the requirements. February 2024: Gmail begins enforcement with temporary 421 deferrals — easy to miss because retries succeed. April 2024: Google starts rejecting some non-compliant traffic outright. June 2024: the original one-click unsubscribe deadline. May 5, 2025: Microsoft turns on enforcement for live.com, hotmail.com and outlook.com with 550 5.7.515 immediate rejection — 33 days from announcement to wall, the most aggressive timeline of the cohort. September 2025: La Poste joins the enforcement bloc. November 2025: Gmail transitions from soft enforcement to permanent rejection at scale. The current state, as of April 2026, is that all four major consumer mailbox families (Gmail, Microsoft consumer, Yahoo, Apple iCloud is expected next) treat SPF + DKIM + DMARC as a hard precondition for delivery, not a soft signal.

Two figures from the current landscape, both verifiable. Roughly 16 percent of domains worldwide have a DMARC record published at all. Among Fortune 500 companies that do publish one, only about 35 percent are at p=reject — the policy that actually blocks impersonation. The other 65 percent went to p=none two years ago, received aggregate reports for a quarter, and never finished the migration. That gap between having DMARC and enforcing DMARC is where almost all the residual deliverability risk concentrates today. A sender at p=none meets the letter of the bulk sender requirement, clears the initial validation check, and still loses inbox placement because receiving providers treat p=none as a maturity signal — and a weak one. The operational irony is that companies that never published DMARC at all are in a better starting position than the ones that published and stalled.

The real cost of staying non-compliant is not the obvious one. Yes, you lose direct rejections — the 550 errors are visible in your bounce logs and impossible to ignore. The bigger loss is silent. Senders who fail authentication checks on a portion of their volume see the rest of the volume re-evaluated downward by reputation systems that share signals across the same provider. Lose 8 percent of your Gmail volume to authentication rejections in a month, and the remaining 92 percent that delivered fine moves further into Promotions — then Updates — then eventually spam over the following 90 days. We saw this pattern eleven times in client audits during 2025 — same shape every time. The volume that delivered yesterday is not the volume that will deliver next quarter, because reputation is durable and reputation cuts both ways.

Two more developments before we move to the protocols themselves. First, industry analysts at Red Sift and Valimail and Proofpoint expect MTA-STS to become a hard requirement at Google and Yahoo within the next year, paralleling the trajectory SPF / DKIM / DMARC followed in 2024. The November 2025 strict enforcement was the second step on a multi-year ladder; transport security is the next rung. Second, BIMI eligibility — which requires DMARC at p=quarantine or stricter — is no longer just a brand-marketing line item. The 4 to 10 percent open rate lift that Red Sift and others have measured turns into real money for any sender north of a couple hundred thousand commercial messages per month. The protocols are converging into a single deliverability posture, and the senders who treat them as separate vendor purchases are the ones still buying four products that share most of their infrastructure.

One last data point before the protocols. Postmark's January 2026 deliverability report counted approximately 30 percent of bulk senders still partially non-compliant on at least one of authentication, one-click unsubscribe headers, or spam rate thresholds — two years after the original Gmail and Yahoo announcements. That is a remarkable number. It tells you that the migration is not technically hard. It tells you that most senders missed the deadline because nobody on their team owned the work. The protocols below are not the difficult part. The difficult part is the project management around them — sequencing the migration, holding the line on p=quarantine for four weeks before reject, refusing to publish BIMI before DMARC reaches enforcement. Read sections 02 through 06 as a deployment ramp, not a feature comparison.

Six protocols, three layers, one stack. SPF and DKIM verify identity at the message level — they answer "did this domain authorise this sender, and was the message tampered with in transit?" DMARC stitches those two together with a policy and a feedback loop, telling receivers what to do when authentication fails and giving the domain owner aggregate reports about who is sending under their name. MTA-STS and TLS-RPT operate one layer down, at the SMTP transport level — they answer "is the connection between sending MTA and receiving MTA encrypted, and was a downgrade attempt visible to anyone?" BIMI sits one layer up, at the rendering level — it answers "should this authenticated message display the brand's verified logo to the recipient?" Each protocol resolves a specific question that the others do not. Each one has a DNS location, an RFC, and a deployment ramp that does not interact cleanly with the others if you start them in the wrong order.

Two of the protocols only make sense as pairs. SPF without DKIM authenticates the envelope but not the message body, which means a perfectly valid SPF pass tells you nothing about whether the From header was rewritten en route. DKIM without SPF authenticates the body but leaves the path unverified, which means a forwarded message with a broken signature looks identical to a forged one. The DMARC p= policy needs both signals to make a useful decision, and the alignment requirement — that at least one of SPF domain or DKIM signing domain matches the From header — is what closes the spoofing window that SPF alone left open. The MTA-STS and TLS-RPT pair has the same dynamic. MTA-STS without TLS-RPT enforces transport security as a one-way command — sending MTAs comply or refuse delivery — but the receiving domain has no visibility into refusals. TLS-RPT without MTA-STS gives you reports on TLS connection results that you cannot do anything about, because no policy is being enforced. The two are designed as a feedback loop, and we have audited deployments where the operator turned on enforce mode without TLS-RPT — they were enforcing blind for six months before someone noticed.

DMARC and BIMI sit at opposite ends of the same line. DMARC is the bottleneck through which both halves of the stack pass — the SPF/DKIM layer reports up to it, the MTA-STS/TLS-RPT layer relies on it for sender identity, and BIMI requires it at quarantine or stricter to even render. If you can only afford to deploy one protocol cleanly, deploy DMARC and accept that the rest will eventually follow because they all anchor on the same record. BIMI is the inverse case. It changes nothing about deliverability — a domain at p=reject with a perfect BIMI deployment delivers no better than the same domain without BIMI. What BIMI does is convert the deliverability work, which is invisible to the recipient, into a visible logo in the inbox. The 4 to 10 percent open rate lift Red Sift and others have published is not a deliverability gain. It is the recipient's behavioural response to seeing a verified brand mark next to an authenticated sender — and that response only exists because the rest of the stack is already in place.

The deployment order matters more than people expect, and most failed migrations failed because the order was wrong. The correct sequence is SPF and DKIM first, then DMARC at p=none for at least three weeks of report ingestion, then DMARC at p=quarantine with a percentage ramp, then DMARC at p=reject, then MTA-STS in testing mode for four to six weeks, then MTA-STS in enforce mode, then BIMI. Eight steps. Each one creates a stable baseline for the next. Skip the p=none reporting window and you publish a quarantine policy without knowing which legitimate senders you are about to break. Skip the MTA-STS testing window and you find out about your backup MX certificate problem when delivery starts failing. Skip the DMARC enforcement step entirely and your BIMI record sits in DNS doing nothing for the eight weeks it takes someone to notice the logo never appeared. We sequence engagements this way not because the spec says to — none of the relevant RFCs prescribes an order — but because we have run the migration twenty-something times and the order is the variable that separates clean deployments from incident reports.

Reference table

// Mandatory at the four-provider level means delivery rejection on non-compliance. Optional means the protocol is not enforced today but is increasingly cited as a maturity signal in placement decisions. The line between the two has been moving toward "mandatory" for every protocol on this list since 2024.

RFC 7208 Section 4.6.4 caps SPF DNS lookups at ten. That is the spec. What the spec does not say, but every operator running modern email infrastructure eventually discovers, is that ten is not many. A standard Google Workspace setup consumes four lookups before you have done anything. Add HubSpot for marketing — that is seven more, and you are already at eleven before Mailchimp, Zendesk, your transactional API, your monitoring alerts, or any of the half-dozen other tools that quietly add an include: to your SPF record over a calendar year. The ceiling is real, the math is unforgiving, and the failure is silent because nothing tells you when you cross it.

When a sending domain crosses the ten-lookup threshold, receiving servers return permerror. That sounds bad and is. The receiving server treats SPF as if it had failed, which means DMARC alignment can no longer pass on the SPF leg. If your DMARC record relies on SPF for at least one alignment path — most do — your messages start producing dmarc=fail outcomes that get routed according to your p= policy. At p=none you see the failures in aggregate reports a week later and have time to fix them. At p=reject you see them in your bounce logs in real time, and the volume that was delivering yesterday is rejecting today. The same misconfiguration produces a slow signal at low enforcement and a hard failure at high enforcement. That asymmetry is why the SPF lookup count tends to break exactly at the moment the operator finally pushes DMARC to reject — when the cost of getting it wrong is highest.

The advice you find in most blog posts is to flatten the SPF record. Flattening means resolving every include: mechanism to its current set of IP addresses and substituting those IPs directly into your SPF record, which removes the lookup count entirely because there are no more includes to chase. It is a real technique. It is also the wrong answer in most cases, and the reason it is the wrong answer reveals more about how SPF actually works than the original problem. When you flatten, you are taking a snapshot of the IPs your third-party senders use today and freezing them into your DNS. Tomorrow, when SendGrid adds a new shared IP range — they do this routinely, on infrastructure rotations they never announce to customers — your flattened record is silently out of date. Mail from the new IPs starts failing SPF, your DMARC alignment breaks for that subset of traffic, and you have no upstream notification because the change was not yours to track. We have seen flattened records that were six months stale before anyone noticed, with placement degradation that operators were attributing to "Gmail being weird that month."

The cleaner answer is usually subtraction, not flattening. Most SPF records that exceed ten lookups are carrying authorisations for senders the operator stopped using two years ago. The marketing automation tool that was replaced. The transactional API that got migrated. The contractor who set up an experimental sending integration that nobody audited afterwards. We typically open an SPF audit by asking the client to tell us which of the included senders is currently sending, and the answer is usually three to five out of nine or ten authorised. Removing the inactive includes restores the lookup budget without taking the structural risk that flattening introduces. The remaining senders, if there are still too many, get evaluated against alignment requirements — some of them only need DKIM alignment for DMARC to pass, in which case dropping their SPF authorisation costs nothing. The full flattening of the record is a last resort, after subtraction and after DKIM alignment review, not a first move.

Three failure modes show up when SPF lookup limits are violated, and the operator usually misdiagnoses which one they are seeing. The first is permerror at validation time — the receiving server tries to evaluate SPF, exhausts the lookup budget, and returns a permanent error. This is the textbook case. Aggregate reports flag it explicitly. The second is inconsistent enforcement, where some receivers are stricter about lookup counting than others, so the same record produces SPF pass at one provider and SPF fail at another. Microsoft and Yahoo tend to be the strict ones. This produces audit traces where Gmail looks fine and Yahoo is rejecting, and operators waste a week chasing the wrong vendor before checking the lookup count. The third is silent drift — caused by upstream include: chains that are themselves at the lookup limit on the day you publish, but cross it next month when one of those upstream vendors adds a new mechanism to their record. You did not change anything. Your record looks the same. Your authentication is failing because of a record you do not control.

Worked example. A mid-market B2B company we audited last quarter had this SPF record: v=spf1 include:_spf.google.com include:sendgrid.net include:_spf.salesforce.com include:spf.protection.outlook.com include:mail.zendesk.com include:_spf.intercom.io include:helpscoutemail.com include:mailgun.org include:amazonses.com -all. Nine includes. Looks reasonable. The actual lookup expansion was nineteen — Google Workspace alone resolves to four nested includes, Outlook adds five, Salesforce adds three, and so on down the list. The record was producing intermittent SPF failures at Yahoo for a month before they ran the audit. Three of those nine senders had been replaced or deprecated. Two more only needed DKIM alignment, not SPF. After cleanup the record sat at six includes, twelve lookup expansions, well under the limit. Total time to fix once we had the inventory: two hours. Total time the broken state had been in production before they noticed: just under fourteen weeks.

// quick action

Run our SPF flattener tool against your domain. The page returns the recursive expansion, the lookup count, and the cycle detection result in your browser, with no logging on our end. If the count is over ten, the tool tells you which includes are contributing most to the budget — the input you need before deciding between subtraction, alignment review, or flattening as a last resort.

The DMARC migration is the most overestimated technical task and the most underestimated project management task in this stack. Publishing the record takes ten minutes. Reading the aggregate reports correctly takes weeks. Deciding when to advance from p=none to p=quarantine, and from p=quarantine to p=reject, takes a level of sender inventory discipline that most organisations do not have when they start. We open every engagement assuming the migration will take eight weeks not because the protocol is hard but because the inventory work that has to happen alongside it has never been done before, and uncovering shadow senders takes the time it takes.

Weeks one through three are observation. The DMARC record goes up at p=none; rua=mailto:[email protected] and the operator does nothing else for twenty-one days. Aggregate reports start arriving within forty-eight hours from receivers that support DMARC reporting — Google plus Microsoft plus Yahoo plus AOL plus Comcast plus a handful of others. Each XML report covers a 24-hour window and lists every IP that sent mail claiming to be from your domain, broken down by SPF and DKIM authentication results. By day fourteen you have a complete inventory. By day twenty-one you have enough volume across each sender to know which ones are stable and which are intermittent. About thirty percent of clients discover at least one sending source they did not know existed during this window. We had a financial services client last year who found a marketing automation tool an intern had set up four years earlier, still sending to a list of two thousand contacts every Tuesday, that nobody in the building remembered authorising.

Week four is the first policy change, and the temptation is to overcommit. The mistake we see most often is operators jumping straight from p=none to p=quarantine; pct=100, applying quarantine to everything from day one. The cleaner path uses the percentage tag to ramp gradually — pct=25 for the first week, then pct=50, then pct=100 by week six. Three weeks of graduated risk. Twenty-five percent of failures going to spam folders during week one is a much smaller incident than one hundred percent during week one. The receivers honour the percentage on a per-message basis, so the sample is statistically uniform. Any sender you missed in the inventory work surfaces as quarantined messages in week one, you fix them, then ramp the percentage. By the time you reach pct=100 you have already corrected the failure modes that would otherwise hit you all at once. Eleven of our last twenty migrations would have produced support escalations if we had skipped the percentage ramp — we know because we backtested the aggregate reports against the senders we discovered during weeks four and five.

Week seven is the move to p=reject and it should be uneventful. If the previous three weeks of pct=100 quarantine produced no surprises in the aggregate reports, the move to reject changes nothing for legitimate traffic. Failing senders that were going to spam now get rejected outright, but you already know who they are. The only senders affected are the ones still failing on week six, which means they were either missed in the inventory or never legitimate to begin with. The transition is mechanical. Update the record from p=quarantine; pct=100 to p=reject, increment the DNS serial, wait for propagation. The week after the move is when most operators feel like they have crossed the finish line — deliverability numbers stabilise, the support queue thins, the aggregate reports get quiet enough that the operator stops checking them daily. That feeling is correct for DMARC. It is not the finish line for the broader stack, because MTA-STS and BIMI still come after, but it is the moment the most invasive part of the migration ends.

Not every domain should reach p=reject. The exceptions are narrow but important. A domain that is exclusively used for transactional mail through a single ESP, with no marketing volume and no employee-originated mail, can usually go straight to p=reject because the inventory is trivial. A domain that has many forwarded relationships — academic institutions, mailing lists, professional associations — sits at the other end. Forwarding breaks DKIM signatures most of the time and breaks SPF alignment whenever the forwarder rewrites the envelope sender, which is most modern forwarders. A p=reject policy on a domain with heavy forwarding produces real legitimate-mail loss that the aggregate reports will tell you about but will not solve. For these domains the right policy is p=quarantine with ARC sealing on the forwarding side, not p=reject. We have one academic client where we have explicitly recommended staying at quarantine indefinitely because their forwarding traffic to alumni inboxes is too important to risk on the strict policy.

Reading aggregate reports without losing the migration window is a skill more than a tool. The reports arrive as XML, one per receiver per 24-hour window, and the raw format is functional but unfriendly — a rua endpoint receiving reports for a domain with a hundred sending sources can produce a hundred files a day, each twenty to forty kilobytes, all formatted for machine ingestion. The operator who tries to read these manually gives up by week two. Every DMARC product on the market — ours included — is a parser, an aggregator, and a dashboard for these reports, plus alerting when the patterns shift. What matters when reading the dashboard is not the count of failures but the trend. A new IP appearing for one of your authorised senders is not a failure even if SPF fails for one report cycle, because authorised senders rotate IPs and the next cycle usually catches up. A new IP appearing for an unauthorised sender, repeated across three or four cycles, is a real signal — either a legitimate sender you missed, or a spoofing attempt. The skill is calibrating that distinction without alert fatigue. We tune our client dashboards to flag patterns repeated across at least two report cycles before paging anyone, which removes about ninety percent of the noise without losing the signal we care about.

Transport security is the part of the stack most operators have never thought about. SMTP shipped in 1982 without encryption. STARTTLS arrived in 2002 as an opportunistic upgrade. Opportunistic was the operative word — if a sending server cannot establish TLS, it falls back to plaintext and delivers anyway. That fallback is what MTA-STS was designed to close, and it is the attack surface that none of the SPF / DKIM / DMARC layer touches because all three of those operate at the message level, not the connection level. A perfectly authenticated message can still be intercepted in transit by an attacker who strips STARTTLS from the SMTP banner and forces a plaintext delivery. The fact that this attack vector exists in 2026 surprises every operator we explain it to for the first time.

The downgrade attack is mechanically simple, which is why it is still effective in 2026. An attacker positioned between the sending and receiving MTAs strips the STARTTLS extension from the receiving server's banner. The sending MTA does not know STARTTLS was offered. It proceeds in plaintext. The attacker reads everything in clear, optionally rewrites headers, optionally injects content, and forwards to the legitimate destination — and from the perspective of both MTAs at either end of the connection, delivery succeeded. From the perspective of the recipient, nothing looks wrong. Cisco Talos and Sectigo have both published case studies documenting this attack pattern against real production traffic over the past four years. The attack works on any MX that accepts opportunistic STARTTLS, which is most of them. MTA-STS is the only mitigation that does not require both endpoints to manually configure forced TLS, and that is why the protocol matters even though most operators have never been targeted by a downgrade attack themselves.

MTA-STS is the only protocol in this stack that lives in two places at once. Half of it is a DNS TXT record at _mta-sts.{domain} declaring "I have a policy, fetch it from this URL, the version identifier is id=20260417a." The other half is a plain text policy file served at https://mta-sts.{domain}/.well-known/mta-sts.txt containing the actual policy fields: version plus mode plus one or more mx: lines plus a max_age: in seconds. Sending MTAs that support MTA-STS read the DNS record first, then fetch the HTTPS file when the id field changes — the id is what tells them to refresh their cached copy. The two halves must stay in sync. Update the policy file but forget to increment the DNS id, and senders cache the old policy for up to max_age seconds — which can be ninety days if you set it that high. We have audited deployments where the policy file had been updated three times while the DNS still pointed at the original id from eight months earlier. Senders were enforcing a policy nobody on the operator's team thought was current.

Going straight to enforce mode is the most common cause of post-deployment incidents, and the spec is explicit that it is the wrong move. RFC 8461 defines three modes: none (effectively disabled), testing (sending MTAs try TLS validation but deliver regardless of outcome), and enforce (sending MTAs must succeed at TLS or refuse delivery). The standard rollout is at least four to six weeks in testing mode while you gather TLS-RPT data, then graduate to enforce once reports show no surprise failures. Operators who skip the testing window typically discover their backup MX certificate problem at the moment the policy starts blocking real mail. The four to six week window is not bureaucratic caution. It is the time required for traffic patterns to surface every edge case — the legacy server that only handles overflow at quarter-end, the third-party integration that sends through a different MX once a month for batch reports, the archive-replay sender that has not updated its TLS stack since 2019.

TLS-RPT is the part the spec lets you skip and that operators should never skip. Per RFC 8460, the protocol is recommended but not required — you can publish MTA-STS without a TLS-RPT companion record and the policy will still work for senders that support it. In production, treating it as optional is malpractice. Without TLS-RPT, sending MTAs that fail your MTA-STS policy reject mail silently. There is no signal back to the receiving domain that traffic stopped flowing until somebody calls. With TLS-RPT, you receive daily JSON aggregate reports of TLS connection results from sending MTAs, including the specific failure type — no STARTTLS offered, certificate validation failed, hostname mismatch, expired chain, untrusted root. The companion record lives at _smtp._tls.{domain} as a TXT record with the format v=TLSRPTv1; rua=mailto:[email protected]. Setup takes ten minutes. Skipping it costs you visibility for as long as the policy is published.

Transport security is currently optional and headed toward mandatory. We have a working draft from a Red Sift analyst circulating in deliverability circles since late 2025 suggesting that Google may make MTA-STS a hard requirement during 2026 — not as part of the bulk sender rules, but as a separate enforcement track aimed at large enterprise senders. Whether that draft proves accurate or not, the direction is clear. Every protocol on the SPF / DKIM / DMARC enforcement timeline took eighteen to thirty months from announcement to hard enforcement. MTA-STS has been in production since 2018 and has never been publicly required. The asymmetry says the announcement is overdue, not that it is unlikely. Senders who deploy MTA-STS now during the optional window are buying a year of operational learning before the requirement becomes binary — the same trade we saw clients make for DMARC in early 2024, with the same payoff profile.

// quick action

Run our MTA-STS validator against your domain. The page checks both halves — the DNS record and the HTTPS-hosted policy file — and verifies the id synchronisation, the policy mode, and the MX directives against the domain's actual MX records. If you have MTA-STS published already, this is the fastest way to find out whether the two halves are still in sync.

BIMI is the protocol most often misunderstood as a deliverability tool. It is not. A domain at p=reject with a perfect BIMI deployment delivers no better than the same domain without BIMI — the inbox placement is identical, the spam folder placement is identical, the reputation signals at the major providers are identical. What BIMI does is render. It takes the work you already did to authenticate your mail and converts it into a visible logo next to the sender name in supported clients. The lift you read about in case studies — 4 to 10 percent on opens, 39 to 80 percent on clicks, 44 percent on brand recall per Red Sift's published benchmarks — is the recipient's behavioural response to that visible signal, not a change in how the message was filtered. Operators who treat BIMI as a deliverability fix end up disappointed. Operators who treat it as a brand-marketing investment with strict authentication prerequisites end up satisfied.

The prerequisite for BIMI is DMARC at p=quarantine or stricter. There is no path around this. Every provider that displays BIMI logos — Gmail, Yahoo, Apple Mail iOS 16+ and macOS 13+, Fastmail, La Poste — checks DMARC enforcement before rendering. A domain at p=none with a published BIMI record renders nothing in any client. We see this misconfiguration in roughly six out of ten BIMI audits. The pattern is identical: marketing team learns about BIMI, sees the open-rate lift numbers, asks IT to "set up BIMI." IT publishes the DNS record, the SVG goes on the CDN, the VMC certificate is procured at considerable cost. Then weeks pass and nobody sees the logo, because DMARC was at p=none the whole time and nobody told the marketing team that BIMI requires the rest of the stack first. The lesson is operationally trivial and yet ignored often enough to remain a leading cause of failed BIMI deployments. Do DMARC first. Do BIMI second. The reverse never works.

VMC versus CMC is the certificate question every BIMI deployment hits, and the answer depends on which provider's display matters most to the sender. VMC is the original Verified Mark Certificate — issued by DigiCert plus Entrust plus Sectigo plus GlobalSign plus SSL.com after a registered-trademark validation that takes seven to ten business days and costs €749 to €1,688 per year depending on the issuing CA. CMC is the Common Mark Certificate, introduced in late 2023 to handle logos that are not registered trademarks. CMC issuance is faster — usually three to five business days — and cheaper at €650 to €1,100. The provider matrix matters. Gmail accepts both VMC and CMC, but only the VMC unlocks the blue verification checkmark next to the sender name — CMC gets you the logo without the checkmark. Yahoo accepts both with no visible difference between them. Apple Mail accepts only VMC, not CMC, and treats CMC-only deployments as if BIMI were not present at all. The choice usually comes down to whether Apple Mail traffic is material for the sender. If yes, pay for VMC and accept the trademark requirement. If no, CMC is the right answer and saves both money and lead time.

The SVG Tiny PS profile is where most BIMI deployments break technically. Tiny PS — Portable/Secure — is a stripped-down SVG variant that bans scripts, animations, external references, foreign objects and several attributes that regular SVG editors emit by default. The most common failure is exporting from Figma or Illustrator or Sketch and uploading the result without conversion. These tools produce full SVG with xlink:href references, <style> blocks, gradient fills with non-tiny-PS attributes, and metadata sections that Tiny PS does not allow. The file must declare baseProfile="tiny-ps" in the root element, must use a square viewBox (typically 0 0 1024 1024 or 0 0 512 512), and must stay under 32 kilobytes. Beyond the syntax constraints, the visual constraints are real — Tiny PS does not support raster image embedding, so any logo with photographic elements has to be vectorised first. Most clients arrive at BIMI with their existing brand SVG and discover that the file fails validation in ways that take a designer two to four hours to fix. Budget for that. The SVG conversion is rarely a one-pass operation, especially for logos that were originally drawn in raster and converted to vector at some forgotten point in the brand's history.

The ROI on BIMI depends on volume and brand recognisability, and it is not universal. The 4 to 10 percent open rate lift translates to material revenue at scale and to noise at small volume. A sender with 50,000 commercial emails per month and a 22 percent open rate sees roughly 11,000 opens — a 7 percent lift adds 770 opens, which on a typical e-commerce conversion path produces maybe 15 to 25 incremental orders. At a €150 average order value that is €2,250 to €3,750 per month against a €1,200 setup plus €99 per month service plus €749 to €1,688 annual VMC. The math works. Recovery takes six to ten months for the first year cost at that volume. A sender at 500,000 monthly volume with the same open rate produces 7,700 incremental opens at the same lift, and the math collapses to two to three months payback. Below 200,000 monthly volume the BIMI investment is a brand-marketing decision, not a financial one. Above that, it usually pays for itself before the first VMC renewal. We tell prospects this honestly because the alternative — selling BIMI to senders who will not see ROI — produces churn that nobody benefits from.

// quick action

Run our BIMI inspector against your domain. The tool pulls the BIMI record, fetches the SVG, validates the Tiny PS profile, downloads the certificate, and confirms DMARC enforcement is at p=quarantine or stricter. If you have BIMI published already, it is the fastest way to find out which of the five common failure modes is the one preventing your logo from rendering.

Agencies that send email on behalf of multiple clients face a problem the protocols were not designed to solve cleanly. DMARC, MTA-STS and BIMI all live in the client's DNS, which means the agency cannot deploy them without DNS access — either delegated or full. SPF can usually be authorised through an include: mechanism that points at the agency's own SPF record, which is the simplest case. DKIM keys can be published either through CNAME delegation pointing at the agency or directly in the client's zone. DMARC is where it gets complicated. The agency cannot publish DMARC for the client's domain because the record has to live at _dmarc.{client-domain} and the client owns the zone. The agency can host the rua reporting endpoint, but the policy decisions, the percentage ramps, the eventual move to p=reject — those have to happen with at least someone on the client side authorised to make DNS changes.

Three operational models cover most agency engagements, ranked by how much DNS control the agency has. The first is full delegation — the client delegates the entire DNS zone to the agency's DNS provider, which lets the agency publish and manage every record without back-and-forth. This is rare. Most clients keep their primary DNS in-house even when they outsource email. The second is selective delegation, where specific records or subdomains are delegated via NS or CNAME — DKIM selectors typically work this way, with mail._domainkey.{client} pointing at mail._domainkey.{agency}.dmarcdelegation.com. The third and most common is no delegation, where the agency provides records in text form for the client's IT team to publish. This last model is operationally awkward but unavoidable. Every record change requires a ticket on the client side, every ramp step requires coordination, and the agency's deployment timeline becomes hostage to the client's DNS change cadence.

Multi-domain DMARC monitoring economics break down at scale in ways that single-domain pricing does not predict. A typical DMARC monitoring service charges €89 per month per domain. An agency managing fifty client domains is looking at €4,450 monthly in raw vendor costs before any agency markup, which is more than most small agencies can absorb without re-pricing the service. The vendor space has responded with multi-domain volume tiers — Red Sift plus PowerDMARC plus Valimail all publish enterprise pricing that drops the per-domain rate substantially above ten or twenty domains, with negotiated rates landing closer to €25 to €40 per domain at the hundred-domain level. Agencies that are running fewer than ten client domains usually pay retail. Agencies above thirty domains negotiate. The pricing inflection point is steep enough that some agencies stand up their own DMARC monitoring stack rather than pay vendor fees — building one is non-trivial but not impossible if the agency already operates the rest of the email infrastructure.

The hardest call in agency engagements is when to require client takeover before publishing strict policies. If the client cannot allocate someone to make DNS changes within forty-eight hours, the migration cannot reach p=reject safely. The standard agency move is to walk the client through p=none for three weeks, gather the inventory, present it back, and ask for explicit signoff on the move to p=quarantine. If the signoff path is unclear, or if the contact who can authorise DNS changes has not responded to two scheduled review calls, stop the engagement at p=quarantine; pct=25 and do not advance further. The operational gap has to close first. We have walked away from two engagements in the last eighteen months because the client could not produce a DNS owner for three weeks running. Better to leave a domain at quarantine than to push it to reject and discover, at the moment legitimate mail starts rejecting, that nobody on the client side can roll the change back inside the SLA window.

Where you are now determines what to do next, and the decision tree is shorter than vendor marketing makes it look. If you have no DMARC record, publish one at p=none today and start collecting reports — that single move buys three weeks of inventory data and costs nothing. If you have DMARC at p=none and have had it for more than three months, the inventory work has been waiting. Schedule the migration to p=quarantine for the next four weeks. If you have DMARC at p=quarantine and stable aggregate reports for the last month, move to p=reject. If you have DMARC at p=reject already, the next question is whether MTA-STS is published — if not, deploy it in testing mode. If MTA-STS is in testing mode and TLS-RPT shows clean reports for four weeks, graduate to enforce. Only after MTA-STS is in enforce should BIMI enter the conversation, and only if the volume justifies the VMC investment. Eight steps, in order, and the order is not negotiable.

The do-it-yourself versus engage-a-specialist decision depends on volume plus complexity plus how much of the next six months an internal team can dedicate to this. A single domain with under five sending sources, a clear DNS owner, and modest volume can usually be migrated by an internal team in eight to ten weeks of part-time effort. Read the relevant RFCs. Set up a free DMARC monitoring tier. Run our free inspector on milestone dates and follow the ramp. Above twenty sending sources, multiple subdomains, or any third-party platform whose admin you do not control, the time cost of doing it internally usually exceeds the cost of engaging a specialist. The break-even is around a hundred to a hundred-and-twenty hours of internal time. At typical fully loaded engineering rates that is €8,000 to €15,000 of internal cost — comparable to the price of an engagement that takes the work off the team's plate and brings the migration in on a fixed timeline with someone else accountable for hitting the dates.

What "done" looks like depends on volume. For a sender below 100,000 monthly commercial emails, done means SPF clean and aligned, DKIM signing on every legitimate sender, DMARC at p=quarantine with active monitoring, and that is enough. The cost of pushing further usually exceeds the marginal benefit at that scale. For a sender between 100,000 and a million monthly emails, done is the same plus DMARC at p=reject, MTA-STS in enforce mode, and TLS-RPT ingestion. BIMI is optional at this tier and depends on whether the brand investment is worth the VMC. For a sender above a million monthly emails, done includes everything above plus BIMI with VMC, multi-domain DMARC monitoring with executive-level reporting, and quarterly aggregate-report reviews to catch drift. Done is not a fixed bar — it scales with what the senders' deliverability is worth and what the cost of regression looks like to the business.

Email authentication in 2026 is not a project anyone finishes — the protocols evolve, the enforcement timeline keeps moving, and last year's compliant configuration drifts into next year's silent failure. What you are buying with the deployment effort is not a checkbox but an operational posture that stays current as the landscape moves. The senders who got DMARC in place during 2024 are now mid-ramp on MTA-STS during 2026. The senders who finish MTA-STS during 2026 will be evaluating whatever protocol becomes the next mandatory layer in 2027 or 2028. The work is continuous. The compounding benefit is also continuous — every month a domain is at full enforcement is a month of reputation accrual at the major providers, and reputation, more than any single technical decision, is what determines whether your mail arrives in the inbox or in spam at the moment that determines a campaign or a transactional flow. Do the work, stay current, treat the next protocol as the predictable consequence of the last one. The senders that approach this stack as a moving target rather than a one-time deployment are the ones who keep delivering.