We read the public email records of 93 Bangladeshi company domains. SPF is nearly universal, but only 36 enforce DMARC. Here are the results and a safe way to fix yours.
A DMARC policy tells other mail servers what to do when someone sends an email that pretends to come from your domain and fails the checks. To see how Bangladeshi companies handle this, we looked up the public email records of their domains on 6 November 2026.
Of the 93 company domains that receive email in our sample, only 36 had a working policy that asks receivers to act on those failed messages. The other 57, about 6 in 10, did not.
The results
Every number below is out of the 93 domains with mail servers.
- SPF: 89 have a record (95.7%). Two of those publish more than one, which the SPF standard treats as an error.
- DKIM: we found a signing key on 70 (75.3%). The real number may be higher, for a reason explained in the method section.
- No DMARC record: 20 (21.5%).
- More than one DMARC record: 3 (3.2%). Under the DMARC standard, this means policy discovery stops and DMARC is not applied.
- DMARC policy set to none: 34 (36.6%).
- DMARC policy set to quarantine: 21 (22.6%).
- DMARC policy set to reject: 15 (16.1%).
The pattern is clear. SPF is close to universal, so most of these companies have already started on email authentication. The gap is in the last step, the one that tells receivers what to do when a message fails.
What each DMARC policy does
- none: the domain owner requests no specific action. You can receive reports, but a forged email is not treated differently because of this policy.
- quarantine: failed messages should be treated as suspicious, which often means the spam folder.
- reject: failed messages should be refused.
A none policy is not a mistake. It is the correct place to start, because it lets you see who is sending email using your domain before anything gets blocked. It only becomes a problem when a company stops there and believes it is protected.
Reports are what make that first stage useful. Of the 34 domains on none, 20 ask for reports. The other 14 are not asking for the reports that would show them what to fix before they tighten the policy.
Does Google require more than none?
No, and this is where a lot of advice gets confusing. Google's email sender guidelines ask all senders to set up SPF or DKIM. Domains sending 5,000 or more messages a day to personal Gmail accounts need SPF, DKIM and DMARC, and a policy of none is accepted.
So a none policy can meet that Gmail rule and still leave your domain easier to impersonate. Those are two separate goals. One helps your email get accepted. The other limits what a stranger can do with your name.
A limit of every DKIM checker
While running this study, we found that our own Email Security Checker was missing some selector names used by a common mail provider and was counting empty, revoked keys as valid. We fixed both and ran the study again, which moved the DKIM figure from 71% to 75.3%.
That is a useful warning about any DKIM checker, including ours. A "not found" result can mean the checker did not try the right name. If you know your selector, enter it.
How to move to a stronger policy safely
Do not jump straight to reject. If you missed a service that sends email for you, its messages can start failing.
- List everything that sends email as your domain. Include your mailbox provider, website forms, newsletter tool, CRM and invoicing software.
- Keep one SPF record. Merge duplicates into a single record that covers all those senders.
- Turn on DKIM for each sender. Most providers give you the DNS records to add.
- Keep one DMARC record, on none, with a reporting address. For example:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com - Read the reports for a few weeks. Look for your real senders failing, and fix them.
- Move to quarantine, then to reject. Change one level at a time and keep watching the reports.
How we ran this study
We wanted a list anyone could rebuild, so we took Bangladeshi companies with an official website from Wikidata, using company, business, enterprise, bank and similar categories. That gave 133 unique domains. We removed government, academic and institute-only sites, leaving 109. Six of those no longer exist in DNS and 10 have no mail servers, which left 93.
We only read public DNS records, through public resolvers. We sent no email and tested no systems, and we are not naming the companies because the point is the overall pattern.
Please keep these limits in mind:
- This is not all Bangladeshi business. Companies listed on Wikidata tend to be larger and better known. Small businesses may look quite different, so do not read these numbers as a national average.
- 93 is a small sample. Treat the percentages as a rough picture.
- DKIM cannot be fully measured from outside. You need to know the selector name, so we tried 21 common ones. That makes 75.3% a minimum.
- This is one day's snapshot. Records can change at any time.
- Records do not show results. We can see what a domain asks for, not how much spoofing or spam it actually suffers.
To see where your own domain stands, run it through the Email Security Checker. It takes a few seconds and needs no sign-up.
Need help putting this into practice?
Our team can do it for you — a clear plan and price within 24 hours, no obligation.
