Author: williamwhite

DMARC policy not enabled is more than a technical warning, it means your domain is still exposed to spoofed email. In most cases, either no DMARC record exists or the record is set to p=none, which collects reports but does not tell inbox providers to block anything. The fix is to publish an enforced DMARC record at _dmarc.yourdomain.com.

If that warning just showed up in a scanner, the real question is simple: what is missing, and how do you fix it without disrupting legitimate mail? That matters because a domain can look fine in DNS while still offering no real protection. Until DMARC enforcement is in place, attackers can imitate your domain more easily, and mailbox providers have less guidance on how to handle suspicious messages.

What the Warning Actually Means

DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, sits on top of SPF and DKIM. SPF checks which servers may send for your domain, and DKIM signs messages so receivers can verify they weren't altered. DMARC then checks whether those signals align with the visible From address, so the message really matches the domain your customers see.

A DMARC policy not enabled warning usually means one of two things. Either there's no DMARC TXT record at all, or the record exists but uses p=none, which is monitoring-only. That state tells receiving servers to report failures, not act on them, so spoofed mail can still get through.

Why alignment matters

Alignment is the part many owners miss. You can have SPF and DKIM in place, but if they don't line up with the From domain, DMARC still won't enforce anything. That's why checking only SPF or only DKIM gives you a false sense of safety.

A quick internal refresher can help here, and we've covered the basics in our guide to what DMARC is and how it fits into email security. The key point is simple, DMARC turns authentication into a policy decision.

For a small business, this is about more than blocking fakes. Unenforced mail can land in spam or get treated as suspicious by receivers that do enforce DMARC, which hurts outreach and customer trust. If your domain looks “set up” but still says DMARC policy not enabled, you're seeing the gap between visibility and actual protection.

Why You Are Seeing It

The warning shows up for a few common reasons, and each one points to a different kind of fix. A brand-new domain may never have had a DMARC record published. A longer-running domain may have a record stuck at p=none because nobody revisited it after setup. A migration can also break the record if the DNS host changed and the TXT value didn't move cleanly.

Fresh domain versus stale setup

A fresh domain often looks healthy everywhere else, which is why this warning catches people off guard. The site works, mail flows, and SPF may already be present, but DMARC never got added. In that case, the scanner is telling you the domain is visible in DNS but not protected by a DMARC policy.

A stale setup is subtler. Someone may have copied a basic record years ago, chose p=none, and left it there. That record still reports on mail, but it doesn't stop anything, so the warning keeps appearing.

Third-party senders complicate the picture

Newsletters, CRMs, ticketing systems, and payment notices all add moving parts. If those services send mail for you, they can change how SPF and DKIM behave, which affects whether DMARC can enforce cleanly. That's why the warning often shows up right when a business starts sending more serious volume or adds another tool to the stack.

Practical rule: if you recently added a sender, changed DNS providers, or moved your mail platform, check DMARC before you change anything else.

The 2026 adoption gap makes this common, not unusual. Valimail's research found that 75-80% of domains with published DMARC records are stuck in monitoring mode, leaving themselves without actual enforcement protection.

That context explains why your warning is so often just a sign that the domain is still in the broad non-enforcing majority.

How to Check Your Current DMARC Record

Start with the DNS record, not with the scanner's opinion. You need to see what is published before you change anything, because a record that looks fine in a dashboard can still be missing or misread in live DNS. That matters for deliverability and for brand protection, since a weak or broken DMARC setup can leave receivers guessing about whether your mail is legitimate.

A quick lookup with dig or nslookup can show whether a TXT record exists at the DMARC host name. If you prefer a web tool, an MXToolbox-style lookup works as a backup and helps confirm what third parties can see. The point is to inspect the live DNS, not a cached copy or a remembered setting from last year.

Reading the record line by line

A DMARC record is a TXT value made of tags. The main ones are v for version, p for policy, rua for aggregate reports, ruf for failure reports, pct for percentage, sp for subdomains, and the alignment tags adkim and aspf. A record that begins with v=DMARC1; p=none is the clearest sign that you are still in monitoring mode.

A typical monitoring record reads like a label on a file folder, version first, then policy, then reporting and alignment details. If p=none is present, the domain is not enforcing anything yet. If you see a malformed record, or the version tag is missing, the scanner may treat it the same way as no policy at all.

If your DNS is managed at your registrar, check the domain's DNS section there first. If a third-party host handles DNS, look in that platform instead, because that is where the published record lives.

If you need a closer look at SPF before you decide what to fix next, review how SPF records work and how to create one. SPF and DMARC are linked, so confirming both helps you avoid chasing the wrong error.

Step-by-Step Fix

