Warming up
DNS is not a thing you configure once. Warmerly re-checks every sending domain's SPF, DKIM, DMARC, MX and TLS daily, turns the result into a health score, and names the record that broke.
Authentication breaks at the domain level, but you send from mailboxes — and a workspace with twenty mailboxes across six domains has six independent failure modes. Every mailbox page carries its own live SPF, DKIM, DMARC and MX result, so a broken DKIM selector on one domain is visible next to the mailboxes it is silently damaging rather than buried in a workspace-level summary.
The health score out of 100 is not a mood ring. It is assembled from authentication status, measured spam placement, bounce rate and delivery outcomes over a rolling window — and every component is visible underneath it. When the number falls, the page tells you which input moved, which is the difference between a metric and an alert.
A monitor that reports 'DKIM: none' has told you nothing you can act on at 9pm. Warmerly says which selector it looked for, why the lookup came back empty, and what to put where — with host-specific guides for Cloudflare, GoDaddy, Namecheap and IONOS, because the field names differ everywhere and that is where people give up.
Roughly six in ten junk-folder cases start with authentication, and almost none of them start on the day the record was written. They start weeks later, when a DNS migration drops a TXT record, a provider rotates a DKIM selector, or an SPF chain quietly crosses the ten-lookup limit. Warmerly re-checks the whole set every day so the gap between 'it broke' and 'you knew' is measured in hours.
SPF is a list, published in DNS, of the servers permitted to send mail using your domain in the envelope sender. It answers one question: was this message handed over by a server you authorised? It says nothing about whether the message was altered in transit, and it breaks the moment mail is forwarded.
DKIM is a cryptographic signature applied by the sending server and verified against a public key published in DNS. It answers a different question: has this message been tampered with since it was signed, and does the signing domain vouch for it? Unlike SPF it survives forwarding, which is why it carries more weight.
DMARC binds the two to the domain a human actually sees in the From header, and tells receivers what to do when neither aligns: nothing (p=none), quarantine, or reject. A DMARC record at p=none is a monitoring instruction, not a protection — it is the correct place to start and the wrong place to stay.
Gmail and Yahoo now require SPF, DKIM and DMARC for bulk senders outright. A domain missing any of the three is not merely disadvantaged; for high-volume sending it is out of policy.
Every deliverability tool on the market can check a domain once. The problem is that the failure mode is drift, and drift is invisible by definition. Consider the ways a correctly configured domain stops being correctly configured without anyone touching the email settings:
None of these produce an error anywhere you are looking. Your mail keeps sending. It just stops landing. The first symptom is usually a reply rate that fell two weeks ago, and by then you have burned a fortnight of campaign volume against a broken configuration.
This one deserves calling out because it is the most common self-inflicted failure and the least understood. An SPF record may trigger at most ten DNS lookups during evaluation. Every include, a, mx, ptr and exists mechanism costs at least one, and an include can cost several because it pulls in a record that has includes of its own.
Exceed ten and the result is not a warning — it is a permanent error, and a permanent error means SPF does not pass at all. A domain that had working SPF yesterday can have no SPF today because somebody added a helpdesk tool to the chain. Warmerly counts the lookups on each check and flags the record before it tips over, rather than after.
The mailbox's health score drops, the mailbox page shows the failing record with the specific reason — selector not found, syntax error, lookup limit exceeded, policy unenforced — and the workspace overview surfaces a banner counting how many mailboxes are affected. If the failure is severe enough to make sending actively harmful, the mailbox's daily allowance narrows rather than continuing at full volume into a filter.
That last behaviour is deliberate and occasionally unwelcome. A monitor that watches a domain fall over while still handing it full sending volume is optimising for your throughput this week at the cost of your domain's reputation for the next six months. Warmerly makes the other trade.
Opportunistic TLS between mail servers is close to universal now, and a sending host that cannot negotiate it stands out. Warmerly checks that the connection to your sending host can be secured, and separately publishes MTA-STS policy for its own hosted domains so receivers are told to require TLS rather than fall back silently.
One deliberate exception exists: Warmerly's own IMAP and SMTP clients do not reject unverified certificates when connecting to your mailbox host. Shared-certificate mail hosts are extremely common at the small-business end of the market, and refusing them would have broken warmup for a large fraction of legitimate users without making anyone meaningfully safer. It is a considered trade, documented rather than hidden.
Daily, for every sending domain in the workspace, plus on demand whenever you open a mailbox and ask for a re-check. Results are timestamped so you can see exactly how fresh the answer is.
Start at p=none to see what is failing, then move to p=quarantine once your legitimate senders align. p=reject is stronger still but unforgiving of any sending service you forgot about. Warmerly's own domains sit at p=quarantine.
Usually the ten-lookup limit. Many checkers report the record's syntax as valid without evaluating how many DNS lookups it triggers at verification time. Once the chain exceeds ten, SPF returns a permanent error — valid syntax, failed evaluation.
A separate sending domain — not a subdomain of your primary — is the safer pattern, because reputation damage stays off the domain your invoices and support mail come from. Warmerly can host and pre-authenticate those domains for you.
For domains Warmerly hosts, the records are created and maintained for you. For domains you own elsewhere, it tells you the exact record to publish and where, with per-host guides — but it does not hold write access to your DNS.
The free checker runs a live DNS lookup on SPF, DKIM, DMARC and MX in about two seconds. No account, nothing stored.