How to Check If My Domain Is Blacklisted

Start with the domain and sending IP

To check if your domain is blacklisted, test the exact domain and IP address used by the mail that is failing.

Look at a recent message header or bounce. Check the visible From domain, any subdomain used for mail, the DKIM d= domain, the SPF return-path domain, and the sending IP address. Many public blocklists track IPs, some track domains or hostnames, and large mailbox providers also use private reputation systems that public lookup tools cannot fully see.

Run a public blocklist lookup for the domain and IP, then run a free InboxRadar domain scorecard to check the SPF, DKIM, DMARC, and MX records mailbox providers can see. A clean public blocklist result does not guarantee inbox placement. Gmail, Outlook, Yahoo, and corporate filters also evaluate authentication, reputation, complaints, list quality, sending patterns, and user behavior.

• Check the visible From domain and any sending subdomain, such as mail.example.com.
• Check the sending IP address from a real message header or bounce.
• Confirm the SPF return-path domain authorizes the service that sent the message.
• Confirm DKIM is signing the message, not just published in DNS.
• Confirm DMARC exists at _dmarc.yourdomain and passes through aligned SPF or DKIM.

What a blacklist result means

A blocklist is a reputation list that names IP addresses, domains, or hostnames associated with spam, malware, abuse, bad configuration, or suspicious mail.

Some lists are widely used by receiving systems, some are narrow, and some are outdated. Treat a listing as evidence to investigate, not as the only reason mail is going to spam. Google says Gmail requires SPF or DKIM for all senders, and SPF, DKIM, and DMARC for bulk senders. It also says unauthenticated mail may be marked as spam or rejected. Microsoft documents DMARC as passing when SPF or DKIM passes with alignment, and recommends a gradual move from p=none to stronger DMARC policies after monitoring.

If you need the standards, use the published specs: RFC 7208 for SPF, RFC 6376 for DKIM, and RFC 7489 for DMARC. For provider behavior, use the current Google sender guidelines and Microsoft DMARC guidance because mailbox-provider enforcement can change.

Check SPF, DKIM, DMARC, and MX

Most delivery problems are not fixed by delisting alone. You also need to prove that your domain's legitimate mail is authenticated and aligned.

SPF is a TXT record that lists the hosts allowed to send for the envelope sender domain. Publish one SPF record for a domain, include every real sender, and stay within SPF's 10 DNS-lookup limit for mechanisms and modifiers such as include, a, mx, ptr, exists, and redirect. Use ~all while validating senders, then consider -all when the list is complete. Avoid +all because it authorizes any sender.

DKIM signs mail with a private key at the sending service and publishes the matching public key in DNS under a selector, such as selector1._domainkey.example.com. Multiple selectors are normal. What matters is that each real mail stream signs messages and that the DKIM signing domain aligns with the visible From domain under DMARC rules.

DMARC checks whether SPF or DKIM passes and aligns with the From domain. A DMARC record lives at _dmarc.yourdomain and can use p=none, p=quarantine, or p=reject. Start with p=none plus a rua=mailto: aggregate reporting address so you can see legitimate and suspicious sources. Move to quarantine or reject only after real mail is passing. MX records do not authenticate outbound mail, but broken MX records can break replies, bounces, and mailbox verification workflows.

• SPF: one SPF TXT record, all real senders included, no lookup-limit failure.
• DKIM: signing enabled in the sender, selector DNS record published, key still valid.
• DMARC: record exists, aggregate reports enabled, SPF or DKIM aligns with the From domain.
• MX: inbound mail hosts are correct for replies, bounces, and mailbox checks.
• Reputation: complaints, hard bounces, spam traps, volume spikes, and list quality are under control.

If your domain is listed

Fix the cause before you request delisting. Otherwise the same behavior can put you back on the list.

Look for a recent change: a new email platform, a cold campaign, a compromised mailbox, a bad list import, missing unsubscribe handling, or a DNS edit that broke authentication. Pause risky sends while you investigate. Remove purchased or unverified contacts. Rotate compromised credentials. Fix SPF, DKIM, DMARC, MX, forward DNS, reverse DNS, and TLS where they apply. Then use the blocklist operator's own delisting process and explain what changed.

After delisting, keep watching the domain. DNS changes, vendor migrations, and expired DKIM keys can quietly break a domain that was healthy last month. InboxRadar can check the domain now and keep watching for drift, so the next authentication failure is caught before it becomes a spam-folder problem. For a broader diagnosis, read the related InboxRadar deliverability guides.