DEV Community: Jose Pollman

Which EU countries let you check a company for free: a status table

Jose Pollman — Fri, 07 Aug 2026 15:24:10 +0000

If you are building anything that touches European business data — onboarding, invoicing, KYB, fraud checks — you will eventually ask the same question I did: which countries can I actually get company data from, for free, without an account?

I could not find this written down anywhere, so I worked it out the hard way while building a supplier checker. Here it is.

The baseline: VIES

The European Commission runs VIES, which validates VAT numbers across all 27 member states plus Northern Ireland (XI). It is free, it needs no key, and it is the obvious starting point.

Two things about it are worth knowing before you build on it.

It answers one question: is this VAT number currently registered. It does not tell you the company is solvent, trading, or that it has not been struck off. A company in liquidation keeps a cleanly resolving VAT number for months, because deregistration and insolvency are run by different authorities on different timetables.

Name and address are returned for 25 of the 28 jurisdictions, not all of them. Germany and Spain confirm registration but publish no company name through VIES. I tested three valid numbers for each before accepting that. For those two, a yes/no is genuinely all you can honestly show.

Where you can go further, free

Ten countries publish enough through a national register to add something meaningful on top of VIES:

Country	Free register	Reports company state	Reports VAT-active
Romania	yes	yes	yes
Poland	yes	—	yes
Slovenia	yes	—	yes
Estonia	yes	yes	—
France	yes	yes	—
Greece	yes	yes	—
Bulgaria	yes	yes	—
Latvia	yes	yes	—
Czechia	yes	—	—
Finland	yes	—	—

Company state means the register tells you whether a business is inactive, in liquidation, bankrupt, insolvent, terminated or struck off. This is the valuable column, and only six countries have it.

VAT-active matters more than it sounds. VIES cannot distinguish "this is a real company that is not VAT-registered" from "this number belongs to nobody". Three registers can.

Note that Czechia and Finland are in the list but in neither of the other columns — they confirm a name and little else. Worth knowing before you design a feature around "the ten countries".

Where you cannot

No free company-data source I could find at all: Germany, Austria, Italy, Spain, Portugal, Lithuania, Luxembourg, Cyprus, Malta.

Behind an account, an API key or a payment: Hungary, Ireland, Belgium, Denmark, Croatia, Netherlands, Sweden.

Hungary deserves its own paragraph. It does return name and address through VIES, so it looks fine at first. What is missing is company state — and I found six separate official routes to it, every single one behind a CAPTCHA. That is not a technical problem you can engineer around. It is a policy decision, and the answer is no.

The UK, post-Brexit

Great Britain left VIES on 1 January 2021. GB VAT numbers now return invalid there, and HMRC's own VAT checking API requires an approved application. If you do not hold one, what you can do for free is verify the official check digit locally — which proves a number is impossible, never that it exists — and then link people to the free checker on GOV.UK.

Northern Ireland is a separate case: XI numbers go through VIES normally.

Poland is the outlier worth knowing about

Poland is the only EU member state where you can check whether a bank account belongs to a company.

The Ministry of Finance publishes the accounts that VAT-registered businesses have declared, on what is known as the white list. It exists because paying into an unlisted account has tax consequences for the payer, so there is a statutory reason for the data to be public and current.

Nowhere else in the EU can you do this from public data. Everywhere else, an IBAN tells you the country and the bank and absolutely nothing about who owns it.

Practical notes for anyone building this

Greece files VAT under EL, not GR. Every ISO country code list will tell you GR. VIES wants EL. This will cost you an afternoon if nobody warns you.
Northern Ireland is XI.
Implement the check digits locally. They are published arithmetic, they work offline, and they work when a registry is down. I did 19 countries and it is one of the highest value-per-line things in the project — it catches a transposed digit instantly with no network call.
Assume the registers will break. They change their markup without warning, and that is the real maintenance cost. It is also why I have not shipped an API: I would rather a scraper break for me than inside somebody else's production pipeline.
VIES has downtime, disproportionately at weekends and quarter ends. National registers are a useful fallback for the ten countries above.

Why the gaps matter more than the coverage

The temptation when you build something like this is to present the ten countries as "European coverage" and let people assume the rest works too. It does not, and the honest version is more useful: sixteen of twenty-seven member states have no free route to company status at all.

