If your outbound email is arriving 15 minutes to several hours late — or your mail logs are full of 451 4.7.1 Greylisted, please try again later responses — you’re being greylisted. The good news: greylisting isn’t a blacklist, and it’s almost always fixable. The better news: the fix usually lives in your DNS.
What is greylisting?
Greylisting is an anti-spam technique used by receiving mail servers. The first time a server sees a new combination of three things — the sending IP address, the envelope sender, and the envelope recipient (the “triplet”) — it temporarily rejects the message with a 4xx SMTP response:
451 4.7.1 Greylisting in action, please come back later
A 4xx response is a temporary failure, not a bounce. Any properly configured mail server (Exim, Postfix, Microsoft 365, Google Workspace) queues the message and retries, usually within 5–30 minutes. When the retry arrives, the receiving server recognizes the triplet, accepts the message, and typically whitelists that combination for days or weeks afterward.
The logic is simple: legitimate mail servers retry. Most spam cannons and compromised botnet hosts fire once and move on. Greylisting filters out a surprising amount of junk at nearly zero cost — which is exactly why so many receiving servers still use it.
Why is my mail getting greylisted?
Greylisting decisions are increasingly reputation-based. Many modern implementations (Postgrey, greylistd, rspamd, commercial gateways) skip greylisting entirely for senders they trust — and aggressively greylist senders they don’t. If your mail is getting greylisted constantly, one or more of these is usually the reason:
1
Your sending IP has no reputation (or a bad one)
New IP addresses, recently reassigned cloud IPs, and IPs with prior spam history all get greylisted more aggressively. If you just moved your mail server, spun up a new VPS, or changed SMTP relay providers, expect greylisting until your IP builds a track record.
2
Missing or broken SPF
Many greylisting implementations check SPF before deciding. A sender that passes SPF is often exempted from greylisting entirely; a sender with no SPF record — or a failing one — gets the full delay treatment. If your SPF record doesn’t include every IP that sends mail for your domain, those “rogue” sources will be greylisted (and increasingly, rejected outright).
3
No DKIM signature
Like SPF, a valid DKIM signature signals that mail is authorized and traceable to your domain. Unsigned mail from an unknown IP is exactly the profile greylisting was designed to slow down.
4
Missing or mismatched reverse DNS (PTR record)
This is one of the most common culprits we see. Your sending IP needs a PTR record, and ideally:
- The PTR resolves to a hostname (e.g.,
mail.example.com) - That hostname resolves back to the same IP (forward-confirmed reverse DNS)
- Your mail server’s HELO/EHLO name matches that hostname
Generic PTR records like ec2-3-91-x-x.compute-1.amazonaws.com scream “not a real mail server” and trigger greylisting, scoring penalties, or outright rejection.
5
Sending from a dynamic or residential IP
Dynamic IP ranges are listed in policy blocklists like Spamhaus PBL. Mail from these ranges is greylisted at best and rejected at worst. If you’re running a mail server on a home or small-office connection, relay outbound mail through a smarthost with a clean static IP.
6
Your DMARC posture is weak or absent
DMARC itself isn’t usually a direct greylisting trigger, but reputation systems weigh the whole picture. Domains with aligned SPF, valid DKIM, and a published DMARC policy get treated as established senders. Domains with none of the above get treated as suspects.
7
Inconsistent sending infrastructure
If your mail rotates through a large pool of outbound IPs (common with some ESPs and cloud relays), every new IP/sender/recipient triplet gets greylisted fresh. Retries may even come from a different IP in the pool, resetting the clock and turning a 15-minute delay into hours. Consistent sending IPs matter.
Is greylisting actually a problem?
A one-time 15-minute delay on first contact with a new recipient is usually harmless. Greylisting becomes a real problem when:
- Time-sensitive mail is delayed — password resets, one-time codes, order confirmations
- Your MTA retries too slowly (or gives up too soon) and the delay stretches to hours or turns into a bounce
- You’re greylisted on nearly every delivery, a symptom that your sender reputation and DNS are in poor shape
Treat persistent greylisting as an early warning. The major mailbox providers have been tightening sender requirements since 2024, and the same signals causing greylisting today will cause hard rejections at Gmail and Microsoft tomorrow. The checklist below keeps you compliant with them, too.
How to fix (and prevent) greylisting
Work through this checklist. Every item is a DNS or mail server configuration task:
- Publish a correct SPF record. One TXT record at your domain root listing every legitimate sending source, ending in
~allor-all. Keep it under 10 DNS lookups. - Sign all outbound mail with DKIM. Use 2048-bit keys, publish the public key in DNS, and verify signatures survive your full delivery path (including any forwarding).
- Publish a DMARC record. Start at
p=nonewith aggregate reporting (rua=) so you can see who’s sending as your domain, then move top=quarantineorp=rejectonce your legitimate sources are aligned. - Fix your reverse DNS. Set a PTR record on your sending IP that matches your mail server’s HELO name, with matching forward resolution. On cloud providers this is set in their console; on business ISP service, ask your ISP.
- Verify your MTA retry schedule. Retries should begin within 5–15 minutes of a 4xx response. Exim and Postfix defaults are fine; some API-based senders and homegrown scripts don’t retry at all — those messages simply vanish.
- Check your IP against blocklists. Spamhaus (ZEN/PBL), Barracuda, and SpamCop are the ones that matter most. Delist and fix root causes before ramping volume.
- Warm up new IPs gradually. Start with low volume to trusted recipients and ramp over 2–4 weeks.
- Keep sending IPs consistent. Avoid large rotating pools for transactional mail where possible.
Greylisting vs. blacklisting at a glance
| Greylisting | Blacklisting | |
|---|---|---|
| SMTP response | 4xx temporary failure (“try again later”) | 5xx permanent rejection (bounce) |
| Cause | Unknown sender triplet, weak reputation | IP/domain listed on a blocklist (DNSBL) |
| Impact | Delay of minutes on first contact | Mail not delivered at all |
| Fix | SPF/DKIM/DMARC, PTR, retry schedule | Delisting request + fix the root cause |
Check your domain right now
Most greylisting problems are visible from the outside — missing SPF, broken DKIM records, no DMARC, mismatched PTR. You can check all of it in about ten seconds. Our free DNS Scanner runs 135 DNS and email deliverability checks and grades your domain A through F, including the exact SPF, DKIM, DMARC, and reverse DNS issues that trigger greylisting.
If the scan turns up gaps, CloudFloorDNS can help you close them. We’ve been running authoritative DNS for over 25 years, and because we host your zone, fixing email authentication is a first-class operation — not a support ticket to a registrar. Our managed DNS platform handles SPF, DKIM, and DMARC records with the reliability your mail flow depends on, and our monitoring keeps watching after you’ve fixed it.
Scan Your Domain Free →
Talk to a DNS Expert
Frequently asked questions
Is greylisting the same as being blacklisted?
No. Greylisting is a temporary delay applied to unknown senders; blacklisting is a rejection based on your IP or domain appearing on a blocklist. Persistent greylisting is often an early symptom of the reputation problems that lead to blacklisting.
How long do greylisting delays last?
Typically 5–30 minutes on first contact with a recipient, then the sender/recipient pair is remembered and future mail flows immediately. Delays of hours indicate a retry-schedule problem or a rotating IP pool on your side.
Can I ask a recipient to whitelist me?
Yes — recipients can whitelist your sending IP or domain in their gateway, which bypasses greylisting entirely. But fixing your SPF, DKIM, DMARC, and PTR records fixes it for every recipient, not just one.
Does Google or Microsoft greylist?
The major providers use reputation-based throttling and deferrals that behave similarly — new or poorly authenticated senders see 4xx deferrals (e.g., Gmail’s 421-4.7.28). The same authentication checklist above resolves those, too.