Push vs Fetch Email on a Phone: Which One to Use

Somewhere in your phone's mail settings there is a screen listing every connected account with a delivery choice next to each: Push, Fetch every 15 minutes, Fetch every 30 minutes, Hourly, Manual. Some accounts have Push available. Some show it greyed out. On Android, the toggle might not appear at all — the Gmail app handles delivery its own way and Outlook another. Meanwhile a couple of emails still take four minutes to land while others buzz your wrist the instant they leave the sender.

That confusion has one root cause: "push" and "fetch" describe two different ways your phone gets told about new mail, and most guides skip the part where a mail app or provider quietly downgrades you from one to the other. This post explains both, tells you which to pick per account, and — importantly — explains why the Push toggle sometimes doesn't do anything at all. The battery arithmetic is covered in the sibling post on sync intervals; here we focus on the choice.

The verdict up front#

Use push where the account has real push available and the mail is time-sensitive. Use scheduled fetch (or manual) for quiet accounts, older phones, and situations where you would rather not be notified every few seconds. For most people the right setup is a mix: real push on your primary account, hourly or manual fetch on personal noise, newsletters routed away from either.

The choice feels harder than it should because push on a phone is not one thing. Real push means the mail server can reach through Apple's or Google's push service — APNs or FCM — and wake your device on delivery. Fake push, which is common, means your mail app shows the Push toggle but silently uses scheduled fetch underneath because the account has no relay. IMAP-only accounts on iOS Mail usually fall into that bucket, which is why toggling Push on a Fastmail or hosted-domain address often changes nothing.

One dimension where fetch is honestly better: battery life on a phone that already struggles to make it to evening. A device that polls once an hour wakes its radio less often than one holding open connections and receiving push wake-ups on every marketing email, and on a two-year-old phone that difference is measurable. If push is not solving a real problem for you, fetch is not the primitive setting — it is the appropriate one.

Push vs fetch at a glance#

The two architectures differ on every axis that matters — latency, battery, data, what happens when the app is closed. Read the first row as cause, and the rest as consequences.

How push actually works: IMAP IDLE, APNs, and FCM#

"Push" on a phone is not one mechanism — it is at least three, stacked. The lowest layer is how the mail server tells someone that new mail arrived. The middle layer is a relay that turns that server event into an OS-level push. The top layer is the phone's push service (APNs on iOS, FCM on Android) that actually delivers a wake-up to your device.

The mail-server layer for IMAP accounts is IMAP IDLE, defined in RFC 2177. A client opens an IMAP connection, selects a folder, and issues the IDLE command. The server holds that connection open and streams a small update whenever new mail arrives or a message changes. On a desktop client running all day, IDLE is how a new mail sound plays the moment mail lands. It works well when both sides can keep a TCP connection alive for tens of minutes.

The problem on a phone is that keeping a TCP connection alive is exactly what mobile operating systems try to prevent. iOS suspends background apps within seconds of you switching away. Android's Doze mode moves the device into low-power sleep and terminates persistent network sockets. The phone itself cannot hold an IMAP IDLE connection for long — the OS will kill it to save battery. Something else has to hold the connection, and that something is a server-side relay.

That is what APNs (Apple Push Notification service) and FCM (Firebase Cloud Messaging, formerly GCM) are for. Both are OS-level push systems: a single persistent connection between the phone and Apple's or Google's data centre, shared by every app on the device. Providers with a push implementation run servers that hold IMAP IDLE (or a proprietary equivalent) on your behalf, and forward each new-mail event through APNs or FCM. Your phone wakes, the mail app is notified, it fetches the new headers, and a banner appears. The phone held one connection to APNs or FCM, not the mail connection itself — which is what makes push cheap in battery terms.

Gmail and Outlook do not use IMAP IDLE at all. Gmail's mobile apps get push through Google's proprietary channel over FCM. Outlook on mobile uses Microsoft's cloud service, which maintains connections to Exchange Online, Gmail, Yahoo, and other providers on your behalf and pushes to APNs or FCM. That is why an Outlook-app IMAP account gets push and the same account added directly to iOS Mail may not — Microsoft is running the relay Apple did not.

How fetch works, and what "every 15 minutes" really means#