If you are relying on this data for anything that matters, know which column your country is in.

I keep a running version of this against a free tool I maintain — a worked example is here if you want to see what the combined output looks like. Happy to answer questions about any specific register in the comments.

Four things get called "someone is spoofing my domain". DMARC fixes one.

Jose Pollman — Wed, 05 Aug 2026 13:52:25 +0000

Someone forwards you a message. It has your company's address on it and you did not send it. The obvious next move is to go and publish p=reject.

Wait. Four quite different attacks get reported in exactly those words, and DMARC only fixes one of them. Enforcing against the wrong one costs weeks and changes nothing.

Triage first: look at the actual From address

Not the display name your mail client shows you. The address.

What you see	What it is	What fixes it
`billing@example.com` — your exact domain	Domain spoofing. Anyone can write any address into a `From:` header.	SPF + DKIM + DMARC at `p=reject`
`Your Company <randomuser@gmail.com>`	Display-name impersonation. The address is theirs. Only the label is yours.	Nothing in your DNS. Receiver-side rules and staff training.
`billing@examp1e.com`, `example-inc.com`	Lookalike domain. A different domain that reads like yours.	Monitoring and takedowns. Your DMARC record has no authority over it.
Genuinely from your account, in your Sent folder	Compromised account.	Password, revoke sessions, and check for forwarding rules the attacker added.

Only the first row is domain spoofing. It's also the only one where a stranger can put your domain in front of your customers, which is why it's worth fixing first and why DMARC exists.

If you can't tell which you're looking at, the raw headers will settle it — the Authentication-Results header names the domain that actually authenticated.

"I'm getting bounces for mail I never sent"

This is how most people discover the problem, and it's alarming in a misleading way.

A spammer sent to a few thousand addresses with your address forged as the sender. Some of those didn't exist. Those servers bounced the messages back to the forged sender — you.

It does not mean anything of yours was accessed. No password is required to type your address into a header. It's evidence your domain is being forged, and a good reason to get to enforcement, but it is not a breach.

One exception worth ruling out immediately: if the bounces correspond to messages that appear in your own Sent folder, that's a compromised account, not spoofing. Different problem, much more urgent.

Why fixing the real thing takes weeks

Worth understanding the mechanism, because it explains the timeline.

Nothing in the original design of email verifies the From: header. SMTP accepts whatever a sender writes. SPF, DKIM and DMARC are a layer bolted on afterwards that lets you publish a claim about who may send as you, and lets receivers act on it.

1. Get SPF or DKIM passing for every legitimate sender. Not just your mailbox provider — the CRM, the invoicing system, the ticketing tool, the booking form. And each must pass aligned with your domain. A vendor sending from its own envelope domain can pass SPF perfectly and still fail DMARC.

2. Publish DMARC at p=none with a reporting address.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

This blocks nothing. It tells you who is sending as you — including the forger, and including the three internal systems you'd forgotten about.

3. Read the reports for four to six weeks, then enforce. Long enough that monthly and quarterly senders show up. Then p=quarantine, then p=reject.

There's no shortcut here that doesn't risk blocking your own mail.

The `sp=` footgun

Attackers move to subdomains once the parent is unusable, because billing.example.com is just as convincing to a recipient and is usually left unprotected.

Subdomains inherit p= unless you override it, so a bare p=reject already covers them.

The mistake is publishing sp=none alongside it — almost always copied from an example record found somewhere — which reopens precisely the door you just shut. If you don't have a specific reason for an sp= tag, don't publish one.

What DMARC will not do, whatever the vendor said

It does not stop lookalike domains. examp1e.com belongs to someone else. Your DNS says nothing about it, and p=reject on your domain has no effect on theirs.
It does not stop display-name impersonation. That message is properly authenticated for the sender's own domain. There is no authentication failure for DMARC to act on. This is now the more common attack against small organisations — precisely because DMARC adoption made the easy version harder.
It does not stop your name being used in the message body.
It does not apply retroactively. Mail already delivered stays delivered.

What it does is remove your domain from the attacker's toolkit. That's worth the few weeks. The rest is a filtering and training problem, not a DNS one.

