Email on Your Own Domain: Forwarding vs a Mailbox, and What Forwarding Breaks

“Free email on your own domain” describes at least three different products, and they are not interchangeable. The one that looks most attractive — forward [email protected] to your existing inbox — has a documented technical defect that a real mailbox does not.

Understanding why is the difference between a setup that works and one that silently fails for a fraction of senders.

Three products wearing one description

Product	What it is	Can you send as [email protected]?
Forwarding / routing	Inbound mail relayed to another address	No — outbound is a separate product
Free hosted mailbox	A real mailbox with storage and a web client	Yes
Paid mailbox (per-user)	A full email account, usually with a suite	Yes

The forwarder is a routing rule. It has no mailbox, no storage, and no outbound path.

That last point is worth being precise about, because the platform that popularised free domain forwarding has since split the products: routing handles inbound, and sending is a distinct service. If you read “email on your domain” as including the ability to reply from that address, check which product you are actually enabling.

What forwarding does to SPF

This is the core of it, and the mechanism is documented in the SPF specification.

“Because SPF evaluation is based on the IP address of the ‘last’ sending SMTP server… the SPF evaluation will fail unless mitigations such as those described in Appendix D are used.”

Read the shape of that sentence. SPF does not ask “was this message authorised by the domain in the From header?” It asks “is the server that just handed me this message allowed to send for that domain?” That is a property of the last hop, not of the original author.

So the sequence is:

1. A sender at bank.example sends you a message. SPF passes at the first hop.
2. The message arrives at your domain’s mail server and is forwarded to your personal Gmail.
3. Gmail evaluates SPF on the message it received — and the last sending server is now your forwarding host, not bank.example.
4. yourdomain.com’s SPF record does not authorise bank.example’s messages, so the check fails.

Nothing is misconfigured. Forwarding is, from SPF’s point of view, indistinguishable from a relay that should not be trusted.

The DMARC specification states the consequence for the broader picture with unusual directness: “Transiting a Mediator often causes either the authentication to fail or Identifier Alignment to be lost.”

The part most articles get wrong: DKIM usually survives

Here is the correction worth knowing, because the common claim that “forwarding breaks authentication” is too broad.

DKIM signs a portion of the message and attaches a signature. It is validated against a key published in DNS — not against the sending IP address. A forwarder that relays the message without modifying the signed headers or body does not break that signature.

So the realistic outcome of forwarded mail is:

Check	After forwarding, typically
SPF	Fails — the last-hop IP changed
DKIM	Often still passes — not IP-based
DMARC	Passes if DKIM passed and the domain aligned

Which is why forwarded mail does not all end up in spam. It ends up in spam when the forwarder modifies the message — adding a footer, a subject tag, a list header — and invalidates the signature, leaving SPF as the only path, and SPF has already failed.

That reframes the practical advice: if you run a forwarder, do not rewrite the message. A helpful “Forwarded from…” footer is the thing that turns a passing DKIM into a failing one.

SRS, and the honest status of it

The documented mitigation for SPF breakage on forwarding is the Sender Rewriting Scheme, which rewrites the envelope sender so that the forwarded message appears to come from a domain that authorises the forwarding host.

Two things about SRS are worth stating plainly. It is the mechanism referenced by SPF’s own appendix on forwarding. And it is not standardised in any RFC — it exists as IETF drafts that were never published as standards-track documents. Implementations interoperate in practice, but “SRS is a standard” is not a claim you can support.

So when you evaluate a forwarding provider, “do you implement SRS, and do you rewrite the message?” are the two questions that decide whether your forwarded mail authenticates.

The documented limits, since you will hit one

If you use a platform’s routing feature, the operational limits are published and they are more specific than expected. For one provider: 200 routing rules per domain, 200 destination addresses per account, inbound messages up to 25 MiB with larger messages rejected, a maximum of 50 recipients per email, 16 KB of headers, 998 characters in the subject, and 30 domains per zone.

The 25 MiB ceiling is the one that bites. It is smaller than what most mailboxes accept, which means a message your destination inbox would have taken without complaint gets rejected at the routing layer — and the sender receives a bounce that mentions your domain.

There is also a documented interaction worth knowing before you enable routing on a domain with existing mail: the routing MX records may conflict with your existing provider’s records. You cannot have two sets of MX records for the same domain.

What the free mailbox actually includes

If you would rather have a real mailbox, the free tiers have documented shapes too, and the limits are not the ones people assume.

One widely used free tier documents up to 5 users, 5 GB per user, a single domain, 25 MB attachments, and web access — and states that IMAP/POP/Active Sync are not included, with those listed as paid features. It is also “available only in selected data centers.”

That IMAP exclusion is the substantive limitation. A mailbox you cannot reach over IMAP cannot be used from a desktop client, cannot be synced to a phone’s native mail app, and cannot be backed up with standard tooling. It is a webmail account, which is a fine product and not the same thing as what most people mean by “email hosting.”

Google Workspace no longer has a free tier of any kind — the free G Suite edition was discontinued and the documented path is a transition, with an opt-out only for non-commercial personal use. Anyone describing a “free Google Workspace” is describing a product that stopped existing.

How to choose

Three questions in order:

1. Do you need to send as the domain address, or only receive? Receive-only is a routing rule and costs nothing. If you need to reply from it, you need a mailbox or a sending service.
2. Will you read it in a client, or only in a browser? Check IMAP/POP explicitly. This is where free tiers diverge sharply.
3. How much of your inbound mail comes from senders with strict DMARC policies? The more it is, the more forwarding quality matters — and the more you should care whether the provider implements SRS and rewrites messages.

Forwarding is not a worse version of a mailbox. It is a different product with a documented failure mode, and choosing it deliberately is perfectly reasonable — as long as you know which messages it will fail to deliver, and why.