Start by publishing a valid DMARC TXT record at the _dmarc host, then move from monitoring to enforcement in stages. That approach keeps legitimate mail flowing while you learn which systems send as your domain. It also gives you time to catch alignment problems before receivers start treating failed messages differently.

Here's the simplest safe starting point for a small business, v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; adkim=r; aspf=r. That setup tells mailbox providers to monitor, report, and leave delivery alone while you review the results. If you are still sorting out SPF, review how to create an SPF record and why it matters for DMARC alignment, since SPF and DMARC work together and a weak SPF record can make a DMARC rollout look broken when it is really just misaligned.

DMARC policy tags and what each one does

Tag	Purpose	Example value
v	Declares the DMARC version	DMARC1
p	Sets the policy for the domain	none
rua	Sends aggregate reports	mailto:reports@yourdomain.com
ruf	Requests failure reports	mailto:forensics@yourdomain.com
pct	Applies policy to a percentage of mail	100
sp	Sets policy for subdomains	quarantine
adkim	Sets DKIM alignment mode	r
aspf	Sets SPF alignment mode	r

Once the monitoring record is live, you can tighten it to p=quarantine, then to p=reject after your reports show the legitimate sources are aligned. Quarantine tells receivers to place failing mail in spam, while reject stops it at the SMTP layer. That staged path protects inbox placement and brand trust while you move from watching reports to enforcing policy.

A few DNS hosts label the field differently, but the setup is the same. The host name is _dmarc, the value is the policy string, and the save button is the last step. If you send from a custom domain on Typewire, you still use the same DNS record format, so there is no special DMARC version for that setup.

Rolling Out Enforcement Safely

The cleanest rollout is a three-stage path, monitoring, quarantine, then reject. You should not jump straight to reject unless you already know every legitimate sender is aligned. If you do, you risk blocking mail from your own newsletters, invoicing tools, or help desk systems.

Monitoring first, then tightening

A typical monitoring period is two to four weeks at p=none, because you need enough report data to see all the mail streams that speak for your domain. During that time, you're looking for normal senders, not just obvious ones. Marketing platforms, receipt systems, and password-reset mail can all show up in the aggregate data.

After that, many teams move to p=quarantine for another short test window. The exact time matters less than the signal, which is whether legitimate mail still aligns while suspicious mail gets pushed into spam. Once those reports look clean, p=reject becomes the final step.

For a small business with only one or two sending sources, the rollout is often faster because there's less to map. That doesn't mean you skip the monitoring stage, it just means you can review the report set more quickly. The goal is confidence, not speed for its own sake.

Use the reports as your checklist. If every normal sender is aligned and nothing unexpected keeps appearing, enforcement is usually ready.

The global adoption numbers make this staged approach even more sensible. As of August 2026, DMARCDKIM.com's monitoring of 1.3 million domains found that 68.6% have no effective DMARC protection, while only 11.5% have full
protection with p=reject at 100% enforcement. That's a reminder that strong enforcement is still the exception, so a careful rollout matters.

Troubleshooting Common Pitfalls

A first DMARC rollout usually goes off track for ordinary reasons. A third-party sender may be passing SPF or DKIM in its own way, but not aligning with your visible From domain. The report inbox may also be full, closed, or pointed at the wrong address, so you never see the data that should guide the change. A policy change made before those reports are reviewed creates the same problem, because the record is published but the domain still has blind spots.

If reports stop arriving, check the rua address first. A typo in the reporting address or a mailbox that no longer accepts mail can leave you without feedback while DMARC is still publishing. If you use a parser, confirm that it still accepts the inbound XML files and that someone reviews the dashboard, because raw reports are easy to miss once they start piling up.

Common breakpoints and quick fixes

A sender can pass SPF and still fail DMARC if the visible From domain does not align. DKIM can fail for the same reason when the signing domain belongs to a vendor instead of your own domain. The fix is to have the third-party platform sign mail with your domain, or to authorise that sender correctly in its setup so the authenticated domain matches the one recipients see.

Another common slip is setting pct=100 too early. That tells receivers to apply the policy to all mail, which only works once alignment is steady across your normal mail streams. If you still see failures in the reports, lower the rollout pressure first, then tighten the policy after the aligned traffic stays clean.

A practical check helps catch mistakes quickly. Send mail from a source you know is not authorised. If DMARC is working at the stage you chose, that message should be quarantined or rejected.

If you need a clearer picture of how SPF, DKIM, and DMARC fit together, our deliverability note on email sender authentication and inbox placement is useful background. It explains why one misconfigured sender can affect the whole domain.

Verifying It Is Working

A DMARC rollout should start acting like a real filter, not just a line in DNS. Re-run the lookup and confirm the published record now shows p=quarantine or p=reject. Then check that third-party scanners stop reporting the domain as missing a policy. If the warning still appears, the record may be published at the wrong host, or an old value may still be cached somewhere.