I maintain notspoofed — a free, no-signup SPF/DKIM/DMARC checker. It reports whether your policy is actually enforcing and flags an sp= tag that's quietly weakening it, which is the failure above that people don't find on their own. There's also an in-browser header analyzer for the triage step; headers are parsed locally and never uploaded. Source on GitHub under MIT.

If you've had the bounce-flood experience and it turned out to be something other than plain domain spoofing, I'd be interested to hear which of the four it was.

What I learned reading ten EU company registers

Jose Pollman — Wed, 05 Aug 2026 00:34:46 +0000

I built a free tool that checks a supplier before you pay them. The part that took most of the work, and taught me most, was reading ten national company registers instead of relying on the EU's own VIES service.

This is what I found out, mostly so the next person doesn't have to.

The problem with "the VAT number is valid"

VIES — the European Commission's VAT Information Exchange System — answers one question: is this VAT number currently registered. That sounds like the question you want answered. It isn't.

A company that has gone into liquidation keeps a cleanly resolving VAT number in VIES. So does one that has been struck off the register. Deregistration and insolvency are run by different authorities on different timetables, and the gap between "this company has stopped being a going concern" and "the VAT number stops validating" can be months.

So you can check a supplier, get a green tick, and be looking at an insolvency estate.

The national registers know. VIES doesn't ask them.

Ten registers, and what each actually gives you

I found free, public, machine-readable-enough sources for ten countries: Bulgaria, Czechia, Estonia, Finland, France, Greece, Latvia, Poland, Romania and Slovenia.

They are not equivalent, and this is the thing I'd have liked written down somewhere before I started:

Six of them report company *state* — inactive, in liquidation, bankrupt, insolvent, terminated, ceased, struck off: Romania, Estonia, France, Greece, Bulgaria, Latvia. This is the valuable one.
Three report whether the company is actually VAT-active — Poland, Romania, Slovenia. That matters more than it sounds, because VIES does not distinguish "this is a real company that isn't VAT-registered" from "this number belongs to nobody".
The rest give you a name and not much more.

Czechia, for instance, is in the ten but in neither of the other two groups. It confirms a name. That's it. Worth knowing before you build a feature around it.

Poland is the interesting one

Poland is the only EU member state where you can check whether a bank account belongs to the supplier.

Not because of anything clever — because the Ministry of Finance publishes the accounts that VAT-registered businesses have declared, on what's known as the white list. It exists because paying an unlisted account has tax consequences for the payer, so there's a statutory reason for the data to be public and current.

Nowhere else in the EU can you do this from public data. In every other country, an IBAN tells you the country and the bank and nothing whatsoever about who owns it.

Where it gets ugly

Nine countries have no free company-data source I could find at all: Germany, Austria, Italy, Spain, Portugal, Lithuania, Luxembourg, Cyprus, Malta.

Seven more are gated behind an account, an API key or a payment: Hungary, Ireland, Belgium, Denmark, Croatia, Netherlands, Sweden.

Hungary deserves a specific mention. It does return a name and address through VIES. What's missing is company state — and I found six separate official routes to it, every one of them behind a CAPTCHA. That's not a technical problem, it's a policy one, and no amount of engineering fixes it.

Germany and Spain are a different flavour of annoying: VIES confirms registration for both, but neither publishes a company name through it. I tested three valid numbers for each to be sure I wasn't holding it wrong. For those two, all you can honestly show is a yes/no.

Small things that cost me time

Greece files VAT under EL, not GR. Every list of ISO country codes will tell you GR. VIES wants EL.
Northern Ireland is XI. Post-Brexit, NI numbers go through VIES; Great Britain numbers don't.
GB is not available unless you hold an approved application for HMRC's VAT API. I don't. What you can do for free is verify the official check digit locally — which proves a number is impossible, never that it exists — and then link to the free checker on GOV.UK, which answers the user's actual question in ten seconds.
Check digits are arithmetic, so they work when the registry is down. I implemented them for 19 countries. This turned out to be one of the highest-value-per-line things in the project: it catches a transposed digit immediately, offline, with no network call.
Registers change their markup without warning. This is the real maintenance cost, and the main reason I haven't shipped an API — I'd rather a scraper break for me than in someone else's production pipeline.

The design decision I'd defend hardest

The tool shows five separate results and deliberately refuses to combine them into a score or a "safe to pay" verdict.

