How to set up email forwarding without breaking deliverability

Forwarding a business address to a personal inbox is one of the most common things a small business does with a domain, and one of the easiest to get quietly wrong.

The one thing to understand first

Forwarding breaks SPF by construction. SPF is an authorisation list: it names the servers allowed to send mail for your domain. A forwarder receives your message and re-sends it from its own servers, so the server the final receiver sees is not on your list — even though nothing about the message is wrong.

DKIM is why some forwarded mail still arrives. The signature travels inside the message, so it survives a clean relay untouched. DMARC judges the pair against the From: domain, and forwarded mail usually fails SPF alignment while passing on DKIM.

That is the mechanism behind "mail I send to one person arrives, and the same mail through a list does not". The records did not change; the path did.

The three ways to do it, and what each one is

The third is the one that is worth the setup. If the address is on a business card and customers write to it expecting a reply, it is a mailbox, and it should behave like one.

Setting it up

1. Get the records in place first. When a domain is registered here, the

provisioning pipeline publishes SPF, MX and DMARC alongside the zone, the nameservers and the certificate. Mail authenticates from the first message without anyone editing a zone file.

1. Decide what the address is. A contact point, or somebody's working

inbox? The answer decides between forwarding and hosting.

1. Forward, if you forward. Point the alias at the destination inside the

mail service, and expect the SPF caveat above — a forwarded message arrives because of DKIM, not because of SPF.

1. If you host the mailbox, use it from the domain. Send from the

address, not to it. A reply that comes from the personal address looks like a different sender to every filter.

1. Do not hand-edit the platform's records. They are maintained for you,

so a hand-added duplicate is not a tweak but a conflict: two SPF or two DMARC records at the same name are ambiguous to receivers and to us. If you need a record the platform did not publish, add it beside the existing ones rather than over them.

1. Check the first message. Send one from outside, and read it as a

stranger would: the SPF and DMARC results in the message headers are the proof that these records are right. DKIM in those headers describes the original sender, not our records.

What the records look like

When a domain is registered here, these three are written into its zone, with your domain in place of yourbrand.com:

text
; SPF — the servers allowed to send for the domain
yourbrand.com.             TXT  "v=spf1 include:_spf.zeso.net ~all"
; MX — where mail for the domain is delivered
yourbrand.com.             MX   10 mx1.zeso.net
yourbrand.com.             MX   20 mx2.zeso.net
; DMARC — what a receiver should do when the checks disagree
_dmarc.yourbrand.com.      TXT  "v=DMARC1; p=none; rua=mailto:dmarc@zeso.net"

Three records, and no DKIM. The keypair belongs to the mail service, so no DKIM record is written here — one invented from anything else would not fail loudly, it would silently break signing.

This platform forwards mail and does not host mailboxes yet. A domain registered here gets unlimited aliases and a catch-all pointed at an inbox you already use.

Reading the records back

The zone is the record of what was published, and dig reads it:

bash
$ dig +short yourbrand.com MX
10 mx1.zeso.net.
20 mx2.zeso.net.

$ dig +short yourbrand.com TXT
"v=spf1 include:_spf.zeso.net ~all"

$ dig +short _dmarc.yourbrand.com TXT
"v=DMARC1; p=none; rua=mailto:dmarc@zeso.net"

An empty answer for the TXT record means the SPF is not there yet, and an SPF that is there but does not include this platform's host is a record that will fail for every message you send.