Fetch is the simpler side. Your mail app schedules itself to wake up at a set interval — 15 minutes, 30 minutes, hourly, or only when you open the app — and each time it wakes, it opens a short-lived connection to the mail server, asks for anything new since the last poll, downloads what it finds, and closes the connection. There is no persistent socket, no relay, no push service in the loop. The phone does all the initiation.

The number in "every 15 minutes" is a ceiling on latency, not a guarantee. If a message arrives one minute after your last poll, you see it in about fourteen minutes. If it arrives one minute before the next poll, you see it in one. On average, expect roughly half the interval as delivery delay. Manual fetch is honest about this — nothing happens until you open the app or pull to refresh, and that is the point.

Fetch is also where the OS gets strict about battery. On iOS, Background App Refresh gates whether the mail app can poll in the background at all — turn it off and only push (if the account supports it) and manual fetch remain. On Android, the fetch schedule interacts with Doze and App Standby: after a period of no interaction, the OS moves your mail app into a bucket that fires less often than the interval you set, so a nominal 15-minute poll on an idle phone may actually run every 30 or 60. That is not a bug — it is exactly what Doze is designed to do.

The upshot: a lower polling frequency does not always deliver the battery win people expect. Once you cross into hourly or manual, the OS is already suppressing the app, and setting fetch to 30 versus 60 minutes has a much smaller effect than setting push versus fetch at all.

Push vs fetch, seen as a decision fork#

Before we get into where each wins, it is worth stepping back and seeing the choice as a fork with real branches. Neither side is wrong; they answer different questions.

Where push wins#

Push is the right architecture whenever the answer to "how quickly do I need to know?" is "seconds." The obvious cases: on-call rotations, alerts from monitoring systems that only email, two-factor codes that expire in a few minutes, any inbox where a message's value decays sharply with time. Push turns a mail account into a pager, and for the people who need that, nothing else will do.

It also wins on the perception of a working inbox. A phone that buzzes as mail arrives feels responsive; a phone that surfaces eight messages at the top of the hour feels slow, even when the total delay was small. For customer-facing roles — support, sales, executives whose calendars turn on inbound requests — push is worth the moderate battery cost because it changes how quickly you can act on the mail that matters.

And on modern iPhones, push is genuinely efficient. APNs runs a single connection for the whole phone; adding another push-enabled account is a rounding error on the battery. Push's reputation for draining phones is largely inherited from an older era of clients that held their own persistent connections rather than routing through APNs — the wrong way to do push on iOS, and not how well-behaved apps do it now.

Where fetch wins#

Fetch is the right architecture when the mail is not urgent, when the account is noisy in a way that would be unpleasant to be notified about, or when battery is the resource that matters most. A newsletter address, a shopping account sending receipts and shipping updates, a project mailbox you check twice a day — none benefit from a wake-up per message, and hourly or manual fetch lets you choose when to pay attention.

Fetch also wins on older devices and constrained connections. A phone whose radio takes longer to acquire signal pays a bigger relative cost per wake-up, and reducing wake-ups helps. On a metered plan, hourly fetch downloads one poll per hour regardless of whether ten messages arrived or none; push generates a small burst per message. Neither is expensive on a modern plan, but on a strict cap the difference is real.

And fetch is honest. Set fetch to hourly and you get a promise: mail lands roughly on the hour and nothing before. That predictability is why people running deep-focus schedules deliberately choose 60-minute or manual fetch — the phone stops pretending an inbox needs immediate attention, which is what the inbox is not usually for anyway.

Why your IMAP account probably isn't getting real push#

This is the part most guides skip, and it is the single most common source of "push isn't working" complaints. If you add a third-party IMAP account — a mailbox at your own domain, a small hosted-mail provider, a work IMAP address — to iOS Mail and turn Push on, in most cases nothing happens. The Push toggle stays green. Delivery falls back to fetch on whatever interval you set. Nothing in the interface tells you.

The reason is the relay. iOS Mail natively supports push for iCloud (Apple runs the relay), Yahoo (Yahoo runs a compatible relay), and a small number of other providers with an APNs deal in place. Everything else defaults to fetch under a Push label. Fastmail, for example, documents that their accounts use fetch on iOS Mail and directs users to the Fastmail app or third-party clients that ship their own push implementation.

