Forwarding breaks SPF by design, which is why forwarded mail occasionally lands in spam. When a message is forwarded, it arrives at your inbox from the forwarding server rather than the original sender's — so an SPF check fails. Modern forwarding services work around this with SRS and by relying on DKIM, which survives forwarding. Mostly this is invisible. When it isn't, the fix is usually on your side, not theirs.
The three records, briefly
- SPF lists which servers are allowed to send mail for a domain. The receiving server checks whether the message came from one of them.
- DKIM attaches a cryptographic signature to the message itself, which the receiver verifies against a key published in DNS.
- DMARC ties the two together: it tells receivers what to do when SPF and DKIM disagree with the visible From address, and where to send reports.
Why forwarding strains SPF specifically
SPF authenticates the sending server. A retailer sends to shop@yourdomain.com from their approved server — that passes. Your alias service then forwards it to your real inbox, and now the message reaches Gmail from the alias service's server, which is not on the retailer's SPF list.
From Gmail's point of view, a server not authorised for that domain has just delivered mail claiming to be from it. SPF fails. That's not a misconfiguration; it's inherent to what forwarding does.
What services do about it
SRS (Sender Rewriting Scheme) rewrites the envelope sender so the forwarding server takes responsibility for the message, which lets SPF pass again in a way that reflects reality.
DKIM survives forwarding, because the signature is on the message rather than the connection — as long as nothing modifies the content. That's the main reason forwarded mail usually authenticates fine: DMARC is satisfied by DKIM alone.
Where it breaks: services that alter the message in transit — appending footers, rewriting links, stripping trackers — invalidate the DKIM signature. Then SPF has already failed and DKIM has been broken, and DMARC has nothing left to pass on.
What you can actually control
SPF, DKIM and DMARC for the mail you receive are published by the sender's domain. You can't change them, and neither can your alias service.
What you control: the DNS records on your own domain, your forwarding destination, and your inbox's filter behaviour. That's where any fix will be.
On your own domain
If you run aliases on a domain you own, set the records your alias service tells you to — MX to route inbound mail, and SPF/DKIM/DMARC as instructed. Any competent service walks you through this during setup, and a missing MX record is the single most common cause of "my aliases aren't receiving anything at all."
In your inbox
If forwarded mail lands in spam, mark it not-spam and add the forwarding source to safe senders. Providers learn quickly, and this resolves most cases within days.
Common symptoms
| Symptom | Usual cause |
|---|---|
| No mail arriving at any alias | MX records missing or wrong on your domain |
| Some forwarded mail in spam | SPF failure on forward; train the filter, add to safe senders |
| Mail from one sender always in spam | That sender has a strict DMARC policy and something is breaking DKIM |
| Mail stopped after a DNS change | You edited or removed a record the alias service needs |
| Mail stopped entirely, everywhere | Check the domain hasn't expired |
Does this argue against aliases?
No — this is how essentially all mail forwarding has always worked, including the plain forwarding built into every mail provider. It's a well-understood problem with well-established mitigations, and in day-to-day use it's invisible.
It's worth understanding for two reasons: so you know where to look when something misbehaves, and so a "your forwarded mail might go to spam" objection doesn't sound like a fundamental flaw when it's a manageable operational detail.