abv.bg: mail servers, SPF, DMARC, DKIM and reputation

Mail servers for abv.bg

abv.bg publishes 2 MX records. Senders deliver to the lowest-priority host first, pmx.abv.bg, and fall back down the list if it does not answer.

Who runs the mail

The hosts match the pattern of an unrecognised provider. The mail hosts do not match a known provider pattern, so the domain is probably self-hosted or on a smaller provider. Catch-all behaviour varies from server to server, which is exactly why a mailbox-level probe, not the MX record, decides whether an address exists.

What this means for verification

An address at abv.bg passes the free checks (syntax, MX, lists), so the API goes on to the mailbox-level SMTP handshake, which ends before any message is sent. The result is deliverable, risky, or undeliverable with a reason field that names the evidence.

SPF for abv.bg

abv.bg publishes an SPF record; it names its senders directly rather than through include mechanisms, and the record ends in ~all (soft fail): mail from unlisted servers is marked suspicious but usually still delivered.

DMARC for abv.bg

The DMARC policy for abv.bg is p=none: the domain collects authentication reports but asks receivers not to act on failures. Spoofed mail is still delivered; the owner just gets told about it.

Why it matters

SPF says which servers may send as abv.bg; DKIM signs the messages; DMARC tells receivers what to do when neither checks out and reports back to the owner. Together they decide whether mail from abv.bg is trusted, and whether someone else can pretend to be abv.bg. For verification they are a domain-quality signal: Spaw folds a missing SPF record into the risk score and reports has_spf and dmarc_policy on every email and domain lookup.

DKIM keys for abv.bg

None of the common selectors publishes a key for abv.bg. That does not mean abv.bg signs nothing: a selector can be any label, and a domain that signs with one of its own (s2024, k2, mail-eu) is invisible to a list of common names. Only a DMARC report, or the DKIM-Signature header on a real message, names the selector for certain.

What the check reads

DKIM keys live in DNS at <selector>._domainkey.abv.bg, one TXT record per selector, and the selector is chosen by whoever signs the mail. This checker asks for the selectors the large providers and sending platforms use by default (google, selector1 and selector2 for Microsoft 365, k1, s1, fm1 and about thirty more), so a key found here is a real key, and a key not found here may simply sit under a name the list does not know.

How it fits with SPF and DMARC

The DMARC policy for abv.bg is p=none: the domain collects authentication reports but asks receivers not to act on failures. Spoofed mail is still delivered; the owner just gets told about it. abv.bg publishes an SPF record; it names its senders directly rather than through include mechanisms, and the record ends in ~all (soft fail): mail from unlisted servers is marked suspicious but usually still delivered.

Transport security for abv.bg

abv.bg publishes no an MTA-STS policy record record at _mta-sts.abv.bg. Without MTA-STS, a sender that cannot negotiate TLS with the mail host may fall back to delivering in the clear, and an attacker on the path can force exactly that. abv.bg publishes no a TLS-RPT record record at _smtp._tls.abv.bg. TLS-RPT would give the domain owner a daily report of delivery attempts that could not establish TLS; without it, failures are invisible.

Brand indicators for abv.bg

abv.bg publishes no a BIMI record record at default._bimi.abv.bg. BIMI is optional and mostly cosmetic; it only becomes possible once DMARC enforces quarantine or reject.

SPF details for abv.bg

abv.bg publishes SPF. The policy's all qualifier is ~all (soft fail: unlisted servers are marked suspicious but usually delivered). Evaluating it takes 0 DNS lookups, within the ten RFC 7208 allows.

DMARC details for abv.bg

The DMARC policy for abv.bg is p=none: the domain collects authentication reports but asks receivers not to act on failures. Spoofed mail is still delivered; the owner just gets told about it. The policy applies to all of the domain's mail (pct=100). Aggregate reports are collected (rua= is set), so the owner sees who sends as the domain.

Is abv.bg disposable?

abv.bg is a free consumer mailbox provider, the kind used for personal accounts. Addresses there are legitimate, but they say nothing about the person's company.

About the domain

Its mail is handled by an unrecognised provider.

How Spaw treats addresses at abv.bg

An address at abv.bg passes the free checks (syntax, MX, lists), so the API goes on to the mailbox-level SMTP handshake, which ends before any message is sent. The result is deliverable, risky, or undeliverable with a reason field that names the evidence.

Common questions about abv.bg

Does abv.bg accept mail?

abv.bg accepts mail through its own mail servers.

Does abv.bg publish SPF and DMARC?

abv.bg publishes SPF ending in ~all and a DMARC policy of none.

Is abv.bg a disposable, relay or free-provider domain?

abv.bg is a free mailbox provider, so an address there is a consumer inbox rather than a company's.

Does abv.bg publish DKIM, MTA-STS, TLS-RPT or BIMI?

abv.bg does not publish MTA-STS, does not publish TLS-RPT and does not publish BIMI. None of the common DKIM selectors publishes a key, which does not mean the domain signs nothing: a selector outside the common list is invisible to this check.

Where does this report come from?

Live DNS, the open disposable, role and free-provider lists, the registry's RDAP record and the threat blocklists the IP product installs, read on 2026-10-08 and cached for a week. Nothing here says anything about a person; it describes the domain's mail setup on that day.

Check another domain

• Email checker
• MX record lookup
• SPF & DMARC checker
• Disposable email domain checker
• DKIM checker
• MTA-STS, TLS-RPT and BIMI checker
• The same answer over the API: GET /api/v1/email/domain/abv.bg