Domain Email and DNS Checker API: MX, SPF, DMARC, Providers avatar

Domain Email and DNS Checker API: MX, SPF, DMARC, Providers

Pricing

from $0.70 / 1,000 domains

Go to Apify Store
Domain Email and DNS Checker API: MX, SPF, DMARC, Providers

Domain Email and DNS Checker API: MX, SPF, DMARC, Providers

Find which email provider, sending services and DNS host each domain uses, from public DNS records only. MX, SPF, DMARC, BIMI and verification TXT read per domain, no personal data, pay only per domain checked.

Pricing

from $0.70 / 1,000 domains

Rating

0.0

(0)

Developer

Rowcraft

Rowcraft

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

17 hours ago

Last modified

Share

Find out who runs the email and the DNS of a domain: which provider hosts its mailboxes (Google Workspace, Microsoft 365, Zoho, Proton, Fastmail and more), which security gateway filters the mail (Mimecast, Proofpoint, Barracuda), which services are allowed to send for it (SendGrid, Mailchimp, Amazon SES, HubSpot, Salesforce, Zendesk), who hosts its DNS, and how well the domain is protected against spoofing (SPF, DMARC, MTA-STS, TLS-RPT, BIMI). Give the actor a list of domains and it returns one row per domain, as JSON, CSV or Excel, from public DNS records only.

It reads nothing else: no website is visited, no WHOIS or RDAP service is asked, no mailbox is touched. DNS is an open protocol meant to be read by anyone, so there is no login, no CAPTCHA, no proxy and no robots.txt in play, and no personal data in the result.

Input form of Domain Email and DNS Checker API: MX, SPF, DMARC, Providers

What you get

One row per domain that exists and answered:

  • Mail setup: the MX servers with their priority, the domain behind each, the mail provider (emailProvider), whether that name was read from the MX hosts or inferred from the SPF record (emailProviderSource), and the security gateway in front of the mailboxes (emailSecurityGateway)
  • Sending services: the SPF record as published, the hosts in its include:, the services those hosts belong to (spfServices, read through the whole include tree, not only the first level), how the record ends (-all, ~all, ?all, +all) and how many DNS lookups it costs against the limit of 10
  • DMARC: the policy (none, quarantine, reject), the subdomain policy, the percentage, the domains that receive the reports (never the addresses) and the reporting service when it is a known one
  • Transport security and branding: whether MTA-STS, TLS-RPT and BIMI records exist
  • DNS: the name servers, the DNS provider (Cloudflare, Amazon Route 53, Google Cloud DNS, Azure DNS, GoDaddy, Namecheap, NS1, DNSimple and others), the IPv4 and IPv6 addresses, a hosting hint when an address sits in a range the platform publishes, and the certificate authorities the domain allows (CAA)
  • Services the owner signed up for: domain-verification records (Google, Microsoft 365, Atlassian, Apple, DocuSign, Stripe, HubSpot, Zoom, Adobe and about ninety more) turned into names of services
  • A score and a list of problems: emailSecurityScore from 0 to 100 and issues such as spf_missing, dmarc_none or spf_too_many_lookups
  • Change tracking: a profileHash of the providers and policies, and the time of the check

The run also writes a COVERAGE record with one line per domain you asked for (ok, not_found, no_records, error or not_checked, with the reason) and a RUN_SUMMARY with counts, the most frequent providers and the DMARC and SPF policies of the list.

Why this actor

  • One row answers the sales and the security question. Who runs their mail, who sends their newsletters, who filters their inbound mail, who hosts their DNS and are they exposed to spoofing: the columns are ready to filter in a spreadsheet, with no second tool in between.
  • Names, not raw records. Other lookups return include:_spf.google.com and leave you to decode it. This actor returns "Google Workspace", and it follows the include tree, so a service named two levels down is found too.
  • Rowcraft's own fingerprints. The tables (42 mail hosts and gateways, 59 sending services, 39 DNS providers, 95 verification services, 16 DMARC reporting services) were written by Rowcraft from each provider's public documentation and checked against the records of real company domains, not copied from another tool. Every pattern is anchored on a name the provider owns, so a look-alike host cannot match.
  • Honest about what it does not know. An unknown mail host is Other, never a guess. A mailbox provider read from SPF behind a gateway is marked as inferred. A lookup that failed is listed in lookupErrors and the fields that depend on it are null, so a server failure is never reported as "no DMARC record".
  • Pay only for domains that answered. Domains that do not exist, cannot be resolved, hold no records, are invalid or repeated in your list, or are unchanged with Only new rows are never charged.
  • Light on the DNS. At most 5 domains and 10 queries at a time, one retry on a server failure, SPF include hosts cached for the whole run.

