Skip to content

My Domain Shows "Pending" — DNS Propagation Explained

You published your SPF/DKIM/DMARC records but AcelleMail still shows the domain as Pending. That's almost always normal DNS propagation. Here's what's happening and exactly what to do.

What this is for

You added your SPF, DKIM, and DMARC records at your DNS host, came back to AcelleMail, and the domain still shows Pending instead of Verified. Nine times out of ten this is normal DNS propagation, not a mistake. This article explains what's happening and exactly what to do — without sending you to a terminal.

Why it's not instant

When you save a DNS record, it doesn't appear everywhere at once. DNS is cached around the internet, and each record has a "time to live" (TTL) that controls how long resolvers hold the old answer before fetching the new one. Until those caches refresh, a checker — including AcelleMail's Verify — may still see "no record yet."

That's the whole story. You don't need to understand DNSSEC or routing to fix a Pending domain; you need to know how long to wait and how to tell a delay from a real error.

What to do

  1. Wait, then re-check. Most records propagate in 5-60 minutes. Give it an hour, then in AcelleMail open the sending domain and click Verify again. A lot of "it's broken!" is just checking too soon.
  2. Still Pending after a few hours? Re-check after the longer window — propagation can occasionally take up to 24-48 hours, especially if your old records had a long TTL.
  3. Still Pending after 24 hours? Now it's worth suspecting a real mistake at your DNS host (see below) — propagation alone never takes that long.

Telling a delay from a real mistake

If a record genuinely won't verify after a day, it's almost always one of these at your DNS host — not propagation:

  • Wrong record type — e.g. an A record where a TXT or CNAME was needed.
  • The host/name field is off — many DNS panels auto-append your domain, so typing dkim._domainkey.example.com becomes dkim._domainkey.example.com.example.com. Use exactly what AcelleMail shows.
  • Extra quotes or line breaks — paste the record value exactly; some panels add their own quotes.
  • It didn't actually save — re-open the record in your DNS panel and confirm it's there as you entered it.

Fix the record, save, wait an hour, and click Verify again.

Common questions

Does a faster TTL make AcelleMail verify quicker? A lower TTL helps future changes propagate faster, but the first time you add a record there's nothing cached yet, so it's mostly down to your DNS host pushing the record out. Just wait and re-check.

The record looks right but still won't verify — what now? Confirm you put it on the exact domain AcelleMail is checking (the apex vs a subdomain catches people out), and that you didn't duplicate an existing SPF record — a domain may only have one SPF record, so multiple v=spf1 lines must be merged into one. See How to Set Up SPF, DKIM, and DMARC Records.

Related articles

12 comments

9 comments

  1. Marcus
    Easy win: set up dmarcian.com (free tier) to receive your DMARC RUA reports. The first 2 weeks of reports tell you everything you didn't know about who's sending as you
  2. Aisha
    Thanks for the explicit cautionary tales. The alignment-vs-pass distinction is exactly where I lost a week last year.
  3. Quân
    The SPF flattening explanation finally made it click for me. I'd been hitting the 10-lookup limit and didn't understand why nesting includes counted.
  4. Lucas
    quick question: do receivers actually enforce the spf -all hard fail, or do most just downrate? i've heard mixed things and i'm hesitant to switch from ~all...
    1. Admin
      Mixed things is about right, because the behaviour genuinely is mixed. Gmail and Outlook both treat SPF as one input to a larger score rather than a kill switch, so an SPF fail alone rarely bins the message on its own, especially when DKIM passes and aligns. Some smaller providers and corporate gateways do reject on -all outright. So the risk of -all isn't "everyone drops it", it's "a minority reject hard and you never find out which". In practice what matters more than -all vs ~all is your DMARC policy. If you're at p=reject, a fail gets rejected regardless of which SPF qualifier you used, because DMARC does the enforcing. If you're at p=none, -all buys you very little. What I'd do: stay on ~all until DMARC aggregate reports are clean for a couple of weeks with every legit sender accounted for, then tighten. Switching qualifiers before you can see your own forwarding paths and third party senders in the reports is how people take out their own transactional mail.
  5. Ravi
    if you use Vercel or Netlify for the apex, watch out — they sometimes override TXT records via their auto-DNS feature. Bit us once with a stripped SPF record.
  6. Emma
    Our DKIM rotation broke for 2 days because we updated the active selector first, then waited to delete the old. Should be the other way — publish new, wait 48h for cache, switch sending, THEN remove old.
  7. Rafael
    How do you handle DNS for clients in white-label setups? The customer would need to add records to their domain — is there a clean way to bulk-verify those?
    1. Admin
      No bulk verify yet, it's one Verify click per domain in the sending identity screen. If clients CNAME to a subdomain you control you own the records and only verify once.
  8. Olufemi
    Hit the 10-lookup SPF limit when we tried to layer SES on top of an existing Google Workspace setup. Flattened with a tool (spfwizard.com) and it's been fine since. That tool's worth a mention.
  9. Thuỳ
    Worth noting: our DNS provider (Cloudflare) caches negative responses for 1 hour. We added a TXT record, dig showed it, but mail-tester said missing for another 40 minutes. Almost lost our minds. TTL was set to 300 but the parent zone NS cache held.
    1. Admin
      This is the thing that trips up almost everyone: the record's own TTL only applies once the record exists in a resolver's cache. Before that, the NXDOMAIN/empty answer gets cached according to the SOA minimum, which Cloudflare sets to 3600. So a fresh TXT record is invisible to any resolver that already asked and got nothing, for up to an hour, no matter what you set the TTL to. Your dig showed it because you were almost certainly querying the authoritative nameserver directly. mail-tester goes through its own recursive resolver, which was still sitting on the negative answer. Quick way to tell the two apart: `dig TXT yourdomain @ns1.cloudflare.com` versus `dig TXT yourdomain @8.8.8.8`. If the first has it and the second doesn't, you're just waiting out the negative cache. I'll add a section on negative caching to the article, it's not in there and it should be.

More in DNS & Domain Setup