Signume
VMCEmail authenticationDMARC

What Are the Technical Requirements for a VMC?

SPF, DKIM, DMARC at enforcement, a square SVG Tiny P/S logo, and a BIMI DNS record. Here is every technical prerequisite for a VMC, and where projects stall.

By Steven M.6 min read

A Verified Mark Certificate has five technical prerequisites: SPF, DKIM, DMARC at an enforcement policy, a compliant square SVG logo, and a BIMI record in DNS. The certificate itself is issued only once the first three are in place, and your logo only appears once all five are.

None of these are difficult on their own. The difficulty is that they have to be true across every system that sends mail using your domain, and most organizations do not have a complete list of those systems.

1. SPF, correctly scoped

SPF (Sender Policy Framework) is a DNS record listing which servers are permitted to send mail for your domain. It is the oldest of the three authentication protocols and the one most likely to have quietly drifted out of date.

Two things matter here. The record has to cover every legitimate sender, including the ones nobody thinks of: your marketing platform, your CRM, your invoicing tool, your helpdesk, your recruitment system, the transactional service inside your product. And it has to stay within the ten DNS lookup limit that SPF imposes. Exceed that limit and the record fails to evaluate, which quietly breaks authentication for everything.

We flatten over-long SPF records regularly. It is a common finding on domains that have accumulated tools over several years.

2. DKIM, on every sending stream

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each message, which the receiving server verifies against a public key in your DNS. It proves the message was not altered and that it came from a system holding your key.

The requirement is per stream. Every platform sending on your behalf needs its own DKIM key published and its signing enabled. A stream that is not signed will not pass DMARC unless SPF happens to align, and relying on that is fragile.

Use a key length of 2048 bits where the platform supports it.

3. DMARC at enforcement

This is the requirement that decides whether the whole project moves. DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM, checks that the authenticated domain aligns with the domain shown to the recipient, and tells receiving servers what to do when that check fails.

Your policy has to be p=quarantine or p=reject. A monitoring policy of p=none is not enough, and no mailbox provider will display your logo while you are on one.

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com"

Two details that catch people out. If you use pct= to phase in enforcement, a value below 100 is treated as not being at full enforcement for BIMI purposes. And the subdomain policy tag sp= matters if you send from subdomains, because a permissive sp=none under a strict parent policy undermines the whole thing.

Getting to enforcement without breaking legitimate mail is genuinely the hardest part of a BIMI project, and it deserves its own explanation. We wrote one: why DMARC enforcement is mandatory.

Your logo has to be supplied as an SVG conforming to the SVG Tiny Portable/Secure profile, usually written SVG Tiny P/S. This is a deliberately restricted subset of SVG, stripped of anything that could carry executable or external content.

The practical requirements:

  • Square aspect ratio. Not "roughly square". Square, with your mark sitting comfortably inside it.
  • A solid background. Transparency is not permitted.
  • No scripts, no animation, no external references. No linked fonts, no embedded raster images, no hyperlinks.
  • A title element describing the mark.
  • Served over HTTPS from a URL that stays stable.
  • Small. Keep the file well under 32 KB.

Almost no brand has this file already. A logo exported from a design tool will usually fail validation on several counts at once, and horizontal wordmarks have to be reworked into a square lockup, which is a design decision rather than a technical one. This is the step where brand teams need to be involved rather than just informed.

5. The BIMI record

Last, a TXT record on your sending domain:

default._bimi.yourdomain.com. IN TXT "v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem"

The l= tag points at the SVG. The a= tag points at the certificate, served as a PEM file. Both URLs have to be reachable over HTTPS and both need to stay reachable, because inboxes fetch them.

default is the selector. You can run other selectors if you need different logos on different streams, which matters when you are covering several brands or subdomains. That is covered in can one VMC cover multiple domains.

Publish this record last. It is the only piece that depends on all the others, and publishing it early just produces a record that points at nothing.

What is not a technical requirement

Worth stating plainly, because it comes up. You do not need to change email provider. You do not need to change your sending infrastructure. You do not need MTA-STS, BIMI does not require it, though it is good practice for other reasons. And you do not need a separate certificate per email platform.

What you do need is the registered trademark, which is a legal prerequisite rather than a technical one, and the one most likely to block you. See is a registered trademark required.

Where projects actually stall

In our experience the technical work divides into two very different halves.

The DNS and SVG work is finite and predictable. Records get written, files get converted, validation gets run. A competent team completes it in days.

DMARC enforcement is neither finite nor predictable at the start, because it depends on discovering every system that sends as you. That discovery takes weeks of report analysis, and it is where the risk sits: move to enforcement too early and you start silently discarding legitimate mail from a system nobody remembered.

Signume runs this sequence for EU and UK brands, including the DMARC discovery work and the SVG preparation, so the certificate application is submitted once and passes.

Frequently asked questions

What are the technical requirements for a VMC? SPF and DKIM configured across all sending streams, DMARC at p=quarantine or p=reject, a square SVG Tiny P/S logo served over HTTPS, and a BIMI TXT record referencing both the logo and the certificate.

Does DMARC have to be at reject, or is quarantine enough? Either works. Both p=quarantine and p=reject count as enforcement. A p=none monitoring policy does not, and a pct= value below 100 is treated as not fully enforced.

What is SVG Tiny P/S? A restricted profile of SVG required for BIMI. It forbids scripts, animation, external references and transparency, and expects a square image with a title element and a solid background.

Do I need to change my email provider to get a VMC? No. A VMC works with your existing sending infrastructure. What matters is that every stream authenticates correctly and that your domain reaches DMARC enforcement.

In what order should the technical work be done? Trademark confirmation first, then SPF and DKIM, then DMARC to enforcement, then the SVG, then the certificate application, and the BIMI record last, since it depends on everything before it.

Ready to check your domain?

Check your domain in 30 seconds, free.

We use cookies

We use necessary cookies to run this site. Analytics only load if you accept. Privacy Policy