Android is a slightly different story. Gmail is push-only on the Gmail app because Google runs its own channel to your phone. Outlook is push on the Outlook app because Microsoft's cloud is holding the connection. A third-party IMAP account added to Gmail or Outlook on Android may still be fetched — the app may or may not run a push relay for non-native providers, and both have quietly changed this across versions. When in doubt, send yourself a test message, walk away for a minute, and see whether the phone buzzes before your next scheduled fetch would have run.

The honest way to think about it: on a phone, push is a feature the provider or the app has to build. It is not something IMAP alone gives you. If your provider does not run a mobile push relay and your app does not run one on your behalf, IMAP IDLE cannot bridge the gap by itself — the operating system will not let it.

What providers actually offer (verify on the vendor page)#

Push on a phone is packaged very differently by provider, and the shape matters more than the price. Some bundle push with their own app, some publish an API a third-party client can hook into, some do not offer mobile push at all. Because this page is not going to print numbers that will be stale by the time you read it, use the shapes below as a map and check current pricing and feature pages on each vendor's own site before deciding.

The pattern is that push is bundled with the provider's own mobile app in almost every case. If push matters to you, the fastest path to real push is the mobile app the provider ships. If you would rather use a third-party client, the honest question to ask its docs is not "does it support push" — every client does in the abstract — but "does it support push for my provider," which is what separates a working setup from a Push toggle that means nothing.

The pricing shape to watch for is usage-metered API push. Google Workspace's Gmail API pub/sub push, for example, is billed by message volume, and third-party clients that use it will pass that cost on somewhere — through their own subscription or a limit on how many mailboxes push covers. Check the current numbers on the vendor page before assuming a plan covers a whole team.

Who each is genuinely for#

Push, real push, is for people whose mail is time-sensitive by nature. On-call engineers, customer-support leads at a company small enough that email is the escalation path, executives whose calendars turn on inbound requests, salespeople whose response time is a competitive dimension, anyone who receives one-time codes by mail. If a two-minute delay changes what happens next, use push.

Fetch — deliberate fetch, hourly or manual — is for the opposite pattern. Heads-down work where interruptions cost more than the mail is worth. A quiet inbox that mostly receives receipts and calendar invites. An older phone whose battery is already the limiting factor. A traveller on a metered data plan. A person who has decided email is a place they check, not a place that checks them. All are legitimate reasons to leave push off, and none require the mail app to change.

In the middle sit most people, and the honest answer is a mix. Push on the account where response time matters. Hourly or manual on everything else. If your mail app supports per-account settings — most do — use them; a global choice is almost never right when accounts do different jobs.

A third position: what your mail client can do about it#

Push vs fetch is a choice about the delivery pipe, not about the mail client on your phone. But a good client sits on top of that pipe and does two things the pipe alone cannot: it decides which wake-ups deserve your attention, and it batches everything else without dropping it. That is where AI Emaily fits — not as a replacement for push or fetch, but as the triage layer between whatever delivery your provider offers and the notifications that actually reach you. We build AI Emaily.

Concretely: AI Emaily uses whatever the underlying provider supports for push — Gmail's proprietary channel, Microsoft's cloud relay for Outlook, native APNs for iCloud, IMAP IDLE where a provider or its app supports it. On our web and iOS apps we pass push through to the device the standard way. On Android we ship as a PWA, so notifications go through the browser's push channel rather than a native FCM implementation of our own — a real limit compared with the Gmail and Outlook Android apps, worth stating plainly rather than glossing over.

What AI Emaily adds on top of delivery is the choice of what to be notified about. The agent triages new mail as it arrives: real replies get pushed through, cold outreach and marketing land silently in a separate bucket, follow-ups you owe come back to the top when you asked to see them. In Copilot mode nothing sends without your approval, so notifications are always about mail arriving, not actions being taken on your behalf. If push on your account is real and constant, this is the difference between a phone that buzzes six useful times a day and one that buzzes forty. If push is not real and you are on fetch, the triage happens the moment you open the app — which is the moment you were going to look anyway.

You can try it on a 7-day free trial of Pro or Autopilot — card required, $0 if you cancel before day 7 — at aiemaily.com/pricing, or start from the homepage at aiemaily.com. Where a native Android mail client is what you need, use the Gmail or Outlook app; where push is not the missing piece and triage is, that is where we fit.