A small service business whose website we maintain asked a simple question: can the owner read the business mailbox in the Gmail app on her phone? The answer is yes, but the route most people reach for (forward everything to a personal Gmail address and reply with "Send mail as") would have lost mail in both directions. The reason sits in three DNS records that most small businesses never look at.
How the domain was set up
Mail and DNS were both at the hosting provider. Reading the records gave this picture:
| Record | State |
|---|---|
| MX | The hosting provider's mail servers |
| DKIM | Published by the provider, which signs all mail sent through its servers |
| SPF | None published |
| DMARC | v=DMARC1; p=reject; with no reporting address |
Briefly, what each one does:
- SPF lists the servers allowed to send mail for the domain.
- DKIM adds a cryptographic signature that proves a message came from an authorised system.
- DMARC tells receiving servers what to do with mail that passes neither check in a way that matches the From address.
p=rejectmeans refuse it outright: no spam folder, no bounce the sender will notice.
With no SPF record and p=reject, the only way a message from this domain gets delivered is a valid DKIM signature from the provider. Anything claiming to be from the domain that leaves through any other server is refused.
The right route: IMAP in the Gmail app
The Gmail app on Android and iOS can act as a client for a mailbox hosted elsewhere. In the app: profile picture, Add another account, Other, enter the address, choose Personal (IMAP), then the provider's IMAP and SMTP server settings. The username is the full email address.
The mail stays at the hosting provider. Replies go out through the provider's SMTP server, so they are DKIM-signed and pass DMARC. Nothing in DNS changes, it costs nothing and it can be undone in a minute. Use IMAP, not POP3: IMAP keeps mail on the server so it stays readable everywhere.
Two practical notes. The mailbox at the provider keeps filling, so check its quota, because a full mailbox bounces incoming mail. And Gmail's Archive behaves inconsistently on IMAP accounts, so Delete is the safer habit.
The wrong route, three times over
Forwarding to a personal Gmail address and replying with "Send mail as" fails for three separate reasons.
It is being switched off. Google is removing Gmailify, POP fetching and third-party "Send mail as". New setups have been restricted since early 2026, and existing ones stop working in January 2027. Google's own advice for mobile users is the IMAP route above.
Replies get rejected. If "Send mail as" sends through Google's servers, the message says it is from the business domain but carries no DKIM signature from that domain, and no SPF record authorises Google. Under p=reject it is refused. The owner believes she has answered an enquiry and the client never receives it.
Incoming mail gets lost. When the provider forwards a message to Gmail, the original sender's SPF no longer matches, because the provider's server is now the one delivering it. If the sender's own domain publishes p=reject, which is increasingly common, Gmail refuses the message. Enquiries disappear without a trace.
Two DNS fixes worth making
Neither blocks the Gmail question, but both are worth doing:
- Publish an SPF record. Take the current include value from the provider's own documentation, not from a forum post, since providers change those hosts. List every other system that sends as the domain as well.
- Add a reporting address to DMARC. Running
p=rejectwith norua=means legitimate mail can be refused and nobody is ever told. One extra tag, such asrua=mailto:dmarc@example.com, makes rejections visible within a day.
What we found on our own domains
pinuno.com.gh publishes p=reject too, and sends from its own server with a DKIM signature. Early in September 2026 we found that the server's own bounce messages were being refused. The mail server passed locally generated bounces around its DKIM signing step (Postfix's internal_mail_filter_classes was empty, which is the default), so they left unsigned. A bounce has an empty envelope sender, so SPF was checked against the server's HELO name, which does not align with pinuno.com.gh. With neither SPF nor DKIM aligned, the receiving mail service rejected every bounce under our own policy. Setting internal_mail_filter_classes = bounce fixed it; ordinary outbound mail was never affected.
The same reports showed the forwarding problem this post describes. A DMARC aggregate report covering 2 September listed one message from pinuno.com.gh that had been forwarded into Gmail. SPF failed, which is normal for a forward, but DKIM failed as well, because the forwarding hop had altered the message. DMARC failed, and Google delivered it only because it trusted the ARC chain the forwarder added. A receiver that does not evaluate ARC would have rejected it, and our own mail log said the message was sent.
Both came to light through aggregate reports, which is the case for the reporting address recommended above: without rua=, neither would have been visible from the sending side.
The application side: authenticate, and guard the test environment
The website's contact and enquiry forms send notification mail as the business domain. Under p=reject, those notifications only arrive if the application authenticates to the provider's SMTP server rather than handing mail to a local transport. We confirmed that it did, so the notifications are signed.
Checking that turned up a different problem. On the test environment the SMTP host variable was unset, there was no file transport and no local mail catcher, so the mailer fell back to the production SMTP configuration. A routine acceptance test of the enquiry form would have delivered to the owner's real inbox, looking exactly like a new client enquiry. A one-off override fixed that test run. The lasting fix belongs in the configuration, so the test environment cannot send real mail at all:
// config/web.php (Yii2)
if (YII_ENV_DEV && !getenv('SMTP_HOST')) {
$config['components']['mailer']['useFileTransport'] = true;
}Privacy is the deciding argument
This mailbox receives enquiries from clients, and with them personal data, some of it sensitive. A free consumer Gmail account comes with no data processing agreement. Google Workspace does offer one. So the IMAP route, where Gmail is only a viewer on the provider's mailbox, or a proper Workspace subscription, are both defensible. Forwarding into a personal account is not.
If the owner ever wants the full Gmail experience, Workspace Business Starter is priced per user per month, with a lower rate on an annual plan; check Google's current pricing for your country. Aliases are free, so a shared address like info@ can be an alias on one account and needs no second licence. One caveat: Google Vault, the retention and eDiscovery tool, is only in Business Plus.
The domain of our energy management product has exactly the setup described at the start of this post: p=reject, DKIM signed by the hosting provider, and no SPF record. When we recorded it in August 2026 it was working, because DMARC passes on either leg and DKIM is the leg that passes. What it lacks is a fallback: anything that breaks DKIM signing, such as a key rotation or a relay change, moves delivery from fine to rejected in one step, with no partial failure first. The same check taught us a method lesson. A DKIM selector cannot be listed; you have to know its name. Probing one generic selector found nothing and produced a confident report that DKIM was absent and mail undeliverable, wrong on both counts. Read the Authentication-Results header on a real message before believing an absence.
Another of our domains showed one more trap. Its hosting provider manages DMARC as an on/off toggle rather than an editable record. To publish your own record, with a reporting address, you have to switch the managed one off and add the custom record in the same save. Leave both in place and the domain publishes two DMARC records, which receivers are required to discard entirely: a silent drop to no policy at all.
Conclusion
Before changing how a business mailbox is read, read its SPF and DMARC records. With p=reject in place, any route that sends as the domain through someone else's servers will fail without anyone noticing, and IMAP in the Gmail app is the one that keeps both the authentication and the data where they belong.
If you would like your business's email, DNS records and website mail checked and set up properly, we can do that for you, or get in touch.