How to use it

  1. Open the Actor and paste your domains or URLs into Domains, one per line. A column copied from a spreadsheet works, and so do entries separated by commas.
  2. For a first try keep the list short, or set Maximum domains delivered to a small number.
  3. Click Start. The status line shows progress; the run stops cleanly at your maximum or at the charge limit you set in the run options.
  4. Open the Dataset tab: the Overview, Sending services and E-mail security views show the main columns. Download JSON, CSV, Excel, XML or HTML, or send the rows to Google Sheets, Slack, Make, n8n or Zapier with the Integrations tab.
  5. Open the COVERAGE record in the key-value store to see which domains could not be read and why.
  6. To watch a list over time, run it on a schedule with Only new rows since the last run turned on: a domain is delivered, and charged, again only when its providers or policies changed.

Input

FieldWhat it does
domainsDomains (example.com) or addresses (https://www.example.com/shop), one per line. Only the domain name is used; a leading www. is dropped. Up to 100,000 per run. E-mail addresses, IP addresses and private names (.local, .internal) are refused.
maxItemsStop after this many delivered rows. 0 = the whole list.
onlyNew, stateNameDeliver a domain only when its providers or policies changed since the last run with the same state name
notifyUrl, notifyWhenEmptyA webhook that receives one message when the run ends; see Automation below
requestIntervalMsOptional pause between domains, default 0. DNS has no robots.txt and the actor already limits itself to 5 domains and 10 queries at a time.

Example: three domains, one row each.

{
"domains": ["shopify.com", "hubspot.com", "atlassian.com"]
}

Example: a weekly check of a customer list that reports only the domains whose setup changed, with a Slack message.

{
"domains": ["customer-one.com", "customer-two.com", "customer-three.com"],
"onlyNew": true,
"stateName": "customers",
"notifyUrl": "https://hooks.slack.com/services/..."
}

Output

34 fields per row. Empty values are null, never missing, so CSV and Excel columns are stable.

FieldTypeExample
idstringexample.com
domainstringexample.com
mxarray[{"host": "aspmx.l.google.com", "priority": 1}, {"host": "alt1.aspm…
mxDomainsstringgoogle.com
emailProviderstringGoogle Workspace
emailProviderSourcestringmx
emailSecurityGatewaystringMimecast
spfRecordstringv=spf1 include:_spf.google.com include:sendgrid.net ~all
spfIncludesstring_spf.google.com, sendgrid.net
spfServicesstringGoogle Workspace, SendGrid
spfAllstring~all
spfLookupCountinteger3
dmarcPolicystringreject
dmarcSubdomainPolicystringquarantine
dmarcPctinteger100
dmarcReportDomainsstringdmarcian.com
dmarcServicesstringdmarcian
hasBimibooleanFalse
hasMtaStsbooleanTrue
hasTlsRptbooleanTrue
nameserversstringns1.example-dns.net, ns2.example-dns.net
dnsProviderstringCloudflare
aRecordsstring104.18.32.7, 104.18.33.7
aaaaRecordsstring2606:4700::6812:2007
hostingHintstringCloudflare
caaIssuersstringletsencrypt.org
verifiedServicesstringAtlassian, Google (Search Console / Workspace), Stripe
verifiedServiceCountinteger3
txtCountinteger12
emailSecurityScoreinteger80
issuesstringdmarc_none, dmarc_no_reporting
lookupErrorsstringDMARC, MTA-STS
profileHashstring3f9a1c27b0d4e856
checkedAtstring2026-10-15T08:12:44.120Z

Lists are delivered as one text, items separated by a comma and a space (for example spfServices: Google Workspace, SendGrid), and are null when empty. That way the results table and a CSV or Google Sheets export show one cell per domain instead of "2 items" or a column per item. Only mx is a real list (of host and priority). verifiedServiceCount counts the services in verifiedServices and is handy for sorting.

Example rows

Two real rows from a run (long texts shortened here, complete in the dataset):

[
{
"id": "shopify.com",
"domain": "shopify.com",
"mx": [
{
"host": "aspmx.l.google.com",
"priority": 1
},
{
"host": "alt1.aspmx.l.google.com",
"priority": 5
},
{
"host": "alt2.aspmx.l.google.com",
"priority": 5
},
"… 2 more"
],
"mxDomains": "google.com",
"emailProvider": "Google Workspace",
"emailProviderSource": "mx",
"emailSecurityGateway": null,
"spfRecord": "v=spf1 include:_spf.google.com include:mail.zendesk.com include:sendgrid.net ~all",
"spfIncludes": "_spf.google.com, mail.zendesk.com, sendgrid.net",
"spfServices": "Google Workspace, SendGrid, Zendesk",
"spfAll": "~all",
"spfLookupCount": 4,
"dmarcPolicy": "reject",
"dmarcSubdomainPolicy": null,
"dmarcPct": 100,
"dmarcReportDomains": "shopify.com",
"dmarcServices": null,
"hasBimi": true,
"hasMtaSts": false,
"hasTlsRpt": false,
"nameservers": "gold.foundationdns.com, gold.foundationdns.net, gold.foundationdns.org",
"dnsProvider": "Cloudflare",
"aRecords": "23.227.38.33",
"aaaaRecords": null,
"hostingHint": null,
"caaIssuers": null,
"verifiedServices": "Adobe, Amazon SES, Apple, Atlassian, Autodesk, DocuSign, Drift, GlobalSign, Google (Search Console / Workspace), Klaviyo, Linear, LiveRam…",
"verifiedServiceCount": 23,
"txtCount": 53,
"emailSecurityScore": 80,
"issues": null,
"lookupErrors": null,
"profileHash": "1f9ee7e6edc17ed5",
"checkedAt": "2026-10-14T17:57:16.642Z"
},
{
"id": "python.org",
"domain": "python.org",
"mx": [
{
"host": "mail.python.org",
"priority": 50
}
],
"mxDomains": "python.org",
"emailProvider": "Own mail server",
"emailProviderSource": "mx",
"emailSecurityGateway": null,
"spfRecord": "v=spf1 mx ip4:188.166.95.178/32 ip6:2a03:b0c0:2:d0::71:1 include:stspg-customer.com include:_spf.google.com include:mailgun.org ~all",
"spfIncludes": "_spf.google.com, mailgun.org, stspg-customer.com",
"spfServices": "Atlassian Statuspage, Google Workspace, Mailgun",
"spfAll": "~all",
"spfLookupCount": 8,
"dmarcPolicy": "none",
"dmarcSubdomainPolicy": "none",
"dmarcPct": 100,
"dmarcReportDomains": "dmarc.postmarkapp.com",
"dmarcServices": "Postmark DMARC Digests",
"hasBimi": false,
"hasMtaSts": false,
"hasTlsRpt": false,
"nameservers": "ns-1134.awsdns-13.org, ns-2046.awsdns-63.co.uk, ns-484.awsdns-60.com, ns-981.awsdns-58.net",
"dnsProvider": "Amazon Route 53",
"aRecords": "151.101.0.223, 151.101.128.223, 151.101.192.223, 151.101.64.223",
"aaaaRecords": "2a04:4e42::223, 2a04:4e42:200::223, 2a04:4e42:400::223, 2a04:4e42:600::223",
"hostingHint": "Fastly",
"caaIssuers": null,
"verifiedServices": "Anthropic, Atlassian Statuspage, GlobalSign, Google (Search Console / Workspace), Microsoft 365, OpenAI, Twilio",
"verifiedServiceCount": 7,
"txtCount": 13,
"emailSecurityScore": 50,
"issues": "dmarc_none",
"lookupErrors": null,
"profileHash": "db8af56c62e9f013",
"checkedAt": "2026-10-14T17:57:19.025Z"
}
]

Results can be downloaded as JSON, CSV, Excel, XML or HTML from the Dataset tab, or read through the Apify API.

Results of Domain Email and DNS Checker API: MX, SPF, DMARC, Providers in the Apify dataset view

How the score and the problems are worked out

emailSecurityScore is a plain sum, so you can see where every point comes from:

PartPoints
SPF record present, exactly one15
SPF ends with -all / ~all / ?all15 / 10 / 3
SPF costs 10 DNS lookups or fewer5
DMARC record valid10
DMARC policy reject / quarantine / none25 / 18 / 5
DMARC applies to 100% of mail with an enforcing policy5
DMARC has a reporting address (rua)5
MTA-STS record10
TLS-RPT record5
BIMI record5

The maximum is 100. The score is null when the TXT lookup or the DMARC lookup failed, because a guess would be wrong in one direction or the other. A domain that sends no mail (a null MX, v=spf1 -all, DMARC reject) scores high on purpose: that is the recommended setup.

issues is one text, problem codes separated by commas (null when none was found), listing what is worth fixing or worth selling against: no_mx (no mail server record), spf_missing, spf_multiple_records (more than one SPF record, which is invalid), spf_too_many_lookups (over the limit of 10, so receivers may reject the record), spf_allows_all (+all), spf_neutral (?all), spf_no_all (no closing mechanism), dmarc_missing, dmarc_invalid, dmarc_multiple_records, dmarc_none (monitoring only), dmarc_pct_below_100, dmarc_no_reporting and single_nameserver. The standards behind them are SPF (RFC 7208), DMARC (RFC 7489), MTA-STS (RFC 8461), TLS-RPT (RFC 8460) and null MX (RFC 7505).

Pricing

Pay per result. You pay for each domain read and delivered to your dataset, nothing else: no subscription, no minimum, no charge for domains that do not exist or could not be resolved (NXDOMAIN, server failure, timeout), for domains that hold no records, for invalid or repeated entries, or for domains skipped by Only new rows because nothing changed.

Your Apify planPrice per 1,000 rowsPrice per row
Free plan$1.00$0.001
Starter plan$0.90$0.0009
Scale plan$0.80$0.0008
Business plan and above$0.70$0.0007

Example: 1,000 domains cost $1.00 on the Free plan and $0.70 on the Business plan. The Apify platform usage of a run (compute and storage) is billed by Apify separately, as for every Actor; the actor runs in 256 MB and spends most of its time waiting for DNS answers. A start event of $0.00005 is charged once per run (Apify default). Cap your spend: set Maximum total charge in the run options. The actor stops cleanly when the cap is reached and you keep everything delivered until then. The run summary (RUN_SUMMARY in the key-value store) says why a run stopped.

Automation: only new rows, notifications, schedules

Only new rows since the last run. Turn on onlyNew and the actor remembers, for every domain it delivered to you, the profile it had (in a key-value store named rowcraft-domain-email-dns-checker-state in your Apify account). The profile is the mail provider, the security gateway, the sending services, the SPF and DMARC policy, the DNS provider, the verified services, the certificate authorities and the hosting hint. The next run with the same stateName delivers a domain again only when one of those changed; a new IP address, a rotated verification token or a different number of TXT records does not count. The first run delivers every domain it can read. Use a different stateName for each list so they keep separate memories.

Notification when the run ends. Put a webhook address in notifyUrl and the actor sends one JSON POST with the number of delivered rows, links to the dataset (JSON and CSV) and the run. It works with Slack and Discord incoming webhooks (the message is in text and content), with Make, n8n and Zapier catch hooks, and with your own endpoint. By default it is sent only when at least one row was delivered; notifyWhenEmpty sends it every time.

Schedules. Create a schedule in Apify Console (daily, weekly, monthly or cron) with onlyNew on, and you get a feed of the domains in your list that moved to another mail provider, switched on DMARC or changed their DNS host, for the price of those rows only.

Integrations. Send the results to Make, n8n, Zapier, Google Sheets, Slack, Google Drive, Airtable or any webhook from the Integrations tab of the Actor, with no code.

API, SDKs and AI agents. Every run is available through the Apify API and the official JavaScript and Python clients; the Actor can also be called by AI agents through the Apify MCP server. The example input in the API tab is a working call.

Use cases

  • Prospecting by mail provider: from a list of company domains, keep the ones on Google Workspace or Microsoft 365 and sell migration, backup, security or training to exactly those.
  • Displacing a gateway or a sending service: find the domains behind Mimecast, Proofpoint or Barracuda, or the ones that send through SendGrid, Mailchimp or Amazon SES, and offer the alternative.
  • Selling email authentication: the domains with dmarc_missing, dmarc_none or spf_too_many_lookups are the ones that need a DMARC, SPF or deliverability service, and the issues column says which.
  • Agency and MSP onboarding: audit a new client's domains in one run before the first meeting: who hosts the DNS, who sends their mail, which SaaS tools they already verified.
  • Due diligence and vendor risk: check the domains of an acquisition target, a supplier or a portfolio for spoofable setups and for the SaaS stack visible in DNS.
  • DNS and hosting migration leads: filter by dnsProvider and hostingHint to find the domains on a provider you want to win customers from.
  • Market research: the share of Microsoft 365 against Google Workspace, of DMARC reject against none, of Cloudflare against Route 53 in any list of domains, straight from the RUN_SUMMARY.
  • Monitoring: a weekly schedule with Only new rows tells you when a competitor, a customer or a supplier changes mail provider or tightens its DMARC policy.

Ready-made examples, each with the input filled in (open one and press Start, or save it as your own task):

What this actor does not do

  • Collect contacts: no e-mail addresses, phone numbers, names of people or social profiles. The contact address of the domain's hostmaster (SOA) is not read, report addresses in DMARC are reduced to their domain, and an address found in a TXT record is never delivered.
  • Look up WHOIS or RDAP data: no registrar, registration date, expiry date or owner is delivered. This actor reads DNS and nothing else.
  • Visit the website or the mail server: no HTTP request, no connection to port 25, no mailbox test, no "is this address valid" check.
  • Check DKIM: the selector names are chosen by each sender and cannot be listed from outside, so DKIM is not reported. The services found through SPF and the verification records show who sends.
  • Fetch the MTA-STS policy file: hasMtaSts says the DNS record exists, not that the policy file behind it is valid.
  • Apply DMARC inheritance: the record is read at the exact name you give. For a subdomain without its own record, the policy of the parent domain may still apply, and the row says dmarc_missing. Give the main domain to get its policy.
  • Give a verdict on the security of a company: the score summarises four DNS-published mechanisms, nothing more.
  • Return history: each row is the setup seen at the time of the run; for changes over time use Only new rows on a schedule.

Limits and fair use

  • Ten lookups per domain, plus the SPF include tree (the hosts are cached for the run, so a list of companies that all include the same services costs few extra queries). In our local test 25 well-known domains took 9 seconds, so a list of 1,000 takes a few minutes. The actor works through up to 5 domains at a time with at most 10 queries in flight.
  • What DNS shows. A provider is recognised from the name of a host, so a mail provider that is not in the tables is Other, and a setup that hides behind a custom hostname (a mail server under the company's own domain) is Own mail server. Provider names change; the tables are updated with each release listed in the changelog.
  • Gateways and inferred providers. When the MX hosts belong to a security gateway, the real mailbox provider is read from SPF only when exactly one mailbox provider (Google Workspace, Microsoft 365, Zoho, Proton, Fastmail, IONOS or OVH) is named there, and the row says emailProviderSource: "spf". Treat it as likely, not certain.
  • Server failures are not "no record". A lookup that fails after one retry is listed in lookupErrors; if nothing at all can be resolved the domain is error in COVERAGE and is not charged. After 10 such domains in a row the run stops and says so, because the resolver is most likely down.
  • Caches. Answers come through the platform's DNS resolver, so a record changed a few minutes ago may still show its old value until its TTL ends.
  • Up to 100,000 domains per run. The run stops 90 seconds before its timeout with the summary, the coverage and the Only new rows memory saved; for long lists raise the timeout or split the list.

Data source and licence

The data is public DNS: the MX, TXT, NS, A, AAAA and CAA records of the domain, and the TXT records published at _dmarc, default._bimi, _mta-sts and _smtp._tls under it. The actor asks the DNS resolver of the Apify platform, the same question any mail server or browser asks, and keeps only provider names, policies, host names and the other fields listed in the Output table. The raw TXT records are not delivered, except the SPF record, which is itself a published list of hosts allowed to send mail.

The fingerprint tables are Rowcraft's own work, written from the public documentation of each provider and tested on real domains. They are not derived from any other tool's rule set. Rowcraft is independent and not affiliated with or endorsed by the providers and services it names (Google, Microsoft, Zoho, Cloudflare, Amazon, Mimecast, Proofpoint and the others); their names and trademarks belong to their owners and are used only to say which service a record points to. The hosting hints use the address ranges that Cloudflare and Fastly publish for their own networks and the addresses that Vercel, Netlify, GitHub Pages and Squarespace give their customers in their setup guides.

Privacy: no personal data

Rowcraft actors are built not to collect personal data:

  • The row holds provider names, policies, host names, IP addresses of the domain and counts. Nothing in it identifies a person.
  • The e-mail address of the zone's administrator (the SOA record) is never read. The report addresses in DMARC (rua, ruf) are cut to the domain after the @ sign before anything is stored. An address found in a TXT record is masked or left out, and the contact entries of CAA records (iodef) are ignored.
  • If an entry in your list is an e-mail address, it is refused and not echoed back in the coverage record.
  • The actor sends no cookies, fills no forms and never logs in anywhere.

You are responsible for using the data in line with the law that applies to you.

Other Rowcraft actors

All Rowcraft actors read official or public sources, deliver flat rows without personal data and support only-new runs and notifications:

FAQ

Which mail providers can it recognise? The mailbox providers Google Workspace, Gmail, Microsoft 365, Outlook.com, Zoho Mail, Proton Mail, Yandex Mail, iCloud Mail, Fastmail, OVH Mail, GoDaddy Email, IONOS Mail, Amazon WorkMail, Rackspace Email, Namecheap Private Email, Gandi Mail, Titan Email, Hostinger Email, Mailbox.org, Tuta Mail, Seznam, VK Mail, Strato, Hetzner, Cloudflare Email Routing, Migadu, Forward Email, ImprovMX, GMX, WEB.DE and Yahoo Mail, and the gateways Mimecast, Proofpoint, Barracuda, Cisco Secure Email, Symantec Email Security.cloud, Cloudflare Email Security, Trend Micro, Hornetsecurity, Forcepoint, SpamExperts and Sophos. Anything else is Other (or Own mail server when the MX host is under the domain's own name).

How does it know which services send mail for a domain? From the SPF record: every include: and redirect= host, at any depth of the include tree, is compared with a table of 59 services (Google Workspace, Microsoft 365, SendGrid, Mailchimp, Mandrill, Amazon SES, Postmark, SparkPost, HubSpot, Salesforce, Zendesk, Freshdesk, Klaviyo, Brevo, Mailjet and others). A service that sends without an SPF entry, or from a hosted address you share with others, cannot be seen from DNS.

What are the verification records? When a company signs up for Google Search Console, Microsoft 365, Atlassian, Stripe, DocuSign and many other services, the service asks it to publish a TXT record that proves it owns the domain, and the record usually stays. The actor turns the record names into service names (never the token) and delivers the list in verifiedServices. It shows the tools a company has used, not the tools it uses today.

Why does the SPF lookup count matter? SPF allows 10 DNS lookups per check. A record that needs more makes receivers return an error, and mail from that domain may land in spam or be rejected. The actor counts the lookups through the whole include tree and reports spf_too_many_lookups above 10.

Is it legal? The actor reads public DNS records, which are published so that anyone can read them, through the platform's resolver and at a low rate, and delivers provider names and policies, not personal data. Whether and how you may use the results (for example for marketing) depends on the law that applies to you.

Does it collect personal data? No personal data: no e-mail addresses, phone numbers or people's names, and no WHOIS contacts. See the Privacy section.

Why is the result empty? Every domain in the list did not exist (not_found), could not be resolved because of a DNS server failure (error), held none of the records asked for (no_records), was an invalid entry, or, with Only new rows on, had not changed since the last run. The COVERAGE record gives the reason per domain, and nothing is charged for any of them apart from the start event.

Do I pay for domains that do not exist? No. not_found, no_records, error, invalid entries and duplicates in your list are never charged.

Can I give full URLs or subdomains instead of domains? Yes for URLs: the address is reduced to its domain. A subdomain such as mail.example.com is checked as it is, with its own records; give the main domain to read the policies that apply to the company's mail.

Does it check DKIM, WHOIS or whether an address exists? No. See "What this actor does not do" above.

How does Only new rows work here? The actor remembers the profile of each domain delivered to you. The next run with the same state name delivers a domain only when its providers or policies changed, so a weekly schedule costs only the domains that moved.

Support and reviews

Problems, missing fields, questions: open an issue on the Issues tab of this Actor. We answer within one working day and fix confirmed bugs in the next release; the changelog lists every change.

If this Actor saved you time, a short review on its page helps other users find it and helps us keep improving it.