That's not modesty, it's the whole point. The most common invoice fraud is bank-detail redirection: a real supplier's mailbox is compromised and only the account number on the invoice changes. The company is real. The VAT number is valid. The goods were delivered. The sanctions check is clean. Every individual check passes, because everything is genuine except the destination of the money.

A single green tick would be a confident lie about the one attack that actually happens. So there are five answers, and a standing instruction to confirm bank details by phone on a number you already had.

If you're building anything in this space, that's the trap: the aggregate score is the most saleable feature and the most dishonest one.

Boring stack, on purpose

The whole thing runs in about 300 MB on a single VPS in Helsinki. No account, no cookies, no ads, no third-party analytics. The full IBAN is never stored or displayed — only country code, check digits and last four — and saved results are deleted after 90 days.

There's no API and no bulk checking. For a developer audience that's probably the whole review, and it's a fair criticism. It's one person maintaining sixteen fragile integrations, and an API is the fastest way to turn that into an operations job I can't staff.

A worked example, if you'd rather see the output than type a VAT number: vetthisvendor.com/example

Happy to go into any of the registry scraping in the comments — that was most of the work and most of the pain.

Every DKIM checker is guessing — including mine

Jose Pollman — Tue, 04 Aug 2026 12:53:34 +0000

Almost every DNS record you care about can be looked up. Ask for the SPF record, you get it. Ask for _dmarc, it's there.

DKIM doesn't work that way, and almost nobody building tooling around it says so out loud.

You cannot list selectors. At all.

A DKIM public key lives at:

<selector>._domainkey.<domain>

The selector is an arbitrary label chosen by whoever set up signing. Google Workspace uses google. Microsoft 365 uses selector1 and selector2. Mailchimp uses k1. Amazon SES generates three random tokens per identity.

There is no DNS query that returns "every name under _domainkey". ANY doesn't do it. Zone transfers are refused by every sane nameserver. To read a DKIM key, you must already know its name.

Which means every DKIM checker in existence — mine included — is guessing from a list.

So when a tool tells you "no DKIM found", the honest translation is:

We tried our list of forty or fifty common selectors and none of them matched.

That is a genuinely different statement from "you have no DKIM", and the gap between the two is where people waste afternoons.

Amazon SES makes it concrete. Its selectors are random tokens. No guess list will ever find them. A domain signing perfectly through SES will read as "no DKIM" on every guessing tool, forever. If your checker doesn't tell you that, it's misleading you by omission.

The opposite failure: selectors that were never there

Now the direction that's actually dangerous, because it produces confident output instead of a shrug.

Some domains publish a wildcard DNS record, which answers every name under the domain. On such a domain:

dig +short TXT totally-made-up-selector._domainkey.example.com

...returns something. Not because that selector exists. Because the wildcard matches everything.

A checker whose test is "did I get an answer?" will report a dozen imaginary selectors on these domains, and it will look authoritative doing it.

The obvious defence is to require the answer to actually parse as DKIM — specifically to carry a p= tag, which RFC 6376 makes mandatory.

That's necessary, and it isn't sufficient. Here's the one that got me:

*._domainkey.example.com.  TXT  "v=DKIM1; p="

That's a structurally valid DKIM record with an empty key. It passes the p= test. So every guessed selector comes back looking like a revoked key — and now your tool is telling someone they have thirty revoked DKIM selectors, which is both alarming and entirely fictional.

The only defence I've found that holds: query a deliberately nonsensical selector first, then discard any result identical to what the wildcard returned. Establish the baseline lie, then subtract it.

If a checker has ever told you that you have dozens of revoked selectors, this is what happened. Ignore it.

Finding yours for certain

Two methods, neither of which involves guessing.

Read a message you sent. Most reliable, and needs access to nothing. Send yourself a message, view the raw source (⋮ → Show original in Gmail), and find:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=selector1; t=1785453729;

s= is your selector. d= is the signing domain — check that d= matches your visible From: domain, because if it doesn't, DKIM is passing and not aligning, and DMARC fails anyway.

Do this once per sending system. Each has its own selector and they all have to work.

Or check the provider's console. Every platform exposes this under "authentication", "verified domains" or "DKIM" — which is also where you switch signing on if it turns out it was never enabled.

