Hunter's Domain Health Check looks for common issues on your sending domain used in Sequences.
Because email accounts are connected via SMTP/IMAP, Hunter can't detect your email provider automatically. The steps below are provider-agnostic and focus on what to change in your domain's DNS.
If you're not sure where DNS is managed or how to find the right record values for your setup, start here: Add SPF, DKIM, and DMARC records for a custom SMTP/IMAP sending domain
After updating DNS, use this checklist to confirm everything is published correctly: Verify SPF, DKIM, and DMARC records (and fix common DNS mistakes)
SPF issues
SPF is a TXT record published on your root domain (example.com). To fix SPF issues, you'll update your domain's DNS.
Useful links:
SPF record missing
What it means
Your domain has no SPF record. Inbox providers can't confirm which servers are allowed to send emails for your domain.
What to do
Add a single SPF TXT record based on your email provider's documentation. Publish it on the root domain (example.com). Find where to setup SPF here.
Multiple SPF records detected
What it means
SPF must be published as a single record. Multiple SPF records can cause SPF to fail or be ignored.
What to do
Merge all SPF mechanisms (include:, ip4/ip6, etc.) into one SPF TXT record, then remove the extra SPF records.
SPF record misconfigured (invalid or too complex)
What it means
Hunter found an SPF record, but it looks invalid or too complex (for example: formatting issues or too many DNS lookups). Some inbox providers may treat SPF as failing.
What to do
Confirm the SPF value follows valid SPF syntax
Remove duplicate or unused mechanisms (especially unused include entries)
Consolidate sending sources where possible to reduce DNS lookups
SPF policy not enforced (missing ~all or -all)
What it means
Your SPF record doesn't end with an "all" mechanism, so it doesn't clearly state how inbox providers should treat unauthorized senders.
What to do
Update your SPF record to end with ~all (soft fail) or -all (hard fail), based on your internal email policy.
SPF policy too permissive (+all)
What it means
Your SPF record uses +all, which effectively allows any server to send on behalf of your domain. This increases spoofing risk and can seriously hurt deliverability.
What to do
Replace +all with ~all or -all, and make sure only legitimate sending sources are included.
SPF policy neutral (?all)
What it means
Your SPF record uses ?all (neutral), which can reduce authentication trust signals.
What to do
Replace ?all with ~all or -all based on your internal email policy.
DKIM issues
DKIM is a TXT record published on a selector hostname (not the root domain), usually like: selector._domainkey.example.com.
DKIM not configured
What it means
DKIM signing isn't enabled for your domain, so emails can't be cryptographically verified.
What to do
Enable DKIM in your email provider admin settings, then publish the DKIM TXT record(s) provided by your email provider. Find where to set up DKIM here.
DKIM configuration issue (invalid or incomplete)
What it means
DKIM records exist, but they look incomplete or invalid, so DKIM verification may fail.
What to do
Confirm the record is published at the correct hostname (selector)
Make sure the value wasn't truncated or split incorrectly
Re-copy the DKIM record from your email provider and publish it again if needed
DMARC issues
DMARC is a TXT record published at: _dmarc.example.com.
Before you start:
DMARC not configured
What it means
Your domain has no DMARC record. Inbox providers have less guidance on what to do when SPF or DKIM fail, and your domain has less protection against spoofing.
What to do
Publish a DMARC TXT record at _dmarc.yourdomain.com based on your provider's documentation.
Multiple DMARC records detected
What it means
DMARC must be published as a single record at _dmarc. Multiple records can cause inbox providers to ignore DMARC.
What to do
Keep one DMARC record and remove duplicates.
DMARC record misconfigured (invalid format or missing policy)
What it means
Your DMARC record is present, but the format is invalid or it's missing a valid p= policy.
What to do
Fix the record format and ensure it includes a valid p= value (none, quarantine, or reject).
DMARC policy set to "none" (monitoring only)
What it means
Your DMARC policy is set to p=none, which is valid but monitoring-only. It doesn't enforce protection, and may provide weaker trust signals than an enforced policy.
What to do
Once SPF and DKIM are stable, consider enforcing DMARC (p=quarantine or p=reject) based on your internal email policy.
Redirect issues
Hunter checks that your domain's redirect is reachable and working. These warnings appear when the domain itself can't be reached — which means any redirect you've configured in your hosting panel can't fire.
Domain not reachable
What it means
DNS doesn't know where this domain lives, so browsers (and Hunter) can't reach it. If you've set up a redirect in your hosting control panel, it won't fire until DNS points somewhere — the redirect rule is never triggered because traffic can't reach your web server in the first place.
Common misconception: setting up a redirect in your hosting control panel is not the same as setting up DNS. Both are needed. A redirect rule alone, without a DNS record pointing to your server, is never triggered.
What to do
Add a DNS record at your DNS host — usually the same place where you registered the domain (GoDaddy, Namecheap, Cloudflare, Bluehost, etc.), in the DNS or Zone Editor section. You do not fix this in Hunter or in your hosting panel's "Redirects" page.
Add either a CNAME or an A record:
CNAME (preferred for subdomains like
support.example.com) — points the subdomain to another domain name. Name/Host: the subdomain part (e.g.support). Value/Target: the apex domain (e.g.example.com.). Note: CNAMEs cannot be used on the apex domain itself.A record (required for the apex domain) — points directly to an IPv4 address. Name/Host: the subdomain part or
@for the apex. Value: the IPv4 address of your server.
After saving, DNS propagation usually takes a few minutes, occasionally up to a couple of hours. You can check with dnschecker.org. Once propagated, your redirect will start working and Hunter's warning will disappear on the next check.
After you apply changes
DNS updates can take time (often minutes, sometimes up to 24–48 hours). Once you've updated your DNS, verify that everything is published correctly: Verify SPF, DKIM, and DMARC records (and fix common DNS mistakes)