Your emails are going to spam. It is almost always three DNS records, and we fix them in a day.

The fix · fixed price · 24 hours

Three tiers. Pick the one that matches how many things send mail as your domain.

Every tier ends the same way: the records written out exactly as they must be published, a before/after check from the authoritative nameservers, and a written explanation of what was wrong. You paste the records, or your web person does, and we verify. We never ask for your DNS login.

After the fix, most people want someone to keep watching. That is the monitoring line in the price list: €29 per domain per month, and we read the reports — you do not.

Card or bank payment through Stripe; VAT handled at checkout (EU VAT ID → reverse charge). Work starts the moment it is paid — you type in the domain, we do the rest. Not sure which tier? Email the domain and we tell you.

Why it breaks

The instruction is right there in the documentation, and it is the exact thing people get wrong

Odoo's own documentation tells the customer to add its include to the SPF record they already have, and warns them in writing:

So the person doing it adds a second record instead of editing the first. Both records now exist. Under RFC 7208 §4.5 the receiver does not pick the stricter one, or the first one — SPF is discarded for the domain entirely, and reported as permerror.

Nothing bounces. Nobody gets an error. Mail keeps flowing on DKIM alone until a receiver somewhere decides it doesn't like the sender, and then a client rings you, because as far as they are concerned the ERP is the thing that changed.

The same mistake appears without an ERP anywhere near it — most often as a leftover from a domain migration, one record added beside another instead of replacing it. We find it on implementation partners' own domains, not only their clients': two records sitting there while the DMARC reports record it daily into a mailbox nobody opens.

A real one · 8 September 2026

One domain, one day, before and after — in the receiver's own headers

This is a domain belonging to one of our own companies, so we can show it without asking anyone. Three mailboxes on Google Workspace. Every message they sent was landing in spam, including mail to our other company next door. The cause was not Google and not the content: the domain had lapsed at the registrar for a while, and when it came back the registrar had put its stock DNS template on it — no SPF, no DKIM, and a DMARC record that says quarantine anything that fails. Which was everything.

Here is what the receiving Gmail server wrote on a message sent the evening before the fix. Nothing here is our tool's opinion; it is Google's:

# Authentication-Results, mx.google.com — BEFORE
spf=none   (kruno@… does not designate permitted sender hosts)
dkim=pass  header.i=@mstv-ch.20251104.gappssmtp.com   ← Google's fallback domain, not ours: unaligned
dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE)

The fix was three records at the registrar — an SPF record naming Google, a DMARC record with a reporting address that is actually read, and a 2048-bit DKIM key generated in the Google Admin console — then waiting out the resolvers' negative cache and switching DKIM signing on. Same sender, same recipient, next morning:

# Authentication-Results, mx.google.com — AFTER
spf=pass   (domain of kruno@… designates 209.85.220.41 as permitted sender)
dkim=pass  header.i=@mstv.ch header.s=google   ← signed as the domain itself: aligned
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE)

Delivered to the inbox. This is the Basic tier, exactly as sold: one domain, one sending platform, fixed inside a day, verified from the receiving side rather than from a checker that would have said "looks fine" the moment the records were typed in. The one thing we would add for a paying client that we did not do here is monitoring — because a domain whose registration lapsed once will do it again, and the next lapse puts the template back.

What we actually check

Public DNS, queried at the source, with the unknowns marked as unknown

No mailbox access. No credentials. No data processing agreement to negotiate before anyone can start. Everything below is readable from outside, which is exactly why it is also readable by whoever is deciding whether to trust your client's mail.

What we do not do

There is no dashboard. That is deliberate, and it is most of the point.

You can buy a DMARC platform for about $18 per domain per month. It is good software. It parses the XML, draws the graphs, and waits for you to log in.

The problem was never the parsing. It is that reading the reports, deciding which of a client's four sending sources is a forgotten mailing tool and which is the invoicing system, and judging when it is safe to move a live domain to p=reject — that is an hour a week per client that an ERP consultant is never going to spend. So the login goes unused and the domain sits at p=none forever, collecting evidence nobody reads.

We are the hour. Not the dashboard.

If you need those, EasyDMARC and dmarcian both sell them properly and we will say so. If you already own one of them, better — you have paid for the data and are not using it. We will read yours.

How you can tell whether we are any good

Three times our own tool was wrong, and how we found out

Anyone can publish a list of checks. The thing worth knowing about a diagnostic is what it does when it is mistaken, so here are three occasions ours was — all caught before a word of it reached the domain's owner.

There is a fourth category, and it is the one that matters most: a lookup that fails is not a record that is absent. Timeouts, SERVFAILs and unreachable nameservers are reported as could not be determined and never as missing. A checker that collapses those two will eventually tell you a DMARC record is gone when it is merely unreachable — and the natural response, publishing a second copy, is how domains end up with exactly the duplicate-record problem at the top of this page.

Our reports carry a section headed What we could not determine. If it is empty we say so. It is usually not empty.

How it runs

Built to fit a handover, not to add a project

For a single fix the sequence is short: you email the domain, we reply with a payment link and three questions (which platforms send as this domain, who can edit DNS, and where DMARC reports should go), the records arrive within the tier's delivery time, and we verify once they are published. For implementation partners it runs like this:

1. Before handover. We check the client's domain and send you a one-page result. If something is wrong you get the record to publish, written out, with a note on what breaks if you apply it the obvious way instead.
2. Thirty days after go-live. The same check again. This is the one that catches the change somebody reverted, or the third-party tool that appeared after launch.
3. Every month after that. Every domain on your list re-checked, DMARC reports read, and one document sent to you containing only what changed and what needs doing. If nothing changed, the document says that in one line.
4. When you want a domain finished. We take it from p=none to p=reject over six to eight weeks — find every legitimate sender, authorise them, move the policy in stages, and sign it off.

Everything arrives as a written document. Reports go to you, in your name if you want them that way; whether your client ever hears our name is your decision, not ours.

Price

Published, because you should not have to book a call to find out

Euro, excluding VAT, invoiced from Croatia with an EU VAT ID. Payment by card through Stripe. No minimum term on monitoring and no setup fee.

Fix

Keep it fixed

For ERP and web implementation partners

Yes, monitoring costs more per domain than a DMARC platform licence. A licence gives you the data. This gives you the reading of it, which is the part that was never the software's job.

Who you would be dealing with

A small company, deliberately narrow

HELO is a service of VSN j.d.o.o., a software company in Osijek, Croatia. It is small. The person who answers your email is the person who runs the checks and writes the reports, and on a larger piece of work a collaborator joins — named, and told to you in advance.

We have no certifications in this, no logos to show you, and no testimonials, because we would have to invent them. What we have instead is a tool you can watch being wrong, a method you can reproduce with dig, and reports that mark their own limits. Judge it on the free domain.

# the site that sells email authentication, configured to prove it
helo.vsn.hr        MX    0 .          ← null MX, RFC 7505
helo.vsn.hr        TXT   "v=spf1 -all"
_dmarc.helo.vsn.hr TXT   "v=DMARC1; p=reject; rua=mailto:office@vsn.hr"

Contact

Send one domain. You will get the report back, not a sales sequence.

Email office@vsn.hr with a domain name in it. That is the whole process. You will get a written reply the same working day, and the report within two. If you already know you want it fixed, say which tier — Basic, Standard or Premium — or order it directly from the fix section; work starts when it is paid.

We work in writing — email, or WhatsApp if you prefer. No discovery calls, no demos, no onboarding sequence. If a written answer is not enough for a decision, we have not written it well enough.