Reading the record once you have the name

dig +short TXT selector1._domainkey.example.com

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…"

Four things worth noticing:

p= with nothing after it means revoked. If anything is still signing with that selector, that mail is failing DKIM right now.
A missing v= tag is fine. RFC 6376 only recommends it. Plenty of production records start straight at k=rsa and validate perfectly.
Key length. 1024-bit RSA is still accepted everywhere but is no longer considered strong. 2048 is the norm. Rotate through your provider, not by hand-editing DNS.
A CNAME instead of a TXT is normal. Most platforms have you delegate the selector to them so they can rotate keys without touching your zone. Follow it and you should land on a valid key.

Worth stealing: the revoke-everything wildcard

The wildcard pattern that breaks checkers is genuinely useful if you own a domain that sends no mail:

*._domainkey.example.com.  TXT  "v=DKIM1; p="

That declares every selector on the domain revoked. Combined with v=spf1 -all and p=reject, it's an unambiguous statement that this domain sends nothing and any signature claiming otherwise is forged.

And it doesn't paint you into a corner: DNS wildcards only apply where no exact match exists, so publishing a real selector later takes precedence automatically. One working key coexists happily with a revoke-everything wildcard.

Most parked and brand-protection domains have SPF and DMARC locked down and leave DKIM wide open. This closes it.

I maintain notspoofed — a free, no-signup SPF/DKIM/DMARC checker. It guesses fifty selectors like everything else, but it says so, it verifies each hit is a real parseable signing key rather than a wildcard echo, and it runs the nonsense-selector baseline described above so it won't invent thirty revoked keys for you. I built that last part because I got it wrong first. Source is on GitHub under MIT.

If you've seen a checker confidently report selectors that don't exist, I'd like to know which — that failure mode is more common than it should be.

SPF passed. DKIM passed. DMARC failed. Nothing is broken.

Jose Pollman — Mon, 03 Aug 2026 19:50:40 +0000

This header block is where most people's understanding of email authentication falls apart:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=bounce@esp-vendor.net;
  dkim=pass header.d=esp-vendor.net;
  dmarc=fail (p=REJECT) header.from=yourcompany.com

Two passes and a fail. No malformed record anywhere. Nothing to fix in DNS. And the mail is being rejected.

Every part of that is correct behaviour.

The question DMARC actually asks

DMARC does not ask "did SPF pass?"

It asks: did SPF or DKIM pass for the same domain that appears in the From: header?

There are three domains in play in any message, and only one of them is visible to a human:

Identifier	Lives in	Who sees it	Checked by
`From:`	The message headers	Your recipient	Nothing, on its own
Envelope sender (`MAIL FROM`)	The SMTP conversation	Nobody	SPF
DKIM `d=`	The signature header	Nobody	DKIM

SPF authenticates the envelope sender. DKIM authenticates the signing domain. Neither of them is the From: header. DMARC exists entirely to insist that at least one of them matches it.

In the header above, SPF authenticated esp-vendor.net and DKIM signed as esp-vendor.net. The recipient sees yourcompany.com. Nothing authenticated yourcompany.com, so DMARC fails.

It has to work this way. If DMARC accepted "SPF passed" without the matching step, anyone with a mailbox at a provider with a valid SPF record could send as you and pass.

How you get here without doing anything wrong

You sign up for a marketing platform, an invoicing tool, or a helpdesk. You set the From address to hello@yourcompany.com because that is what your customers should see.

The platform sends from its own infrastructure with its own envelope domain — it has to, because that is where bounces go. SPF passes, for them. Your From: says you.

Those do not align. If nothing is DKIM-signed with your domain, every message from that platform fails DMARC.

This is the single most common cause of "we set up SPF and it still doesn't work".

The fix that feels right and does nothing

Adding include:esp-vendor.net to your SPF record.

It is the intuitive move. It changes nothing.

That include authorises their servers to send for your envelope domain. Their mail still uses their envelope domain, so the alignment comparison is untouched. You have spent one of your ten SPF DNS lookups for no benefit at all.

If your reaction to a dmarc=fail is to edit your SPF record, stop and read the Authentication-Results header first.

Relaxed vs strict, and the trap in the middle

