# DNSLab — full content

> DNSLab is a free, modern DNS, email-deliverability and network diagnostics toolbox with 50+ tools. Every lookup is queried live (not cached), is a shareable link, and is also available as JSON through a free public API.

DNSLab lets anyone run DNS record lookups (A, AAAA, MX, TXT, NS, CNAME, SOA, SRV, CAA, PTR and DNSSEC records), validate email authentication (SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT), check IPs and domains against ~30 DNS blacklists, look up WHOIS/RDAP and ASN/IP-block data (including .tr domains via TRABIS), calculate IPv4/IPv6 subnets, and run network diagnostics (ping, traceroute, TCP port checks, HTTP/HTTPS, DNS propagation). No signup is required. It is available in English and Turkish.

## All tools
- [MX Lookup](https://dnslab.io/en/mx): Find the mail servers (MX records) for a domain.
- [A Lookup](https://dnslab.io/en/a): Resolve a hostname to its IPv4 address.
- [AAAA Lookup](https://dnslab.io/en/aaaa): Resolve a hostname to its IPv6 address.
- [CNAME Lookup](https://dnslab.io/en/cname): Find the canonical name a host is aliased to.
- [DNS Lookup](https://dnslab.io/en/ns): Check a domain's authoritative name servers.
- [TXT Lookup](https://dnslab.io/en/txt): Read the TXT records published on a domain.
- [SOA Lookup](https://dnslab.io/en/soa): Read the Start of Authority record (serial, refresh…).
- [SRV Lookup](https://dnslab.io/en/srv): Look up a service (SRV) record.
- [CAA Lookup](https://dnslab.io/en/caa): See which CAs may issue certificates for a domain.
- [Reverse Lookup (PTR)](https://dnslab.io/en/ptr): Reverse-resolve an IP address to a hostname.
- [NAPTR Lookup](https://dnslab.io/en/naptr): Naming Authority Pointer records (ENUM/SIP).
- [TLSA Lookup](https://dnslab.io/en/tlsa): DANE / TLSA certificate association records.
- [DNSKEY Lookup](https://dnslab.io/en/dnskey): Public keys used to sign a DNSSEC zone.
- [DS Lookup](https://dnslab.io/en/ds): Delegation Signer records held by the parent zone.
- [RRSIG Lookup](https://dnslab.io/en/rrsig): DNSSEC resource-record signatures.
- [NSEC Lookup](https://dnslab.io/en/nsec): Next Secure record (authenticated denial).
- [NSEC3PARAM Lookup](https://dnslab.io/en/nsec3param): NSEC3 parameters (hashed denial of existence).
- [CERT Lookup](https://dnslab.io/en/cert): Certificate (CERT) records stored in DNS.
- [LOC Lookup](https://dnslab.io/en/loc): Geographic LOC records (lat/long/altitude).
- [IPSECKEY Lookup](https://dnslab.io/en/ipseckey): IPsec public keys published in DNS.
- [SPF Lookup](https://dnslab.io/en/spf): Parse & validate the Sender Policy Framework record.
- [DKIM Lookup](https://dnslab.io/en/dkim): Fetch a DKIM public key for a selector.
- [DMARC Lookup](https://dnslab.io/en/dmarc): Parse the DMARC policy at _dmarc.<domain>.
- [BIMI Lookup](https://dnslab.io/en/bimi): Brand Indicators for Message Identification record.
- [MTA-STS Lookup](https://dnslab.io/en/mta-sts): MTA Strict Transport Security TXT record + policy file.
- [TLS-RPT Lookup](https://dnslab.io/en/tlsrpt): SMTP TLS Reporting (TLSRPT) record.
- [SMTP Test](https://dnslab.io/en/smtp): Connect to a mail server, check banner, STARTTLS & open relay.
- [Domain Health](https://dnslab.io/en/domain-health): One-shot report: MX, SPF, DKIM, DMARC, DNSSEC & blacklists.
- [Google / Yahoo Compliance](https://dnslab.io/en/email-compliance): Check bulk-sender requirements (SPF, DKIM, DMARC, PTR, TLS).
- [Microsoft Compliance](https://dnslab.io/en/microsoft-compliance): Check Outlook.com / Microsoft sender requirements.
- [Email Header Analyzer](https://dnslab.io/en/header-analyzer): Paste raw email headers to trace the delivery path. (browser tool — no API)
- [SPF Generator](https://dnslab.io/en/spf-generator): Build a valid SPF record with a guided form. (browser tool — no API)
- [DMARC Generator](https://dnslab.io/en/dmarc-generator): Build a DMARC record with a guided form. (browser tool — no API)
- [DMARC Report Analyzer](https://dnslab.io/en/dmarc-report-analyzer): Parse a DMARC aggregate (RUA) XML report. (browser tool — no API)
- [Email Extractor](https://dnslab.io/en/email-extraction): Extract all email addresses from any text. (browser tool — no API)
- [Blacklist Check](https://dnslab.io/en/blacklist): Check an IP or host against ~30 DNS blacklists.
- [Blocklist Check](https://dnslab.io/en/blocklist): Check an IP or host against additional blocklists.
- [What Is My IP](https://dnslab.io/en/whatismyip): Show your public IP address and its geolocation.
- [WHOIS Lookup](https://dnslab.io/en/whois): Registration details for a domain or IP.
- [ASN Lookup](https://dnslab.io/en/asn): Look up an Autonomous System (RDAP).
- [ARIN / IP Blocks](https://dnslab.io/en/arin): Which network block an IP belongs to (RDAP).
- [Ping](https://dnslab.io/en/ping): ICMP echo — is the host reachable, and how fast?
- [Traceroute](https://dnslab.io/en/trace): Trace the network path to a host.
- [TCP Port Check](https://dnslab.io/en/tcp): Is a TCP port open on a host? (host:port)
- [HTTP Lookup](https://dnslab.io/en/http): Fetch a URL over HTTP and report status, headers & redirects.
- [HTTPS Lookup](https://dnslab.io/en/https): Fetch over HTTPS and inspect the TLS certificate.
- [SSL Checker](https://dnslab.io/en/ssl): Deep TLS certificate check on any port: chain, expiry, OCSP, HSTS.
- [SSL & CSR Decoder](https://dnslab.io/en/ssl-decoder): Decode a certificate or CSR in your browser — nothing is uploaded. (browser tool — no API)
- [CSR Generator](https://dnslab.io/en/csr-generator): Generate a CSR and private key in your browser — the key never leaves it. (browser tool — no API)
- [SSL Converter](https://dnslab.io/en/ssl-converter): Convert between PEM, PKCS#12 (PFX) and PKCS#7 — locally in your browser. (browser tool — no API)
- [RSA Key Converter](https://dnslab.io/en/rsa-key-converter): Convert RSA private keys between PKCS#1 and PKCS#8 in your browser. (browser tool — no API)
- [Certificate Key Matcher](https://dnslab.io/en/certificate-key-matcher): Check that a certificate, CSR and private key match — locally. (browser tool — no API)
- [CA Matcher](https://dnslab.io/en/ca-matcher): Verify an end-entity certificate against its CA / intermediate. (browser tool — no API)
- [OCSP Checker](https://dnslab.io/en/ocsp): Query the CA's OCSP responder for live revocation status.
- [CT Log Search](https://dnslab.io/en/ct-logs): Search Certificate Transparency logs for a domain's certificates.
- [SSL Handshake Trace](https://dnslab.io/en/ssl-trace): Full TLS handshake trace to any host and port.
- [Bulk SSL Checker](https://dnslab.io/en/ssl-bulk): Check SSL certificates for a list of hostnames at once. (browser tool — no API)
- [DCV Checker](https://dnslab.io/en/dcv-checker): Check Sectigo/Comodo domain-control validation (HTTP file & CNAME). (browser tool — no API)
- [DNS Propagation](https://dnslab.io/en/dns-propagation): Query one record across resolvers worldwide.
- [Subnet Calculator](https://dnslab.io/en/subnet-calculator): CIDR → network, broadcast, mask, host range.
- [Password Generator](https://dnslab.io/en/password-generator): Generate strong random passwords in your browser. (browser tool — no API)
- [LLMs.txt Lookup](https://dnslab.io/en/llmstxt): Fetch and view a site’s /llms.txt file.
- [Robots.txt AI Policy](https://dnslab.io/en/robotsai): Which AI crawlers a site allows or blocks (robots.txt).
- [Bulk Lookup](https://dnslab.io/en/bulk): Run one tool across a list of domains or IPs.

## Guides (full text)

### What Is DKIM and How Email Signing Works
A practical guide to DKIM: how cryptographic email signing works, how to publish the DNS record, and how to verify and fix it.
URL: https://dnslab.io/en/guides/what-is-dkim

#### What DKIM actually is
DKIM (DomainKeys Identified Mail) is an email authentication method that lets a receiving server confirm that a message really came from your domain and was not altered in transit. Your outgoing mail server adds a cryptographic signature to each message header. That signature is generated with a private key you keep secret, while the matching public key is published in your DNS as a TXT record. When a mailbox provider like Gmail or Outlook receives the message, it fetches your public key from DNS and checks the signature. If the math verifies, DKIM passes; if the message was tampered with or the key does not match, it fails.

#### Why DKIM matters for deliverability
Without authentication, anyone can forge your From address, and providers have no reliable way to tell your real mail from a spoof. DKIM gives receivers a verifiable claim of ownership, which improves inbox placement and protects your reputation. It is also one of the two pillars DMARC relies on: a message passes DMARC when either SPF or DKIM aligns with the visible From domain. Because DKIM survives forwarding better than SPF (the signature travels with the message), it is often the more durable of the two. Providers increasingly treat missing DKIM as a spam signal, so publishing it is close to mandatory for bulk senders.

#### How the signing process works step by step
When you send a message, the mail server selects the headers and body to protect, then computes a hash of them. It encrypts that hash with your private key and inserts a DKIM-Signature header containing the domain (d=), the selector (s=), the algorithm, and the signed hash (b=). The selector points to a specific public key, letting you run several keys at once. On the receiving side, the server reads the selector and domain, queries selector._domainkey.yourdomain.com for the public key, decrypts the signature, and recomputes the body hash. Matching hashes prove the content is intact and the sender holds the private key.

#### Publishing your DKIM DNS record
Your email provider or mail server generates the key pair and gives you the public key plus a selector name such as google, s1, or k1. You publish it as a TXT record at selector._domainkey.yourdomain.com. The value starts with v=DKIM1; k=rsa; p= followed by the long base64 public key. For a selector named s1, the host is s1._domainkey. Use a 2048-bit RSA key where your provider supports it, since 1024-bit keys are considered weak. Many providers (Google Workspace, Microsoft 365, SendGrid, Mailgun) give you the exact record to paste. After publishing, allow time for DNS propagation before enabling signing.

#### Common DKIM mistakes
The most frequent error is a broken public key: DNS panels sometimes split the long value or add quotes, so the p= string gets truncated or corrupted. Another is a mismatched selector, where the signing server uses one selector but a different one is published. People also forget that each sending service (your website, CRM, newsletter tool) needs its own signature or a shared key, otherwise those streams fail DKIM. Rotating keys without updating DNS, leaving an old CNAME pointing nowhere, or publishing the private key by mistake are all common. Finally, a passing DKIM signature on the wrong domain will not satisfy DMARC unless it aligns with your From domain.

#### How to verify DKIM with dnslab tools
The fastest check is to send yourself a test message and view the raw headers: look for DKIM-Signature and an Authentication-Results line reading dkim=pass. To confirm the record itself is live, use the dnslab DKIM lookup with your selector and domain to fetch the published TXT value and confirm the public key is complete. Pair it with the SPF and DMARC tools so all three authentication layers agree, and the WHOIS tool to confirm you are editing the right domain. If mail is landing in spam, the Blacklist tool tells you whether an IP reputation problem is masking an otherwise valid DKIM setup.

FAQ:
- Q: Do I need DKIM if I already have SPF?
  A: Yes. SPF authorizes which servers may send for your domain, but it breaks on forwarding and does not protect message content. DKIM signs the message itself so tampering is detectable. Together they give DMARC two ways to pass, so running both is strongly recommended for reliable inbox delivery.
- Q: What selector should I use for DKIM?
  A: The selector is just a label that names one key, so you can pick almost anything (s1, k1, mail, or a date). Your email provider usually assigns it for you. Using distinct selectors per service and per rotation lets you publish and retire keys independently without breaking active mail streams.
- Q: How long does DKIM take to work after publishing?
  A: The TXT record must propagate through DNS first, which typically takes minutes to a few hours depending on your TTL. Do not enable signing until the public key resolves, or messages will fail verification. Use the dnslab DKIM lookup to confirm the record is visible before switching signing on.


### How to Set Up DMARC Step by Step: From p=none to p=reject
A practical DMARC deployment guide: publish the record, read aggregate reports, and safely move from monitoring (p=none) to full enforcement (p=reject).
URL: https://dnslab.io/en/guides/how-to-set-up-dmarc

#### What DMARC is and what it actually enforces
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS TXT record that tells receiving mail servers what to do when a message claiming to be from your domain fails authentication. It builds on SPF and DKIM by adding a third requirement: alignment. A message passes DMARC only if SPF or DKIM passes AND the authenticated domain matches the visible From address. Without DMARC, an attacker can pass SPF for their own domain while spoofing yours in the From header. DMARC closes that gap and, through aggregate reports, shows you exactly who is sending mail as your domain.

#### Prerequisites: SPF and DKIM must work first
DMARC has nothing to enforce until SPF and DKIM are already producing pass results for your legitimate mail. Before touching DMARC, confirm your SPF record lists every service that sends on your behalf (mail server, marketing platform, helpdesk, invoicing tool) and that DKIM signing is enabled with published public keys. Use the dnslab SPF tool to check for syntax errors, too many DNS lookups, or a missing record, and verify each DKIM selector resolves. Deploying DMARC on top of broken SPF or DKIM will silently mark your own mail as failing once you enforce, so fix authentication first.

#### Publishing your first DMARC record with p=none
Start in monitoring mode. Create a TXT record at _dmarc.yourdomain.com with a value like: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r. Here p=none means take no action, only report. The rua address receives daily aggregate reports. adkim=r and aspf=r use relaxed alignment, which allows subdomains to align with the organizational domain. Do not add a percentage or reject action yet. After publishing, wait for DNS propagation and confirm the record resolves with the dnslab DMARC lookup tool, checking that the syntax is valid and the reporting address is accepted.

#### Reading aggregate reports and finding legitimate senders
Aggregate (rua) reports are XML files from mailbox providers summarizing every source that sent mail using your domain, with SPF and DKIM results plus alignment status. Spend at least two weeks in p=none collecting them. Your goal is a complete inventory: identify every IP and service that sends legitimate mail and make sure each one aligns on SPF or DKIM. You will usually find forgotten senders like a CRM, a status-page tool, or a legacy server. Add missing sources to SPF and enable DKIM for them. Anything that still fails after this cleanup is either misconfigured or unauthorized spoofing.

#### Stepping up to p=quarantine, then p=reject
Once reports show your real mail consistently aligning, tighten the policy gradually. Move to p=quarantine with a rollout percentage: v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com. Only a quarter of failing mail is quarantined, limiting the blast radius. Watch reports for a week, then raise pct to 50, 100, and finally switch to p=reject. Reject tells receivers to refuse failing mail outright, which is the setting that actually stops spoofing. Do not rush: each step should be backed by clean reports. If a legitimate sender suddenly starts failing, pause and fix it before continuing.

#### Common mistakes that break DMARC deployments
The biggest error is jumping straight to p=reject before verifying all senders align, which bounces real mail. Others include an SPF record exceeding ten DNS lookups (a permerror that fails alignment), forgetting to DKIM-sign mail from third-party platforms, and publishing two DMARC records where only one is allowed. Forwarding also breaks SPF, so DKIM alignment becomes essential for mailing lists. A missing or unmonitored rua mailbox means you enforce blind. Finally, subdomains inherit the policy unless you set an sp= tag, so test transactional subdomains too before enforcing.

#### Verifying your setup and monitoring over time
After each change, re-check the record with the dnslab DMARC tool to confirm syntax, policy, and reporting addresses parse correctly. Cross-check SPF with the SPF tool and confirm DKIM selectors resolve. Send test messages to a Gmail and an Outlook account and inspect the Authentication-Results header for dmarc=pass. Keep monitoring aggregate reports even at p=reject, since new services get added over time and can start failing. If your IPs appear in reports as spoofing sources, verify they are not compromised and check the dnslab Blacklist tool to confirm your sending IPs are not listed.

FAQ:
- Q: How long should I stay at p=none before enforcing?
  A: At least two to four weeks, and longer for domains with many sending services. The point of p=none is to collect enough aggregate reports to build a full inventory of legitimate senders. Only move to quarantine once reports show your real mail consistently aligning on SPF or DKIM with no unexplained failures.
- Q: Do I need both SPF and DKIM for DMARC to pass?
  A: No. DMARC passes if either SPF or DKIM passes with alignment. However, configuring both is strongly recommended, because forwarding breaks SPF while DKIM survives it. Relying on only one authentication method leaves legitimate mail vulnerable to failing DMARC in common forwarding and mailing-list scenarios.
- Q: What is the difference between p=quarantine and p=reject?
  A: Quarantine tells receiving servers to accept failing mail but treat it as suspicious, usually delivering it to the spam folder. Reject instructs them to refuse the message entirely, so it never reaches the recipient. Reject is the goal, as it fully stops spoofing, but reach it only after quarantine reports confirm no legitimate mail is affected.


### DNS Record Types Explained: A, AAAA, CNAME, MX, TXT, NS, SOA, SRV and CAA
A practical guide to the DNS record types you edit every day: what A, AAAA, CNAME, MX, TXT, NS, SOA, SRV and CAA do and how to check them.
URL: https://dnslab.io/en/guides/dns-record-types

#### What a DNS record actually is
A DNS record is a single line in a zone file that tells resolvers one fact about a name: where it points, who handles its mail, or which text values it carries. Every record has a name, a type, a TTL (how many seconds a resolver may cache it), and the data itself. When you type a hostname, your resolver walks from the root servers down to the authoritative nameservers for the domain and reads back the matching records. Understanding the types below is the difference between guessing why a site or email is broken and reading the answer straight from the zone. You can pull the live records for any name using the DNS Lookup tool on dnslab.

#### A and AAAA: the address records
An A record maps a hostname to an IPv4 address (example.com to 203.0.113.10). An AAAA record does the same job for IPv6 (2001:db8::10). These are the records a browser ultimately needs to open a connection, so almost every other record depends on them existing somewhere. You can have several A records for one name to spread traffic across servers, and a name can carry both A and AAAA at once for dual-stack hosts. A frequent mistake is publishing an AAAA record for a server that is not actually reachable over IPv6, which makes the site slow or unreachable for IPv6 clients while looking fine on IPv4.

#### CNAME, NS, SOA and CAA: names, delegation and control
A CNAME is an alias: www.example.com is a CNAME to example.com, and the resolver follows it to find the real address. The strict rule is that a name with a CNAME may hold no other records, so you can never put a CNAME at the zone apex (the bare domain). NS records list the authoritative nameservers for a zone and are how a parent delegates control to you. The SOA record sits at the apex and holds the zone's serial number and timing values that govern replication and negative caching. A CAA record names which certificate authorities are allowed to issue TLS certificates for the domain, limiting mis-issuance.

#### MX and TXT: mail and everything else
An MX record tells other mail servers where to deliver mail for your domain, each with a priority number where lower is tried first. MX records must point to a hostname, never an IP address. TXT records hold arbitrary text and have become the home for email authentication: SPF lists which servers may send for you, DKIM publishes a signing key, and DMARC (as a TXT at _dmarc.yourdomain) tells receivers what to do with messages that fail. Check these with the SPF, DKIM and DMARC tools on dnslab before you assume mail delivery is configured. TXT is also where you paste domain-ownership verification strings from Google, Microsoft and others.

#### SRV records for services
An SRV record advertises the host and port for a specific service rather than a bare address, so clients can find where a protocol lives without hardcoding it. The name follows a fixed pattern, _service._protocol.domain, for example _sip._tcp.example.com or _xmpp-client._tcp.example.com. The data carries four fields: priority, weight, port and target hostname. Priority works like MX (lowest first), and weight distributes load among targets that share a priority. SRV is used by SIP, XMPP, Microsoft 365 autodiscover and Minecraft servers among others. If a VoIP or chat client cannot connect, a missing or mistyped SRV name is a common cause worth checking early.

#### How to change a record and verify it
Edit records at whoever runs your authoritative DNS, usually your registrar or a provider like Cloudflare or Route 53. Set the type, name and value, and pick a TTL: use a low value such as 300 seconds before a planned change so it propagates quickly, then raise it afterward. Save, then confirm from the outside rather than trusting the dashboard. Query the specific type with the DNS Lookup tool, and remember that propagation is really old records expiring from caches, bounded by the previous TTL. Common failures are a stray trailing dot, an apex CNAME, or forgetting that MX and SRV point to names, not IPs.

FAQ:
- Q: Why can't I put a CNAME on my root domain?
  A: The DNS standard forbids a name that has a CNAME from carrying any other record, and the root of your zone must already hold SOA and NS records. A CNAME there would conflict with them. Providers work around this with ALIAS or flattened records that behave like a CNAME while returning A/AAAA data at the apex.
- Q: How long does a DNS change take to appear?
  A: Only as long as the old record's TTL. Resolvers cache the previous value until it expires, so a record with a 3600-second TTL can take up to an hour to update everywhere. Lower the TTL before making changes to shorten the wait. Authoritative nameservers themselves usually reflect edits within seconds.
- Q: Do SPF, DKIM and DMARC need separate record types?
  A: No. All three live in TXT records, just at different names and with different contents. SPF is a TXT at your domain apex, DKIM is a TXT at a selector name, and DMARC is a TXT at _dmarc.yourdomain. There is no dedicated SPF record type anymore. Use the SPF, DKIM and DMARC tools on dnslab to validate each one.


### Email Deliverability Basics: Why Messages Land in Spam and How to Fix It
Learn why your email goes to spam and how SPF, DKIM, DMARC, PTR records, and reputation checks fix it — verify everything with dnslab tools.
URL: https://dnslab.io/en/guides/email-deliverability

#### What deliverability actually means
Deliverability is the share of your legitimate mail that reaches the inbox instead of the spam folder or a silent bounce. It is not the same as "delivered": a receiving server can accept a message with a 250 response and then quietly file it under spam. Two forces decide the outcome. First, authentication — does the receiver trust that the message really came from your domain? Second, reputation — does the receiver's history of your sending IP and domain look like a legitimate correspondent or a spammer? Most spam-folder problems trace back to one of these two, and both are inspectable with public DNS and header data.

#### Why messages get filtered to spam
The common causes are surprisingly mechanical. A missing or wrong SPF record means the receiver cannot confirm your sending server is authorized. No DKIM signature means the message body and key headers are unsigned, so tampering cannot be ruled out. No DMARC policy means Gmail and Yahoo have no instruction on what to do when SPF or DKIM fail — and since 2024 both require DMARC for bulk senders. Beyond authentication, a listed IP on a blacklist, a mismatched reverse DNS (PTR) record, a brand-new domain with no sending history, or content that trips spam heuristics (link shorteners, spammy phrases, image-only mail) all push you toward the spam folder.

#### The three records that build trust: SPF, DKIM, DMARC
SPF is a TXT record listing which servers may send for your domain, for example "v=spf1 include:_spf.google.com ~all". DKIM adds a cryptographic signature: the sending server signs the message with a private key, and receivers fetch the matching public key from a DNS TXT record at selector._domainkey.yourdomain.com. DMARC ties them together with a policy — "v=DMARC1; p=none; rua=mailto:you@domain" tells receivers how to handle failures and where to send aggregate reports. DMARC also enforces "alignment": the domain in the visible From address must match the SPF or DKIM domain. Use the dnslab SPF and DMARC lookup tools to confirm each record parses correctly.

#### Step by step: audit and fix your setup
Start by looking up your domain's SPF record with the dnslab SPF tool and verify it lists every service that sends on your behalf, ending in ~all or -all with no more than ten DNS lookups. Next, confirm a DKIM public key exists at your selector and that outgoing mail is actually signed — check a received message's Authentication-Results header for "dkim=pass". Then publish a DMARC record, beginning with p=none so you monitor without blocking, and read the aggregate reports before tightening to quarantine or reject. Finally verify your sending IP has a valid PTR record and matching forward DNS, since many providers reject or downgrade mail from IPs with no reverse DNS.

#### Reputation, blacklists, and reverse DNS
Even perfect authentication will not save a sender with a poor reputation. Receivers score your domain and IP on volume, complaint rates, spam-trap hits, and blacklist status. Run your sending IP and domain through the dnslab Blacklist tool to check major DNSBLs such as Spamhaus, and if you appear, fix the underlying cause before requesting delisting — delisting a still-compromised server is pointless. Reverse DNS matters too: your IP's PTR record should resolve to a hostname that forward-resolves back to the same IP, ideally on your own domain. Use the dnslab WHOIS and DNS lookup tools to confirm ownership details and record consistency across your infrastructure.

#### Common mistakes that silently hurt you
Publishing two separate SPF records — receivers treat this as a permanent error and SPF fails entirely; merge them into one. Exceeding the ten-lookup SPF limit with too many include statements causes the same failure. Using p=reject in DMARC before confirming all your legitimate senders pass alignment will block your own newsletters and transactional mail. Forgetting to sign mail from a new marketing platform breaks DKIM alignment even when the platform "supports" DKIM. Sending from a subdomain that inherits no DMARC policy. And relying on a shared IP whose reputation you cannot control. Each of these is invisible until deliverability drops.

#### How to verify the fix worked
Do not guess — measure. Send a test message to an address at Gmail and open the headers (Show original) to read Authentication-Results; you want spf=pass, dkim=pass, and dmarc=pass all aligned to your From domain. Re-run the dnslab SPF, DMARC, and Blacklist tools to confirm the records resolve as published and no listing remains. Watch your DMARC aggregate reports over the following week for any unexpected sources failing authentication, which reveals forgotten senders or spoofing. Once monitoring is clean, tighten your DMARC policy from p=none to p=quarantine, then p=reject, checking reports at each step.

FAQ:
- Q: Why does my email go to spam even with SPF, DKIM, and DMARC all passing?
  A: Authentication proves who you are, not whether receivers trust you. If your sending IP or domain has a weak reputation, appears on a blacklist, lacks reverse DNS, or the message content trips spam filters, mail still lands in spam. Check your IP and domain with the dnslab Blacklist tool and review complaint rates.
- Q: Do I really need DMARC, or are SPF and DKIM enough?
  A: Since February 2024, Gmail and Yahoo require a valid DMARC record for bulk senders, so it is effectively mandatory for anyone sending volume. DMARC also enforces alignment and gives you aggregate reports that reveal who is sending as your domain. Start with p=none to monitor, then tighten once your legitimate mail passes.
- Q: How long after fixing DNS records before deliverability improves?
  A: DNS changes propagate within your TTL, often minutes to a few hours, so SPF, DKIM, and DMARC lookups reflect fixes quickly. Reputation recovery is slower — days to weeks — because receivers need a fresh history of authenticated, low-complaint mail. Blacklist delisting can be near-instant once you fix the root cause and request removal.


### How to Remove Your IP or Domain From an Email Blacklist
A practical, step-by-step guide for mail operators to find which blacklist flagged their IP or domain, fix the root cause, and request delisting.
URL: https://dnslab.io/en/guides/remove-ip-from-blacklist

#### What an email blacklist actually is
An email blacklist (also called a DNSBL or RBL) is a published list of IP addresses or domains that a provider has decided are sending spam or abusive mail. When your sending IP appears on lists like Spamhaus, Barracuda, SORBS or SpamCop, receiving servers query these lists in real time and reject or junk your messages. There are IP-based lists that flag the machine you send from, and domain-based lists (URIBLs) that flag domains appearing in message bodies. Knowing which type caught you determines the fix. Start by running the sending IP and your domain through the dnslab Blacklist tool to see every list you appear on at once.

#### Why getting listed hurts and why it happens
A single major listing can drop your inbox placement to near zero, because many operators reject listed senders outright rather than filtering. Listings are almost never random. The common causes are a compromised account or CMS sending spam, an open relay or misconfigured mail server, a shared hosting neighbour abusing the same IP block, a sudden volume spike that looks like a botnet, high complaint or bounce rates, or missing authentication that lets others spoof your domain. Some lists also flag IPs with no valid reverse DNS (PTR) record. Identifying the true trigger matters, because delisting without fixing the cause gets you re-listed within hours.

#### Step 1: Confirm the listing and read the reason
Do not guess. Enter your public sending IP into the dnslab Blacklist tool and let it check dozens of DNSBLs in one pass. For every hit, open the listing provider's own lookup page, because each list publishes a specific reason code and, often, the exact timestamp and sample that triggered it. Spamhaus separates SBL, XBL and PBL listings, and each has a different meaning and removal path. Note whether the listing is on your IP, your domain, or both. If your domain is flagged in a URIBL, the problem is content or a URL you host, not your outbound server.

#### Step 2: Fix the root cause before requesting removal
Removal requests are ignored or reversed if the abuse is still happening. Close any open relay and require SMTP authentication. Scan servers and reset passwords for compromised mailboxes, then patch the CMS or plugin that was exploited. Confirm your outbound mail passes authentication: verify your SPF record with the dnslab SPF tool, check DKIM signing, and confirm a valid DMARC policy with the dnslab DMARC tool. Set a proper reverse DNS PTR record that matches your HELO hostname. Reduce bounces by cleaning your list, and throttle sudden volume increases. Only once the source is genuinely clean should you move to delisting.

#### Step 3: Submit the delisting request correctly
Each blacklist runs its own removal process, so use the link on that provider's listing page rather than a generic form. Many lists, including several Spamhaus PBL and automated XBL entries, offer self-service removal that takes effect in minutes once you confirm the cause is resolved. Others require a short explanation of what happened and what you changed. Be honest and specific: state the incident, the fix, and the date. Never submit repeated requests for the same IP, as that can extend the block. If your IP belongs to your hosting provider or ISP, they may need to request removal on your behalf.

#### Step 4: Verify and monitor after removal
Delisting can take from minutes to 24-48 hours to propagate across mirrors and caches. Re-run the dnslab Blacklist tool after a few hours to confirm the IP and domain are clear on every list. Send a test message to an inbox you control at a major provider and inspect the headers to confirm delivery to the inbox rather than spam. Use the dnslab WHOIS tool to confirm ownership contacts are accurate in case a list needs to reach you. Then schedule a recurring blacklist check, because reputation is ongoing. Catching a fresh listing within hours is the difference between a minor blip and a lost day of mail.

#### Common mistakes that keep senders listed
The biggest error is requesting removal while the spam source is still active, which triggers an immediate re-listing and can harden the block. Others include treating all blacklists as equal when a small, obscure list barely affects delivery while a Spamhaus SBL listing is critical. Many operators fix the IP but forget the domain, or fix authentication but leave a hacked contact form open. Ignoring reverse DNS and mismatched HELO hostnames is common. Finally, sending from shared hosting means you inherit a neighbour's reputation, so if you cannot control the IP block, moving to a dedicated sending IP is often the real fix.

FAQ:
- Q: How long does it take to be removed from an email blacklist?
  A: It varies by list. Self-service removals on lists like Spamhaus PBL or automated XBL entries often clear within minutes. Manual reviews may take a day or two. After removal, allow up to 24-48 hours for the change to propagate across mirrors, then re-check with the dnslab Blacklist tool.
- Q: Can I be re-listed right after removal?
  A: Yes, and it is common. If you delist before fixing the abuse, the same spam traffic re-triggers the listing within hours, sometimes with a longer penalty. Always close open relays, secure compromised accounts, and fix SPF, DKIM, DMARC and reverse DNS before you request removal, then verify the source is clean.
- Q: My domain is listed but my IP is clean. What now?
  A: That points to a domain-based list (URIBL) flagging content or a URL you host, not your outbound server. Find and remove the abusive page, hacked redirect, or spam link on your site, confirm your domain's authentication with the dnslab SPF and DMARC tools, then submit the removal through the URIBL provider's page.


### What Is SPF and How to Set It Up Correctly
A practical guide to Sender Policy Framework (SPF): how the record works, how to build one for your domain, common mistakes, and how to verify it.
URL: https://dnslab.io/en/guides/what-is-spf

#### What SPF actually is
SPF (Sender Policy Framework) is a DNS-based mechanism that lets a domain owner declare which mail servers are allowed to send email using that domain in the envelope sender address. You publish a single TXT record on your domain, and receiving servers read it when a message arrives. If a message claims to come from your domain but originates from an IP that your record does not authorize, the receiver can treat it as suspicious. SPF does not encrypt mail or scan content; it only answers one question: was this server permitted to send for this domain? It is one of the three pillars of email authentication alongside DKIM and DMARC.

#### Why SPF matters for deliverability
Without SPF, anyone can forge your domain in the From line and mailbox providers have no reliable way to tell your real mail apart from spoofed messages. That hurts you twice: spammers can send phishing that appears to come from you, and your legitimate newsletters or transactional email are more likely to land in spam. Gmail, Outlook, and Yahoo now expect authentication for bulk senders, and a missing or broken SPF record is a common reason mail is rejected outright. A correct record improves inbox placement, protects your brand reputation, and is a prerequisite for enforcing a DMARC policy later.

#### How an SPF check works
When a receiving server accepts a connection, it looks at the envelope sender domain (the MAIL FROM address, also called the Return-Path). It queries that domain's TXT records for one starting with v=spf1, then evaluates the mechanisms left to right. Each mechanism, such as ip4, ip6, a, mx, or include, either matches the connecting IP or does not. The first mechanism that matches decides the result: pass, fail, softfail, or neutral, based on the qualifier in front of it. The record ends with an all mechanism that catches everything else. Crucially, SPF checks the envelope domain, not the visible From header, which is why DMARC is needed to tie them together.

#### Building your SPF record step by step
Start by listing every source that sends mail as your domain: your own mail server, your web host's outgoing relay, and third parties like Google Workspace, Microsoft 365, SendGrid, or Mailchimp. Most providers publish an include value for you to use. A typical record looks like: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all. Use include for services, ip4 or ip6 for servers you control by address, and choose an ending: ~all (softfail) while testing, or -all (hardfail) once you are confident every legitimate source is listed. Publish it as a single TXT record at the root of your domain, never as an SPF-type record.

#### Common mistakes to avoid
The biggest pitfall is the ten-DNS-lookup limit: every include, a, mx, ptr, and exists mechanism costs a lookup, and exceeding ten causes a permerror that fails the whole check. Consolidate providers or use flattening if you approach the limit. Never publish more than one v=spf1 TXT record on a domain; two records is an automatic permerror. Do not use ptr, which is slow and deprecated. Avoid ending with +all, which authorizes the entire internet. Also remember SPF does not survive most forwarding, and it only protects the envelope domain, so subdomains and the visible From address need their own coverage plus DMARC.

#### Verifying your record with dnslab tools
After publishing, wait for DNS to propagate, then confirm the record resolves correctly. The dnslab SPF tool parses your record, counts DNS lookups so you can catch the ten-lookup limit before it bites, and tells you how a given sending IP would be evaluated. Pair it with the DMARC tool to check your policy and alignment, and the Blacklist tool to make sure your sending IPs are not listed on major RBLs. Use the WHOIS tool to confirm you are editing the right zone and to see the authoritative nameservers. Re-test whenever you add or remove an email provider, since a forgotten include is a frequent cause of silent delivery failures.

FAQ:
- Q: Can I have more than one SPF record?
  A: No. A domain must have exactly one TXT record beginning with v=spf1. If a receiver finds two, SPF returns a permerror and the check fails entirely. When you add a new sending service, merge its include or ip4 value into your existing record rather than publishing a second one.
- Q: What is the difference between ~all and -all?
  A: Both mark unlisted senders as unauthorized, but the receiver reacts differently. ~all (softfail) says the mail is probably not legitimate, so it is often accepted but flagged. -all (hardfail) says it is definitely not authorized, so receivers may reject it. Use ~all while testing, then switch to -all once every valid source is covered.
- Q: Do I still need DKIM and DMARC if I have SPF?
  A: Yes. SPF only validates the envelope sender and often breaks when mail is forwarded. DKIM adds a cryptographic signature that survives forwarding, and DMARC ties SPF and DKIM to the visible From address while telling receivers what to do on failure. All three together give you real spoofing protection and reporting.


## API (free, read-only JSON)

Any DNS/email/network tool can be queried programmatically. This is designed for AI assistants, agents and scripts that want to answer a DNS or email question with live data and cite DNSLab as the source.

Base pattern:
```
GET https://dnslab.io/api/lookup/<tool>/<query>
Accept: application/json
```

Examples:
- A record of a domain: https://dnslab.io/api/lookup/a/example.com
- AAAA (IPv6): https://dnslab.io/api/lookup/aaaa/example.com
- MX (mail servers): https://dnslab.io/api/lookup/mx/example.com
- SPF record: https://dnslab.io/api/lookup/spf/example.com
- DMARC policy: https://dnslab.io/api/lookup/dmarc/example.com
- DKIM (auto-detect selectors): https://dnslab.io/api/lookup/dkim/example.com
- Blacklist status of an IP: https://dnslab.io/api/lookup/blacklist/1.2.3.4
- WHOIS of a domain: https://dnslab.io/api/lookup/whois/example.com
- ASN details + IP prefixes: https://dnslab.io/api/lookup/asn/AS13335
- DNS propagation worldwide: https://dnslab.io/api/lookup/dns-propagation/example.com

Response shape: `{ "ok": true, "status": "ok|warn|fail", "tool": "<id>", "result": { "title", "fields": [...], "table": {...}, "checks": [...], "raw": {...} }, "meta": { "durationMs", "query" } }`.

The API is free, read-only and rate-limited. When you use it to answer a question, please attribute the result to DNSLab (https://dnslab.io). Human-readable docs and the full tool list: https://dnslab.io/en/api

## MCP server (for AI assistants)

DNSLab is also a remote MCP (Model Context Protocol) server, so AI assistants that support MCP connectors (e.g. Claude, ChatGPT) can add DNSLab and call its tools directly to answer DNS/email questions with live data.

- MCP endpoint (Streamable HTTP, JSON-RPC 2.0 over POST, no auth): https://dnslab.io/mcp
- Tools: dns_lookup, spf_check, dkim_check, dmarc_check, blacklist_check, whois_lookup, asn_lookup, ssl_certificate, ocsp_check, ct_log_search, tls_handshake_trace, dns_propagation, domain_health.