The clearest live test is to send a message from a sender you have not authorised. With quarantine, that mail should land in spam or junk. With reject, the receiving server should block it. That difference matters because it shows the policy is protecting your brand and not just sitting there for display.

A simple final checklist

• Confirm the record exists: Make sure the DMARC TXT entry is published at the right host.

• Check the policy: Verify it moved from p=none to p=quarantine or p=reject.

• Review the reports: Look for aligned senders before you tighten further.

• Test the result: Send a non-authorised message and see whether it is blocked or filtered.

For a business using a custom domain on Typewire, the same DNS steps apply, and the result is easy to observe. Your domain stops saying “monitor only” and starts telling receivers how to handle spoofed mail. That gives you a clear signal that your brand is harder to impersonate and your legitimate mail has a cleaner path to the inbox. For a wider view of how authentication supports delivery, see email sender authentication and inbox placement.

Your emails can be genuine, authenticated, and still look easy to fake in a crowded inbox. BIMI changes that by displaying a verified brand logo next to supported messages, giving recipients a faster visual cue that the email is really from you.

For any business sending invoices, newsletters, or account updates, that extra recognition can matter. BIMI will not improve deliverability, but it can improve trust at a glance. The catch is simple, it only works after your domain has the right authentication foundation in place with SPF, DKIM, and DMARC.

What is BIMI?

BIMI stands for Brand Indicators for Message Identification. It's an email display standard, not a delivery system, and it lets supported inboxes show your logo beside messages that already pass authentication checks. The simplest way to think about it is as a verified badge for email, except the badge only appears when the sender has done the security work first.

That distinction matters. BIMI doesn't make an email more likely to arrive, and it doesn't replace SPF, DKIM, or DMARC. It sits on top of them as a visual trust layer, so recipients can spot a legitimate brand more quickly in a crowded inbox. Typewire's guide to sender authentication and deliverability fits neatly here, because BIMI only makes sense once the basics are already in place.

Why small businesses keep asking about it

A lot of owners don't care about the acronym. They care about whether their emails look trustworthy when they land. That's the appeal of BIMI, especially for a small team competing with larger brands that already look familiar to customers.

Practical rule: if your messages still fail authentication checks, BIMI won't rescue them. It only helps after your domain is already behaving like a well-managed sender.

The reason BIMI gets attention now is that it's no longer experimental. The BIMI standard was formally published in 2020, and by mid-2024 it had grown to 33,924 unique and valid records. Of that total, approximately 3,450 records included a link to a VMC (about 10.2%). That shows the idea has moved from niche to operational, but also that most deployments are still selective and carefully controlled.

How BIMI displays your logo in inboxes

When BIMI works, the logo does not travel with the email itself. The recipient's mailbox provider checks the message, confirms the sender's authentication status, and then looks up the BIMI record in DNS. If everything lines up, the provider fetches the brand logo and, where required, verifies the mark certificate before showing the brand logo in inbox.

That's why BIMI feels visible to users but invisible in transit. It's a lookup and validation process that happens behind the scenes, which keeps the system tied to domain ownership instead of simple image hosting.

What happens in the inbox

The flow is easier to understand if you break it into a few steps. First, your email is sent. Then the receiving system checks whether the domain meets the BIMI conditions already discussed, including enforced authentication. After that, it pulls the logo information from DNS and decides whether the client supports display.

Major providers support it only in participating clients, including Gmail, Yahoo, and Apple Mail. That means the logo can improve recognition inside those inboxes, but not every mailbox on the internet will show it. Sectigo's overview of BIMI support is useful for understanding that limitation.

A short video walkthrough can also help if you're visual:

The practical takeaway is simple. BIMI is only useful where the client supports it, and the logo appears because the provider has already decided the sender deserves that visual trust signal. If a message is poorly authenticated, or if the recipient uses a client that doesn't participate, nothing appears.

The biggest misconception is that BIMI “adds security” by itself. It doesn't. It makes existing security visible to the user.

BIMI requirements DMARC and VMC

BIMI has a reputation for being about logos, but the real gatekeeper is authentication policy. The domain must use enforced DMARC, not monitoring only, and the BIMI Group and Red Sift both state that the policy must be p=quarantine or p=reject, with pct=100 for the relevant domain. In other words, BIMI only works when you've already chosen to block or quarantine unauthorised mail. Red Sift's BIMI guidance is explicit on that point.

The three things you need

The technical list is short, but each item carries real work. You need strong authentication, a compliant logo, and the publishing record that ties them together.

• Enforced DMARC policy: Your domain must move beyond monitoring. If you're still at a reporting-only stage, BIMI won't display.