Alignment has two modes, set per-mechanism with aspf= and adkim= in your DMARC record:

Relaxed (r, the default) — organisational domains must match. mail.example.com aligns with example.com.
Strict (s) — exact match only. mail.example.com does not align with example.com.

Relaxed is right for almost everyone. Strict is worth it only if you are confident every sender uses the exact apex domain, and it breaks the day someone starts sending from a subdomain.

Here is the part that matters if you are implementing this yourself: "organisational domain" is not "the last two labels".

attacker.co.uk and victim.co.uk share their last two labels and have no relationship whatsoever. Getting this right means consulting the Public Suffix List, not counting dots. A checker that counts dots will tell you two unrelated domains are aligned, which is the worst possible direction to be wrong in.

Reading it from your own mail

Send a message to a mailbox at a different provider. Open the delivered copy and view the source — ⋮ → Show original in Gmail, View message details in Outlook.

Then compare exactly three lines:

From: Your Company <hello@yourcompany.com>     <- the domain that must be matched
spf=pass smtp.mailfrom=bounce@esp.net          <- authenticated esp.net
dkim=pass header.d=esp.net                     <- signed by esp.net

If neither the smtp.mailfrom domain nor the DKIM d= matches your From domain, DMARC fails regardless of how correct your SPF record is.

Use a message you received, not one from your Sent folder. Sent copies have no Authentication-Results header at all — that verdict is written by the receiving server. Nearly everyone trips on this the first time and concludes their headers are broken.

Fixing it properly

Get DKIM signing with your own domain. Every serious sending platform supports it. It is usually called "authenticate your domain", "domain authentication" or "custom DKIM", and it hands you a selector to publish in DNS. Once the platform signs with d=yourcompany.com, DKIM aligns and DMARC passes no matter what the envelope sender says.

There is a second reason to prefer DKIM, and it is the one that bites later: DKIM survives forwarding and SPF does not. The moment a message is forwarded, the forwarding server is not in your SPF record. Every mailing list and every user-configured forward becomes a DMARC failure if SPF alignment is all you have.

Optionally, also set a custom return-path. Some platforms let you point the envelope sender at a subdomain of yours — "custom return-path" or "custom bounce domain". You publish a CNAME, the envelope domain becomes bounce.yourcompany.com, and that aligns under relaxed. This fixes only the SPF half and still dies on forwarding, so do it as well as DKIM, not instead.

Before you enforce

This is the actual reason the p=none → quarantine → reject order exists.

Run at p=none with a reporting address and read the aggregate reports. They tell you which sources pass SPF and DKIM with alignment — a different and much smaller set than the sources that merely pass SPF. Move to p=quarantine only when that list matches the systems you expect to be there.

Skip it and you will find your misaligned senders the hard way: by having their mail rejected.

I maintain notspoofed — a free, no-signup checker for SPF, DKIM and DMARC. It has an in-browser header analyzer that does the three-way alignment comparison above and shows relaxed vs strict as a table; headers are parsed locally and never uploaded. It uses the Public Suffix List for organisational domains, because counting labels is wrong. Source is on GitHub under MIT.

If you have hit an alignment failure with a cause that is not on this list, I would like to hear it — those are the interesting ones.

