HELO — email authentication for ERP implementations

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:

"If the domain name already has an SPF record, the record must be updated. Do not create a new one, as a domain must have only one SPF record."

— Odoo 19.0 documentation, Configure DNS records to send emails

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.

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.

Per domain

SPF — record count, syntax, recursive include-counting against the ten-lookup limit, and which all mechanism ends it
DKIM — selectors published directly or delegated by CNAME to Microsoft 365, Google, SendGrid, SES, and the key behind them
DMARC — policy, alignment mode, subdomain policy, and whether rua= points anywhere real
MX — routing, including null MX for domains that correctly accept no mail at all
Reverse DNS and blacklist status on the addresses involved

Two things most checkers skip

We query the domain's authoritative nameservers, not a recursive resolver. Recursive resolvers cache the answer "this does not exist" — so a record published twenty minutes ago reads as missing for as long as that cache lasts, which is precisely when you are looking at it.
We probe the odoo selector. It is the selector Odoo's documentation tells customers to publish, and a generic checker has no reason to know that. On a domain behind an ERP go-live it is the one that decides whether the thing worked.

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.

Things we will tell you to buy elsewhere, or skip

BIMI, MTA-STS and TLS-RPT management
ConnectWise, HaloPSA, Autotask, Splunk and Sentinel integrations
Single sign-on, audit logs, permission and group management
One-click DNS writes into your registrar — we hand you the record, you apply it, because an outsider with write access to your client's DNS is a risk neither of us needs
Multi-year retained history, on a service you started last month

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.

It called a correctly parked domain broken

A domain published MX 0 . — a null MX record, which under RFC 7505 is a deliberate statement that the domain accepts no mail. Our tool reported it as critical: no mail routing. It was the most correct configuration on the whole domain. Fixed, and it now says so.

It reported "no DKIM" on domains whose DKIM was fine

It probed selectors for TXT records only. Microsoft 365, SendGrid, Mailchimp and SES all have you publish a CNAME that points into their zone, so the key lives at the other end. Every domain using them was being reported as unsigned. That is a confident wrong answer about somebody else's mail, which is worse than saying nothing.

Then the fix for that introduced a new mistake

Following the CNAME, it found a selector with no key behind it and called the signatures broken. They were not. Providers publish selectors in pairs and populate whichever one they are currently signing with; an empty second selector is the normal resting state of a rotation. It is now reported as an observation, not a fault.

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

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.
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.
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.
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 the retainer and no setup fee.

What	What you get	Price
First domain	One domain, fully checked, written up. So you can judge the work before paying for any of it.	Freeonce per company
Go-live check	Before handover, and again 30 days later. Two checks, two documents, per client domain.	€150per domain
Estate audit	Your whole client list checked once and ranked by severity, worst first, in one document.	€40per domain minimum €400
Monthly monitoring	Every domain re-checked monthly, DMARC reports read, one findings-only document to you. Cancel with 30 days' notice.	€30per domain / month minimum €250
Enforcement project	One domain from `p=none` to `p=reject`. Fixed price, 6–8 weeks, signed off.	€1,200per domain
Something is on fire	"Our invoices are going to spam." Diagnosis from headers, bounce logs and DNS, with a written cause.	€90per hour

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.

Or judge it on two other businesses we own, which we ran the whole service against and then published in full: three faults on a live domain, before and after, with the mail headers. Both domains are named, so you can check every record on this page for yourself.

Our own domain, since you can check it

Single SPF record, 1 of the 10 permitted lookups. A 2048-bit DKIM key, verified as aligned by two independent receivers — Google and Mimecast — in their own aggregate reports, not in a claim we made up. DMARC moved off p=none to p=quarantine on 6 September 2026, with np=reject for subdomains that do not exist. reject follows once a fortnight of reports confirms every sender, and the date will be published here when it does.

Doing this to ourselves turned up a sender we had forgotten: a transactional service on a subdomain, sending under our name, that nobody had thought about in a year. That is what the discovery step is for, and it is exactly why we do not put a live domain straight to reject on the first day — ours included.

This subdomain sends no mail at all, and says so properly:

# 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"

The go-live worked. Three weeks later the invoices stopped arriving.