• Valid mark certificate: Many providers want proof that the logo belongs to you. That's where a VMC certificate comes in.

• Correct logo file: The image must meet BIMI's file rules, which are stricter than a normal web graphic.

A VMC is especially important for organisations that want broad support in inboxes that verify the mark more tightly. For some small businesses, that extra legal and administrative step is the point where BIMI starts to feel expensive rather than elegant. The standard also recognises the practical reality that a logo is only trustworthy if the brand can prove rights to it.

Why the logo file matters

Your logo isn't just a design asset in this context. It has to be an SVG Tiny Portable/Secure (SVG P/S) file, usually square, hosted over HTTPS, and kept at 32 KB or smaller. Common guidance also says the SVG should avoid scripts, external references, animations, and embedded raster images. Sender's BIMI implementation guide covers those requirements clearly.

That sounds fussy, but the reason is straightforward. Mail providers want a safe, consistent file they can fetch quickly and trust. A messy SVG or a weak DMARC setup can stop the logo from showing, even if the rest of your mail flow works fine.

For a plain-language DMARC refresher, this Typewire explanation of DMARC is a good companion piece. BIMI sits on top of that foundation, so understanding DMARC first saves a lot of frustration later.

How to set up a BIMI record

A BIMI record is just the DNS entry that points mailbox providers to your verified logo. The record itself is simple, but you shouldn't treat it as the first step. It comes after authentication is hardened, the logo is prepared correctly, and any required certificate work is finished.

The usual record format uses a BIMI version tag and references to your logo and certificate. A common syntax pattern looks like v=BIMI1; l=...; a=...;, where the version identifies the standard, l points to the logo location, and a points to the authority or certificate reference. If the record is malformed, the provider may ignore it completely.

A practical setup sequence

Start with your domain authentication. If DMARC isn't enforced, stop there and fix that first. BIMI won't help if the sender policy still allows unauthorised mail to float around unchecked.

Next, prepare the logo. It needs to meet the SVG and hosting rules already mentioned, because mailbox providers don't want to clean up a bad file on your behalf. Then, if your provider requires it, apply for a mark certificate through a trusted certificate authority and complete the verification steps.

Finally, publish the BIMI TXT record in DNS and test it in the mailbox clients you care about. That last part matters because inbox support is not universal. A record can be valid and still never appear in every client you use.

Here's the operational trade-off. A clean DNS change is easy. The time-consuming part is usually the work before that, especially if your authentication posture still needs attention or your logo assets aren't ready. The setup feels technical because it is. It's really a proof chain, not a branding shortcut.

Is BIMI worth it for small businesses?

For many small businesses, BIMI is attractive but not urgent. It can make legitimate messages easier to recognise, and it can support trust in a way that plain text email can't. But the value only shows up after you've paid the cost of getting authentication right, and that cost is often the decision point.

That's why I'd frame BIMI as a second-stage project, not a first move. If your team is still cleaning up SPF, DKIM, and DMARC, that work usually deserves priority. A logo in the inbox looks nice, but it won't fix a sender that can't prove who it is.

When it makes sense

BIMI starts to make more sense when email is core to your sales, support, or billing flow. If customers regularly receive invoices, order notices, or appointment confirmations from you, a recognisable logo can reduce hesitation and help people spot your messages faster. That's especially true when you're competing against phishing attempts that imitate real brands.

It also makes more sense when your brand already has trademarked assets and the team can handle the certificate process. The more organised your mail programme is, the less painful BIMI becomes. The more ad hoc your setup, the more BIMI can turn into another maintenance task.

When to hold off

You should probably wait if your budget is tight, your sending volume is modest, or your email stack changes often. The North American market shows how concentrated adoption has become, with 8,670 active U.S. BIMI certificates, or 42.9% of the global total, as of July 2, 2026, and certificates issued rising roughly 12-fold from 2021 to 2025. That trend says BIMI is getting mainstream attention, but it also shows the ecosystem is still weighted toward larger, more mature deployments. VMCcerts' state of inbox trust report makes that clear.

For a smaller operation, that can translate into a simple question. Do you want to invest in a trust badge now, or make sure your mail is fully authenticated and stable first? In many cases, the second option is the smarter one.

If you're deciding between providers, our comparison of the best email hosting for small businesses is a helpful next read. My view is straightforward, DMARC mastery comes first, and BIMI comes after the foundation is solid. Once your sender identity is dependable, the logo becomes a bonus, not a distraction.

---

If you want help building a stronger email foundation before you think about BIMI, Typewire gives you private email hosting, custom domains, and straightforward security controls without the usual big-tech noise. We're a Canadian provider, and we focus on email infrastructure that makes authentication, trust, and day-to-day sending easier to manage. Visit Typewire to see how our approach fits your business.