Why your DMARC reports never arrive (and why Gmail can't be your rua address)

Jose Pollman — Sun, 02 Aug 2026 21:02:50 +0000

You published a DMARC record months ago. Every checker says it's valid. No reports have ever arrived, and at some point you stopped thinking about it and quietly concluded nobody's forging your domain.

You don't know that. You just can't see.

Two causes account for almost all of it, and both leave the DMARC record itself looking perfect.

1. Your reporting address never agreed to receive them

This is in the spec and almost nobody knows about it.

If your rua= address is on a different organisational domain from the domain publishing the record, RFC 7489 section 7.1 requires the destination to explicitly consent. The reason is obvious once you see it: otherwise anyone could point rua= at your mailbox and use the world's mail infrastructure as a free DDoS.

Consent is a DNS record, published by the receiving domain:

<your-domain>._report._dmarc.<their-domain>.  TXT  "v=DMARC1"

So if example.com sends reports to dmarc@reports.vendor.com, then vendor.com has to publish:

example.com._report._dmarc.reports.vendor.com.  TXT  "v=DMARC1"

Without it, conforming reporters send nothing at all. That includes Google, which is most of your report volume.

You can watch this working in production. PayPal sends aggregate reports to a third party, and the authorisation record exists:

paypal.com._report._dmarc.rua.agari.com.  TXT  "v=DMARC1;"

The practical consequence: not a Gmail address

You cannot put a Gmail address in rua=.

Google is not going to publish yourdomain.com._report._dmarc.gmail.com on your behalf, and you can't create records in their zone. Same for Outlook, Yahoo, or any address at a domain you don't control.

This is a common first move — publish DMARC, point reports at your personal inbox, wait. Nothing arrives, and nothing is wrong with the record.

If you use a commercial DMARC service they normally publish these records during onboarding, often via a wildcard. If reports never start after you sign up, check this before anything else.

When it doesn't apply: reporting to your own organisational domain needs no authorisation. example.com sending to dmarc@mail.example.com is fine.

2. There's no mail server behind the address

Subtler, and easy to create by accident on a domain that only serves a website.

You publish:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"```

Self-referential, so no authorisation needed. Correct in every way.

But if `example.com` has **no MX record**, senders fall back to its A record — the implicit MX rule in [RFC 5321 section 5.1](https://www.rfc-editor.org/rfc/rfc5321#section-5.1). On a web-only domain that A record points at a web server, which doesn't speak SMTP. Every report bounces.

The DMARC record is flawless. You just have no mailbox.

This bites hardest on marketing sites and defensive brand registrations — exactly the domains where you published DMARC as a hardening measure and are least likely to notice the silence.

The fix doesn't require running a mail server. A forwarding service will publish MX records for you and forward `dmarc@` somewhere you actually read.

## Checking both in about thirty seconds



```bash
# 1. What does your record actually say?
dig +short TXT _dmarc.example.com

# 2. If rua points off-domain, is it authorised?
dig +short TXT example.com._report._dmarc.THEIR-DOMAIN.com
#    Expect "v=DMARC1". Anything else means reports are refused.

# 3. If rua points at your own domain, can it receive mail?
dig +short MX example.com
#    Empty means every report bounces.

A third possibility, but rule the others out first

Some providers only send aggregate reports once they see meaningful volume from a domain. A domain sending almost nothing may legitimately get few reports, particularly from smaller receivers.

That's a real explanation, but it's also the comfortable one, so don't reach for it early. The two DNS causes above are deterministic and fixable. Google will typically report on any domain with real traffic within a day or two.

Why this matters more than it sounds

The entire value of p=none is the reporting. That's the whole point of the stage.

If you're sitting at p=none with broken reporting, you've done all the work of DMARC and got none of the benefit — no protection, because p=none blocks nothing, and no visibility either. You're paying the setup cost and collecting nothing.

Check it on the day you publish, not six months later when someone asks how the rollout is going.

I maintain notspoofed, a free checker that tests both of these — whether an external rua= is actually authorised, and whether the reporting address can receive mail at all. It's the failure mode I've seen most often and the one fewest tools look for. No signup, and checked domains aren't logged.

If you've had reports silently missing for months, I'd be curious which of the two it turned out to be.

Your SPF record can be valid, published, and completely ignored

Jose Pollman — Sun, 02 Aug 2026 20:55:09 +0000

There's a failure mode in SPF that produces no error anywhere you'd think to look.

Your record is syntactically valid. dig returns it. Your DNS provider is happy. Your own test mail arrives fine. And yet some of your mail is failing authentication at the receiver, and nothing in your infrastructure will tell you.

The cause is usually that you've gone past ten DNS lookups.

Ten is a hard ceiling, not a guideline

RFC 7208 section 4.6.4 requires evaluators to cap DNS-querying terms at ten. Go past it and the result is PermError — a permanent failure.

The important part: receivers don't degrade gracefully. They don't evaluate the first ten and shrug at the rest. They treat the entire record as unusable. You go from "SPF configured" to "SPF absent" in one step, and the only place that's visible is in DMARC aggregate reports, which most people aren't reading yet.

Six terms cost a lookup. Four are free.

Costs a lookup	Free
`include:`	`ip4:`
`a`	`ip6:`
`mx`	`all`
`ptr`	`exp=`
`exists:`
`redirect=`

The count isn't yours to control

This is what catches people out. The limit applies to the whole resolution tree, not just your record.

You publish four includes. One of those vendors publishes six includes of their own. You're at eleven, and your record lists four things.

Nothing changed on your side. A vendor updated their record and broke yours. There is no notification for this, from anyone, ever.

Counting it by hand

You can walk the tree with dig if you want to see it directly:

dig +short TXT example.com | grep spf1

Then for every include: you find, recurse:

dig +short TXT _spf.vendor.com | grep spf1

Keep going until you bottom out, counting every include:, a, mx, ptr, exists: and redirect= along the way.

It's tedious but instructive — you'll usually find one vendor accounting for half your budget.

Three traps that make tools lie to you

Doing this by hand or with a naive script, there are three places to go wrong. I've seen all three produce confidently incorrect output.

1. `redirect=` uses `=`, not `:`

It's a modifier, not a mechanism, and both humans and regexes skip it. Plenty of production domains are nothing but a redirect:

hubspot.com.  TXT  "v=spf1 redirect=_hspf.hubspot.com"

Miss that single term and you conclude the domain uses zero lookups — when in fact every include and every cost lives behind it. If a checker tells you a domain like this uses no lookups, the checker is broken.

2. Void lookups have a separate budget

A lookup that returns nothing is a void lookup, and RFC 7208 caps those at two.

So an include pointing at a vendor you stopped paying for last year, whose record no longer exists, hurts you twice: once against the ten, and once against the void limit. Dead includes aren't free just because they resolve to nothing.

3. TXT records arrive in pieces, joined with nothing

This is the one that bites anyone writing their own tooling.

DNS transmits TXT records as one or more character-strings of at most 255 bytes. A long SPF record arrives in several chunks, and RFC 7208 section 3.3 says they're concatenated with no separator.

Real records split mid-token. One production record ends a chunk with ...ip4 and starts the next with :161.38.192.0/20.

Join them correctly and you get ip4:161.38.192.0/20. Join them with a space — the obvious-looking thing to do — and you get ip4 :161.38.192.0/20, which isn't valid syntax.

If you're parsing SPF yourself, handle this first. If you're using someone else's tool and the output looks subtly mangled, this is usually why.

Fixing it, in the order worth trying

Remove senders you no longer use. The only fix with no downside, and it's almost always available. Most domains over the limit are carrying includes for tools nobody has logged into in years, and deleting one buys back its entire subtree. Get the include list in front of whoever owns marketing and billing and ask what's still live.

Ask the vendor for a narrower include. Some publish a broad include covering all their infrastructure plus a tighter one scoped to a product or region. This is rarely documented — you have to ask support.

Flatten, but as little as possible. Replacing include:vendor.com with the IPs it resolves to turns a five-lookup subtree into zero, because ip4: and ip6: are free.

The cost is permanent and easy to underestimate: you've taken on that vendor's maintenance burden. When they add a sending IP, their record updates and yours doesn't. Your mail from that provider starts failing SPF silently, and you find out when someone notices deliverability dropped a month ago.

If you flatten:

Only flatten enough to get under ten. Retiring the single most expensive include is often sufficient, and leaves everyone else free to rotate their own IPs.
Never flatten a provider using macros. A term like exists:%{i}._spf.example.com expands against the connecting IP. There's no fixed set of addresses to inline, and flattening it silently drops every sender it would have matched.
Re-check monthly, in a calendar, not in your head.

Worth knowing: large providers increasingly flatten their own records for this reason. _spf.google.com today contains only ip4: and ip6: entries with no nested includes, so include:_spf.google.com costs you exactly one lookup rather than four.

Don't aim for ten

Ten is legal. Ten is not a target.

A record sitting at exactly ten breaks the day someone in marketing signs up for one more tool, and nobody will connect those two events. Aim for seven or eight so there's headroom to add a sender without causing an outage.

I maintain notspoofed, a free checker that walks the whole include tree, follows redirect=, counts against the real ceiling, and generates a corrected record that flattens only what it has to. It handles all three traps above, because I got them wrong first. No signup, and the domains you check aren't logged.

If you've hit this in an interesting way — particularly a vendor whose record silently blew your budget — I'd like to hear about it.